MicroStrategy Project Design Guide

Project Design Guide
Version: 8.1.1
Document Number: 09330811
Fourth Edition, September 2007, version 8.1.1
To ensure that you are using the documentation that corresponds to the software you are licensed to use, compare this version number
with the software version shown in “About MicroStrategy...” in the Help menu of your software.
Document number: 09330811
Copyright © 2007 by MicroStrategy Incorporated. All rights reserved.
If you have not executed a written or electronic agreement with MicroStrategy or any authorized MicroStrategy distributor, 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-2007 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, Inc. 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, Inc., 1861 International Drive, McLean, Virginia 22102. Rights are reserved under copyright
laws of the United States with respect to unpublished portions of the Software.
The following are either trademarks or registered trademarks of MicroStrategy Incorporated in the United States and certain other
countries:
MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition, MicroStrategy 7i Olap Services, MicroStrategy 8,
MicroStrategy Evaluation Edition, MicroStrategy Administrator, MicroStrategy Agent, MicroStrategy Architect, MicroStrategy BI Developer Kit,
MicroStrategy Broadcast Server, MicroStrategy Broadcaster, MicroStrategy Broadcaster Server, MicroStrategy Business Intelligence Platform,
MicroStrategy Consulting, MicroStrategy CRM Applications, MicroStrategy Customer Analyzer, MicroStrategy Desktop, MicroStrategy Desktop Analyst,
MicroStrategy Desktop Designer, MicroStrategy eCRM 7, MicroStrategy Education, MicroStrategy eTrainer, MicroStrategy Executive, MicroStrategy
Infocenter, MicroStrategy Intelligence Server, MicroStrategy Intelligence Server Universal Edition, MicroStrategy MDX Adapter, MicroStrategy Narrowcast
Server, MicroStrategy Objects, MicroStrategy OLAP Provider, MicroStrategy SDK, MicroStrategy Support, MicroStrategy Telecaster, MicroStrategy
Transactor, MicroStrategy Web, MicroStrategy Web Business Analyzer, MicroStrategy World, Alarm, Alarm.com, Alert.com, Angel, Angel.com,
Application Development and Sophisticated Analysis, Best In Business Intelligence, Centralized Application Management, Changing The Way
Government Looks At Information, DSSArchitect, DSS Broadcaster, DSS Broadcaster Server, DSS Office, DSSServer, DSS Subscriber, DSS Telecaster,
DSSWeb, eBroadcaster, eCaster, eStrategy, eTelecaster, Information Like Water, Insight Is Everything, Intelligence Through Every Phone, Your
Telephone Just Got Smarter, Intelligence To Every Decision Maker, Intelligent E-Business, IWAPU, Personal Intelligence Network, Personalized
Intelligence Portal, Query Tone, Quickstrike, Rapid Application Development, Strategy.com, Telepath, Telepath Intelligence, Telepath Intelligence (and
Design), MicroStrategy Intelligent Cubes, The E-Business Intelligence Platform, The Foundation For Intelligent E-Business, The Integrated Business
Intelligence Platform Built For The Enterprise, The Intelligence Company, The Platform For Intelligent E-Business, The Power Of Intelligent eBusiness,
The Power Of Intelligent E-Business, The Scalable Business Intelligence Platform Built For The Internet, Industrial-Strength Business Intelligence, Office
Intelligence, MicroStrategy Office, MicroStrategy Report Services, MicroStrategy Web MMT, MicroStrategy Web Services, Pixel Perfect, MicroStrategy
Mobile and MicroStrategy Integrity Manager are all registered trademarks or trademarks of MicroStrategy Incorporated.
All other products are trademarks of their respective holders. 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,501,832, 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,707,889, 6,741,980, 6,765,997, 6,768,788, 6,772,137, 6,788,768, 6,792,086, 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,888,929, 6,895,084, 6,940,953, 6,964,012, 6,977,992, 6,996,568, 6,996,569, 7,003,512,
7,010,518, 7,016,480, 7,020,251, 7,039,165, 7,082,422, 7,113,993, 7,127,403, 7,174,349, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181 and
7,272,212. Other patent applications are pending.
Various MicroStrategy products contain the copyrighted technology of third parties. This product may contain one or more of the following copyrighted
technologies:
Graph Generation Engine Copyright © 1998-2007. Three D Graphics, Inc. All rights reserved.
Actuate® Formula One. Copyright © 1993-2007 Actuate Corporation. All rights reserved.
XML parser Copyright © 2003-2007 Microsoft Corporation. All rights reserved.
Xalan XSLT processor. Copyright © 1999-2007. The Apache Software Foundation. All rights reserved.
Xerces XML parser. Copyright © 1999-2007. The Apache Software Foundation. All rights reserved.
FOP XSL formatting objects. Copyright © 2004-2007. The Apache Software Foundation. All rights reserved.
Portions of Intelligence Server memory management Copyright 1991-2006 Compuware Corporation. All rights reserved.
International Components for Unicode
Copyright © 1999-2007 Compaq Computer Corporation
Copyright © 1999-2007 Hewlett-Packard Company
Copyright © 1999-2007 IBM Corporation
Copyright © 1999-2007 Hummingbird Communications Ltd.
Copyright © 1999-2007 Silicon Graphics, Inc.
Copyright © 1999-2007 Sun Microsystems, Inc.
Copyright © 1999-2007 The Open Group
All rights reserved.
Real Player and RealJukebox are included under license from Real Networks, Inc. Copyright © 1999-2007. All rights reserved.
CONTENTS
Description of Guide ................................................................ xiii
About this book .............................................................................xv
How to find business scenarios and examples .......................xv
Prerequisites .......................................................................... xvi
Who should use this guide..................................................... xvi
Resources.................................................................................... xvi
Documentation....................................................................... xvi
Education ............................................................................. xxiii
Consulting ............................................................................ xxiii
International support ............................................................ xxiii
Technical Support ................................................................. xxv
Feedback .................................................................................... xxx
1. BI Architecture and
the MicroStrategy
Platform
Introduction.................................................................................. 1
Business intelligence architecture ................................................. 2
Source systems for data collection .......................................... 3
Extraction, transformation, and loading process...................... 4
Data warehouse for data storage and relational design .......... 5
The MicroStrategy platform ........................................................... 7
MicroStrategy metadata........................................................... 8
MicroStrategy Intelligence Server .......................................... 11
MicroStrategy Desktop........................................................... 11
MicroStrategy Web and Web Universal ................................. 13
MicroStrategy project ............................................................. 14
The project design process.......................................................... 15
© 2007 MicroStrategy, Inc.
v
Contents
2. The Logical Data
Model
Project Design Guide
Introduction................................................................................ 17
Facts: Business data and measurements.................................... 21
Attributes: Context for your levels of data.................................... 22
Attribute elements: Data level values..................................... 23
Attribute relationships ............................................................ 24
Hierarchies: Data relationship organization ................................. 25
Sample data model...................................................................... 26
Building a logical data model ....................................................... 26
User requirements ................................................................. 27
Existing source systems ........................................................ 28
Converting source data to analytical data.............................. 28
Logical data modeling conventions.............................................. 33
Unique identifiers ................................................................... 34
Cardinalities and ratios .......................................................... 35
Attribute forms ....................................................................... 36
3. Warehouse Structure
for Your Logical Data
Model
Introduction................................................................................ 39
Columns: Data identifiers and values .......................................... 41
Tables: Physical groupings of related data.................................. 41
Uniquely identifying data in tables with key structures........... 42
Lookup tables: Attribute storage ............................................ 43
Relate tables: A unique case for relating attributes ............... 45
Fact tables: Fact data and levels of aggregation ................... 46
Homogeneous versus heterogeneous column naming.......... 49
Schema types: Data retrieval performance versus redundant
storage......................................................................................... 51
Highly normalized schema: Minimal storage space............... 52
Moderately normalized schema: Balanced storage space
and query performance.......................................................... 54
Highly denormalized schema: Enhanced query
performance........................................................................... 56
Design trade-offs ......................................................................... 59
Schema type comparisons .......................................................... 60
4. Creating and
Configuring a Project
vi
Introduction................................................................................ 63
Project connectivity components ................................................. 64
MicroStrategy metadata......................................................... 64
Metadata shell ....................................................................... 65
Project source ........................................................................ 65
© 2007 MicroStrategy, Inc.
Project Design Guide
Contents
Database instance ................................................................. 67
Project.................................................................................... 67
Summary of project connectivity ............................................ 68
Creating a project ........................................................................ 68
Creating the metadata repository ................................................ 71
Connecting to the metadata repository and data source ............. 71
Connecting to the metadata repository .................................. 72
Connecting to a data source .................................................. 72
Creating the project ..................................................................... 73
Creating a test or prototype project using Project Builder...... 74
Creating a production project using Project Creation
Assistant ................................................................................ 75
Creating facts and attributes........................................................ 82
Configuring additional schema-level settings .............................. 83
Deploying your project and creating reports ................................ 84
5. The Building Blocks of Introduction................................................................................ 85
Business Data: Facts
Creating facts............................................................................... 87
Simultaneously creating multiple, simple facts ...................... 88
Creating and modifying simple and advanced facts .............. 91
The structure of facts ................................................................... 96
How facts are defined ................................................................. 97
Mapping physical columns to facts: Fact expressions ........... 98
Fact column names and data types: Column aliases ................ 105
Modifying the levels at which facts are reported: Level
extensions.................................................................................. 107
Defining a join on fact tables using table relations............... 110
Defining a join on fact tables using fact relations................. 114
Forcing facts to relate to attributes: Using cross
product joins ........................................................................ 116
Lowering the level of fact data: Fact degradations .............. 118
Disallowing the reporting of a fact at a certain level............. 122
6. The Context of Your
Business Data:
Attributes
Introduction.............................................................................. 125
Creating attributes ..................................................................... 129
Simultaneously creating multiple attributes.......................... 129
Adding and modifying attributes .......................................... 134
Unique sets of attribute information: Attribute elements ............ 140
© 2007 MicroStrategy, Inc.
vii
Contents
Project Design Guide
Column data descriptions and identifiers: Attribute forms ......... 143
Attribute form properties ...................................................... 146
Attribute form expressions ................................................... 147
Modifying attribute data types: Column aliases ................... 156
Attribute forms versus separate attributes ........................... 158
Attribute relationships ................................................................ 159
Viewing and editing the parents and children of
attributes .............................................................................. 161
Supporting many-to-many and joint child relationships ....... 163
Attributes that use the same lookup table: Attribute roles ......... 175
Specifying attribute roles ..................................................... 177
Attributes with more than one ID column: Compound
attributes .................................................................................... 183
Example: Creating compound attributes.............................. 184
Collections of attribute forms: Form groups............................... 186
Supporting compound attributes .......................................... 187
Displaying and organizing related forms.............................. 188
Using attributes to browse and report on data........................... 189
Setting how attribute forms are displayed by default ........... 191
7. Creating Hierarchies
to Organize and
Browse Attributes
Introduction.............................................................................. 193
Creating user hierarchies........................................................... 194
Types of hierarchies .................................................................. 196
System hierarchy: Project schema definition ....................... 197
User hierarchies: Logical business relationships ................. 197
Hierarchy organization............................................................... 198
Hierarchy structure............................................................... 199
Viewing hierarchies: Hierarchy Viewer ................................ 200
Configuring hierarchy display options........................................ 200
Controlling the display of attribute elements ........................ 201
Filtering attributes in a hierarchy.......................................... 203
Entry point............................................................................ 205
Hierarchy browsing .............................................................. 206
Using the Hierarchy Viewer and Table Viewer .......................... 211
Using the Hierarchy Viewer ................................................. 211
Using the Table Viewer........................................................ 213
8. Optimizing and
Maintaining Your
Project
viii
Introduction.............................................................................. 215
Updating your MicroStrategy project schema............................ 216
© 2007 MicroStrategy, Inc.
Project Design Guide
Contents
Data warehouse and project interaction: Warehouse
Catalog ...................................................................................... 218
What should I know before I use the Warehouse
Catalog? .............................................................................. 219
Accessing the Warehouse Catalog...................................... 219
Adding and removing tables for a project ............................ 220
Managing warehouse and project tables ............................. 221
Modifying data warehouse connection and operation
defaults ................................................................................ 226
Customizing catalog SQL statements.................................. 233
Troubleshooting table and column messages ..................... 239
Using summary tables to store data: Aggregate tables ............. 241
When to use aggregate tables............................................. 242
Determining the frequency of queries at a specific level...... 246
Considering any related parent-child relationships .............. 246
Compression ratio................................................................ 247
Creating aggregate tables ................................................... 248
The size of tables in a project: Logical table size................. 249
Dividing tables to increase performance: Partition mapping...... 250
Server versus application partitioning .................................. 250
Metadata partition mapping ................................................. 251
Warehouse partition mapping .............................................. 254
Metadata versus warehouse partition mapping ................... 255
9. Creating
Transformations to
Define Time-Based
and Other
Comparisons
Introduction.............................................................................. 257
Creating transformations ........................................................... 258
Expression-based versus table-based transformations ....... 259
Building a table-based transformation ................................. 260
Building an expression-based transformation...................... 261
Transformation components ...................................................... 263
Transformation metrics and joint child attributes ....................... 265
A. MicroStrategy Tutorial Introduction.............................................................................. 267
What is the MicroStrategy Tutorial?........................................... 267
MicroStrategy Tutorial data model............................................. 271
Geography hierarchy ........................................................... 272
Products hierarchy ............................................................... 274
Customers hierarchy............................................................ 276
Time hierarchy ..................................................................... 277
Promotions hierarchy ........................................................... 278
© 2007 MicroStrategy, Inc.
ix
Contents
Project Design Guide
MicroStrategy Tutorial schema .................................................. 280
Geography schema ............................................................. 283
Products schema ................................................................. 284
Customers schema .............................................................. 285
Time schema ....................................................................... 286
Promotions schema ............................................................. 287
Sales fact tables .................................................................. 287
Inventory fact tables............................................................. 288
Miscellaneous fact tables..................................................... 288
B. Connecting to OLAP
Cube Sources
Introduction.............................................................................. 291
MicroStrategy integration with OLAP cube sources .................. 292
Understanding MicroStrategy architecture........................... 294
Authentication ...................................................................... 297
Understanding the SAP BW terminology ................................... 298
Relating objects from SAP BW to MicroStrategy ....................... 302
Supporting SAP BW variables ............................................. 308
SAP BW structures .............................................................. 311
Relating objects from Essbase to MicroStrategy ....................... 311
Relating objects from Analysis Services 2000 to
MicroStrategy............................................................................. 317
Relating objects from Analysis Services 2005 to
MicroStrategy............................................................................. 322
Connecting to SAP BW servers................................................. 327
Connecting to SAP BW servers on Windows ...................... 328
Connecting to SAP BW servers on UNIX and Linux............ 330
Connecting to Essbase servers ................................................. 334
Configuring the XMLA Provider ........................................... 334
Connecting to Analysis Services 2000 servers.......................... 337
Configuring the XMLA Provider ........................................... 338
Connecting to Analysis Services 2005 servers.......................... 340
Configuring the XMLA Provider ........................................... 341
Integrating OLAP cubes into MicroStrategy............................... 343
Importing OLAP cubes......................................................... 344
Mapping OLAP cubes .......................................................... 349
Creating metrics from OLAP cube data with MDX and
compound metric techniques ............................................... 359
x
© 2007 MicroStrategy, Inc.
Project Design Guide
C. Logical Tables
Contents
Introduction.............................................................................. 369
Logical tables............................................................................. 370
How should I use logical tables? ............................................... 371
Creating logical tables ............................................................... 373
Using SQL for logical views ................................................. 375
Logical view examples............................................................... 376
Business case 1: Distinct attribute lookup table................... 376
Business case 2: Attribute form expression across
multiple tables ...................................................................... 377
Business case 3: Slowly changing dimensions.................... 378
Business case 4: One-to-many transformation tables ......... 389
Business case 5: Outer joins between attribute
lookup tables........................................................................ 390
D. Data Types
Introduction.............................................................................. 395
Mapping of external data types to MicroStrategy data types..... 395
MicroStrategy data types ........................................................... 397
Format types.............................................................................. 398
Data type and format type compatibility..................................... 399
Big Decimal................................................................................ 400
Using the Big Decimal data type.......................................... 401
Glossary ................................................................................... 403
Index ......................................................................................... 427
© 2007 MicroStrategy, Inc.
xi
Contents
xii
Project Design Guide
© 2007 MicroStrategy, Inc.
PREFACE
Description of Guide
The MicroStrategy Project Design Guide provides
comprehensive information on planning, creating, and
modifying a project in MicroStrategy and covers a wide range
of project-related topics, including the following:
© 2007 MicroStrategy, Inc.
•
Chapter 1, BI Architecture and the MicroStrategy
Platform, provides a brief introduction to business
intelligence architecture and some of the main
components within the MicroStrategy platform.
•
Chapter 2, The Logical Data Model, explores logical data
modeling and how it can help you identify the different
elements within your business data and plan your project.
•
Chapter 3, Warehouse Structure for Your Logical Data
Model, describes components of the physical warehouse
schema such as columns and tables and explores how you
can map components from the logical data model to
components in the database to form the physical
warehouse schema.
•
Chapter 4, Creating and Configuring a Project, describes
the major components involved in project creation and
guides you through the process of creating a project in
MicroStrategy.
xiii
Preface
Project Design Guide
•
Chapter 5, The Building Blocks of Business Data: Facts,
describes the structure of facts and explores different
types of facts and how they relate to your business data.
This chapter also covers all the steps necessary to create
facts for your project.
•
Chapter 6, The Context of Your Business Data:
Attributes, provides a conceptual look at the structure of
attributes and explores different types of attributes and
how they relate to your business data. This chapter also
covers all the steps necessary to create attributes for your
project.
•
Chapter 7, Creating Hierarchies to Organize and Browse
Attributes, discusses the different types of hierarchies in
MicroStrategy, and explains how you can create user
hierarchies to help organize and enhance your project.
•
Chapter 8, Optimizing and Maintaining Your Project,
describes methods you can implement to better optimize
and maintain your project for both the short and long
term.
•
Chapter 9, Creating Transformations to Define
Time-Based and Other Comparisons, discusses the
different types of transformations in MicroStrategy and
describes how you can create transformations in your
project.
The appendixes contain the following additional reference
information, which you may or may not require depending on
your specific needs:
xiv
•
Appendix A, MicroStrategy Tutorial, provides
information on the MicroStrategy Tutorial project, which
includes a metadata and warehouse, and a set of
demonstration applications designed to illustrate the
features of the MicroStrategy platform.
•
Appendix B, Connecting to OLAP Cube Sources, provides
information about connecting to an OLAP Cube source
such as SAP® BW, Microsoft® Analysis Services, or
Hyperion® Essbase® for use within MicroStrategy.
•
Appendix C, Logical Tables, discusses logical tables, the
different types of logical tables, and how to create logical
tables and views in MicroStrategy.
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
•
Appendix D, Data Types, provides information about the
different data types in MicroStrategy.
About this book
This book is divided into chapters that begin with a brief
overview of the chapter’s content.
The following sections provide the location of additional
examples, list prerequisites for using this book, and describe
the user roles the information in this book was designed for.
How to find business scenarios and examples
Within this guide, many of the concepts discussed are
accompanied by business scenarios or other descriptive
examples. For examples of reporting functionality, see the
MicroStrategy Tutorial, which is MicroStrategy’s sample
warehouse, metadata, 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.
Business scenarios can be found in the Analytics Modules,
which are a set of sample analytics, each from a different
business area. Example analysis includes such business areas
as financial reporting, human resources, and customer
analysis. Each module comes with a sample data model and a
collection of packaged reports that allow dozens of analytical
variations. The Analytics Modules are part of a product
bundle called the MicroStrategy Business Intelligence
Developer Kit (BIDK).
© 2007 MicroStrategy, Inc.
About this book
xv
Preface
Project Design Guide
Prerequisites
Before working with this document, you should be familiar
with:
•
the information provided in the MicroStrategy
Installation and Configuration Guide
•
the nature and structure of the data you want to use for
your business intelligence application
Who should use this guide
This document is designed for all users who require an
understanding of how to design, create, and modify a
MicroStrategy project using the MicroStrategy platform.
In short, the following business intelligence application users
should read this guide:
•
Project Designers
•
Database Administrators
Resources
Documentation
MicroStrategy provides both manuals and online help; these
two information sources provide different types of
information, as described below.
Manuals: MicroStrategy manuals provide
xvi Resources
•
introductory information
•
concepts
•
checklists
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
•
examples
•
high-level procedures to get started
Online help: MicroStrategy online help provides
•
detailed steps to perform procedures
•
descriptions of each option on every software screen
Manuals
The following manuals are available from your CD-ROM or
the machine where MicroStrategy was installed. The
procedure to access them is below.
Acrobat Reader 4.0 or higher is required to
Adobe
view these documents. If you do not have Acrobat
Reader installed on your computer, you can download
it from www.adobe.com.
MicroStrategy Overview
•
Introduction to MicroStrategy: Evaluation Guide
Instructions for installing, configuring, and using the
MicroStrategy Evaluation Edition of the software.
•
MicroStrategy Quick Start Guide
Overview of the installation and evaluation process, and
additional resources.
Manuals for Query, Reporting, and Analysis
Products
•
MicroStrategy Installation and Configuration Guide
Information to install and configure MicroStrategy
products on Windows, UNIX, Linux, and HP platforms, as
well as basic maintenance guidelines.
•
MicroStrategy Upgrade Guide
Instructions to upgrade existing MicroStrategy products.
© 2007 MicroStrategy, Inc.
Resources
xvii
Preface
Project Design Guide
•
MicroStrategy System Administration Guide
Concepts and high-level steps to implement, deploy,
maintain, tune, and troubleshoot a MicroStrategy
business intelligence system.
•
MicroStrategy Project Design Guide
Information to create and modify MicroStrategy projects,
and understand facts, attributes, hierarchies,
transformations, advanced schemas, and project
optimization.
•
MicroStrategy Basic Reporting Guide
Instructions to get started with MicroStrategy Desktop
and MicroStrategy Web, and how to analyze data in a
report. Includes the basics for creating reports, metrics,
filters, and prompts.
•
MicroStrategy Advanced Reporting Guide
Instructions for advanced topics in the MicroStrategy
system, building on information in the Basic Reporting
Guide. Topics include reports, Freeform SQL reports,
Query Builder reports, OLAP Cube reports, filters,
metrics, Data Mining Services, custom groups,
consolidations, and prompts.
•
MicroStrategy Report Services Document Creation
Guide
Instructions to design and create Report Services
documents, building on information in the Basic
Reporting Guide and Advanced Reporting Guide.
•
MicroStrategy Office User Guide
Instructions for using MicroStrategy Office to work with
MicroStrategy reports and documents in Microsoft®
Excel, PowerPoint®, Word, and Outlook, to analyze,
format, and distribute business data.
•
MicroStrategy Mobile User Guide
Instructions for using MicroStrategy Mobile to view and
analyze data, and perform other business tasks with
MicroStrategy reports and documents on a mobile device.
Covers installation and configuration of MicroStrategy
Mobile and how a designer working in MicroStrategy
xviii Resources
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
Desktop or MicroStrategy Web can create effective
reports and documents for use with MicroStrategy
Mobile.
•
MicroStrategy Functions Reference
Function syntax and formula components; instructions to
use functions in metrics, filters, attribute forms; examples
of functions in business scenarios.
•
MicroStrategy Web Services Administration Guide
Concepts and tasks to install, configure, tune, and
troubleshoot MicroStrategy Web Services.
Manuals for Information Delivery and Alerting
Products
•
MicroStrategy Narrowcast Server Getting Started Guide
Instructions to work with the tutorial to learn Narrowcast
Server interfaces and features.
•
MicroStrategy Narrowcast Server Installation and
Configuration Guide
Information to install and configure Narrowcast Server.
•
MicroStrategy Narrowcast Server Application Designer
Guide
Fundamentals of designing Narrowcast Server
applications.
•
MicroStrategy Narrowcast Server System
Administrator Guide
Concepts and high-level steps to implement, maintain,
tune, and troubleshoot Narrowcast Server.
•
MicroStrategy Narrowcast Server Upgrade Guide
Instructions to upgrade an existing Narrowcast Server.
© 2007 MicroStrategy, Inc.
Resources
xix
Preface
Project Design Guide
Manuals for Analytics Modules
•
Business Intelligence Developer Kit (BIDK) Installation
and Porting Guide
•
Customer Analysis Module Reference
•
Sales Force Analysis Module Reference
•
Financial Reporting Analysis Module Reference
•
Sales and Distribution Analysis Module Reference
•
Human Resources Analysis 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.
•
MicroStrategy Web SDK
Web SDK is available in the MicroStrategy
The
Developer Library, which is sold as part of the
MicroStrategy SDK.
•
Narrowcast Server SDK Guide
Instructions to customize Narrowcast Server
functionality, integrate Narrowcast Server with other
systems, and embed Narrowcast Server functionality
within other applications. Documents the Narrowcast
Server Delivery Engine and Subscription Portal APIs, and
the Narrowcast Server SPI.
To access installed online documentation
1 From the Windows Start menu, choose Programs,
MicroStrategy, then Product Manuals. A Web page
opens with a list of available manuals in PDF format.
2 Click the link for the desired manual.
xx Resources
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
3 Some documentation is provided in HTML help format.
When you select one of these guides, the File Download
dialog box opens. Select Open this file from its current
location, and click OK.
bookmarks are not visible on the left side of an
IfAcrobat
(PDF) document, click the Bookmarks and
Page from the View menu.
Online help
MicroStrategy provides several ways to access online help:
© 2007 MicroStrategy, Inc.
•
Help button: Use the Help button at the bottom of most
software screens to see context-sensitive help.
•
Help menu: Select Contents and Index to see the main
table of contents for the help system.
•
F1 key: Press F1 to see context-sensitive help addressing
the function or task you are currently performing.
Resources
xxi
Preface
Project Design Guide
Documentation standards
MicroStrategy online help and PDF manuals (available both
online and in printed format) provides standards to help you
identify concepts and procedures. The following table lists
these conventions.
Type
bold
Indicates
• button names, check boxes, dialog boxes, options,
lists, and menus that are the focus of actions or part
of a list of such GUI elements and their definitions
• text to be entered by the user
Example: Click Select
Warehouse.
Example: Type cmdmgr -f scriptfile.scp and
press ENTER.
italic
• new terms defined within the text and in the glossary
• names of other product manuals
• when part of a command syntax, indicates variable
information to be replaced by the user
Example: The
aggregation level is the level of
calculation for the metric.
Example: Type copy c:\filename
d:\foldername\filename
Courier
font
•
•
•
•
•
•
calculations
code samples
registry keys
path and file names
URLs
messages displayed in the screen
Example:
Sum(revenue)/number of months.
UPPERCASE
• keyboard command key (such as ENTER)
• shortcut key (such as CTRL+V)
Example: To bold
the selected text, press
CTRL+B.
+
xxii Resources
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.
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
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.
For a detailed description of education offerings and course
curriculums, visit 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
www.microstrategy.com/Consulting.
International support
MicroStrategy supports several locales. Support for a locale
typically includes native database and operating system
support, support for date formats, decimal formats, currency
symbols, and more. It also includes the availability of
translated interfaces and documentation. The level of support
is defined in terms of the components of a MicroStrategy
business intelligence environment. A MicroStrategy business
intelligence environment consists of the following
components, collectively known as a configuration:
© 2007 MicroStrategy, Inc.
•
warehouse, metadata, and statistics databases
•
MicroStrategy Intelligence Server
•
MicroStrategy Web server
•
MicroStrategy Desktop client
•
Web browser
Resources
xxiii
Preface
Project Design Guide
MicroStrategy is certified in homogeneous configurations
(where all the components lie in the same locale) in the
following languages: English (US), French, German, Italian,
Japanese, Korean, Portuguese (Brazilian), Spanish, Chinese
(simplified) and Swedish.
MicroStrategy also provides limited support for
heterogeneous configurations (where some of the
components may lie in different locales). Please contact
MicroStrategy Technical Support for more details.
A translated user interface is available in each of the above
languages. In addition, translated versions of the online help
files and product documentation are available in several of
the above languages.
The following table lists the language selection possibilities
for different installation cases.
Installation
Result
Fresh installation on a system in
which MicroStrategy application
has never been installed before
The MicroStrategy Installation
Wizard prompts you to select the
language from the drop-down list.
The user language in the product
interface is the language that you
select during installation.
Once the product is installed, the
Online Help is displayed in the
same language that the user
selects in the language prompt of
the installation routine.
Repair or maintenance installation
on a system on which
MicroStrategy application has
been installed before
All subsequent executions of the
installation routine are displayed in
the language that you selected the
first time you installed the product
on the system.
The user language in the product
interface is also the language that
you selected the first time you
installed the product on the
system.
Upgrading an earlier installation
from version 7.2.3
xxiv Resources
The user language preference that
was set previously in version 7.2.3
is the language of display of the
installation routine and the user
language of the product interface.
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
Installation
Result
Upgrading an earlier installation
from version 7.2.2 or earlier,
including 7.1.x
The MicroStrategy Installation
Wizard prompts you to select the
language from the drop-down list.
The installation routine is displayed
in the selected language.
However, the user language of the
product interface language
remains the same as the one set in
the product interface before
running the upgrade installation.
Besides, all subsequent
executions of the installation
routine for maintenance or for
upgrade, unless overridden by the
command line parameter, are
displayed in the language that you
selected during the upgrade
installation.
Completely uninstalling all the
MicroStrategy products and
installing the same version or a
newer version
If you uninstall all the products and
install either the same version or a
higher version again, the
MicroStrategy Installation Wizard
prompts you to select the language
from the drop-down list.
Note: Even if you select a
language from the language
prompt in the installation routine, it
has no effect on the default
language of the product interfaces.
installation, the installation Online Help is
During
displayed in English only.
Technical Support
If you have questions about a specific MicroStrategy product,
you should:
1 Consult the product guides, online help, readme files, and
release notes. Paths to access each are described above.
2 Consult the MicroStrategy Knowledge Base online at
http://www.microstrategy.com/support/
k_base/index.asp
© 2007 MicroStrategy, Inc.
Resources
xxv
Preface
Project Design Guide
administrator in your organization may
Abetechnical
able to help you resolve your issues
immediately.
3 If the resources listed in the steps above do not provide
you with a solution, contact MicroStrategy Technical
Support directly. To ensure the most effective and
productive relationship with MicroStrategy Technical
Support, review the Policies and Procedures document
posted at http://www.microstrategy.com/
Support/Policies. Refer to the terms of your
purchase agreement to determine the type of support
available to you.
MicroStrategy Technical Support may be contacted by your
company’s Support Liaison. A Support Liaison is a person
whom your company has designated as a point-of-contact
with MicroStrategy’s support personnel. All customer
inquiries and case communications must come through these
named individuals. Your company may designate two
employees to serve as their Support Liaisons. Your company
may request to change their Support Liaisons two times per
year with prior written notice to MicroStrategy Technical
Support.
Ensure issues are resolved quickly
Before logging a case with MicroStrategy Technical Support,
the Support Liaison may follow the steps below to ensure that
issues are resolved quickly:
1 Verify that the issue is with MicroStrategy software and
not a third party software.
2 Verify that the system is using a currently supported
version of MicroStrategy software by checking the
Product Support Expiration Schedule at
http://www.microstrategy.com/Support/
Expiration.asp.
3 Attempt to reproduce the issue and determine whether it
occurs consistently.
4 Minimize the complexity of the system or project object
definition to isolate the cause.
xxvi Resources
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
5 Determine whether the issue occurs on a local machine or
on multiple machines in the customer environment.
6 Discuss the issue with other users by posting a question
about the issue on the MicroStrategy Customer Forum at
https://forums.microstrategy.com.
The table on the following page shows where, when, and how
to contact MicroStrategy Technical Support. If your Support
Liaison is unable to reach MicroStrategy Technical Support
by phone during the hours of operation, they can leave a
voicemail message, send e-mail or fax, or log a case using the
Online Support Interface.
North America
E-mail: support@microstrategy.com
Web: https://support.microstrategy.com
Fax: (703) 842–8709
Phone: (703) 848–8700
Hours: 9:00 A.M.–7:00 P.M. Eastern Time (1400–0000 GMT), Monday–Friday
except holidays
Europe, the Middle East, and
Africa (EMEA)
E-mail: eurosupp@microstrategy.com
Web: https://support.microstrategy.com
Fax: +44 (0) 208 396 0001
The European Technical Support Centre is closed on certain public holidays.
These holidays reflect the national public holidays in each country.
Phone:
• United Kingdom: +44 (0) 208 396 0085
• Benelux: +31 20 346 9210
• Finland: +35 8 9 6937 9620
• France: +33 1 41 91 86 49
• Germany: +49 69 95096206
• Ireland: +35 3 1242 1522
• Italy: +39 02696 33 456
• Spain: +34 91 406 90 10
• International distributors: +44 (0) 208 396 0080
Hours:
• United Kingdom: 9:00 A.M.–6:00 P.M. GMT, Monday-Friday except holidays
• Mainland Europe: 9:00 A.M.–6:00 P.M. CET, Monday-Friday except holidays
© 2007 MicroStrategy, Inc.
Resources
xxvii
Preface
Project Design Guide
Asia Pacific
E-mail: apsupport@microstrategy.com
Web: https://support.microstrategy.com
Fax: +81 3 5456 5464
Phone:
• Korea: +82 2 560 6565
• Singapore (supporting Singapore, China, Taiwan, Hong Kong, Pakistan, India,
and Sri Lanka): +65.6303.8969
• Japan (supporting Japan, Australia, New Zealand, Malaysia, and all other Asia
Pacific countries not listed in this section): +81 3 3511 6720
Hours: 9:00 A.M.–6:00 P.M. JST (Tokyo), Monday-Friday except holidays
Latin America
E-mail: latamsupport@microstrategy.com
Web: https://support.microstrategy.com
Fax: +55 11 3044 4088
Phone: LATAM (except Argentina): +55 11 3054 1010
Argentina: 0 800 444 MSTR
Hours: 9:00 A.M.–7:00 P.M. BST (Sao Paulo), Monday–Friday except holidays
Support Liaisons should contact the Technical Support
Center from which they obtained their MicroStrategy
software licenses or the Technical Support Center to which
they have been designated.
The individual Technical Support Centers are closed on
certain public holidays. In North America, these holidays
reflect many U.S. national holidays. In Europe, Asia Pacific,
and Latin America, these holidays reflect the national public
holidays in each country.
Although not a requirement, we recommend you designate
Support Liaisons who have permissions to be MicroStrategy
project administrators. This can eliminate security conflicts
and improve case resolution time. During the course of
troubleshooting and researching issues, MicroStrategy
Technical Support personnel may make recommendations
that require administrative privileges on the MicroStrategy
projects, or that assume that the designated Support Liaison
has a security level that permits them to fully manipulate the
MicroStrategy projects and has access to potentially sensitive
project data such as security filter definitions.
Required information when calling
When contacting MicroStrategy Technical Support, please
provide the following information:
•
xxviii Resources
Personal information:
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
•
•
Name (first and last)
Company and customer site (if different from
company)
Contact information (phone and fax numbers, e-mail
addresses)
Case details:
Configuration information, including MicroStrategy
software product(s) and versions
Full description of the case including symptoms, error
messages(s), and steps taken to troubleshoot the case
thus far
Business/system impact
If this is the Support Liaison’s first call, they should also be
prepared to provide the following:
•
street address
•
phone number
•
fax number
•
e-mail address
To help the Technical Support representative work to resolve
the problem promptly and effectively, be prepared to provide
the following additional information:
© 2007 MicroStrategy, Inc.
•
case number: Please keep a record of the number assigned
to each case logged with MicroStrategy Technical
Support, and be ready to provide it when inquiring about
an existing case
•
software version and product registration numbers of the
MicroStrategy software products you are using
•
case description:
What causes the condition to occur?
Does the condition occur sporadically or each time a
certain action is performed?
Does the condition occur on all machines or just on
one?
Resources
xxix
Preface
Project Design Guide
•
When did the condition first occur?
What events took place immediately prior to the first
occurrence of the condition (for example, a major
database load, a database move, or a software
upgrade)?
If there was an error message, what was its exact
wording?
What steps have you taken to isolate and resolve the
issue? What were the results?
system configuration (the information needed depends on
the nature of the problem; not all items listed below may
be necessary):
computer hardware specifications (processor speed,
RAM, disk space, and so on)
network protocol used
ODBC driver manufacturer and version
database gateway software version
(for MicroStrategy Web-related problems) browser
manufacturer and version
(for MicroStrategy Web-related problems) Web server
manufacturer and version
If the issue requires additional investigation or testing, the
Support Liaison and the MicroStrategy Technical Support
representative should agree on certain action items to be
performed. The Support Liaison should perform any
agreed-upon actions before contacting MicroStrategy
Technical Support again regarding the issue. If the Technical
Support representative is responsible for an action item, The
Support Liaison may call MicroStrategy Technical Support at
any time to inquire about the status of the issue.
Feedback
Please send any comments or suggestions about user
documentation for MicroStrategy products to:
xxx Feedback
© 2007 MicroStrategy, Inc.
Project Design Guide
Preface
documentationfeedback@microstrategy.com
Send suggestions for product enhancements to:
support@microstrategy.com
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.
© 2007 MicroStrategy, Inc.
Feedback
xxxi
Preface
xxxii Feedback
Project Design Guide
© 2007 MicroStrategy, Inc.
1
1.
BI ARCHITECTURE AND THE
MICROSTRATEGY PLATFORM
Introduction
Before planning and creating a project in MicroStrategy, it is
important to understand how business intelligence systems
work and, specifically, how the MicroStrategy platform
interacts with your business data to provide a wide range of
functionality.
Business intelligence (BI) systems facilitate the analysis of
volumes of complex data by providing the ability to view data
from multiple perspectives. An optimum business
intelligence application:
© 2007 MicroStrategy, Inc.
•
Gives users access to data at various levels of detail
•
Allows users to request information and have it delivered
to them accurately and quickly
•
Provides a foundation for the proactive delivery of
information to system subscribers
1
1
BI Architecture and the MicroStrategy Platform
Project Design Guide
This chapter introduces you to the basic architecture of BI
systems, as well as some of the components within the
MicroStrategy platform that allow you to create and analyze
your business intelligence.
Business intelligence architecture
A BI architecture has the following components:
•
A source system—typically an online transaction
processing (OLTP) system, but other systems or files that
capture or hold data of interest are also possible
•
An extraction, transformation, and loading (ETL) process
•
A data warehouse—typically an online analytical
processing (OLAP) system
•
A business intelligence platform such as MicroStrategy
diagram above illustrates the common setup for
The
standardizing data from source systems and
transferring that data into MicroStrategy.
MicroStrategy can also access data from text files,
Excel files, SAP BW, Hyperion Essbase, Microsoft
Analysis Services, and other data sources. For more
information on how MicroStrategy can access your
data sources, see Data warehouse for data storage
and relational design, page 5.
2 Business intelligence architecture
© 2007 MicroStrategy, Inc.
Project Design Guide
BI Architecture and the MicroStrategy Platform
1
Source systems for data collection
Source systems refer to any system or file that captures or
holds data of interest. A bank is an example of a business with
many source systems. An average bank offers several services
such as account activity updates and loan disbursement, and
therefore has many source systems to support these services.
For example, suppose one source system—a database file on
the bank’s server—keeps track of deposits and withdrawals as
they occur. Meanwhile, a different source system—another
file on the server—keeps track of each customer’s contact
information.
A source system is usually the most significant site of online
transaction processing (OLTP). Transactional processing
involves the simple recording of transactions and other
business data such as sales, inventory, e-commerce, deposits,
website usage, and order processing. This processing is relied
upon daily by nearly every industry, including health care,
telecommunications, manufacturing, and many others.
OLTP systems are databases or mainframes that store
real-time processing data and have the following
characteristics:
•
Data access is optimized for frequent reading and writing,
as the system records huge volumes of data every day. An
example of data that benefits from this type of
optimization is the number of credit card transactions
that an OLTP system might record in a single day. This is
in contrast to data warehouses which are often designed
for reading data for analysis with a minimum number of
updates, insertions, or deletions. For more information on
data warehouse design, see Data warehouse for data
storage and relational design, page 5.
•
Data is aligned by application, that is, by business
activities and workflow.
•
Data formats are not necessarily uniform across systems.
•
Data history is limited to recent or current data.
Recall the example of a bank that relies on several source
systems to store data related to the many services the bank
offers. Each of these business services has a different and
specific workflow.
© 2007 MicroStrategy, Inc.
Business intelligence architecture
3
1
BI Architecture and the MicroStrategy Platform
Project Design Guide
At an automated teller machine (ATM), you can withdraw or
deposit money as well as check on balances. However, to get a
money order, you must enter the bank and perform the
transaction with a bank teller. This is because the operational
systems supporting these two services are designed to
perform specific tasks, and these two services require
different operational systems.
If a bank wants to see a unified view of a particular customer,
such as a customer's ATM activity, loan status, account
balances, and money market account information, the
customer information stored in each of these different
systems must be consolidated. This consolidation is achieved
using the extraction, transformation, and loading (ETL)
process.
The ETL process consolidates data so it can be stored in a
data warehouse.
Extraction, transformation, and loading process
The extraction, transformation, and loading (ETL) process
represents all the steps necessary to move data from different
source systems to an integrated data warehouse.
The ETL process involves the following steps:
1 Data is gathered from various source systems.
2 The data is transformed and prepared to be loaded into
the data warehouse. Transformation procedures can
include converting data types and names, eliminating
unwanted data, correcting typographical errors, filling in
incomplete data, and similar processes to standardize the
format and structure of data.
3 The data is loaded into the data warehouse.
This process can be explained with the example of a bank that
wants to consolidate a variety of information about a
particular customer, including the customer's ATM activity,
loan status, and account balances. Each of these different sets
of data is likely gathered by different source systems. Since
4 Business intelligence architecture
© 2007 MicroStrategy, Inc.
Project Design Guide
BI Architecture and the MicroStrategy Platform
1
each source system can have its own naming conventions, the
data that comes from one system may be inconsistent with
the data that comes from another system.
In this case, the ETL process extracts the data from the
different banking source systems, transforms it until it is
standardized and consistent, and then loads the data into the
data warehouse.
Data warehouse for data storage and relational design
A well-designed and robust data warehouse is the source of
data for the decision support system or business intelligence
system. It enables its users to leverage the competitive
advantage that the business intelligence provides. Data
warehouses are usually based on relational databases or some
form of relational database management system (RDBMS)
platform. These relational databases can be queried directly
with Structured Query Language (SQL), a language
developed specifically to interact with RDBMS software.
However, MicroStrategy does not require that data be stored
in a relational database. You can integrate different types of
data sources with MicroStrategy such as text files, Excel files,
and OLAP cubes. For more information on accessing data
stored in alternative data sources, see Storing and analyzing
data with alternative data sources, page 6.
The source systems described above, such as OLTP systems,
are generally designed and optimized for transactional
processing, whereas data warehouses are usually designed
and optimized for analytical processing. In combination with
MicroStrategy tools and products, the data warehouse also
provides the foundation for a robust online analytical
processing (OLAP) system. Analytical processing involves
activities such as choosing to see sales data by month and
selecting the applicable metric to calculate sales trends,
growth patterns, percent-to-total contributions, trend
reporting, and profit analysis.
Most data warehouses have the following characteristics:
•
© 2007 MicroStrategy, Inc.
Data access is typically read-only. The most common
action is the selection of data for analysis. Data is rarely
inserted, updated, or deleted. This is in contrast to most
Business intelligence architecture
5
1
BI Architecture and the MicroStrategy Platform
Project Design Guide
OLTP source systems which must be able to handle
frequent updates as data is gathered. For more
information on source systems, see Source systems for
data collection, page 3.
•
Data is aligned by business subjects.
•
Data formats are uniformly integrated using an ETL
process (see Extraction, transformation, and loading
process, page 4).
•
Data history extends long-term, usually two to five years.
•
A data warehouse is populated with data from the existing
operational systems using an ETL process, as explained in
Extraction, transformation, and loading process, page 4.
structure of data in a data warehouse and how it
The
relates to your MicroStrategy environment can be
defined and understood through a logical data model
and physical warehouse schema. Defining a project’s
logical data model and physical warehouse schema are
important steps in preparing your data for a
MicroStrategy project. For more information on the
steps of the project design process, see Chapter 2, The
Logical Data Model and Chapter 3, Warehouse
Structure for Your Logical Data Model.
Storing and analyzing data with alternative data
sources
Along with integrating with relational databases, which are a
common type of data warehouse, MicroStrategy can also
integrate with a number of alternative data sources. A data
source is any file, system, or storage location which stores
data that is to be used in MicroStrategy for query, reporting,
and analysis. A data warehouse can be thought of as one type
of data source, and refers specifically to using a database as
your data source.
The following are different data source alternatives which
MicroStrategy can integrate with:
•
6 Business intelligence architecture
OLAP cube sources: In MicroStrategy you can integrate
with sets of data from SAP BW, Microsoft Analysis
Services, and Hyperion Essbase, which are referred to as
© 2007 MicroStrategy, Inc.
Project Design Guide
BI Architecture and the MicroStrategy Platform
1
OLAP cube sources. MicroStrategy can integrate with
these data sources while simultaneously accessing a
relational database effectively. For more information on
connecting to and integrating OLAP cube sources in
MicroStrategy, see Appendix B, Connecting to OLAP
Cube Sources.
•
Text files and Excel files: With MicroStrategy’s
Freeform SQL and Query Builder features, you can query,
analyze, and report on data stored in text files and Excel
files. As with OLAP cube sources described above,
MicroStrategy can report against these alternative data
sources while concurrently accessing a relational database
to integrate all of your data into one cohesive project. For
more information on using text files and Excel files with
the Freeform SQL and Query Builder features, see the
MicroStrategy Advanced Reporting Guide.
The MicroStrategy platform
A business intelligence platform offers a complete set of tools
for the creation, deployment, support, and maintenance of
business intelligence applications. Some of the main
components of the MicroStrategy platform include:
© 2007 MicroStrategy, Inc.
•
MicroStrategy metadata, page 8—a repository that
stores MicroStrategy object definitions and information
about the data warehouse
•
MicroStrategy Intelligence Server, page 11—an analytical
server optimized for enterprise querying, reporting, and
OLAP analysis
•
MicroStrategy Desktop, page 11—an advanced,
Windows-based environment providing a complete range
of analytical functions designed to facilitate the
deployment of reports
•
MicroStrategy Web and Web Universal, page 13—a
highly interactive user environment and a
low-maintenance interface for reporting and analysis
The MicroStrategy platform
7
1
BI Architecture and the MicroStrategy Platform
•
Project Design Guide
MicroStrategy project, page 14—where you build and
store all schema objects and information you need to
create application objects such as reports in the
MicroStrategy environment, which together provide a
flexible reporting environment
The MicroStrategy platform components work together to
provide an analysis and reporting environment to your user
community, as shown in the following diagram.
The sections that follow provide a brief overview of each of
these components. For more detailed information about
these and the other components that make up the
MicroStrategy platform, refer to the MicroStrategy
Installation and Configuration Guide. To learn how to
administer and tune the MicroStrategy platform, see the
MicroStrategy System Administration Guide.
MicroStrategy metadata
MicroStrategy metadata is a repository that stores
MicroStrategy object definitions and information about your
data warehouse. The information is stored in a proprietary
8 The MicroStrategy platform
© 2007 MicroStrategy, Inc.
Project Design Guide
BI Architecture and the MicroStrategy Platform
1
format within a relational database. The metadata maps
MicroStrategy objects—which are used to build reports and
analyze data—to your data warehouse structures and data.
The metadata also stores the definitions of all objects created
with MicroStrategy Desktop and Web such as templates,
reports, metrics, facts, and so on.
In general, report creation in MicroStrategy is achieved
through using various types of objects which represent your
data as report building blocks. You can build and manipulate
several fundamentally different kinds of objects in
MicroStrategy; these objects, which are described below, are
all created and stored in the metadata repository.
•
Configuration objects—Objects that provide important
information or governing parameters for connectivity,
user privileges, and project administration. Examples
include database instances, users, groups, and so on.
These objects are not used directly for reporting, but are
created by a project architect or administrator to
configure and govern the platform. As a general rule,
configuration objects are created and maintained with the
managers in MicroStrategy Desktop within the
Administration icon. For more information about creating
and administering configuration objects, see the
MicroStrategy System Administration Guide.
•
Schema objects—Objects that are created in the
application to correspond to database objects, such as
tables, views, and columns. Schema objects include facts,
attributes, hierarchies, and other objects which are stored
in the Schema Objects folder in MicroStrategy Desktop’s
folder list. Facts, attributes, and hierarchies are three
essential pieces to any business intelligence application.
These schema objects are often created and managed by a
MicroStrategy architect:
© 2007 MicroStrategy, Inc.
Facts relate numeric data values from the data
warehouse to the MicroStrategy reporting
environment. Facts are used to create metrics, which
are analytical calculations that are displayed on a
report. The number of units sold is one example of a
fact. Facts are discussed in more detail in Chapter 5,
The Building Blocks of Business Data: Facts.
The MicroStrategy platform
9
1
BI Architecture and the MicroStrategy Platform
•
Project Design Guide
Attributes represent the business context in which fact
data is relevant. In the example of regional sales in the
Southeast, Southeast represents the attribute or
context of the sales data. Attributes are used to define
the level at which you want to view the numeric data
on a report. Attributes are discussed in more detail in
Chapter 6, The Context of Your Business Data:
Attributes.
Hierarchies are groupings of attributes so that they
can be displayed to reflect their relationships to other
attributes. These groupings can help users make
logical connections between attributes when reporting
and analyzing data. One of the most common
examples of a hierarchy is a time hierarchy which
includes attributes such as Year, Month, Quarter, and
so on. Hierarchies are discussed in more detail in
Chapter 7, Creating Hierarchies to Organize and
Browse Attributes.
Application objects—Objects used to provide analysis of
and insight into relevant data. Application objects include
reports, documents, filters, templates, custom groups,
metrics, and prompts. Application objects are created
using schema objects as building blocks. All application
objects can be created and maintained in MicroStrategy
Desktop. Reports and documents can also be created and
managed in MicroStrategy Web. Information on creating
application objects is in the MicroStrategy Basic
Reporting Guide and MicroStrategy Advanced
Reporting Guide.
more information about MicroStrategy Web,
For
see MicroStrategy Web and Web Universal,
page 13.
The metadata enables the sharing of objects across
MicroStrategy applications by providing a central repository
for all object definitions. MicroStrategy Intelligence Server
evaluates the most efficient data retrieval scenario to provide
excellent query performance.
MicroStrategy metadata also facilitates the retrieval of data
from the data warehouse when using MicroStrategy
applications. It converts user requests into SQL queries and
10 The MicroStrategy platform
© 2007 MicroStrategy, Inc.
Project Design Guide
BI Architecture and the MicroStrategy Platform
1
translates the results of those SQL queries back into
MicroStrategy objects such as reports and documents which
can be easily analyzed and understood.
MicroStrategy Intelligence Server
MicroStrategy Intelligence Server is an analytical server
optimized for enterprise querying, reporting, and OLAP
analysis. The important functions of MicroStrategy
Intelligence Server are:
•
Sharing objects
•
Sharing data
•
Managing the sharing of data and objects in a controlled
and secure environment
•
Protecting the information in the metadata
MicroStrategy Intelligence Server also provides a library of
over 150 different sophisticated mathematical and statistical
functions. You can also add and define your own functions.
See the MicroStrategy Functions Reference for details about
these functions.
For information on how to install and configure
MicroStrategy Intelligence Server, refer to the MicroStrategy
Installation and Configuration Guide. For a detailed
description of MicroStrategy Intelligence Server functionality
and tuning recommendations, refer to the MicroStrategy
System Administration Guide.
MicroStrategy Desktop
MicroStrategy Desktop is an advanced, Windows-based
environment providing a complete range of analytical
functionality designed to facilitate the deployment of reports.
MicroStrategy Desktop provides the project designer
functionality essential to creating both schema and
application objects necessary to serve the user communities
of both MicroStrategy Desktop and Web.
© 2007 MicroStrategy, Inc.
The MicroStrategy platform
11
1
BI Architecture and the MicroStrategy Platform
Project Design Guide
Desktop enables you to model applications using an intuitive,
graphical interface. It provides a unified environment for
creating and maintaining business intelligence projects. If
you need to change how to view your business information or
how the data is modeled, Desktop provides the ability to
modify one aspect of the application without affecting the
others.
Desktop is where you can manage application objects such as
reports, filters, and metrics. However, before application
objects are created, schema objects must first exist. Schema
objects allow application objects to interact with the data
warehouse to access the data for analysis. Facts, attributes,
hierarchies, and other schema objects are the building blocks
for application objects such as reports and documents. For
example, facts are used to create metrics, which are in turn
used to design reports. Application objects such as reports
are used to analyze and provide insight into the relevant data.
One of the other functions of MicroStrategy Desktop is to
create projects. Projects are discussed in Chapter 4, Creating
and Configuring a Project.
The following examples highlight some ways in which
Desktop allows you to model your business intelligence
applications:
•
Every report or query can automatically benefit from the
tables you include in an application. Tables in
MicroStrategy are references to tables in your data
warehouse, thus providing access to your data.
•
You can change the structure of a business hierarchy by
re-ordering it. This modification is necessary if you have
new requirements that require you to add or remove new
levels of data in a hierarchy. The change automatically
takes effect in the application, without making any
alterations to the database.
After reports have been created, report designers and
analysts can deploy them through different interfaces,
including MicroStrategy Desktop, MicroStrategy Web, and
MicroStrategy Office.
For information about the various components that comprise
MicroStrategy Desktop, refer to the MicroStrategy
Installation and Configuration Guide.
12 The MicroStrategy platform
© 2007 MicroStrategy, Inc.
Project Design Guide
1
BI Architecture and the MicroStrategy Platform
For more information about creating application objects such
as reports in MicroStrategy Desktop, refer to the
MicroStrategy Basic Reporting Guide. For information on
advanced Desktop functionality, see the MicroStrategy
Advanced Reporting Guide.
MicroStrategy Web and Web Universal
MicroStrategy Web provides users with a highly interactive
environment and a low-maintenance interface for reporting
and analysis. Using the Web interface, users can access,
analyze, and share data through any web browser on many
operating systems. MicroStrategy Web provides ad-hoc
querying, industry-leading analysis, quick deployment, and
rapid customization potential, making it easy for users to
make informed business decisions.
MicroStrategy Web Universal is a version of MicroStrategy
Web that provides the added benefits of also working with:
•
Operating systems such as Sun Solaris™, IBM AIX®, Red
Hat® Linux®, and HP-UX
•
Application servers such as BEA WebLogic™, IBM
WebSphere®, Sun ONE®, Oracle®, and Apache Tomcat
•
All web servers and browsers supported by MicroStrategy
Web
Intelligence Server must be running
MicroStrategy
for users to retrieve information from your data
warehouse using MicroStrategy Web products. For
more information about deploying MicroStrategy
Web, see the MicroStrategy Installation and
Configuration Guide.
Additional MicroStrategy definitions, including many
project-related terms, are discussed in Project connectivity
components, page 64.
© 2007 MicroStrategy, Inc.
The MicroStrategy platform
13
1
BI Architecture and the MicroStrategy Platform
Project Design Guide
MicroStrategy project
A project is where you build and store all schema objects and
information you need to create application objects such as
reports in the MicroStrategy environment, which together
provide a flexible reporting environment. A project also
represents the intersection of a data source, metadata
repository, and user community. In MicroStrategy Desktop,
projects appear one level below project sources in the Folder
List.
A project:
•
Determines the set of data warehouse tables to be used,
and therefore the set of data available to be analyzed.
•
Contains all schema objects used to interpret the data in
those tables. Schema objects include facts, attributes,
hierarchies, and so on. Schema objects are discussed in
later chapters in this guide.
•
Contains all reporting objects used to create reports and
analyze the data. Reporting objects include metrics,
filters, reports, and so on. Report objects are covered in
the MicroStrategy Basic Reporting Guide and the
MicroStrategy Advanced Reporting Guide.
•
Defines the security scheme for the user community that
accesses these objects. Security objects include security
filters, security roles, privileges, access control, and so on.
Security and other project-level administrative features
are discussed in the MicroStrategy System
Administration Guide.
A project can contain any number of reports in addition to a
number of other objects that support simple and advanced
reporting requirements. Conceptually, a project the
environment in which all related reporting is done. A project
can contain many types of objects, including application
objects such as filters, prompts, metrics, and reports that you
can create using schema objects such as attributes and facts.
Projects are often used to separate data from a data
warehouse into smaller sections of related data that fit user
requirements. For example, you may have a project source
separated into four different projects with analysis areas such
as human resources, sales distribution, inventory, and
14 The MicroStrategy platform
© 2007 MicroStrategy, Inc.
Project Design Guide
BI Architecture and the MicroStrategy Platform
1
customer satisfaction. This allows all of your users in the
human resources department to use the human resources
project and they do not have to look through inventory data
that they are not interested in.
Some key concepts to understand before you begin creating a
project are as follows:
•
A project is created within a specified metadata
repository, determined by the project source through
which you create the project.
•
The project’s warehouse location is specified by
associating it with the appropriate database instance.
The procedures associated with these concepts are explained
in Creating the project, page 73.
The project design process
When you create a project in MicroStrategy Desktop, one of
the connections you create is between the project and your
data warehouse. In the project, you can then create schema
objects based on the columns and tables in the warehouse.
© 2007 MicroStrategy, Inc.
The project design process
15
1
BI Architecture and the MicroStrategy Platform
Project Design Guide
The diagram below shows this high-level view of data
modeling, schema design and implementation, and project
creation, which are each covered in the following chapters:
Notice that the project design process includes a feedback
loop. Designing a project is very rarely a single, linear
process. As projects are deployed and tested, new user
requirements and project enhancements require
modification to the initial project design. It is important to
keep this in mind as you design your project and plan for the
next phase of development.
16 The project design process
© 2007 MicroStrategy, Inc.
2
2.
THE LOGICAL DATA MODEL
Conceptualizing your business model
and the data on which to report
Introduction
Devising a model of your business data can help you analyze
the structure of the data, how its various parts interact, and
can also help you decide what you intend to learn from the
data.
This chapter describes one of the major components of data
modeling: the logical data model. A logical data model is a
logical arrangement of data as experienced by the general
user or business analyst. This is different from the physical
data model or warehouse schema, which arranges data for
efficient database use. The logical data model graphically
depicts the flow and structure of data in a business
environment, providing a way of organizing data so it can be
analyzed from different business perspectives.
A logical data model is similar in concept to using a map and
an itinerary when going on a trip. You need to know where
you are going and how to get there. You also need a plan that
is visible and laid out correctly. For example, a simple logical
data model for a retail company can organize all necessary
© 2007 MicroStrategy, Inc.
17
2
The Logical Data Model
Project Design Guide
facts by store, product, and time, which are three common
business perspectives typically associated with a retail
business.
Logical data models are independent of a physical data
storage device. This is the key concept of the logical data
model. The reason that a logical data model must be
independent of technology is because technology is changing
so rapidly. What occurs under the logical data model can
change with need or with technology, but the blueprint
remains the same, and you do not need to start over
completely.
you are familiar with multidimensional data
Ifmodeling,
logical data modeling is similar to
multidimensional data modeling. As the
MicroStrategy platform does not require you to define
dimensions explicitly, the word logical is a more
accurate term than multidimensional. While a
multidimensional data model must have at least one
dimension, a logical data model may or may not have
any explicitly defined dimensions.
The scope and complexity of a logical data model depends on
the requirements of the reporting needs of the user
community and the availability of source data. The more
sophisticated and complex the reporting requirements and
source data, the more complex the logical data model
becomes.
18
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
The logical data modeling process produces a diagram similar
to the one shown in the following diagram:
A logical data model represents the definition,
characteristics, and relationships of data in a technical,
conceptual, or business environment. This process can help
you think about the various elements that compose your
company’s business data and how those elements relate to
one another.
© 2007 MicroStrategy, Inc.
19
2
The Logical Data Model
Project Design Guide
Devising a logical data model for your business intelligence
environment allows you to then consider various ways to
physically store the business data in the data warehouse. This
is usually one of the first steps in designing a project, as
shown in the following diagram:
This chapter provides conceptual information about logical
data models, the elements that exist within them, and also
general instructions and guidelines for creating these models.
A logical data model is a graphic representation of the
following concepts:
20
•
Facts: Business data and measurements, page 21
•
Attributes: Context for your levels of data, page 22
•
Hierarchies: Data relationship organization, page 25
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
Facts: Business data and measurements
One of the first things you do when you create a logical data
model is to determine the facts. Conceptually, you can think
of facts as business measurements, data, or variables that are
typically numeric and suitable for aggregation. Sales,
Inventory, and Account Balance are some examples of facts
you can use as business measurements.
Facts allow you to access data stored in a data warehouse and
they form the basis for the majority of users’ analysis and
report requirements. In MicroStrategy, facts are schema
objects that relate data values (typically numeric data) from
the data warehouse to the MicroStrategy reporting
environment.
Facts are the building blocks used to create business
measurements or metrics from which to derive insight into
your data. The rest of data modeling consists mostly of
providing context for the data that facts provide access to.
In a data warehouse, facts exist as columns within the fact
tables. They can come from different source systems and they
can have different levels of detail. For example, you can
capture sales data in one system and track it daily, while you
capture stock and inventory data in another system and track
it weekly.
familiar with SQL, facts generally represent
Tothethose
numeric columns in database tables on which you
perform SQL aggregations, such as SUM and AVG.
For example, in the following SQL statement, the
ORDER_AMT column in the warehouse may correspond
to the Order Amount fact in the MicroStrategy
environment:
SELECT sum(a21.ORDER_AMT) EMP_NAME
FROM ORDER_FACT a21
JOIN LU_EMPLOYEE a22
ON (a21.EMP_ID = a22.EMP_ID)
WHERE
a22.CALL_CTR_ID in (5, 9, 12)
© 2007 MicroStrategy, Inc.
Facts: Business data and measurements
21
2
The Logical Data Model
Project Design Guide
In addition, while ORDER_AMT is the fact,
sum(a21.ORDER_AMT) represents a metric, which
are business calculations often built using facts.
Metrics are discussed in detail in the MicroStrategy
Basic Reporting Guide.
Fore a more complete discussion about facts, refer to Chapter
5, The Building Blocks of Business Data: Facts.
Attributes: Context for your levels of data
After the facts are determined, the attributes must be
identified. Attributes allow you to answer questions about a
fact and provide a context for reporting and analyzing those
facts.
For example, consider the sales figures of your company. If
you were informed that your company had sales of $10,000,
you can gather little useful information. To make the sales
figure meaningful, you would need to know more about the
source of that sales figure such as:
•
A time frame for the sales
•
Who and how many people contributed to the sales total
•
What products were sold from which departments
•
The scope of the sale, such as national, regional, local, or a
single store
Attributes provide context and levels for convenient
summarization and qualification of your data to help answer
the type of questions listed above. They are used to answer
business questions about facts at varying levels of detail. For
example, if your sales data is stored at the day level, a Month
attribute allows you to see the same sales data summarized at
the month level.
those familiar with SQL, attributes generally
Torepresent
the non-numeric and non-aggregatable
columns in database tables. These columns are used to
qualify and group fact data.
22 Attributes: Context for your levels of data
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
For example, in the following SQL statement, the
MONTH_ID column in the warehouse maps to the
Month attribute in the MicroStrategy environment:
SELECT a11.MONTH_ID MONTH_ID,
max(a12.MONTH_DESC) MONTH_DESC,
sum(a11.TOT_DOLLAR_SALES) DLRSALES
FROM MNTH_CATEGORY_SLS a11
join LU_MONTH a12
on (a11.MONTH_ID = a12.MONTH_ID)
WHERE a11.MONTH_ID in
(200201,200202,200203)
GROUP BY al1.MONTH_ID
Attribute forms contain additional descriptive information
about a given attribute and are discussed in terms of the
logical data model in Attribute forms, page 36.
For a complete discussion about attributes, refer to Chapter
6, The Context of Your Business Data: Attributes.
Attribute elements: Data level values
Attribute elements are the unique values or contents of an
attribute. For example, 2005 and 2006 are elements of the
Year attribute while New York and London are elements of
the City attribute. On a report, attributes are used to build the
report and the attribute elements are displayed in rows or
columns on the executed report.
Attribute elements also allow you to qualify on data to
retrieve specific results. For example, a Customer attribute
allows you to see sales data at the customer level and you can
qualify on the elements of the Customer attribute to see sales
data for groups such as customers with last names beginning
with the letter h.
© 2007 MicroStrategy, Inc.
Attributes: Context for your levels of data
23
2
The Logical Data Model
Project Design Guide
The following diagram shows some examples of attributes
and attribute elements.
By recognizing and understanding the elements of an
attribute, you can better design your data model and project.
Although attribute elements are not included in the logical
data model, they are necessary in understanding attribute
relationships.
Attribute elements are discussed in more detail in Unique
sets of attribute information: Attribute elements, page 140.
Attribute relationships
Building an effective project in MicroStrategy requires you, as
the project designer, to have a solid understanding of all the
attributes in the project, as well as how each of them relates
to the other attributes.
Attribute relationships, which are associations between
attributes that specify how attributes are connected, are
essential to the logical data model. Without relationships,
there is no interaction between data, and therefore no logical
structure. The relationships give meaning to the data by
providing logical associations of attributes based on business
rules.
Every direct relationship between attributes has two parts—a
parent and a child. A child must always have a parent and a
parent can have multiple children. The parent attribute is at a
24 Attributes: Context for your levels of data
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
higher logical level than the child is. For example, in a
relationship between Year and Quarter, Year is the parent
attribute and Quarter is the child.
Attributes are either related or unrelated to each other.
Examples of related and unrelated attributes, along with
more detailed information about attribute relationships, are
discussed in Attribute relationships, page 159.
Hierarchies: Data relationship organization
Hierarchies in a logical data model are ordered groupings of
attributes arranged to reflect their relationship with other
attributes. Usually the best design for a hierarchy is to
organize or group attributes into logical business areas. For
example, you can group the attributes Year, Month, and Day
to form the Time hierarchy.
In a logical data model, hierarchies contain attributes that are
directly related to each other. Attributes in one hierarchy are
not directly related to attributes in another hierarchy.
For example, Year and Quarter are attributes that are usually
directly related to each other. One year has many quarters
and both attributes are in the Time hierarchy.
Year and Customer are attributes that are usually not in the
same hierarchy and are not directly related to each other.
However, if you want to create a report that shows
information about customer purchases in a particular year,
there must be some way to determine how these two
attributes are related. Year and Customer are related through
a fact. It is the existence of a fact that ties the Time hierarchy
to the Customer hierarchy. In this case, the fact is a customer
purchase.
Therefore, facts exist at the intersection of hierarchies. They
are identified by multiple attributes, which represent the
level at which a fact is stored. A graphical example of how
facts, attributes, and hierarchies are related and form a
complete logical data model is shown in the section Sample
data model, page 26 below.
© 2007 MicroStrategy, Inc.
Hierarchies: Data relationship organization
25
2
The Logical Data Model
Project Design Guide
For a complete discussion about hierarchies, refer to Chapter
7, Creating Hierarchies to Organize and Browse Attributes.
Sample data model
When all of the components are placed in a single
diagram—facts, attributes, relationships, and hierarchies—a
logical data model begins to take shape.
The following diagram is an example of a logical data model:
Building a logical data model
The first thing you must do before creating a logical data
model is study the factors that influence your design. Some of
the things to consider when creating a logical data model are
26 Sample data model
•
User requirements
•
Existing source systems
•
Converting source data to analytical data
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
User requirements
The primary goal of logical data modeling is to meet the
needs of your users’ reporting requirements. Developing such
a model involves the following:
•
Identification of user requirements
•
Design of solutions
•
Evaluation of those solutions
Logical data modeling is a reiterative process, where
additional questions and concerns arise with each draft of the
logical data model.
Your user community can consist of people with vastly
different requirements. For example, company executives are
typically interested in overall trends and may want reports
showing data aggregated across the company and over a long
period of time. Lower-level managers are typically more
interested in data about their particular areas of
responsibility. These managers may want reports about their
specific region or store over short-and long-terms.
When creating the logical data model, you must consider all
the potential users and how to accommodate their varied
requirements. In some cases, lack of data in the source
systems can limit user requirements. Sometimes, to satisfy
user requirements, you can derive additional data not found
in the source systems, as explained in Existing source
systems, page 28.
User requirements are an important part of the initial project
design process. However, additional user requirements can
be encountered after deploying a project as users encounter
areas for enhancement. In some cases, new user
requirements may require you to modify the logical data
model to better support the type of analysis and the retrieval
of data that users demand.
© 2007 MicroStrategy, Inc.
Building a logical data model
27
2
The Logical Data Model
Project Design Guide
Existing source systems
Understanding what data is available is an important step in
creating a logical data model. Existing data is usually
abundant, consisting of a large number of facts and
attributes. You must determine what facts and attributes in
the existing data are necessary for supporting the decision
support requirements of your user community.
While a review of your data is initially helpful in identifying
components of your logical data model, you may not find all
the facts and attributes to meet your needs within the data
itself. The existing data should suggest a number of facts,
attributes, and relationships, but a substantial portion of the
work in creating a suitable logical data model involves
determining what additional components are required to
satisfy the needs of the user community.
For example, an insurance company’s transactional system
records data by customer and city, but the business analysts
want to see data for different states or regions. State and
region do not appear in the existing source data and so you
need to extract them from another source. Additionally,
although data is stored at a daily level in the source system,
users also want to see data at the monthly or yearly level. In
this case, you can plan additional attributes to provide the
levels at which you intend to analyze the facts in your data
model.
Although some data may not exist in a source system, this
does not mean that it should not be included in the logical
data model. Conversely, everything you find in the source
data does not necessarily need to be included in the logical
data model. User requirements should drive the decision on
what to include and what to exclude.
Converting source data to analytical data
If there are no existing systems and you are just beginning
your data warehousing initiative, you can build the logical
data model based heavily on current user requirements.
However, most logical models begin with an examination of
the source data once existing systems are developed and
28 Building a logical data model
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
implemented. The source data usually has some sort of
documented physical structure. For example, most OLTP
systems have an entity relationship diagram (ERD). An ERD
provides a graphical representation of the physical structure
of the data in the source system, which lets you easily
recognize tables and columns and the data stored in those
columns.
logical data model is similar in concept to an ERD.
AHowever,
in this guide the logical data model also
takes into account how your data can be integrated
into MicroStrategy to develop a business intelligence
solution.
Whether you start from nothing or have an existing source
system to use, the steps to create a logical data model are as
follows:
•
Step 1: Identify the facts, page 29
•
Step 2: Identify the attributes, page 30
•
Step 3: Determine attribute relationships, page 31
•
Step 4: Define hierarchies, page 32
details in these steps are related to using an
The
existing source system.
Step 1: Identify the facts
Using your existing data, make a list of all data that can be
represented as facts in MicroStrategy. Remember that facts
can be calculated and are usually numeric and aggregatable,
for example, sales and profit figures. After you have all the
facts listed, determine the business level at which each fact is
recorded. For example, in retail models, sales facts are often
stored at the store, item, or day level, meaning that a sale
takes place in a particular store, for a particular item, on a
particular day. A product inventory fact, however, can be
© 2007 MicroStrategy, Inc.
Building a logical data model
29
2
The Logical Data Model
Project Design Guide
stored at the region, item, or week level. These business levels
become the attributes in your logical data model (see Step 2:
Identify the attributes, page 30).
Step 2: Identify the attributes
Uncover attributes by considering the levels at which you
would like to view the facts on your reports. Start by looking
at the levels at which each fact is recorded and build from
there.
For example, in the existing data there may be fact data
recorded only at the day level. However, your users are
interested in analyzing data at more than just at the day level.
They also want to view their data at the year, month, and
week levels. This information may only be apparent to you
after you deploy your project and you determine that a high
percentage of your users are viewing sales data at the yearly
level. This analysis requires MicroStrategy to aggregate the
sales data from the day level to the year level. To improve
performance and meet the requirements of the majority of
your users, you can include an aggregate table that stores
sales data at the year level (see Using summary tables to
store data: Aggregate tables, page 241). You can then design
a Year attribute for your project. This practice is sometimes a
reaction to user requirements established after project
deployment, but such considerations should be taken into
account during your initial project design initiative.
30 Building a logical data model
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
not to include more facts and attributes
Bethancareful
necessary. It is usually unnecessary to bring all
data from the source system into the analytical
environment. Only include facts and attributes that
can serve your user community. Logical data modeling
is an iterative process; if necessary, you can always add
more attributes and facts later.
Step 3: Determine attribute relationships
Once you have identified your data to be defined as attributes
in MicroStrategy, you must then determine which attributes
are related to each other. For example, in the Sales Force
Analysis Module of the MicroStrategy BIDK opportunity
information is stored with an Opportunity attribute which is
directly related to the attributes Opportunity Close Date,
Opportunity Open Date, Primary Competitor, and so on.
These attributes are all related to the Opportunity attribute
because they all answer questions about opportunity
information.
Additionally, you should determine the type of relationship.
For example, in the diagram below, Year has a one-to-many
relationship to Month, and Month has a one-to-many
relationship to Day. This one-to-many relationship specifies
that, for every year, several months exist, and for every
month, several dates exist. From the reverse perspective the
same relationship specifies that, for a number of dates (in a
© 2007 MicroStrategy, Inc.
Building a logical data model
31
2
The Logical Data Model
Project Design Guide
form such as 12/01/2005), only one month exists (in a form
such as Dec 2005), and for a number of months, only one
year exists.
example may not accurately define how you store
This
time information. Consider the Year to Month
attribute relationship type of one-to-many. If you
define the attribute Month as simply the month name
(Dec, Jan, and so on) and not directly connected to a
year (Dec 2005, Jan 2006, and so on) then the
relationship would become many-to-many.
If you have documentation for the existing data, such as an
ERD, it is likely that the documentation provides some
additional details about the nature of the data and any
inherent relationships.
Attribute relationships are discussed in detail in Attribute
relationships, page 24.
Step 4: Define hierarchies
Hierarchies provide a structure for your data and can help
your users easily and intuitively browse for related attributes
and include them in a report. In the context of a logical data
model, think of hierarchies as logical arrangements of
attributes into business areas. For example, you can organize
all time-related attributes into the Time hierarchy. You can
32 Building a logical data model
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
have a Customer hierarchy containing all attributes related to
your customers and a Supplier hierarchy for all attributes
related to supplier data.
on the complexity of your data and the
Depending
nature of your business, you may have very few
hierarchies or you may have many. It is possible that
all the data is directly related, in which case you may
have one big hierarchy. Again, the requirements of
your user community should help you determine what
hierarchies are necessary.
Logical data modeling conventions
There are numerous logical data modeling conventions you
can use to enhance your logical data model. These include:
•
Unique identifiers
•
Cardinalities and ratios
•
Attribute forms
These logical modeling conventions can provide cues for
system optimization opportunities, help with system
maintenance, and make for a more robust logical data model.
Although the user community is the ultimate beneficiary of a
© 2007 MicroStrategy, Inc.
Logical data modeling conventions
33
2
The Logical Data Model
Project Design Guide
well-optimized and maintained system, these conventions
are primarily intended for project designers, administrators,
and advanced report designers.
Each convention adds more information about the data to the
logical data model. This additional information can be
particularly useful to a person learning about the system.
Unique identifiers
An additional modeling convention is to add unique
identifiers for each attribute and fact. Unique identifiers
denote the key that maps an attribute to its source data in the
source system, when applicable. This information can help
define primary keys in the physical warehouse schema (see
Uniquely identifying data in tables with key structures,
page 42).
Remember that facts are usually identified by multiple
attributes and therefore will have multiple unique identifiers.
The following diagram shows a logical data model with
unique identifiers added. Some attributes rely on more than
34 Logical data modeling conventions
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
one ID column to identify its elements. For example, note the
Item attribute, which requires both the Item_ID and
Class_ID columns to uniquely identify its elements.
Cardinalities and ratios
Another enhancement to the logical data model is the
addition of cardinalities and ratios for each attribute.
Cardinality is the number of unique elements for an attribute
and ratios are the ratios between the cardinalities of related
attributes.
Cardinalities help the database administrator estimate the
size of the data warehouse and help project designers
determine the best paths for users to navigate through the
data using hierarchies in MicroStrategy, which are discussed
in Chapter 7, Creating Hierarchies to Organize and Browse
Attributes. Ratios can be particularly helpful when trying to
© 2007 MicroStrategy, Inc.
Logical data modeling conventions
35
2
The Logical Data Model
Project Design Guide
decide where creating aggregate tables will be most effective.
This additional information can be invaluable to database
administrators and project designers.
The following diagram shows a logical data model which
includes cardinalities and ratios. Note the cardinalities in the
upper right corner of each attribute rectangle and the ratios
next to some of the relationships between attributes. Also
note that the cardinality of some attributes such as Date of
Birth are unknown; this is because this information varies
and is unpredictable. For example, it is impossible to
determine how many customers have different dates of birth
in the warehouse.
Attribute forms
Including attribute forms in your logical data model can help
you get a more complete view of all of the information that is
made available in your project.
36 Logical data modeling conventions
© 2007 MicroStrategy, Inc.
Project Design Guide
The Logical Data Model
2
Attribute forms contain additional descriptive information
about a given attribute. For example, you create an attribute
called Customer to represent customers in your system, and
it is part of the Customer hierarchy. Each element of the
Customer attribute represents a different customer, and in
the data, you store the following information about your
customers:
•
Customer number (some numeric code used to uniquely
identify customers)
•
First name
•
Last name
•
Address
•
Email address
In your logical data model, you could have included each of
these pieces of information as separate attributes, each with a
one-to-one relationship to the Customer attribute. In reality,
though, these attributes simply provide additional
information about the Customer attribute; they do not
represent different levels within the Customer hierarchy.
When a one-to-one relationship exists between an attribute
and one of its descriptions, you can model these additional
© 2007 MicroStrategy, Inc.
Logical data modeling conventions
37
2
The Logical Data Model
Project Design Guide
pieces of descriptive information as attribute forms. The
following diagram shows how you add attribute forms to a
logical data model:
forms are discussed in terms of their role in
Attribute
MicroStrategy in Column data descriptions and
identifiers: Attribute forms, page 143.
38 Logical data modeling conventions
© 2007 MicroStrategy, Inc.
3
3.
WAREHOUSE STRUCTURE FOR
YOUR LOGICAL DATA MODEL
Physical Warehouse Schema
Introduction
As discussed in the previous chapter, the logical data model
can help you think about the logical structure of your
business data and the many relationships that exist within
that information.
The physical warehouse schema is based on the logical data
model. It is a detailed graphic representation of your business
data as it is stored in the data warehouse. The physical
warehouse schema organizes the logical data model in a
method that makes sense from a database perspective.
contrast, the logical data model is a logical
Inarrangement
of data from the perspective of the
general user or business analyst. For more
information on what a logical data model is and how to
create one, see Chapter 2, The Logical Data Model.
The logical data model is only concerned with logical objects
of the business model, such as Day, Item, Store, or Account.
Several physical warehouse schemas can be derived from the
same logical data model. The structure of the schema
© 2007 MicroStrategy, Inc.
39
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
depends on how the data representing those logical objects
are to be stored in the warehouse. For example you can store
logical objects in the same table, in separate tables,
duplicated across several tables, or in some other
arrangement.
While the logical data model tells you what facts and
attributes to create, the physical warehouse schema tells you
where the underlying data for those objects is stored. The
physical warehouse schema describes how your data is stored
in the data warehouse and how it can be retrieved for
analysis.
Creating a physical warehouse schema is the next step in
organizing your business data before you create a project, as
shown below:
The key components that make up the physical warehouse
schema are columns and tables.
Columns and tables in the physical warehouse schema
represent facts and attributes from the logical data model.
The rows in a table represent attribute elements and fact
data.
40
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
Columns: Data identifiers and values
Columns are fields in the warehouse that contain attribute
and fact data. The types of columns are:
•
ID columns contain attribute element identification
codes. These codes are typically numeric because
computers can process numbers much more rapidly than
text. All attributes must have an ID column.
•
Description columns contain descriptions (text or
numeric) of attribute elements. Description columns are
optional.
An ID column can serve a dual purpose as both an ID and
description. Date is one example of an attribute that
usually does not have a description column.
The majority of attributes typically have an ID column
and at least one description column. If an attribute has
many attribute forms—additional descriptive information
about a given attribute—they are represented by
additional description columns.
•
Fact columns contain fact data.
Tables: Physical groupings of related data
The different types of tables are
•
Lookup tables: Attribute storage, page 43
•
Relate tables: A unique case for relating attributes,
page 45
•
Fact tables: Fact data and levels of aggregation, page 46
While each type of table may function differently within the
data warehouse, each type of table can be assigned a primary
key that uniquely identifies the elements within the given
table.
© 2007 MicroStrategy, Inc.
Columns: Data identifiers and values
41
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
Uniquely identifying data in tables with key structures
In relational databases, each table has a primary key that
creates a unique value identifying each distinct data record or
row. This applies to every type of table within the data
warehouse.
The types of keys that can be assigned to a table include:
•
Simple key requires only one column to identify a record
uniquely within a table.
•
Compound key requires multiple columns to identify a
unique record.
Which key structure you use to identify a unique attribute in
a table depends on the nature of your data and business
requirements. The following diagram shows how the
different key structures can be used to identify a calling
center.
The simple key shows how you can identify a calling center
with only its Call_Ctr_id. This means that every calling
center has its own unique ID.
In the compound key, calling centers are identified by both
Call_Ctr_id and Region_id. This means that two calling
centers from different regions can share the same
Call_Ctr_id. For example, there can be a calling center
with ID 1 in region A, and another calling center with ID 1 in
region B. In this case, you cannot identify a unique calling
center without knowing both the Call_Ctr_id and the
Region_id.
Simple keys are generally easier to handle in the data
warehouse than are compound keys because they require less
storage space and they allow for simpler SQL. Compound
42 Tables: Physical groupings of related data
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
keys tend to increase SQL query complexity, query time, and
required storage space. However, compound keys have a
more efficient ETL process.
Which key structure you use for a particular attribute
depends entirely on the nature of the data and your system.
Consider what key structures work best when creating lookup
tables in the physical warehouse schema.
Lookup tables: Attribute storage
Lookup tables are the physical representation of attributes.
They provide the ability to aggregate data at different levels.
Lookup tables store the information for an attribute in ID and
description columns (see Columns: Data identifiers and
values, page 41).
Depending on how you choose to organize the physical
schema, a lookup table can store information for one or more
related attributes. If a table only stores data about one
attribute, it is said to be a normalized table. If a table holds
data about multiple attributes, it is said to be a denormalized
table.
The following diagram shows the different ways in which you
can organize the same attribute information. Notice that the
denormalized table holds the exact same data as the
normalized tables. While the denormalized table consolidates
© 2007 MicroStrategy, Inc.
Tables: Physical groupings of related data
43
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
information about attributes within one table, the normalized
tables each contain only a subset of all of the information
about the attributes.
You can use either structure for any table in the physical
warehouse schema, though each structure has its advantages
and disadvantages, as explained in the following sections and
outlined in the table in Schema type comparisons, page 60.
Attribute relationships and lookup table
structure
Attribute relationships are a major factor in determining the
structure of lookup tables in a physical warehouse schema. In
general, the following guidelines apply:
•
One-to-one relationships usually denote the existence of
an attribute form. The description column of an attribute
form should simply be included as an additional column
in the attribute’s lookup table.
•
Many-to-many relationships usually require the use of a
relate table distinct from either attribute lookup table. A
relate table should include the ID columns of the two
attributes in question. For more information on how to
use relate tables, see Relate tables: A unique case for
relating attributes, page 45.
44 Tables: Physical groupings of related data
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
Relate tables: A unique case for relating attributes
While lookup tables store information about attributes, relate
tables store information about the relationship between two
attributes. Relate tables contain the ID columns of two or
more attributes, thus defining associations between them.
Relate tables are often used to create relationships between
attributes that have a many-to-many relationship to each
other.
With attributes whose direct relationship is one-to-many—in
which every element of a parent attribute can relate to
multiple elements of a child attribute—you define
parent-child relationships by placing the ID column of the
parent attribute in the lookup table of the child attribute. The
parent ID column in the child table is called a foreign key.
This technique allows you to define relationships between
attributes in the attributes’ lookup tables, creating tables that
function as both lookup tables and relate tables as shown in
the following diagram:
In the case of a many-to-many relationship—in which
multiple elements of a parent attribute can relate to multiple
elements of a child attribute—you must create a separate
relate table as shown in the following diagram:
© 2007 MicroStrategy, Inc.
Tables: Physical groupings of related data
45
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
Fact tables: Fact data and levels of aggregation
Fact tables are used to store fact data. Since attributes
provide context for fact values, both fact columns and
attribute ID columns are included in fact tables. Facts help to
link indirectly related attributes. The attribute ID columns
included in a fact table represent the level at which the facts
in that table are stored.
For example, fact tables containing sales and inventory data
look like the tables shown in the following diagram:
For more details on the level of aggregation of your fact data,
see Fact table levels: The context of your data, page 48.
46 Tables: Physical groupings of related data
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
Base fact columns versus derived fact columns
The types of fact columns are base fact columns and derived
fact columns:
•
Base fact columns are represented by a single column in a
fact table. The following diagram shows an example of a
fact table and base fact columns:
•
Derived fact columns are created through a mathematical
combination of other existing fact columns. The following
diagram shows an example of a fact table and how you can
create a derived fact column from base fact columns:
In the example, the derived fact Tot_Dollar_Sales is
created using the Qty_Sold, Unit_Price, and Discount
fact columns. Also, the derived fact exists in several tables,
including Item_Mnth_Sls and City_Ctr_Sls.
© 2007 MicroStrategy, Inc.
Tables: Physical groupings of related data
47
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
Because facts in different fact tables are typically stored at
different levels, derived fact columns can only contain fact
columns from the same fact table.
There are advantages and disadvantages to consider when
deciding if you should create a derived fact column. The
advantage of storing derived fact columns in the warehouse is
that the calculation of data is previously performed and
stored separately, which translates into simpler SQL and a
speedier query at report run time. The disadvantage is that
derived fact columns require more storage space and more
time during the ETL process.
You can create the same type of data analysis in
MicroStrategy with the use of metrics. Metrics allow you to
perform calculations and aggregations on fact data from one
or more fact columns. For more information on what metrics
are and how to create them, see the MicroStrategy Advanced
Reporting Guide.
For more information on the different types of facts in
MicroStrategy and how they are defined, see How facts are
defined, page 97.
Fact table levels: The context of your data
Facts and fact tables have an associated level based on the
attribute ID columns included in the fact table. For example,
the following image shows two facts with an Item/Day/Call
Center level.
The Item_id, Day_id, and Call_Ctr_id columns in the
table above represent practical levels at which sales and
inventory data can be analyzed on a report. The Sales and
Inventory facts can be analyzed at the item, day, and call
center levels because those levels exist as ID columns in the
fact table.
48 Tables: Physical groupings of related data
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
You do not need to include more lookup column IDs than are
necessary for a given fact table. For example, notice that the
table above does not include the Customer_id column; this
is because analyzing inventory data at the customer level does
not result in a practical business calculation. Fact tables
should only include attribute ID columns that represent
levels at which you intend to analyze the specific fact data.
The levels at which facts are stored become especially
important when you begin to have complex queries with
multiple facts in multiple tables that are stored at levels
different from one another, and when a reporting request
involves still a different level. You must be able to support
fact reporting at the business levels which users require.
Homogeneous versus heterogeneous column naming
Suppose the data warehouse has information from two
source systems, and in one source system regions are
identified by column name Region_id and in the other the
column name is Reg_id, as shown in the diagram below.
These naming inconsistencies occur because source systems
use different naming conventions to name the data they
collect.
Though the Region_id and Reg_id columns have different
names, they store the same data: information about regions.
This is called heterogeneous column naming.
© 2007 MicroStrategy, Inc.
Tables: Physical groupings of related data
49
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
The data for the Lookup_Region table came from a
different source system than the data for the
Lookup_Call_Ctr and the source systems have different
naming conventions. This explains why the same information
about regions is represented by two columns with different
names.
When you define facts and attributes in MicroStrategy
Desktop, consider the heterogeneous column names that may
exist in your source systems. In order for reports to retrieve
accurate and complete results, heterogeneous columns must
be mapped to their corresponding facts and attributes.
For example, if you create a Region attribute given the tables
in the example above, you must map both the Region_id
and Reg_id columns to the attribute so all information about
regions is calculated correctly and displayed on reports when
the Region attribute is used.
For consistency, it is a good idea for columns that contain the
same data to have the same column name. This is called
homogeneous column naming. In this case, the Region_ID
column has the same name in both tables, as shown in the
following diagram:
50 Tables: Physical groupings of related data
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
Just as it is possible for the same attribute data to exist in
different lookup tables, it is also possible for the same fact
data to exist in different fact tables. A fact column may or
may not have the same name in different tables, as shown
below:
Schema types: Data retrieval performance
versus redundant storage
There are many ways to structure your data warehouse and
no method is inherently right or wrong. How you choose to
structure the warehouse depends on the nature of your data,
the available storage space, and the requirements of your
user community. Typically, one of the schema types, or a
combination of them, is used to organize the physical schema
to enhance query performance while maintaining and
acceptable amount of data storage space. These schema types
are:
© 2007 MicroStrategy, Inc.
•
Highly normalized schema: Minimal storage space
•
Moderately normalized schema: Balanced storage space
and query performance
•
Highly denormalized schema: Enhanced query
performance
Schema types: Data retrieval performance versus redundant storage
51
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
In each of these schemas a base fact table and any number of
aggregate fact tables are used (For more information on
aggregate fact tables, see Using summary tables to store
data: Aggregate tables, page 241). Fact table keys consist of
attribute keys relevant to the level of data stored in the table.
The schema examples that follow show data at the Item/Call
Center/Date level.
When comparing the different schema types, you should keep
in mind the following concepts:
•
Redundant data can cause a couple of drawbacks. The
most obvious drawback is that redundant data requires
more storage space to hold the same amount of data as a
system with no redundancy.
Data redundancy also makes updating data a more
intensive and difficult process because data resides in
multiple places. With no data redundancy, data only has
to be updated in a single place.
•
Joins are SQL operations that are required to combine
two tables together in order to retrieve data. These
operations are necessary, but as with any operation
performed on your data warehouse, the number of joins
required to build your queries affects the performance of
those queries.
•
The sections below are not meant to be an exhaustive list
of all possible schema types. However, the sections below
are meant to give a description of the most common or
general schema types that are used to develop a physical
warehouse schema.
Highly normalized schema: Minimal storage space
The following diagram is an example of a highly normalized
schema. In highly normalized schemas, lookup tables contain
unique developer-designed attribute keys, such as
Call_Ctr_id, Dist_Ctr_id, and Region_id, as shown
in the figure below. They also contain attribute description
columns, such as Call_Ctr_desc, Dist_Ctr_desc, and
52 Schema types: Data retrieval performance versus redundant storage
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
Region_desc. Also, the lookup table for an attribute contains
the ID column of the parent attribute, such as Dist_Ctr_id
in the Lookup_Call_Ctr table.
© 2007 MicroStrategy, Inc.
Schema types: Data retrieval performance versus redundant storage
53
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
The following diagram shows what physical lookup tables
look like in the warehouse:
One benefit of using a highly normalized schema is that it
requires minimal storage space in the warehouse because of
it uses smaller lookup tables than the other schema types.
However, there is a drawback to using only small tables in the
data warehouse. When accessing higher-level lookup tables
such as Lookup_Region in the example above, numerous
joins are required to retrieve information about the
higher-level tables. This is because each table contains only a
small amount of information about a given attribute;
therefore, multiple tables must be joined until the required
column is found.
Moderately normalized schema: Balanced storage space and
query performance
The following diagram shows an example of a moderately
normalized schema. This schema type has the same basic
structure as the highly normalized schema. The difference
54 Schema types: Data retrieval performance versus redundant storage
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
here is the higher-level attribute ID columns are present
within all tables of related attributes. For example,
Region_id is included in the Lookup_Call_Ctr table.
© 2007 MicroStrategy, Inc.
Schema types: Data retrieval performance versus redundant storage
55
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
The fact table structure within a moderately normalized
schema is identical to that of the highly normalized schema.
The following diagram shows what the physical lookup tables
look like in the warehouse.
Using a moderately normalized schema provides a balance
between the pros and cons of normalized and denormalized
schema types. Because the ID columns of both the parents
and grandparents of an attribute exist in multiple tables,
fewer joins are required when retrieving information about
an attribute.
However, since some tables contain the same ID columns (as
shown above with the Region_ID column), the tables within
this type of schema take up some redundant storage space in
the warehouse.
Highly denormalized schema: Enhanced query performance
The following diagram is an example of a highly
denormalized schema. A highly denormalized schema has
the same basic structure as the other two schema types. With
56 Schema types: Data retrieval performance versus redundant storage
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
this type, not only are higher-level attribute ID columns
present within all related tables, but the description columns
are present as well. For example, Region_desc is included
in the Lookup_Call_Ctr table.
Using a highly denormalized schema further reduces the
joins necessary to retrieve attribute descriptions. For
example, you can include the descriptions of Call Center,
Distribution Center, and Region along with Sales Dollars in
the same report while only having to join the
Lookup_Call_CTR and Fact_Sales tables. This is
possible because Lookup_Call_CTR contains all
information (including description data) for Call Center as
well as for Distribution Center and Region.
However, this schema type requires the largest amount of
storage space within the warehouse because of its large
lookup tables. High denormalized schemas also cause the
highest level of data redundancy.
© 2007 MicroStrategy, Inc.
Schema types: Data retrieval performance versus redundant storage
57
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
Star schema: Consolidating lookup tables
When using the highly denormalized schema, it is possible to
eliminate most of the lookup tables and leave just a few, as
shown below. Arranging the warehouse schema this way
produces a star schema. In this type of schema, the lookup
tables are consolidated so that every attribute ID and
description column for a given hierarchy exists in one table.
Recall that in a highly denormalized schema, each hierarchy
(for example, geography) consists of several lookup tables. In
a star schema, however, only one lookup table is used to
contain all of the attribute IDs and description columns for a
given hierarchy, as shown below:
As with any schema type model there are advantages and
disadvantages to using a star schema. As with a highly
denormalized schema type, the amount of join operations are
reduced by using a star schema. A star schema can also
reduce the amount of storage space necessary in a highly
denormalized schema. However, star schemas can often
58 Schema types: Data retrieval performance versus redundant storage
© 2007 MicroStrategy, Inc.
Project Design Guide
Warehouse Structure for Your Logical Data Model
3
require large lookup tables that can take a more time to
search than the smaller tables that are used in the other
schema types.
Design trade-offs
Constructing a logical data model and physical warehouse
schema is an iterative process of compromises and trade-offs.
The following diagram shows the three major requirements
that must be balanced to create an effective system.
Each of these categories affects the others. If you try to satisfy
every single user requirement from the simplest to the most
complex, you will have to create an extensive data model and
schema to support those requirements. This results in an
increased load on the warehouse, slower query performance,
and greater maintenance for the database administrator. You
must decide which factors are most important in your
particular environment and weigh them against the other
factors.
For example, if you have the storage space necessary to
accommodate data in a star schema it may seem that you
would never want to normalize your schema. However, SQL
queries directed at a consolidated table require the use of a
DISTINCT operator and these types of queries tend to be very
© 2007 MicroStrategy, Inc.
Design trade-offs
59
3
Warehouse Structure for Your Logical Data Model
Project Design Guide
expensive in terms of database resources and processing
time. The use of a resource-intensive DISTINCT query could
therefore negate any performance gain achieved by reducing
the number of joins between higher-level lookup tables.
In addition to the previous points, you may need higher level
lookup tables to take advantage of aggregate tables, which are
discussed in Using summary tables to store data: Aggregate
tables, page 241.
For more comparisons between the different schema types
described in this chapter, see the following section Schema
type comparisons, page 60.
Schema type comparisons
One way to achieve a balance of the various trade-offs in your
schema design is to use a variety of schema types in your
physical warehouse schema. One hierarchy can be highly
normalized while another can be highly denormalized. You
can even use different schema types within the same
hierarchy. The table below compares the different schema
types.
Schema Type
Lookup Table
Structure
Advantages
Disadvantages
Highly
normalized
schema
• Attribute ID
• Attribute
description
column
• ID column of
parent
Minimal storage space and
minimal data redundancy
which makes updating data
less intensive than for the
other schema types
Requires numerous joins to
retrieve information from
higher-level lookup tables
Moderately
normalized
schema
• Attribute ID
• Attribute
description
column
• ID column of
parent
• ID column of
grandparents
Greatly reduces the number of
joins necessary to relate an
attribute to its grandparents as
compared to a highly
normalized schema
Requires some redundant
storage
60 Schema type comparisons
© 2007 MicroStrategy, Inc.
Project Design Guide
Schema Type
Warehouse Structure for Your Logical Data Model
Lookup Table
Structure
Advantages
Disadvantages
Requires the most storage
space and redundant data
requires a more intensive
process to update
Highly
denormalized
schema
• Attribute ID
• Attribute
description
column
• ID column of
parent
• description
column of parent
• ID column of
grandparents
• description
column of
grandparents
Further reduces joins
necessary to retrieve attribute
descriptions as compared to a
moderately normalized
schema
Star schema
• Consolidates an
entire hierarchy
into a single
lookup table
• Further reduces joins
necessary to retrieve
attribute descriptions as
compared to a moderately
normalized schema
• Requires less storage
space and data
redundancy than a highly
denormalized schema and
thus data is easier to
update
3
Large lookup tables can
negatively affect query
performance when searching
tables and requiring
DISTINCT operations to be
performed
Now that you have gained an understanding of data modeling
and the roles of facts and attributes, you can learn about
these same schema objects in terms of how they exist in the
MicroStrategy environment. As facts and attributes are the
cornerstones of the reports you intend to create using
MicroStrategy, it is essential to understand the structure of
each of these schema objects before creating a project.
© 2007 MicroStrategy, Inc.
Schema type comparisons
61
3
Warehouse Structure for Your Logical Data Model
62 Schema type comparisons
Project Design Guide
© 2007 MicroStrategy, Inc.
4
4.
CREATING AND CONFIGURING
A PROJECT
Introduction
Once you create a logical model of your business data and
arrange the data within the data warehouse, you are ready to
create a project in MicroStrategy.
This chapter guides you through the first few major steps
involved in creating a project in MicroStrategy. For
definitions and descriptions of the components within the
MicroStrategy platform that allow you to create and analyze
your business intelligence applications, see Chapter 1, BI
Architecture and the MicroStrategy Platform.
see a sample project, access the MicroStrategy
ToTutorial
provided with the MicroStrategy platform.
The Tutorial is a sample data warehouse and
demonstration project you can use to learn about the
various features of the MicroStrategy platform. It is
ready to be used and requires no additional
configuration tasks. For more information about the
© 2007 MicroStrategy, Inc.
63
4
Creating and Configuring a Project
Project Design Guide
Tutorial, refer to the MicroStrategy Basic Reporting
Guide. To view the structure of the MicroStrategy
Tutorial, see Appendix A, MicroStrategy Tutorial.
Project connectivity components
This section defines some of the basic terminology used in
project creation in MicroStrategy Desktop. It is intended to
familiarize you with some of the terms discussed in this
guide.
MicroStrategy metadata
All schema objects, application objects, configuration objects,
and project settings are stored in the MicroStrategy
metadata. Metadata is stored in a relational database with a
predefined structure. The RDBMS for the metadata and
warehouse do not need to be the same.
64 Project connectivity components
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
can find the list of supported RDBMS platforms in
You
the readme file that is installed with MicroStrategy
products. To view the readme from the Start menu
select Programs, then MicroStrategy, and then select
ReadMe.
Metadata shell
Before you can populate the metadata repository with data,
the necessary tables to hold the data must be present. The
metadata shell is the set of blank tables that are created when
you initially implement a MicroStrategy business intelligence
environment.
You create the metadata shell with the MicroStrategy
Configuration Wizard, which creates the blank tables and
populates some of the tables with basic initialization data.
This first step in the project creation process is outlined in
Creating the metadata repository, page 71.
Project source
The project source is a configuration object which represents
a connection to a metadata repository. In MicroStrategy
Desktop, the project source appears in the Folder List with an
icon that varies depending on the type of connection it
represents. A connection to a metadata repository is achieved
in one of two ways:
•
Direct or two-tier mode ( ): Connects to the metadata
by specifying a DSN, login, and password to a metadata
repository.
is highly recommended that you never use direct
Itmode
connection in a production environment.
MicroStrategy strongly suggests you always
connect to the metadata through Intelligence
Server because of the security and scalability it
provides. You should not connect directly to the
metadata unless you are implementing a prototype
environment.
© 2007 MicroStrategy, Inc.
Project connectivity components
65
4
Creating and Configuring a Project
•
Project Design Guide
Server or three-tier mode( ): Connects to the
metadata by pointing to an Intelligence Server definition,
which in turn governs and validates the connection to the
metadata. The project metadata is the first tier,
MicroStrategy Desktop is the second tier, and Intelligence
Server is the third tier. Intelligence Server manages all
connections to databases, enforces security, and ensures
metadata integrity. For these reasons, Intelligence Server
is a necessary part of any production project.
four-tier connection is a Server (three-tier)
Aconnection
in conjunction with MicroStrategy Web
deployed on a web server.
The following diagram illustrates Server connectivity
between a MicroStrategy metadata repository, Intelligence
Server, and MicroStrategy Desktop. This is the type of
connection used to create a production-ready project in
MicroStrategy.
After the connection to the metadata is established, every
object definition you create within this project source is
stored in this metadata. This includes application objects,
schema objects, and configuration objects from any number
of projects defined within this project source (see
MicroStrategy metadata, page 8 for definitions of these
object types).
A project source connects to a single metadata repository.
However, the same metadata repository can be accessed by
multiple project sources. A project source may contain any
number of projects.
66 Project connectivity components
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
Database instance
The database instance is a configuration object that
represents a connection to a data source. When you define a
project, you specify the data source location by creating and
selecting a database instance with the appropriate connection
parameters.
For information on database instances, see the
MicroStrategy Installation and Configuration Guide.
Connecting to a data source through a database instance is
explained in detail in Connecting to a data source, page 72.
Project
A project is where you build and store all schema objects and
information you need to create application objects such as
reports in the MicroStrategy environment. A project also
represents the intersection of a data source, metadata
repository, and user community. For more information on
what a project is in MicroStrategy, see MicroStrategy
project, page 14.
© 2007 MicroStrategy, Inc.
Project connectivity components
67
4
Creating and Configuring a Project
Project Design Guide
Summary of project connectivity
With a firm understanding of the MicroStrategy metadata,
project sources, database instances, and projects, you can
begin to build an understanding of how these various pieces
work together to provide an integrated business intelligence
environment as shown in the following diagram.
Creating a project
The following procedure describes the main steps to create a
MicroStrategy project. These steps provide you with a
high-level view of the project creation process. Bear this
process in mind as you proceed through the rest of this guide.
1 Creating the metadata repository
The metadata repository contains the objects and
definitions associated with your project. It acts as the
68 Creating a project
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
intermediary between your business data and your
reporting environment. Therefore, the first step in the
project creation process is to create a metadata repository.
For detailed instructions, see Creating the metadata
repository, page 71.
2 Connecting to the metadata repository and data source
Once the metadata repository is created and populated
with initialization data, you must establish connections to
both the metadata repository and data source. For
detailed instructions, see Connecting to the metadata
repository and data source, page 71.
3 Creating the project
Having created a metadata repository and established the
necessary connections between the different parts of your
MicroStrategy environment, you are ready to create the
basic definition of your project. For detailed instructions,
see Creating the project, page 73.
4 Creating facts and attributes
Schema objects such as facts and attributes are the basic
components of the logical structure of a project. The
business data your user community wants to report on is
represented by schema objects in MicroStrategy.
Therefore, it is necessary to setup schema objects before
reports can be created. This step is covered in Creating
facts and attributes, page 82 of this chapter.
can use Query Builder or Freeform SQL to
You
create schema objects as you design reports. For
more information for these features, see the
MicroStrategy Advanced Reporting Guide.
© 2007 MicroStrategy, Inc.
Creating a project
69
4
Creating and Configuring a Project
Project Design Guide
5 Configuring additional schema-level settings
Once you create the initial schema objects, you can
configure additional schema-level settings that allow you
to add complexity and depth to objects in your project and
to the project as a whole. For example, you can create
advanced facts and attributes to retrieve specific result
sets. You can also use attributes to create time-series
analysis schema objects called transformations and
implement various tools to optimize and maintain your
project over time. For information about:
•
Advanced fact creation, see Creating and modifying
simple and advanced facts, page 91.
•
Advanced attribute creation, see Adding and
modifying attributes, page 134.
•
Hierarchies and hierarchy creation, see Chapter 7,
Creating Hierarchies to Organize and Browse
Attributes.
•
Transformations and transformation creation, see
Chapter 9, Creating Transformations to Define
Time-Based and Other Comparisons.
•
Project optimization and maintenance, see Chapter 8,
Optimizing and Maintaining Your Project.
steps listed above relate to the process of creating
The
a project which connects to a database or other data
source such as a text file or Excel file. MicroStrategy
also supports connecting to data stored in SAP BW,
Microsoft Analysis Services 2000 and 2005, and
Hyperion Essbase systems. When integrated with
MicroStrategy, these systems are referred to as OLAP
cube sources. You can connect to any of these OLAP
cube sources to report and analyze the data
concurrently within a project that also connects to a
database, or you can create a a standalone connection
to your OLAP cube source (see Appendix B,
Connecting to OLAP Cube Sources).
70 Creating a project
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
Creating the metadata repository
Your first step in project creation is to create a metadata
repository. This repository stores all the objects necessary to
support your project.
You can create an empty metadata repository in the database
location of your choice using the Metadata Tables option in
the Configuration Wizard.
proceeding to the next section, make sure your
Before
metadata repository exists in a non-Microsoft Access
database. An Access database is unsuitable for a
production project.
Create a metadata repository using the guidelines outlined in
the Configuring and Connecting Intelligence Server chapter
of the MicroStrategy Installation and Configuration Guide.
When you create the metadata repository, MicroStrategy
creates a default configuration in the repository. The default
configuration populates the tables with the basic data
required for the metadata, such as the default project folder
structure and basic connection information.
These tables are populated with your project information
during the project creation step in the Project Creation
Assistant, outlined in Creating the project, page 73.
instructions on creating a metadata repository in a
For
database, see the MicroStrategy Installation and
Configuration Guide.
Connecting to the metadata repository and data
source
Once you have created a metadata repository, your next step
is to connect MicroStrategy Desktop to the metadata
repository and to your data source.
© 2007 MicroStrategy, Inc.
Creating the metadata repository
71
4
Creating and Configuring a Project
Project Design Guide
Connecting to the metadata repository
You connect to the metadata repository in MicroStrategy
Desktop or Web through a project source. Recall that a
project source is a pointer to a metadata repository. It
connects either through a DSN that points to the appropriate
database location or by pointing to an instance of Intelligence
Server which, in turn, points to the metadata repository
location.
To configure Intelligence Server and establish a server
connection between the metadata, Intelligence Server, and
MicroStrategy Desktop, follow the steps in the MicroStrategy
Installation and Configuration Guide.
Connecting to a data source
A data source contains the business data from which you
intend to gain analytical insight. Once you connect to the
metadata repository through Intelligence Server, your next
step is to create a connection to the data source to which your
project can connect. You connect to the data source by
creating a database instance in MicroStrategy Desktop.
Create a database instance using the procedures outlined in
the Configuring and Connecting Intelligence Server chapter
of the MicroStrategy Installation and Configuration Guide.
When you create a project, you must assign a database
instance to that project. A project specifies only one database
instance at a time, but a database instance can be assigned to
multiple projects.
72 Connecting to the metadata repository and data source
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
also allows you to connect to your SAP
MicroStrategy
BW, Microsoft Analysis Services, and Hyperion
Essbase data sources. For information about
connecting to these OLAP cube sources, see Appendix
B, Connecting to OLAP Cube Sources.
Creating the project
You can now begin building the MicroStrategy project that
connects to the metadata repository and data source. Project
creation involves creating a basic project definition and
creating your project’s first schema objects.
There are several methods for creating and editing a project,
which includes:
•
Creating a test or prototype project using Project Builder
With Project Builder, you can build project prototypes for
proof-of-concept tests with your own data. Project Builder
is best suited for creating a test project, and it is not
intended to create production projects.
•
Creating a production project using Project Creation
Assistant
This section guides you through the creation of a
production-ready MicroStrategy project.
The following table compares the main features of both the
Project Creation Assistant and Project Builder. Use the table
to determine the project creation tool that best suits your
needs.
Features
Project Creation Assistant
Project Builder
Intended audience
Advanced users
Newer users
Project type
Production-ready or other large
projects
Test or basic projects
Complexity
Extensive features require more
project design knowledge
Easier to use but fewer features
© 2007 MicroStrategy, Inc.
Creating the project
73
4
Creating and Configuring a Project
Project Design Guide
Features
Project Creation Assistant
Project Builder
Functionality
Advanced; can create the following
objects and more:
• multiple tables, attributes, and facts
at once
• attributes with many-to-many and
joint child relationships
Limited; cannot be used to create
multiple schema objects at once, but
can be used to create basic
hierarchies and metrics
Metadata repository
type
A variety of databases and other data
sources
Microsoft Access
Metric and report
creation
No, must be done after project creation Yes, basic metrics and reports only
Creating a test or prototype project using Project Builder
Project Builder is a wizard that allows you to create simple
MicroStrategy projects quickly and efficiently. Project Builder
was created with speed in mind; thus it provides only a subset
of the features and functionality of the Project Creation
Assistant. It allows you to rapidly create user hierarchies and
simple metrics and reports. With Project Builder, you can
build project prototypes for proof-of-concept tests with your
own data and simple yet functional projects.
To create a project for your production environment, it is
highly recommended you follow the steps outlined in
Creating a production project using Project Creation
Assistant, page 75. The Project Creation Assistant can add
greater functionality and capability to your project in your
production environment.
To learn more about Project Builder, proceed through this
section. You can also refer to the Introduction to
MicroStrategy: Evaluation Guide and the Project Builder
online help (press F1 from within Project Builder).
Using Project Builder
By default, Project Builder uses a Microsoft Access database
for the metadata repository. A Microsoft Access database is
suitable for creating the metadata repository for a prototype
74 Creating the project
© 2007 MicroStrategy, Inc.
Project Design Guide
4
Creating and Configuring a Project
project, but not a production project. You should not use
Microsoft Access for anything other than a proof-of-concept
or demonstration type of application.
can use Project Mover to move a demonstration
You
project into a production-ready database (see the
System Administration Guide.)
Project Builder contains the following options that assist you
in creating a prototype project:
•
My Database allows you to name the project and select
the database that contains the business information you
want to analyze with the project you create.
•
My Business Model allows you to identify relationships
that define the business information in your database.
Project Builder uses this structure to help you analyze the
data.
•
My Reports allows you to use the attributes and metrics
you defined using My Business Model, to create a variety
of reports. These reports are based on pre-defined
templates. You can also preview and run the reports.
can learn about creating and designing reports in
You
more detail in the MicroStrategy Basic Reporting
Guide.
To access Project Builder from the Start menu select
Programs, then MicroStrategy, then Desktop, and then
select Project Builder.
Creating a production project using Project Creation Assistant
This section describes how to create a Server-connected
(three-tier) project for your production setup using
MicroStrategy Desktop.
is assumed you intend to implement Intelligence
ItServer
in your business intelligence environment as
the means of connecting to your project as opposed to
using a two-tier setup.
© 2007 MicroStrategy, Inc.
Creating the project
75
4
Creating and Configuring a Project
Project Design Guide
Creating a project using the Project Creation Assistant in
MicroStrategy Desktop provides advanced functionalities and
greater complexity to your project than Project Builder. It
allows you to create a new project and add the following
objects to it or to an existing project:
•
Tables
•
Facts
•
Attributes
With the Project Creation Assistant you create and configure
a project and some of the essential schema objects that reside
within it. The intended audience for this tool includes
experienced project creators who have planned all their facts,
attributes, and data relationships. This information is
covered elsewhere in this guide. For a listing of information
covered in specific chapters, see Planning your project
below.
The main advantage of the Project Creation Assistant over
Project Builder is its ability to create multiple schema objects
at once. Since you can efficiently add multiple tables and
develop numerous attributes and facts, it is especially useful
for large projects which contain many tables and schema
objects. With the Project Creation Assistant you can also
create attributes with many-to-many relationships.
Planning your project
Before using the Project Creation Assistant, you should plan
your project and consider the following:
76 Creating the project
•
The logical data model you intend to use for this project;
logical data models are covered in Chapter 2, The Logical
Data Model.
•
The tables to use in the project; physical warehouse
schema models are covered in Chapter 3, Warehouse
Structure for Your Logical Data Model.
•
The facts to include in the project and the data types used
to identify them; facts are covered in Chapter 5, The
Building Blocks of Business Data: Facts.
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
•
4
The attributes to create in the project and the data types
used to identify them, including:
The description column name for each attribute.
Any other attribute forms for each attribute.
The child attributes for each attribute.
Attributes are covered in Chapter 6, The Context of Your
Business Data: Attributes.
Creating a new project using the Project
Creation Assistant
Once you have planned your project and completed the
prerequisites, you can use the Project Creation Assistant to
build the project and populate the metadata based on the
data structures present in your data warehouse.
The steps of the Project Creation Assistant are:
1 Initialize/create the project.
Initializing the project means giving the project a name
and selecting the metadata repository in which to create
the project—that is, the project source. After you specify
these settings, the shell of a project is created in the
metadata. This configures the folder structure and default
connectivity settings. Be aware that this process can take
some time to complete.
2 Select tables from the Warehouse Catalog.
In this step, you use the Warehouse Catalog to specify
which data warehouse tables to include in your project.
3 Create facts.
4 Create attributes.
should complete all the steps in the Project
You
Creation Assistant at the same time. While you can
save an incomplete project definition, you cannot
finish creating it later with the Project Creation
Assistant. Instead, you must complete it using the
© 2007 MicroStrategy, Inc.
Creating the project
77
4
Creating and Configuring a Project
Project Design Guide
appropriate interface, such as the Warehouse Catalog,
Fact Creation Assistant, or Attribute Creation
Assistant.
To create a new project using the Project Creation Assistant
1 Log in to a project source in MicroStrategy Desktop.
To create a project source which connects to your data
through Intelligence Server, see the Configuring and
Connecting Intelligence Server chapter of the
MicroStrategy Installation and Configuration Guide.
2 From the Schema menu, select Create New Project. The
Project Creation Assistant opens, as shown below:
3 Click Create project. The New Project page opens.
4 Enter the name, description, and default document
directory location for the project.
default document directory for a project is the
The
directory location to store all HTML documents.
For more details on how to setup HTML
documents for a project, see the MicroStrategy
Installation and Configuration Guide.
78 Creating the project
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
5 To support anonymous authentication mode for guest
users for this project, select Enable the guest user
account for this project.
6 From the Project Source drop-down list, select the
project source in which you created the database instance
to connect to your metadata repository.
7 Click OK. The Login dialog box opens.
you are not authorized by your database or system
Ifadministrator
to create projects in the data source you
have selected, you cannot proceed to the next step.
8 Enter a valid login ID and password and click OK. The
Project Creation Assistant creates an empty project in the
metadata repository.
you create a new project, a language check
When
ensures that the language settings of the user profile of
the local machine (the CURRENT_USER registry key),
the language of the local machine (the
LOCAL_MACHINE registry key), and the Project locale
property match. When these properties do not match,
it can lead to inconsistencies in the language display.
The language check prevents these inconsistencies and
ensures that the language display is consistent across
the project.
Proceed to the next section to determine the tables to be used
in your project.
Adding tables using the Warehouse Catalog
The warehouse tables for a project determines the set of data
available to be analyzed in the project. You use the
Warehouse Catalog to add warehouse tables to your project.
The Warehouse Catalog lists all the tables in the data source
to which you are connected through your database instance
and to which your database login has read privileges.
The Warehouse Catalog queries the data source and lists the
tables and columns that exist in it. From this list, you select
the lookup, fact, and relationship tables to use in your new
© 2007 MicroStrategy, Inc.
Creating the project
79
4
Creating and Configuring a Project
Project Design Guide
project. You should also include all other tables needed to
complete your project, including transformation tables,
aggregate tables, and partition mapping tables.
MicroStrategy schema objects such as attributes, facts, and
tables are abstractions built on top of the tables and columns
in the data source. Once tables are selected from the data
source and added to your project, they become schema
objects known as logical tables in MicroStrategy. Logical
tables are representations of the tables that are available in
the data warehouse, and are discussed in detail in Appendix
C, Logical Tables.
database login you use must have read privileges
The
so you are able to view the tables in the selected
warehouse. Database instances and database logins
are MicroStrategy objects that determine the
warehouse to which a project connects. To learn more
about these objects, refer to the MicroStrategy
Installation and Configuration Guide.
To add and remove tables to the project using the Warehouse
Catalog
1 In the Project Creation Assistant, select Select tables
from the Warehouse Catalog. The Warehouse Database
Instance dialog box opens.
2 Select a database instance from the drop-down list and
click OK. The database instance selected in this dialog box
determines which data source is accessed. The Warehouse
Catalog opens.
can edit your database instance by clicking
You
Edit.
80 Creating the project
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating and Configuring a Project
4
3 The left side of the Warehouse Catalog lists all available
tables and the number of rows each table contains. The
list on the right shows all the tables currently being used
in the project, if any:
4 From the left side, select the tables you want to add to the
Warehouse Catalog, and click > to add the selected tables.
Click >> to add all the listed tables.
5 To remove tables from your project, select them from the
right side and click < to remove them. Click << to remove
all the tables from your project.
Warehouse Catalog options
6 Right-clicking any table provides you with additional
Warehouse Catalog functionality.
For example you can view rows in a table, specify a table
prefix, copy a table, or specify a database instance for a
table. For more information on these abilities and how to
use them, see Managing warehouse and project tables,
page 221.
© 2007 MicroStrategy, Inc.
Creating the project
81
4
Creating and Configuring a Project
Project Design Guide
7 To set advanced options you can click Options on the
Warehouse Catalog toolbar.
For example, you can change the database instance,
customize how tables and columns are read from the
database system catalog, display extra table and row
information, and decide whether schema objects are
mapped automatically or manually. For more information
on these abilities and how to use them, see Modifying
data warehouse connection and operation defaults,
page 226.
8 In the toolbar, click Save and Close to save your changes
to the Warehouse Catalog. The table definitions are
written to the metadata. This process can take some time
to complete.
After exiting the Project Creation Assistant, you can still
access the Warehouse Catalog to add additional tables. For
steps to access the Warehouse Catalog to add tables to a
project, see Adding and removing tables for a project,
page 220.
The next step in the Project Creation Wizard involves
creating schema objects: facts and attributes. Follow the
instructions outlined in Creating facts and attributes,
page 82 and Configuring additional schema-level settings,
page 83 to learn how to create these schema objects and
configure additional schema-level settings for those objects.
Creating facts and attributes
This step in the project creation process involves using the
Project Creation Assistant to create two kinds of schema
objects: facts and attributes.
Before you create facts and attributes, however, it is
important to understand what facts and attributes are and
the defining characteristics of each. This information is
covered in Chapter 5, The Building Blocks of Business Data:
Facts and Chapter 6, The Context of Your Business Data:
Attributes.
82 Creating facts and attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
4
Creating and Configuring a Project
Configuring additional schema-level settings
The final step in the project creation process involves
configuring additional schema-level settings to add more
analytical depth to your schema objects and optimize the
project as a whole. These settings include:
•
Fact definitions: The Fact Editor allows you to create,
edit, and configure facts. This is covered in Creating and
modifying simple and advanced facts, page 91.
•
Attribute definitions: The Attribute Editor allows you to
create and edit attributes, attribute forms, and attribute
form expressions. This is covered in Adding and
modifying attributes, page 134.
•
User hierarchies: The Hierarchy Editor allows you to
create user hierarchies, which facilitate access to attribute
and element browsing and drilling. This is covered in
Chapter 7, Creating Hierarchies to Organize and Browse
Attributes.
•
Advanced configurations: These objects include
transformations, aggregate tables, and partitioning and
partition mappings:
The Transformation Editor allows you to create
transformations, which are schema objects used for
time-series analysis. Transformations are covered in
Chapter 9, Creating Transformations to Define
Time-Based and Other Comparisons.
The tools used to create aggregate tables and
partitions are the Warehouse Catalog, the Metadata
Partition Mapping Editor, and the Warehouse
Partition Mapping Editor. This information is covered
in Chapter 8, Optimizing and Maintaining Your
Project.
Now that you have completed most of the key steps in
creating a new project, proceed to the chapters referenced
above to complete the next steps in the project creation
process.
© 2007 MicroStrategy, Inc.
Configuring additional schema-level settings
83
4
Creating and Configuring a Project
Project Design Guide
Deploying your project and creating reports
After you create a project, you can deploy it to your user
community using MicroStrategy Web. Keep in mind,
however, that if you completed only the steps in this chapter,
the project you deploy will contain only basic facts and
attributes. Proceed to the chapters listed above to add
analytical depth and more functionality to your project.
Facts and attributes provide the backbone of the reports and
documents created by report designers. Facts are used to
create metrics, and metrics and attributes are essential
components of reports.
Metrics, and other report objects such as filters, custom
groups, and prompts, are beyond the scope of this guide. For
a complete discussion of metrics, filters, reports, and other
report objects, refer to the MicroStrategy Basic Reporting
Guide and the MicroStrategy Advanced Reporting Guide.
To learn more about how to deploy your project using
MicroStrategy Web, refer to the Deploying your Project with
MicroStrategy Web chapter of the MicroStrategy
Installation and Configuration Guide.
You can also begin creating reports in MicroStrategy Desktop
and MicroStrategy Web. For information about creating
reports in MicroStrategy Desktop, refer to the MicroStrategy
Basic Reporting Guide; for creating reports in MicroStrategy
Web, see the MicroStrategy Web online help.
Note the following:
•
MicroStrategy allows you to connect to your SAP
BW, Microsoft Analysis Services, and Hyperion
Essbase data sources. For information about
connecting to OLAP cube sources, see Appendix B,
Connecting to OLAP Cube Sources.
•
For information on how to use your own
customized SQL statements to create reports, see
the Creating Freeform SQL reports chapter in the
MicroStrategy Advanced Reporting Guide.
84 Deploying your project and creating reports
© 2007 MicroStrategy, Inc.
5
5.
THE BUILDING BLOCKS OF
BUSINESS DATA: FACTS
Introduction
Facts are one of the essential elements within the business
data model. They relate numeric data values from the data
warehouse to the MicroStrategy reporting environment.
Facts generally represent the answers to the business
questions on which users want to report.
In the MicroStrategy environment, facts are schema objects
created by and shared between MicroStrategy users. The facts
you create in MicroStrategy allow users to access data stored
in the data warehouse. Facts form the basis for metrics,
which are used in the majority of analyses and reports that
users can create with MicroStrategy.
Facts and attributes are necessary to define projects. In a
MicroStrategy project, facts are numeric data and attributes
are contextual data for the facts. For example, you want to
analyze the amount of sales at a certain store during January.
In this case, the amount of sales represents the fact, and the
store and month represent attributes. As the project designer,
© 2007 MicroStrategy, Inc.
85
5
The Building Blocks of Business Data: Facts
Project Design Guide
you must create projects that contain facts and attributes.
Users can then use these facts and attributes as building
blocks for metrics and reports.
Facts are stored in the data warehouse in fact tables. These
fact tables are composed of different columns. Each cell in the
columns represents a specific piece of information. When fact
information is requested for a report in MicroStrategy, that
column is accessed to retrieve the necessary data. This data is
used to create a metric (such as profit) which is a business
measure.
Facts are based on physical columns within tables in the data
warehouse, as shown below.
86
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
Like other schema objects such as attributes, facts are logical
MicroStrategy objects that correspond to physical columns
and tables. Unlike attributes, facts do not describe data. Facts
are the actual data values stored at a specific fact level. A fact
entry level is the lowest set of attributes at which a fact is
stored.
While creating facts is a major step in the initial creation of a
project, it can often be necessary to modify and create facts
throughout the life cycle of a project. The procedures to
perform these tasks are discussed in the first section
(Creating facts, page 87) of this chapter. The later sections
discuss conceptual information on facts, as well as highlight
some advanced fact design techniques and procedures.
Creating facts
A fact has two common characteristics: it is numeric and it is
aggregatable. Examples of facts include sales dollars, units
sold, profit, and cost.
Data warehouses contain different types of facts depending
on the purpose of the data. For example, facts such as Tenure
and Compensation Cost could exist in a data warehouse that
contains human resources data. Facts such as Quantity and
Item Cost could exist in a warehouse containing sales and
distribution data.
It is important to understand how to define facts because
facts are the basis for almost all metrics. Facts also allow you
to create advanced metrics containing data that is not stored
in the warehouse but can be derived by extending facts.
This section provides steps to create facts at different phases
of the project design process, using different techniques and
MicroStrategy interfaces:
© 2007 MicroStrategy, Inc.
•
Simultaneously creating multiple, simple facts, page 88
covers steps to create multiple, simple facts as part of the
initial project design effort or later in a project’s life cycle.
•
Creating and modifying simple and advanced facts,
page 91 covers steps to add and modify both simple and
advanced facts for an existing project.
Creating facts
87
5
The Building Blocks of Business Data: Facts
Project Design Guide
Simultaneously creating multiple, simple facts
During your initial project design effort, you can create
multiple simple facts using the Project Creation Assistant and
the Fact Creation Wizard. However, fact creation and
modification can be done throughout the entire life cycle of a
project. Facts can be created and modified using a number of
various techniques, utilizing the following MicroStrategy
tools:
•
The Fact Creation Wizard is a step-by-step interface that
is typically used when you first create a project. It allows
you to create multiple facts in a single creation process.
Project Creation Assistant utilizes the Fact
The
Creation Wizard to help you create the facts for
your initial project creation effort. You can also
access the Fact Creation Wizard in MicroStrategy
Desktop from the Schema menu.
•
88 Creating facts
The Fact Editor, which is discussed in Creating and
modifying simple and advanced facts, page 91, is used to
add advanced features to facts that already exist or to
create new simple or advanced facts as your project
evolves.
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
To create facts with the Fact Creation Wizard
1 In the Project Creation Assistant, select Create facts. The
Fact Creation Wizard opens, as shown below:
2 Click Define Rules to set some basic fact creation rules.
The Fact Creation Rules page opens.
Rules help automate and govern the fact creation process.
If the naming conventions in your warehouse do not
conform to the defaults in the Fact Creation Rules page,
you may need to change these rules.
3 The Column data type area allows you to select the
column data types that are available as possible fact ID
columns. Select the check boxes for the data types to be
included when the wizard searches the data warehouse for
available fact columns.
For example, if you select Character and Numeric and
leave the remaining check boxes cleared, only columns
whose data types are numeric or character-based are
displayed in the Fact Creation Wizard as possible columns
to use for your facts.
most attributes which can access multiple
Unlike
columns of description information, a fact does not
have description information. Therefore, you can
only select data types for the ID columns of your
facts.
© 2007 MicroStrategy, Inc.
Creating facts
89
5
The Building Blocks of Business Data: Facts
Project Design Guide
4 The Fact name area allows you to determine how to create
default fact names, that is, whether to replace underscores
in the fact name with spaces and whether the first letter is
capitalized. Select the appropriate check boxes to create
the desired default fact names.
5 Click OK to accept your rule changes and return to the
Fact Creation Wizard.
Fact column selection
6 Click Next. The Column Selection page opens, with
columns that are not currently being used in the project
listed in the Available columns pane.
7 From the Available columns pane, select the fact columns
to use for your facts and click > to add them to your
project. Click >> to add all the listed columns.
Note the following:
– You can rename any fact to make its name more
user-friendly by right-clicking the fact and
selecting Rename.
– The Fact Creation Wizard cannot handle columns
that hold the same information but have different
column names (that is, heterogeneous columns).
For more information about mapping facts to
heterogeneous columns, see Facts with different
column names: Heterogeneous column names,
page 102.
8 To remove fact columns from your project, select them
from the Facts pane and click < to move them to the left
side. Click << to remove all the columns in your project.
9 Click Next. The Finish page opens.
10 Review the summary information in the Finish page and
click Finish to create the facts.
The selected fact definitions are stored in the metadata. To
continue creating a project with the Project Creation
Assistant, see Simultaneously creating multiple attributes,
page 129.
90 Creating facts
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
Creating and modifying simple and advanced facts
After you have created a project, you can use either the Fact
Creation Wizard or the Fact Editor to create new facts in your
project:
•
•
With the Fact Creation Wizard you can:
Create simple facts
Create multiple facts quickly
Add a large number of facts during project creation
With the Fact Editor you can:
Create simple and advanced facts
Edit existing facts and configure additional
schema-level settings
The Fact Creation Wizard can create multiple facts quickly
and easily. However, it limits you to creating simple facts and
does not allow you to edit existing facts. Typically, you only
use the Fact Creation Wizard as part of the initial project
creation, for creating most of the facts for the project. You can
use the Fact Editor to edit existing facts and create fact
expressions, column aliases, level extensions; map multiple
or heterogeneous columns; and configure other settings.
Creating one or more simple facts with the Fact
Creation Wizard
Although the Fact Creation Wizard is primarily used to create
most of a project’s facts during initial project creation, you
can use it to create one or more simple facts at the same time.
To create facts with the Fact Creation Wizard
1 In MicroStrategy Desktop, log in to the project source that
contains your project and expand your project.
© 2007 MicroStrategy, Inc.
Creating facts
91
5
The Building Blocks of Business Data: Facts
Project Design Guide
must use a login that has Architect privileges.
You
For more information about privileges, see
Permissions and Privileges of the MicroStrategy
System Administration Guide.
2 From the Folder List in MicroStrategy Desktop, select the
project to which to add additional facts.
3 From the Schema menu, select Fact Creation Wizard.
The Fact Creation Wizard opens.
To use the Fact Creation Wizard to add facts, follow the
procedures outlined in To create facts with the Fact
Creation Wizard, page 89.
Creating simple and advanced facts with the
Fact Editor
As your project evolves, you can create additional facts and
modify existing facts with the Fact Editor. You can also use
the Fact Editor to add extensions to those facts and configure
additional settings within them to support various analytical
requirements.
The following procedure describes how to use the Fact Editor
to create a simple fact based on a single fact column in a
table.
To create a simple fact with the Fact Editor
1 In MicroStrategy Desktop, log in to the project source that
contains your project and expand your project.
must use a login that has Architect privileges.
You
For more information about privileges, see
Permissions and Privileges of the MicroStrategy
System Administration Guide.
2 From the Folder List in MicroStrategy Desktop, select the
project to which to add additional facts.
92 Creating facts
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
3 From the File menu, select New, and then Fact. The Fact
Editor opens, with the Create New Fact Expression dialog
box displayed on top of it.
4 From the Source table drop-down list, select the source
table for the fact.
source table is the table or logical view that
The
contains the fact column on which you want to base
a new fact.
5 From the Available columns pane, drag and drop a fact
column into the Fact expression pane.
6 In the Mapping area, select Automatic or Manual.
•
Automatic mapping means that MicroStrategy scans
all of the tables in the project and selects all tables with
the columns used in the fact expression as possible
source tables for the fact. You can then remove any
tables mapped automatically or select other tables.
•
Manual mapping means that MicroStrategy scans all
of the tables in the project and locates all tables with
the columns used in the fact expression. You then
select which of those tables are used as source tables
for the fact.
– If you are creating a constant expression that is not
based on a physical column in a project table, select
the tables for which you want your constant
expression to apply.
– These mapping methods are different from the
automatic mapping methods for the Warehouse
Catalog. Using automatic mapping in the Attribute
Editor helps you decide which tables to map your
facts to when creating a fact. The Warehouse
Catalog mapping methods (discussed in Mapping
schema objects and calculating logical sizes for
tables, page 231) determine whether attributes or
facts are automatically mapped to new tables when
they are added after an attribute or fact is created.
– If the same column name does not contain the
same data across different tables, manually select
the appropriate source tables for each fact.
© 2007 MicroStrategy, Inc.
Creating facts
93
5
The Building Blocks of Business Data: Facts
Project Design Guide
For example, suppose you have a column named
Sales, which exists in both the Fact_Sales table
and the Fact_Discount table. In the
Fact_Sales table, the Sales column contains
revenue data. However, in the Fact_Discount
table, the Sales column contains discount data. In
other words, although the column name is the
same in both tables (i.e. Sales), the columns
contain different fact data in each table. When
creating the Revenue fact, you must select the
Manual mapping method so you can select the
Fact_Sales table as a source table for the
Revenue fact. When creating the Discount fact, you
must select the Manual mapping method so you
can select the Fact_Discount table as a source
table for the Discount fact. If you use the
Automatic mapping method in both cases, the
MicroStrategy SQL Engine may use the incorrect
column for the facts.
7 Click OK to close the Create New Fact Expression dialog
box.
8 Use the tabs of the Fact Editor to define fact expressions,
create column aliases, and create extensions, as described
below.
detailed information about the options on each
For
tab within the Fact Editor, refer to the
MicroStrategy Desktop online help.
•
Definition: This tab allows you to define fact
expressions. Fact definitions are discussed in How
facts are defined, page 97.
•
Column Alias: This tab allows you to create a column
alias for the fact. Column aliases are discussed in Fact
column names and data types: Column aliases,
page 105.
•
Extensions: This tab allows you to create fact level
extensions. Fact extensions are discussed in
Modifying the levels at which facts are reported:
Level extensions, page 107.
9 When your changes are complete, click Save and Close.
94 Creating facts
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
10 In the Save As dialog box, navigate to the location in
which to save the fact. Enter a name for the fact and click
Save. The fact is saved and the Fact Editor closes.
11 From the Schema menu, select Update Schema to
update the project schema.
Modifying simple and advanced facts
To modify an existing fact
1 In MicroStrategy Desktop, open the folder that contains
the fact to modify.
2 Double-click the fact to open the Fact Editor and edit the
fact.
You can learn how to create more advanced facts in the
various sections below.
© 2007 MicroStrategy, Inc.
Creating facts
95
5
The Building Blocks of Business Data: Facts
Project Design Guide
The structure of facts
As shown in the diagram below, facts are made up of the
following components:
96 The structure of facts
•
The fact definition is composed of one or more fact
expressions. Every fact must have at least one expression.
Fact definitions are discussed in detail in How facts are
defined, page 97.
•
The column alias stores the column name MicroStrategy
uses to generate SQL statements when creating temporary
tables related to the fact. Every fact must have a column
alias. MicroStrategy selects a default column alias
depending on the type of fact, unless you create a new
column alias. Column aliases are discussed in detail in
Fact column names and data types: Column aliases,
page 105.
•
Fact level extensions allow facts stored in the data
warehouse at one level to be reported at an unrelated
level. Extensions can also prevent a fact from being
reported at a certain level, even though it is stored at that
level. Level extensions are very effective for advanced data
modeling scenarios. Level extensions are discussed in
detail in Modifying the levels at which facts are reported:
Level extensions, page 107.
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
You create facts in MicroStrategy Desktop using the Fact
Creation Wizard and the Fact Editor. During project creation
with the Fact Creation Wizard, when you select the numeric
column used to represent the fact, both the fact definition
and column alias are automatically defined. Level extensions
are optional.
For a discussion of the tools used to created facts and
procedures on how to use them, see Creating facts, page 87.
How facts are defined
A fact definition contains properties that define a fact and its
components. The fact definition is composed of at least one
fact expression and basic information about the fact,
including the fact name, expression, and the source tables it
uses.
The following table provides an example of a fact definition,
which includes the fact’s name, expression, and source tables.
Fact
Name
Expression
Source Tables
Unit Price
All_Sales
LU_ITEM
ORDER_DETAIL
In the example, the fact expression maps the fact to the
All_Sales columns in the LU_ITEM and ORDER_DETAIL
tables in the warehouse. The fact expression contained in the
definition represents how the fact is calculated by
MicroStrategy. In this case, the fact expression is simply the
name of the column which holds the fact data. However,
some facts use more advanced expressions to perform
calculations on multiple columns of data to return a single
fact.
Facts can be found in multiple tables in a warehouse schema,
and often must be calculated differently from one table to the
next. While the Unit Price fact only has one expression,
multiple expressions can exist within a fact definition.
© 2007 MicroStrategy, Inc.
How facts are defined
97
5
The Building Blocks of Business Data: Facts
Project Design Guide
Note the following:
•
Each fact expression relates to one or more related
tables that contain the fact.
•
For each of the tables, fact expressions define how
the fact is calculated.
Mapping physical columns to facts: Fact expressions
A fact expression maps facts to physical columns in the
warehouse. These expressions can be as simple as a fact
column name from the warehouse or as sophisticated as a
formula containing multiple fact column names and numeric
constants. Regardless of how it is defined, a fact expression
represents a mapping to specific fact information in the
warehouse. A fact definition must have one or more fact
expressions.
The following image illustrates a column in the fact table and
the associated fact expressions:
Valid fact expressions are formulas constructed from fact
columns with or without numeric constants or mathematical
operators. The mathematical operators that can be used in a
fact expression are:
98 How facts are defined
•
Addition (+)
•
Subtraction (-)
•
Multiplication (*)
•
Division (/)
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
Note the following:
•
You can use the Fact Editor to create fact
expressions. These steps are covered in Creating
and modifying simple and advanced facts,
page 91.
•
A fact can also be defined using an ApplySimple
function. Apply functions are discussed in the
Pass-Through Expressions appendix in the
MicroStrategy Advanced Reporting Guide.
Most facts represent physical columns in the data warehouse.
However, some facts do not exist at all in the warehouse and
are defined in other ways, as explained in the following
sections.
Implicit facts and implicit fact expressions
Implicit facts are virtual or constant facts that do not
physically exist in the database. An implicit fact indicates a
fact table from which to retrieve data. The implicit fact can
have its expression defined as a constant value, although
nothing is saved in a table column.
For example, you can use implicit fact expressions to create
“temporary columns” in the database with a value of “1” for
every row. These temporary columns allow you to keep track
of how many rows are returned for a certain attribute. You
may also find it helpful to use implicit facts when building
metrics, where you can sum the column holding the constant
to create a COUNT. For example, if you want to build a metric
defined as Sum(1), you can define a fact equal to the constant
“1”. For detailed information about metrics, see the
MicroStrategy Advanced Reporting Guide.
Derived facts and derived fact expressions
A derived fact has its value determined by an expression that
contains more than just a column in a table. Any operation on
a column such as adding a constant, adding another column’s
values, or setting the expression to be an absolute value,
creates a derived fact. In other words, you are creating a fact
© 2007 MicroStrategy, Inc.
How facts are defined
99
5
The Building Blocks of Business Data: Facts
Project Design Guide
from information that is available in the data warehouse. For
example, a table in your data warehouse contains the
following elements:
Fact Table 1
Item
Quarter
Quantity_Sold
Price
You can create a new fact, Sales, by creating the following
derived fact:
Sales = Quantity_Sold * Price
One advantage of creating a derived fact is that a derived fact
allows one consistent fact to exist in the project in lieu of
having to retrieve multiple intermediary facts from multiple
tables. Using a single fact saves storage space and limits the
number of SQL passes used in queries.
Rather than creating a derived fact, you can create such
analysis in MicroStrategy with the use of metrics. Metrics
allow you to perform calculations and aggregations on your
fact data. For more information on what metrics are and how
to create them, see the MicroStrategy Advanced Reporting
Guide.
Example: creating derived facts
The Cost fact in the MicroStrategy Tutorial contains the
derived fact expression Qty_Sold * Unit_Cost. This
expression implies that columns containing data about the
quantity of items sold and the price of those units can be
multiplied to produce a useful business calculation. In this
case, the columns are used to answer the business question,
“How much did it cost the company to create the items
purchased by customers?”
The following procedure describes how to create a derived
fact that uses the derived fact expression described above.
For a more generalized procedure to create derived facts,
refer to the MicroStrategy Desktop online help.
100 How facts are defined
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
To create a derived fact
1 In MicroStrategy Desktop, log in to the MicroStrategy
Tutorial project.
2 Navigate to the My Personal Objects folder, and open the
My Objects folder.
3 From the File menu, point to New, and then select Fact.
The Fact Editor opens, with the Create New Fact
Expression dialog box displayed on top of it.
4 From the Source table drop-down list, select the
ORDER_DETAIL table.
5 From the Available columns pane, double-click the
QTY_SOLD column to add it to the Fact expression pane
on the right.
6 With the cursor in the Fact expression pane, click *
(multiplication operator) to add it to the expression.
7 From the Available columns list, double-click the
UNIT_PRICE column to add it to end of the fact
expression.
8 Under Mapping method, select Automatic.
9 Click Validate to check whether the syntax of the
expression is correct. The expression should appear as
shown below:
10 Click OK. The derived fact expression appears in the Fact
expression pane in the Fact Editor.
© 2007 MicroStrategy, Inc.
How facts are defined
101
5
The Building Blocks of Business Data: Facts
Project Design Guide
11 From the File menu, select Save As. The Save menu
opens.
12 Enter a name for the derived fact and click Save.
13 When you create a fact for your project, at this point, you
must update the project schema. However, since this is
only an example, it is not necessary to update the schema.
Facts with different column names:
Heterogeneous column names
In your warehouse, the same fact can access columns with
different column names. In the example below, two fact
tables in a warehouse each contain columns for dollar sales.
Table 1 contains a fact called Dollar_Sales. Table 2
includes a fact called Dollar_Sls. These two items
represent the same information.
Table 1
Table 2
Year
Dollar_Sales
Month
Dollar_Sls
MicroStrategy allows you to identify heterogeneous fact
column names for each fact. With heterogeneous column
names, you can refer the same fact to multiple columns with
different column names and from different tables that
identify the same quantitative value.
In the example above, creating a heterogeneous fact column
name for dollar sales informs the system that the
Dollar_Sales and Dollar_Sls columns represent the
same fact. When you call for the information in a report
through the use of a metric, both fact columns are used in the
SQL, resulting in an accurate representation of the fact in the
report.
102 How facts are defined
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
Example: mapping heterogeneous fact columns
The Units Sold fact in MicroStrategy Tutorial consists of two
fact columns in the warehouse, Qty_Sold and
Tot_Unit_Sales. Although these fact columns have
different names and exist in different fact tables, they
represent the same data and are therefore both mapped to
the Unit Sold fact.
You must map heterogeneous fact columns to their
corresponding facts to ensure that accurate and complete
data is displayed on reports.
The following procedure describes how to create the Units
Sold fact that already exists in MicroStrategy Tutorial. In the
procedure, you create the Units Sold fact and map its
corresponding heterogeneous fact columns to it. For a more
generalized procedure to map heterogeneous fact columns,
refer to the MicroStrategy Desktop online help.
To create heterogeneous fact columns
1 In MicroStrategy Desktop, log in to the MicroStrategy
Tutorial project.
2 Navigate to the My Personal Objects folder, and open the
My Objects folder.
3 From the File menu, point to New, and then select Fact.
The Fact Editor opens, with the Create New Fact
Expression dialog box displayed on top of it.
4 From the Source table drop-down list, select the
ORDER_FACT table. This is one of the tables in which a
heterogeneous fact column for the Units Sold fact exists.
5 From the Available columns pane, double-click the
QTY_SOLD column to add it to the Fact expression pane
on the right.
6 In the Mapping method area, select Automatic.
7 Click OK. The Fact Editor opens and the fact expression
you just created appears in the Fact expression pane.
© 2007 MicroStrategy, Inc.
How facts are defined
103
5
The Building Blocks of Business Data: Facts
Project Design Guide
Now you must add the other heterogeneous fact column
as separate expression for the Units Sold fact.
8 Click New. The Create New Fact Expression dialog box
opens.
9 From the Source table drop-down list, select the
CITY_CTR_SALES table. This is the other table in which
a heterogeneous fact column for the Units Sold fact exists.
10 From the Available columns pane, double-click the
TOT_UNIT_SALES column to add it to the Fact
expression pane on the right.
11 In the Mapping method area, select Automatic.
12 Click OK. The Fact Editor opens and the fact expression
you just created appears in the Fact expression pane. Now
the Units Sold fact you are creating maps correctly to its
heterogeneous fact columns.
13 From the File menu, select Save As. The Save menu
opens.
14 Enter a name for the new fact and click Save.
15 When you create a fact for your project, at this point, you
must update the project schema. However, since this is
only an example, it is not necessary to update the schema.
104 How facts are defined
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
Fact column names and data types: Column
aliases
A column alias specifies both the name of the column to be
used in temporary tables and the data type to be used for the
fact.
By default, the data type for a fact is inherited from the data
type of the column on which the fact is defined in the data
warehouse. However, there are cases where you may need to
change this.
For example, you can define a fact to be the difference
between two dates to perform a calculation such as the
average number of days between a start and an end date. You
could create this fact using the following expression:
ApplySimple("DateDiff(day,#0, #1)",
[Start_Date_Id], [End_Date_Id])
expression syntax is specific to your database
The
type. This syntax is specific to Microsoft SQL Server.
The SQL you create may be different.
© 2007 MicroStrategy, Inc.
Fact column names and data types: Column aliases
105
5
The Building Blocks of Business Data: Facts
Project Design Guide
The data type for this fact is automatically set to a Date data
type because the Start_Date_ID and End_Date_ID have
Date data types. However, the result of the calculation, that
is, the difference between the two dates, is an integer.
This is used when a temporary SQL table needs to be created
for the calculation. If you did not change the data type of the
column alias, then the system uses a Date data type and tries
to insert integer data into this column. This can cause an
error for some database platforms. To avoid the possibility of
an error due to conflicting data types, you should modify the
column alias for the fact to change the default Date data type
to an Integer data type.
You can use the Fact Editor to create column aliases.
To create a column alias for a fact
procedure assumes you have already created a
This
fact with a valid fact expression for which to create a
new column alias.
1 In MicroStrategy Desktop, log in to the project source that
contains the fact to create a new column alias for.
2 Right-click the fact and select Edit. The Fact Editor opens.
3 Select the Column Alias tab.
4 In the Column alias area, click Modify. The Column
Editor - Column Selection dialog box opens.
5 Select New to create a new column alias. The Column
Editor - Definition dialog box opens.
6 You can modify the following properties for the column
alias:
•
Column name: The name for the column alias which
is used in any SQL statements which include the fact
column.
•
Data type: The data type for the fact. For a description
of the different data types supported by MicroStrategy,
see Appendix D, Data Types.
106 Fact column names and data types: Column aliases
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
•
5
Depending on the data type selected, you can specify
the byte length, bit length, precision, scale, or time
scale for your column alias. For a detailed description
on each of these properties, see the MicroStrategy
Desktop online help.
7 Click OK to save your changes and return to the Column
Editor - Column Selection dialog box.
8 Click OK to save your changes and return to the Fact
Editor.
9 Select Save and Close to save your changes.
Modifying the levels at which facts are
reported: Level extensions
Facts are stored at a particular business level in the
warehouse. The level of a fact is defined by the attribute IDs
present in the table. For example, the fact table shown below
contains several attribute IDs, including Item and Quarter.
These attribute IDs imply that the fact is reported at the item
and quarter levels by default.
Fact Table 1
Item
Quarter
Quantity_Sold
Price
Level extensions are necessary when facts are stored in the
data warehouse at one level and reported at different levels.
Every fact is tied to a set of attributes that may or may not
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
107
5
The Building Blocks of Business Data: Facts
Project Design Guide
satisfy all users’ reporting requirements. A fact extension is
needed when a fact does not relate directly or indirectly to an
attribute included on a report.
If the entry level of a fact is at the lowest level of a hierarchy,
all attributes at a higher logical level in the hierarchy are
available for use as well, without the use of level extensions.
For example if you have a cost fact at the level of a date
attribute in a time hierarchy, MicroStrategy can aggregate the
cost fact data to the level of the year attribute because it is in
the same hierarchy as the date attribute and at a higher level.
However, facts require level extensions to be related to any
attributes that are at a lower logical level in the same
hierarchy than the entry level for a fact (see Lowering the
level of fact data: Fact degradations, page 118).
You can use level extensions to change a fact level and extend
a fact level to a level in a completely different hierarchy. For
example, you record a Discount fact at the Item/Date level.
That is, discounts apply to particular items on particular
days. To see if some call centers are selling significantly more
items at a discount than other call centers, you have to extend
the level of the Discount fact to the Call Center level, which is
an attribute from a different hierarchy.
108 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
Level extensions define how facts can be extended, lowered,
or disallowed to other attributes across the schema. By
creating a level extension, you are allowing facts or attributes
that have been captured at one level to be extended to other
levels to meet reporting requirements.
Level extensions are not required like the fact definition and
column alias, and they tend to be used only in specific cases.
Before a metric containing a fact can be used with an
attribute that is not in or related to the attribute’s entry level,
a level extension must be defined for the fact. This is because
if a fact is stored at a level unrelated to an attribute on a
report, a level extension must exist to relate the fact data to
the attribute. Otherwise, there is no way to make a
connection between the fact data and the attribute.
You can create fact level extensions by using any of the
following methods:
•
Defining a join on fact tables using table relations,
page 110
•
Defining a join on fact tables using fact relations,
page 114
•
Forcing facts to relate to attributes: Using cross product
joins, page 116
•
Lowering the level of fact data: Fact degradations,
page 118
•
Disallowing the reporting of a fact at a certain level,
page 122
You can find complete descriptions for each of these methods
in the online help for the Level Extension Wizard in the Fact
Editor.
You can use the Fact Editor to create level extensions.
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
109
5
The Building Blocks of Business Data: Facts
Project Design Guide
Defining a join on fact tables using table relations
A table relation defines a join on tables. When you specify a
table to join with a fact, you are creating a table relation to
extend a fact. A fact extension can be used to relate a fact to
an attribute using a fact table. The join is important as the
table contains an attribute in the entry level and the attribute
to which to extend.
For example, the MicroStrategy Tutorial project includes a
Freight metric. This metric has a table relation fact extension
to the Item attribute. Since the ORDER_FACT table that
defines Freight does not include the identity column for the
Item attribute, the Freight fact cannot be reported at the Item
level. A fact extension is required to view freight values for
each item included in an order. In this example, the
ORDER_DETAIL table is used to create the Freight fact
extension to Item because:
1 The ORDER_FACT and ORDER_DETAIL tables both
contain the Order attribute’s identity column to join the
tables, and ORDER_DETAIL contains the Item attribute’s
identity column to extend the fact to Item.
2 The Freight fact cannot simply be joined with a table
containing Item information to return a meaningful
freight value for each item. An allocation expression is
required to extend Freight to the Item level. Notice that
the ORDER_FACT and ORDER_DETAIL tables include
Order-level Units Sold and Item-level Units Sold columns
respectively. These two columns are used to allocate the
fact expression in the procedure below.
The following procedure steps through how to create the fact
extension that has been created for the Freight fact of the
Tutorial project. The procedure also describes general
principles of creating fact extensions which you can use to
create fact extensions for the facts in your project.
110 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
5
The Building Blocks of Business Data: Facts
To define a fact extension with a table relation
1 In Desktop, log in to the MicroStrategy Tutorial project.
2 Browse to the Facts folder and double-click the Freight
fact to edit it. The Fact Editor opens.
3 Click the Extensions tab.
4 Select Extension to Item and click Modify. The Level
Extension Wizard opens.
a new fact extension you would click
ToNew.create
However, this example steps through how the
Freight fact extension Extension to Item was
created.
5 Read the Welcome statement and click Next. The General
Information page opens.
To lower, extend, or disallow the fact entry level
6 Enter a name and a description for your fact extension
(already provided). Then select whether you want to:
•
Lower the fact entry level: define a fact degradation
(see Lowering the level of fact data: Fact
degradations, page 118)
•
Extend the fact entry level: define a fact extension on
a table relation, dynamic fact relation, or a cross
product join
•
Disallow partially or completely the fact entry
level: define a fact extension that does not allow a fact
to be reported at a certain level (see Disallowing the
reporting of a fact at a certain level, page 122)
For this example you are creating a fact extension on a
table relation, so select Extend the fact entry level, and
click Next. The Extended Attributes page opens.
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
111
5
The Building Blocks of Business Data: Facts
Project Design Guide
To select attributes to extend the fact to
7 Select the attributes you want to extend the fact to,
allowing the fact to be reported at the new level. For this
example Item is already selected. Click Next. The
Extension Type page opens.
the fact so that it can be reported at any
Tolevelextend
in a hierarchy, choose the lowest level
attribute in that hierarchy.
To select the type of fact extension
8 Select how you want to extend the fact:
•
Specify the relationship table used to extend the
fact: select a relationship table and join attributes.
•
Select the relationship table dynamically: select a
fact and join attributes. This allows the MicroStrategy
Engine to select the table that includes the fact and
join attributes you choose to create the fact extension
(see Defining a join on fact tables using fact relations,
page 114).
•
Perform the extension through a cross product:
select to apply a cross product join (see Forcing facts
to relate to attributes: Using cross product joins,
page 116) .
For this example select Specify the relationship table
used to extend the fact, and click Next to continue
defining your fact extension on a table relation. The Table
Selection page opens.
To select the table, join attributes, and define the
allocation expression
9 Select the table used to extend the fact to the new level.
For this example, the ORDER_DETAIL table is already
selected. Click Next. The Join Type page opens.
10 Select whether to allow Intelligence Server to dynamically
select what attribute(s) to perform the join, or manually
select the attribute(s). Since you know that you want to
join the ORDER_FACT and ORDER_DETAIL tables using
the Order attribute, select Order and click Next. The Join
Attributes Direction page opens.
112 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
5
The Building Blocks of Business Data: Facts
11 You can choose to join using the attribute, or join using
the attribute and its children. In this case Order has no
children, so you do not have to click the Join against
arrow to change the default. Click Next. The Allocation
page opens.
12 Enter an allocation expression that calculates the fact at
the new level. For this example, the allocation expression
is already provided, ((Freight * [Item-level
Units Sold]) / [Order-level Units Sold]).
a moment to review the allocation expression.
Take
Notice that the expression returns an average
freight amount per item of an order. Therefore, the
extension of Freight provides an estimate of the
freight for each item of an order, not an exact
calculation. A more detailed description of why this
occurs follows this procedure.
13 Click Finish to create the fact extension.
When the engine processes a report containing Order, Item,
and Freight, it joins ORDER_FACT and ORDER_DETAIL and
considers the resulting table as one logical fact table at the
Item, Day, Order, Employee, Promotion level. The SQL
generated for the report containing Order, Item, and Freight
(metric mapped to the Freight fact) is:
select a11.[ORDER_ID] AS ORDER_ID,
max(a11.[ORDER_DATE]) AS ORDER_DATE,
a12.[ITEM_ID] AS ITEM_ID,
max(a13.[ITEM_NAME]) AS ITEM_NAME,
sum(((a11.[FREIGHT] * a12.[QTY_SOLD]) /
a11.[QTY_SOLD])) AS WJXBFS1
from [ORDER_FACT] a11, [ORDER_DETAIL] a12,
[LU_ITEM] a13
where a11.[ORDER_ID] = a12.[ORDER_ID] and
a12.[ITEM_ID] = a13.[ITEM_ID]
group by a11.[ORDER_ID], a12.[ITEM_ID]
SQL statement above is for an Access database.
The
The SQL for your reports may vary depending on the
type of DBMS you use.
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
113
5
The Building Blocks of Business Data: Facts
Project Design Guide
To view how the fact extension is an estimation of freight
values for each item of an order, review the values of the first
order with an extra metric that calculates the number of each
item type in an order shown below.
Notice that the Freight metric averages the amount of freight
per item in an order. The larger freight values occur because
more than one of the item type was included in the order.
This illustrates how fact extensions often provide an
estimation of values at a different level rather than an exact
calculation. If you want to provide exact values of data at a
certain level, you most likely need to capture such data and
store it in your data source.
Defining a join on fact tables using fact relations
Fact extensions can be defined by a fact relation instead of a
table relation. With a fact relation, the table join is possible
on any table that contains the fact. This allows more
flexibility in defining the relations, since the MicroStrategy
Engine is responsible for choosing the appropriate table to
join, rather than you having to select tables manually.
114 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
The following diagram shows the schema from the example
in Defining a join on fact tables using table relations,
page 110 after two summary tables are added to it.
To extend the entry level of the Freight fact to Customer, you
can create a fact relation using the Order Unit Sales fact.
The MicroStrategy Engine tries to join a table containing
Freight to a table containing Order Unit Sales. The engine can
make the following joins, depending on the join attributes
specified:
•
Table 1 and Table 2 on Distribution Center, and Order
•
Table 1 and Table 4 on Distribution Center
•
Table 2 and Table 3 on Distribution Center
•
Table 3 and Table 4 on Distribution Center
The joins described above demonstrate how the join
attributes can be either Distribution Center and Order or just
Distribution Center.
You can define the fact relation in the Level Extension Wizard
which you can access from the Fact Editor. Open the Order
Unit Sales fact and extend it to either Distribution Center and
Order or just Distribution Center. Next, select the Select the
relationship table dynamically option and specify the tables
to use for the extension. This option is set in the step
immediately after To select the type of fact extension,
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
115
5
The Building Blocks of Business Data: Facts
Project Design Guide
page 112 in the procedure above. The tables and attributes
you specify in the wizard determine the different types of
joins that are created, as explained above.
The SQL generated for a report containing Distribution
Center, Customer, and Freight is shown below, if the only join
attribute is Distribution Center.
select a1.DIST_CENTER, a2.CUSTOMER,
sum(a1.Freight)
from TABLE3 a1, TABLE4 a2
where a1.DIST_CENTER = a2.DIST_CENTER
group by a1.DIST_CENTER, a2.CUSTOMER
SQL statement above is for an Access database.
The
The SQL for your reports may vary depending on the
type of DBMS you use.
As with table relations, you can specify the best fit as the join
strategy so that the engine calculates the joins. In a best fit
join, the set of join attributes must contain the entire key of
the left-hand-side fact table (Table 3 in the example SQL
above).
Forcing facts to relate to attributes: Using cross product joins
You can use a cross product join when a join does not exist
and you need to force a fact to relate to an attribute by
extending the fact. The cross product join is an extension that
allows a single fact value to relate to all elements of an
unrelated attribute. This method can produce incorrect data
because data can be repeated and counted twice in some
cases.
products should only be used when no other way
Cross
to extend the fact exists. When you specify a cross
product join to relate a fact to an attribute, you are
creating a Cartesian product of the lookup attribute.
Since this method can be inefficient, MicroStrategy
does not recommend using the cross product join.
116 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
5
The Building Blocks of Business Data: Facts
For example, in the following schema, Distribution Center
does not relate to Dollar Sales:
Table 1
Table 2
Distribution Center
Order
Customer
Dollar Sales
To report Dollar Sales by Distribution Center, a cross product
join must be used.
You can define this cross product join in the Level Extension
Wizard in the Fact Editor. Open the Dollar Sales fact and
extend it to the Distribution Center attribute. Next, select the
Perform the extension through a cross product option.
This option is set in the step immediately after To select the
type of fact extension, page 112 of the procedure above. For
this example, you do not need to specify an allocation
expression.
Notice that no join attributes are specified. The
MicroStrategy Engine always cross-joins the lookup tables of
the attributes in the extension.
The SQL generated for a report containing Customer,
Distribution Center, and Dollar Sales is:
select a1.DIST_CENTER, a2.CUSTOMER,
sum(a2.DOLLAR_SALES)
from TABLE1 a1, TABLE2 a2
group by a1.DIST_CENTER
SQL statement above is for an Access database.
The
The SQL for your reports may vary depending on the
type of DBMS you use.
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
117
5
The Building Blocks of Business Data: Facts
Project Design Guide
Lowering the level of fact data: Fact degradations
Degradation, which lowers a fact level, is the logical opposite
of aggregation. To view fact data at a lower logical level than
the fact is stored at, you must degrade the fact to a lower
level. This scenario may occur because you stored a fact at a
level that is used most commonly in reports. However, you
must support those users who wish to view and analyze the
same fact data at a lower logical level.
For example, the Human Resources Analysis Module of the
MicroStrategy BIDK includes a Planned Compensation fact
that is stored at the Department level, and has a fact
degradation to the Employee level (the attributes, facts, and
metrics used in this example can all be found in this Analytics
Module). The fact extension does not use an allocation
expression to degrade Planned Compensation to the
Employee level. This causes every employee to be listed with
the same planned compensation value as the employee’s
department, as shown below:
The analytical value of this fact degradation is not
immediately recognizable. However, now that Planned
Compensation is available at the Employee level, you can
create more meaningful analysis with other fact data that is
118 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
stored at the Employee level. For example, the Compensation
Cost fact is stored at the Employee level. The metric Actual as
% Planned Compensation has been created to calculate the
actual compensation of an employee as a percentage of the
planned compensation for the entire department of the
employee. The metric definition is ([Compensation
Cost]/[Planned Compensation]), which performs a
division of metrics defined from the Compensation Cost and
Planned Compensation facts, respectively. You can now view
what percentage of your planned compensation per
department has been spent per employee, as shown below:
Without using a degradation of Planned Compensation to
Employee, you could not include Department and Employee
on a report with these metrics and return accurate values.
The following procedure steps through how to create the fact
degradation that has been created for the Planned
Compensation fact of the Human Resources Analysis
Module. The procedure also describes general principles of
creating fact degradations which you can use to create fact
degradations for the facts in your project.
To define a fact degradation
1 In Desktop, log in to the Human Resources Analysis
Module.
2 Browse to the Facts / Compensation / Planning folder
and double-click the Planned Compensation fact to edit
it. The Fact Editor opens.
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
119
5
The Building Blocks of Business Data: Facts
Project Design Guide
3 Click the Extensions tab.
4 Select Degradation to Employee and click Modify. The
Level Extension Wizard opens.
a new fact degradation you would click
ToNew.create
However, this example steps through how the
Planned Compensation fact degradation
Degradation to Employee was created.
5 Read the Welcome statement and click Next. The General
Information page opens.
6 Enter a name and a description for your fact extension
(already provided). Then select whether you want to:
•
Lower the fact entry level: define a fact degradation
•
Extend the fact entry level: define a fact extension on
a table relation, dynamic fact relation, or a cross
product join (see Defining a join on fact tables using
table relations, page 110 and Defining a join on fact
tables using fact relations, page 114)
•
Disallow partially or completely the fact entry
level: define a fact extension that does not allow a fact
to be reported at a certain level (see Disallowing the
reporting of a fact at a certain level, page 122)
For this example you are creating a fact degradation so
select Lower the fact entry level, and click Next. The
Extended Attributes page opens.
7 Select the attributes you want to degrade the fact to,
allowing the fact to be reported at the new level. For this
example Employee is already selected. Click Next. The
Join Type page opens.
the fact so that it can be reported at any
Tolevelextend
in a hierarchy, choose the lowest level
attribute in that hierarchy.
8 Select what attribute(s) to perform the join. For this
example, the Department attribute is already selected.
Click Next. The Join Attributes Direction page opens.
120 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
5
The Building Blocks of Business Data: Facts
9 You can choose to join using the attribute, or join using
the attribute and its children. For this example, the join is
performed on the Department attribute and its children.
Click Next. The Allocation page opens.
10 Enter an allocation expression that calculates the fact at
the new level. For this example, you do not need to
include an allocation expression. See Fact degradations
with allocation expressions, page 121 for an example of
using an allocation expression for a fact degradation.
11 Click Finish to create the fact degradation.
Fact degradations with allocation expressions
Not all fact degradations can simply be lowered to a new
level. Ordinarily, you must add an allocation expression,
which allows the distribution of values according to a
calculation you specify, to change the definition of the fact in
a level extension.
is similar in concept to choosing an aggregation
This
function (Sum, Avg, and so on) when aggregating data
to higher levels.
For example, if your fact is stored at the yearly level and you
want to report the data at the monthly level, you can create a
degradation on the fact to relate it to the monthly level. You
select Month to be the attribute to which to degrade. You then
specify that the allocation expression is fact/12.
By creating allocation expressions, you define how
higher-level facts are degraded to lower-level attributes.
Allocation expressions are defined by operations you set on
attributes and facts in the Level Extension Wizard in the Fact
Editor.
Fact degradations often produce data estimates rather than
exact values for the fact data at lower logical levels. For
example, consider the allocation expression fact/12 for a
degradation from Year to Month. Using such an allocation
expression would spread a year’s fact data evenly over the 12
months of that year. While it is possible that the fact data
would be the same for every month of the year, this is often
an unlikely scenario. Such fact degradations should be used
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
121
5
The Building Blocks of Business Data: Facts
Project Design Guide
only when fact data is not stored at a lower logical level and
there is no way to directly relate the fact data to the lower
logical level.
Disallowing the reporting of a fact at a certain level
The Disallow partially or completely the fact entry level
setting within the Fact Editor is like a lock which prevents a
fact from being reported at a specific level. The setting
prevents unnecessary joins to lookup tables. The following
examples describe instances in which disallowing a fact entry
level can prove useful.
Disallowing a fact to be extended to a level lower than the
fact’s entry level due to unnecessary complexity and the cost
of analyzing fact data at such a level is a common use for this
feature. If a fact is stored at a level that is counterproductive
to a query, such as data that is stored at the Minute or Second
level, you can disallow the lower levels. For example, if you
have three years’ worth of data, querying at the Minute or
Second level consumes too many resources and returns
extensive data. With a disallow in place, if you create a report
and attempt to include the fact at the Minute or Second level,
an error is returned, indicating that the report cannot be run
at that level.
Consider a schema containing three dimensions: Geography,
Time, and Product. Suppose you create a fact called Sales at
the Item level in the Product dimension and a metric called
Sales as the sum of the Sales fact. When you create a report
containing the Month attribute and the Sales metric, the
Analytical Engine does a dynamic cross-join and evaluates
the report. To explicitly disallow an extension of the Sales fact
to the Time dimension, you would use the Disallow partially
or completely the fact entry level setting and select the
lowest attribute in the Time dimension such as Day. This
option is set in the step immediately after To lower, extend,
or disallow the fact entry level, page 111 of the procedure to
create a fact extension above. After updating the schema and
re-executing the report, the report fails because the disallow
setting now prevents the cross-joins between the lookup
tables and fact tables. This setting, however, does not affect
normal joins.
122 Modifying the levels at which facts are reported: Level extensions
© 2007 MicroStrategy, Inc.
Project Design Guide
The Building Blocks of Business Data: Facts
5
the previous example, for the Sales fact, assume you
Inspecify
an extension to the Month attribute and also
disallow extension to Year which is a parent of the
extended attribute, Month. If you execute the report
containing the Year attribute and Sales metric, the
report runs successfully. In this case, the engine sorts
the extension conditions specified in some order and
calculates the report based on the sorted order of
extensions. This is not an expected design condition,
although the engine returns a valid SQL. It is advisable
to avoid fact definitions that contain contradictory
extension definitions.
The Disallow the fact entry level setting applies only to
attributes that can be considered as extended attributes. For
example, you create a report that contains the attributes
Subcategory and Item and the Revenue metric, which is
defined as sum of the Revenue fact. You now disallow an
extension on the Revenue fact for the Item attribute and
update the schema. If you re-execute the report, you can still
see Revenue by Item. This implies that the fact extension has
not been disallowed. This is because Revenue exists at the
same level as Item in the MicroStrategy Tutorial project. So
you encounter only normal joins and no extensions. There
must be a valid reason to disallow reporting a fact at a certain
level. In this case, disallowing the Revenue fact at the level it
is stored at in the data warehouse does not make logical
sense.
© 2007 MicroStrategy, Inc.
Modifying the levels at which facts are reported: Level extensions
123
5
The Building Blocks of Business Data: Facts
124 Modifying the levels at which facts are reported: Level extensions
Project Design Guide
© 2007 MicroStrategy, Inc.
6
6.
THE CONTEXT OF YOUR
BUSINESS DATA: ATTRIBUTES
Introduction
Business data represented by facts can offer little insight
without the presence of business concepts and context, which
take the form of attributes in MicroStrategy. Attributes
provide the business model with a context in which to report
on and analyze facts. While knowing your company’s total
sales is useful, knowing where and when the sales took place
provides the kind of analytical depth users require on a daily
basis.
For example, you have a report with the Month, Year, and
Region attributes on the template, as well as a Revenue
metric based on the Revenue fact. When executed, the report
displays your company’s revenue at the region, month, and
year levels. Because of the attributes on the report, a
substantial amount of information is available, including
which regions produced the least revenue and which years
saw the highest growth in revenue. If you remove the
attributes from the report, you can only find out how much
revenue the company generated in total.
© 2007 MicroStrategy, Inc.
125
6
The Context of Your Business Data: Attributes
Project Design Guide
Creating attributes is an important step in the initial project
design effort, which comes after creating facts when using the
Project Creation Assistant. New user and application
requirements make attribute creation and modification an
important part of the entire project life cycle.
In the data warehouse, attributes are normally identified by a
unique ID column in a lookup table. In MicroStrategy
reports, attributes are identified by the column headers of the
reports.
A report designer creates a report in part by determining
these report column headers. Intelligence Server, using this
report definition, instructs the engine how to build the SQL
for that report. The expressions of attributes and facts in the
report define the SELECT clause of the SQL command.
For example, consider the following:
Select Store_ID, Date, sum(Sales)
From Store_Fact
Group By Store_ID, Date
126
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
In the SQL above, sales information will be retrieved by store
and date. The attributes and metrics in the report tell
Intelligence Server where to look in the data warehouse for
the information and how to create the SQL that will retrieve
it. Because of this process, report analyzers do not have to
know SQL to extract information from a data warehouse.
The lowest level attribute you include in a report, such as
Day, is the lowest level of detail reported. A high-level report,
such as a report at the Year level, includes the Year attribute
but lacks the detail of a similar report which includes the
lower level attributes Month and Week. It is important to
understand the data is still the same, it is just not aggregated.
discussion about metrics, filters, and reports is
Abeyond
the scope of this guide and is covered in the
MicroStrategy Advanced Reporting Guide.
Attributes are defined by these properties:
© 2007 MicroStrategy, Inc.
•
Attribute form: contains an identifier or descriptor of an
attribute. Attributes can have multiple attribute forms.
For example, for the Customer attribute, Customer Email,
Customer First Name, and Customer Last Name are
examples of attribute forms. See Column data
descriptions and identifiers: Attribute forms, page 143.
•
Attribute expression: maps a MicroStrategy attribute
form to one or more columns in the warehouse. See
Attribute form expressions, page 147.
•
Attribute relationship: allows interaction of data at
different conceptual levels and shows how data is related
within a project. See Attribute relationships, page 159.
127
6
The Context of Your Business Data: Attributes
Project Design Guide
The following diagram illustrates how the attribute
properties listed above are related:
While creating attributes is a major step in the initial creation
of a project, it is often necessary to modify and create
attributes throughout the life cycle of a project. The
procedures to perform these tasks are discussed in the first
section (Creating attributes, page 129) of this chapter. The
later sections discuss conceptual information on attributes,
as well as highlight some advanced attribute design
techniques and procedures.
128
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
Creating attributes
An attribute is primarily used to group and aggregate fact
data to add business context to the fact data. The ability to
report on and analyze data requires data to have a business
context; therefore, creating attributes is a major step in any
project design effort.
This section provides steps to create attributes at different
phases of the project design process, using different
techniques and MicroStrategy interfaces:
•
Simultaneously creating multiple attributes,
page 129—steps to create multiple attributes as part of the
initial project design effort or later in a project’s life cycle.
•
Adding and modifying attributes, page 134—steps to add
and modify attributes for an existing project. This
includes adding advanced features such as attribute forms
to attributes that already exist or adding new attributes as
your project evolves.
Simultaneously creating multiple attributes
During your initial project design effort, you can create
multiple attributes using the Attribute Creation Wizard.
To create attributes using the Attribute Creation Wizard
This procedure is part of an initial project creation effort
using the Project Creation Assistant, which launches the
Attribute Creation Wizard to complete the attribute creation
tasks. For steps to access the Project Creation Wizard, see To
create a new project using the Project Creation Assistant,
© 2007 MicroStrategy, Inc.
Creating attributes
129
6
The Context of Your Business Data: Attributes
Project Design Guide
page 78. You can also access the Attribute Creation Wizard at
any time in the development of a project from the Schema
menu in MicroStrategy Desktop.
1 In the Project Creation Assistant, click Create attributes.
The Attribute Creation Wizard opens, as shown below.
2 Review the introduction page that is displayed.
Define attribute creation rules
These rules can make the process of choosing attribute
columns and naming your attributes considerably easier,
especially if you use consistent naming conventions and
data types in your data warehouse. The Attribute Creation
Wizard uses these rules below to help automate the
attribute creation process. Change these rules if the
naming or data type conventions in your warehouse do
not conform to these defaults.
3 Click Define Rules to set some basic attribute creation
rules. The Attribute Creation Rules page opens.
4 The Column data type area allows you to select the
column data types to be available as possible attribute ID
columns. Select the check boxes for the data types that
should be included when the wizard searches the data
warehouse for available attribute ID columns.
130 Creating attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
5 The Attribute name area allows you to determine how to
create default attribute names. You can select the
appropriate check boxes to set the following default
behaviors for creating attribute names:
•
Replace underscores in the attribute name with spaces
•
Remove the word “ID” from the name
•
Capitalize the first letter
6 The Warehouse search area determines naming
conventions to help locate your warehouse objects. The
defaults are ID for identifier columns, DESC for
description columns, and LOOKUP for lookup tables.
7 Click OK to accept your rule changes and return to the
Attribute Creation Wizard.
ID column selection
An ID column is a column or group of columns that
uniquely identifies each element of an attribute.
8 Click Next. The ID Column Selection page opens.
choosing the ID column for an attribute,
When
make sure that all values in the column are unique
and that it does not contain NULL values. You
should never use a column that has NULL or
repeated values as the ID column for an attribute.
Doing so results in unexpected behavior and
errors.
Only those columns with data types that match those
chosen in the rules you defined above appear on the ID
Selection page. The columns that match the identifier
naming convention that you set in the warehouse search
rule above are automatically highlighted.
© 2007 MicroStrategy, Inc.
Creating attributes
131
6
The Context of Your Business Data: Attributes
Project Design Guide
9 From the Available columns pane, select the columns to
use for your attribute IDs and click > to add them to your
project. Click >> to add all the listed columns.
Note the following:
– You can rename any attribute name to make it
more user-friendly by right-clicking the attribute
and selecting Rename.
– To remove attribute ID columns from your project,
select the attribute IDs in the Attributes pane and
click < to move them to the Available columns
pane.
– The Attribute Creation Wizard cannot handle
columns that hold the same information but have
different column names (that is, heterogeneous
columns). For more information about mapping
attributes to heterogeneous columns, see Joining
dissimilar column names: Heterogeneous
mappings, page 153.
Create compound attributes
A compound attribute is defined as an attribute with more
than one column specified as the ID column. This implies
that more than one ID column is needed to uniquely
identify the elements of that attribute (see Attributes with
more than one ID column: Compound attributes,
page 183).
10 To create a compound attribute, complete the following
steps:
•
Click Compound Attributes and then click Add. The
New Compound Attribute dialog box opens.
•
Type a name for the attribute.
•
Select the columns that are required to uniquely
identify the compound attribute and click OK. You are
returned to the Attribute Creation Wizard.
Description column selection
Description columns provide the data which gives context
and meaning to your attributes.
132 Creating attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
11 After adding all your attribute ID columns, click Next. The
Description Column Selection page opens.
12 Select whether to use the ID or a different column for the
description of the attribute. The column that meets the
description naming convention that you set in the
warehouse search rule is automatically selected.
Note the following:
– In general, you should use the default description
column for each attribute. In some cases, however,
it may make sense to use the ID column as the
description column, such as Year.
– Other attribute forms need to be created through
the Attribute Editor after you complete steps in the
Project Creation Assistant. Refer to Adding
attributes with the Attribute Editor, page 136, for
more information about attribute forms.
Lookup table selection
Lookup tables are the physical representation of
attributes; they provide the information for an attribute
through data stored in their ID and description columns.
13 Click Next when you are finished selecting description
columns for attributes. The Lookup Table Selection page
opens.
14 Select the lookup table for each attribute.
The table that follows the lookup naming convention that
you set in the warehouse search rule is automatically
selected. In general, you should choose the default lookup
table for each attribute.
15 Click Next:
© 2007 MicroStrategy, Inc.
•
If you have created compound attributes, the
Compound Attribute Definition page opens. Specify
the lookup table and description column for the
compound attributes and click Next. The Relationship
Definition page opens.
•
If you have not created a compound attribute, the
Relationship Definition page opens.
Creating attributes
133
6
The Context of Your Business Data: Attributes
Project Design Guide
Relationship definition
For each attribute, you specify the children and the type of
relationship: one-to-one, one-to-many, or many-to-many.
When you design a logical data model for your project (see
Chapter 2, The Logical Data Model), the relationships
between attributes should become apparent. Related
attributes such as City, State, or Region are often grouped
in a common hierarchy, like Location. In a logical data
model, when attributes are in the same hierarchy they
must be related to each other, whereas attributes in
different hierarchies cannot be related.
16 For each attribute, define child attributes:
•
In the Attributes pane, select an attribute and click
Add. The Select Children Attributes dialog box opens.
•
Select the child attributes from the list of available
child attributes and click OK. You are returned to the
Attribute Creation Wizard.
•
In the Children of: attribute name pane, select the
relationship type for the attribute to its child attribute.
For more information on the different attribute
relationship types, see Attribute relationships,
page 159.
17 When you have defined children for all the attributes that
need them, click Next. The Finish page opens.
18 Review the summary information in the Finish page and
click Finish to create the attributes.
After you have completed the steps of the Attribute Creation
Wizard, the attributes are created. This completes the initial
creation of a project with the Project Creation Assistant.
Adding and modifying attributes
Just as you can add more facts to your project once you have
created it, you can also create and add attributes as they
become necessary. As a company evolves, so does its
134 Creating attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
reporting requirements; these requirements can lead to
changes to the data warehouse as well as to the schema
within its MicroStrategy projects.
For example, a health care company, with offices only in the
United States, decides to extend its operations into Europe
and Asia. Before the shift overseas, the company does not
include lookup tables with information about different
countries in its data warehouse.
However, when the company opens its offices in Europe and
Asia, it must add lookup tables that contain data about its
new offices to its warehouse. It must then add these tables to
its MicroStrategy project, and create the appropriate
attributes so report users can analyze business data for their
appropriate country.
You can create attributes with either the Attribute Creation
Wizard, which you use to create the first attributes for your
project, or the Attribute Editor, which allows you to define
attributes, attribute forms, and attribute form expressions.
•
•
The Attribute Creation Wizard allows you to:
Create simple attributes
Create multiple attributes quickly
Add a large number of attributes during project
creation
The Attribute Editor allows you to:
Create simple and advanced attributes
Edit existing attributes and configure additional
schema-level settings
The Attribute Creation Wizard works well for building a large
number of attributes initially, but you cannot use it to modify
existing attributes or to define more advanced attributes. In
general, you only use the Attribute Creation Wizard as part of
the initial project creation, for creating most of the attributes
for the project. You can use the Attribute Editor to edit
existing attributes and create additional attribute forms, map
heterogeneous column names, define advanced expressions,
configure additional settings, and so on.
© 2007 MicroStrategy, Inc.
Creating attributes
135
6
The Context of Your Business Data: Attributes
Project Design Guide
Adding attributes with the Attribute Creation
Wizard
Although the Attribute Creation Wizard is primarily used to
create most of a project’s attributes during initial project
creation, you may still find it useful if you need to create
multiple attributes from remaining lookup columns in your
warehouse.
Follow the steps below to use the Attribute Creation Wizard
to create simple attributes in bulk.
To create simple attributes in bulk using the Attribute Creation
Wizard
1 In MicroStrategy Desktop, log in to the project source that
contains your project and expand your project.
must use a login that has Architect privileges.
You
See the Permissions and Privileges appendix of the
MicroStrategy System Administration Guide for
more information.
2 From the Folder List, select the project to which to add
new attributes.
3 From the Schema menu, choose Attribute Creation
Wizard. The Attribute Creation Wizard opens.
4 To create attributes with the Attribute Creation Wizard,
follow the steps outlined in Simultaneously creating
multiple attributes, page 129.
Adding attributes with the Attribute Editor
The Attribute Editor is used to add advanced features such as
attribute forms to attributes that already exist. You can also
use it to add new attributes to your project.
136 Creating attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
To create an attribute using the Attribute Editor
1 In MicroStrategy Desktop, log in to the project source that
contains your project and expand your project.
2 From the File menu, select New, and then Attribute. The
Attribute Editor opens, with the Create New Form
Expression dialog box displayed on top of it.
3 From the Source table drop-down list, select a table
which contains the columns of data for the attribute. Its
columns are listed in the Available Columns pane.
4 To create a simple attribute form expression (Attribute
form expressions, page 147), drag a column name from
the Available columns pane to the Form expression pane.
To create a more advanced attribute form expression, use
a combination of any of the following techniques:
•
Enter constants in double quotes.
•
Click f(x) in the Form expression toolbar to create a
function using the Insert Function Wizard.
•
Click any operator in the Form expression toolbar to
insert it into the expression.
you create an expression for an attribute
When
form, you are only required to select an available
column and move it to the Form expression pane.
You do not have to include any operators,
functions, or parentheses.
5 Click Validate to make sure your expression is valid.
6 Under Mapping Method, select Automatic or Manual:
•
© 2007 MicroStrategy, Inc.
Automatic mapping means that MicroStrategy scans
all of the tables in the project and selects all tables with
the columns used in the attribute form expression as
possible source tables for the attribute form. You can
then clear any tables mapped automatically, or select
other tables.
Creating attributes
137
6
The Context of Your Business Data: Attributes
•
Project Design Guide
Manual mapping means that MicroStrategy scans all
of the tables in the project and locates all tables with
the columns used in the attribute form expression.
You then select which of those tables are used as
source tables for the attribute form.
Note the following:
– The mapping method defaults to Automatic for the
first attribute or attribute form expression you
create. The system maps the expression to each of
the source tables. For subsequent attributes, the
default is Manual.
– A constant expression cannot use the automatic
mapping method.
– These mapping methods are NOT the same as the
automatic mapping methods for the Warehouse
Catalog. Using automatic mapping in the Attribute
Editor helps you decide which tables to map your
attribute to when creating an attribute. The
Warehouse Catalog mapping methods (discussed
in Mapping schema objects and calculating logical
sizes for tables, page 231) determine whether
attributes or facts are automatically mapped to new
tables when they are added after an attribute or
fact is created.
7 Click OK. The Create New Attribute Form dialog box
opens, from which you can create attribute forms for the
attribute (Column data descriptions and identifiers:
Attribute forms, page 143).
8 From the Source tables pane, select a table and click Set
as Lookup to set the lookup table for the attribute. A
lookup table holds the information for an attribute. If you
chose manual mapping, select the check boxes of the
tables to map to the attribute form.
9 In the Form general information area, type a name and
description in the associated fields for the attribute form.
138 Creating attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
10 In the Category used drop-down list, do one of the
following:
•
Select a form category from the drop-down list. For a
description of form categories, see Attribute form
properties, page 146.
•
Click Modify to create a new form category.
a column with a non-numeric data type as an
Using
ID column of an attribute can result in SQL
generation issues. Therefore, if you select a column
with a non-numeric data type and set it as an ID
column, a warning message appears by default
when you click OK in the Create New Attribute
Form dialog box.
11 In the Form format area, select a display type and a
default sorting option from the associated drop-down
lists.
groups are sorted by the Default sort of the
Custom
form that appears first in the Report display forms.
For more information on custom groups, refer to
the MicroStrategy Advanced Reporting Guide.
12 Click OK. The Attribute Editor opens.
13 From the File menu, select Save As. The Save dialog box
opens.
14 Navigate to the folder in which to save the attribute. Enter
a name for the derived fact. Click Save.
15 From the Schema menu, select Update Schema to
update the project schema. This ensures that your project
is updated to recognize the new attribute definition.
Modifying attributes
After creating an attribute, you can modify the attribute at
any time using the Attribute Editor. You cannot use the
Attribute Creation Wizard to modify attributes.
© 2007 MicroStrategy, Inc.
Creating attributes
139
6
The Context of Your Business Data: Attributes
Project Design Guide
To modify an existing attribute
1 In MicroStrategy Desktop, open the folder that contains
the attribute to modify.
2 Double-click the attribute to edit. The Attribute Editor
opens.
You can then modify all the options available when
creating and attribute in the Attribute Editor, which is
described in the previous procedure To create an
attribute using the Attribute Editor, page 137.
You can learn how to create more advanced attributes in the
various sections below.
Unique sets of attribute information: Attribute
elements
Attribute elements are the unique sets of information or
values of an attribute. For example, in the following diagram,
Customer is the attribute and New York NY, Baltimore BA,
and Boston BN are elements of the attribute City:
140 Unique sets of attribute information: Attribute elements
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
The following example displays the physical warehouse table
that stores elements and data for the Customer attribute.
Each attribute element is a row in an attribute lookup table in
your data warehouse, as shown below:
The Customer attribute is a good example to understand the
components of an attribute and the concept of an attribute
element. With the Customer attribute, each attribute element
is an individual customer. Each customer (attribute element)
has its own set of information such as last name, first name,
email address, and so on which are defined by the attribute
forms (see Column data descriptions and identifiers:
Attribute forms, page 143).
As shown above, an attribute element is a unique set of
information defined by the attribute forms of an attribute.
Attribute elements are identified by their browse forms,
which should be forms that provide a general description of
the attribute element. For example, in the image above, the
First Name and Last Name forms are used to identify the
© 2007 MicroStrategy, Inc.
Unique sets of attribute information: Attribute elements
141
6
The Context of Your Business Data: Attributes
Project Design Guide
attribute elements. Just as you would not refer to a customer
by his or her street address, you would not want to use the
Address form to identify the Customer attribute elements.
For more information on selecting the attribute forms used to
identify attribute elements, see Using attributes to browse
and report on data, page 189.
Attribute elements can be identified in logical data models.
As shown below, the attribute Division has multiple attribute
elements, such as Men’s Clothing, Shoes, and Sporting
Goods:
In MicroStrategy reports, attribute elements are displayed
depending on the location of the attribute they are associated
with. For example, the report below (created from the Sales
142 Unique sets of attribute information: Attribute elements
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
and Distribute Analysis Module of the MicroStrategy BIDK)
has two attributes, Sales Organization and Year. Sales
Organization is on the rows of the report along with its
attribute elements such as USA Central. Year is on the
columns of the report along with its attribute elements such
as 2005.
The display of attributes and their attribute elements is also
affected by the location of the metrics on the report. The
report above uses the common practice of putting the metrics
(Sales Orders Quantity (Base Units) and Cost Sales Orders)
on the columns of the report.
Column data descriptions and identifiers:
Attribute forms
Attribute forms are identifiers or descriptors of an attribute,
as explained in Logical data modeling conventions, page 33.
Every attribute must have at least one form, and most have at
least two:
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
143
6
The Context of Your Business Data: Attributes
•
The ID form (required)
•
A description form
Project Design Guide
Every attribute must have an ID form (identity form). ID
forms serve to uniquely identify each attribute element from
other elements for the same attribute. For example, the
Customer attribute’s ID form is Customer_ID, which is a
column of unique numeric values to identify each customer.
To differentiate between two customers such as John Smith
and Fred Black, each customer must have a different value for
their identity column. In this case John Smith can have a
value of 1 in the Customer_ID column and Fred Black can
have a value of 2 in the Customer_ID column.
Attributes also have description forms. The Customer
attribute in the MicroStrategy Tutorial has various forms,
including the Customer Name and the Address forms. These
types of forms give context and information about the
Customer attribute.
Some attributes can have additional descriptive forms that do
not serve as the primary description form. For the Customer
attribute, Email is included as an additional descriptive form,
as shown in the following diagram:
144 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
In the data warehouse, a lookup table with three columns
holds the following separate forms, described below:
•
Customer_ID: a unique, identifying number for each
customer (ID form)
•
Customer_Full_Name: the full name of each customer
(Description form)
•
EMAIL: the email address for the specific customer
(Additional description form)
In this example, the LU_CUSTOMER table records all of the
attribute form data for the Customer attribute.
Attributes must contain at least one ID form, which uniquely
identifies the attribute. The forms you create must have a
reference to a lookup table and can include multiple
expressions. Each table must have an ID form; the ID forms
are used to join tables. When creating an attribute form, you
can choose a lookup table in the Attribute Editor from a list of
tables existing in the project. In the warehouse, two columns
with different names can represent the same information
about an attribute. In such cases, you must map the
appropriate columns to the same attribute to retrieve
accurate and complete results when using an attribute on a
report. Heterogeneous column names are discussed in
Joining dissimilar column names: Heterogeneous
mappings, page 153.
For example, two tables exist, one with the forms
Customer_ID, Name, and SSN. The second lookup table
contains Customer _ID and Email. The attribute will have
the Customer_ID, Name, SSN, and Email forms and the
tables will join together through the ID columns because that
is the column they have in common.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
145
6
The Context of Your Business Data: Attributes
Project Design Guide
Attribute form properties
You must select properties for each form when you create
forms in the Attribute Editor in MicroStrategy Desktop.
These properties affect the display of the forms and include
the following:
•
Categories help group the types of forms. The standard
category options are ID, Desc, and None. You can create
new form categories in the Attribute Editor.
When you have attributes that require multiple
description forms, it is a good practice to map the most
commonly used or most important description form to
the Desc form of the attribute. Each attribute can have
only one Desc form; the other description forms must be
mapped to None forms. While there is no difference in
how a Desc attribute form and None attribute form are
used in MicroStrategy, mapping the most commonly used
or most important description form can be helpful for
project designers to quickly distinguish this attribute form
from the other secondary forms. There is no way to
distinguish a Desc attribute form from a None attribute
form on a MicroStrategy report.
•
Format types control how the form is displayed and how
filters are built. For example, specifying a format type of
Big Decimal allows users to preserve precision when
qualifying on a form with more than 15 digits. Big Decimal
is discussed in detail in Appendix D, Data Types.
•
Default sort governs how the form is sorted by default
when included in a report. You can choose from
Ascending, Descending, or None. For information on how
attribute forms are sorted when multiple attribute forms
of a single attribute define a default sort order, see Default
sorting of multiple attribute forms, below.
Default sorting of multiple attribute forms
When creating attribute forms, you can define the default
sort order for each attribute form. If you define multiple
attribute forms of an attribute with ascending or descending
sort orders, the first attribute form with a default sort order is
146 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
used to sort the attribute on the report. If the first attribute
form with a default sort order is not included on a report,
then the second attribute form with a default sort order is
used for sorting, and so on.
For example, the Customer attribute in the MicroStrategy
Tutorial project has the five attribute forms shown below:
Of these five attribute forms, only Last Name has a default
sort order set. Modify the Address form so that it has a
descending default sort order. If you include Customer on a
report with both Last Name and Address, customers are
sorted by their Last Name in ascending order. This is because
Last Name was created first and therefore is considered for
sorting before the Address form. If you remove the Last
Name form from the report, customers are sorted by their
address in descending order.
This is the default functionality for how attributes are sorted
by their attribute forms on reports. It is important to note
that you can change how attribute forms are sorted from
within a report. In a report you can use advanced sorting to
define how attribute forms, metrics, and other report objects
are sorted. Sorting defined for a report takes precedence over
default sorting defined for attribute forms. For more
information on advanced sorting, refer to the MicroStrategy
Advanced Reporting Guide.
Attribute form expressions
Attributes act like holders of information and provide context
for fact data. For example, the Customer attribute holds
information about the customer such as Name and Address.
These information units are called attribute forms. An
attribute form expression defines what columns in the
warehouse are used to represent the attribute form in SQL.
Each attribute form must have at least one expression.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
147
6
The Context of Your Business Data: Attributes
Project Design Guide
For example, the form expression for the Customer First
Name attribute form is CUST_FIRST_NAME. The form
expression for the Customer Last Name attribute form is
CUST_LAST_NAME. In this instance, the CUST_FIRST_NAME
and CUST_LAST_NAME columns in the warehouse provide
information about first and last names respectively.
Although you can have multiple expressions in different
tables, a form cannot have two different expressions in the
same source table.
You can create expressions using attribute columns,
constants, and/or mathematical operators, for example, +, -,
/, *. Only implicit attributes do not include a column in the
expression, since they only use the constants you declare.
You can also create a form expression using Apply functions.
These functions are discussed in the Pass-through
Expressions appendix in the MicroStrategy Advanced
Reporting Guide.
The types of attribute form expressions are:
•
Simple expressions, page 148: Simple form expressions
access data through columns in the data warehouse.
•
Derived expressions, page 150: Derived form expressions
perform some type of mathematical calculation on
columns in the data warehouse to create an attribute
form.
•
Joining dissimilar column names: Heterogeneous
mappings, page 153: Heterogeneous mappings allow you
to use columns with different names in the data
warehouse as the same attribute form.
•
Implicit expressions, page 155: Implicit form expressions
do not relate directly to data stored in the data warehouse.
These form expressions create virtual data by combining
or using columns to generate the data.
Simple expressions
A simple expression is based on a single warehouse column.
The definition of the simple expression includes the tables in
which the column is found.
148 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
For example, Category is an attribute in the MicroStrategy
Tutorial. It has two forms, ID and Description, both of which
are defined by simple expressions. The expression for the ID
form is the CATEGORY_ID column and the expression for the
description form is the CATEGORY_DESC column. Both of
these columns reside in the table LU_CATEGORY.
Example: creating an attribute form with a simple expression
A retailer begins a promotion that offers customers 25% off of
their purchases if they fill out a feedback survey on the
company website. The retailer intends to analyze the data
gathered from the surveys to better market their products in
the future.
The retailer’s customers provide a variety of information on
the surveys, including their dates of birth. Once gathered, the
date of birth data eventually becomes part of the retailer’s
data warehouse and the appropriate lookup table is added to
the retailer’s project in MicroStrategy.
At this point, the project designer must add the column
containing the customer dates of birth as an additional
attribute form of the Customer attribute. This will enable
report designers to display each customer’s date of birth
alongside each customer’s name on reports.
Follow the procedure below to create Customer Birth Date as
an attribute form in the Customer attribute.
To create an attribute form with a simple expression
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
in to MicroStrategy Tutorial.
2 Navigate to the Schema Objects folder, open the
Attributes folder, and then the Customers folder.
3 Double-click the Customer attribute. The Attribute
Editor opens.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
149
6
The Context of Your Business Data: Attributes
Project Design Guide
4 Click New. The Create New Attribute Form dialog box
opens.
5 From the Source table drop-down list, select the
LU_CUSTOMER table. This is the table that contains
customers’ dates of birth.
6 Double-click the CUST_BIRTHDATE column to add it to
the Form expression pane on the right. The mapping
method is selected as Automatic by default.
7 Click OK. The Create New Attribute Form dialog box
opens.
8 In the Form general information area, in the Name field,
type Customer Birth Date.
9 From the Category used drop-down list, select DATE
since Customer Birth Date is neither the ID form of
Customer nor the primary description form.
10 Click OK. The new Customer Birth Date attribute form is
added to the Attribute form pane in the Attribute Editor.
11 Because this is only an example, close the Attribute Editor
without saving your changes.
Derived expressions
Derived expressions are created using a combination of
warehouse columns, mathematical operators, functions, and
constants. While simple expressions have their value
determined by just one column in a warehouse table, derived
expressions are defined using one or more columns as well as
other operators and values. Any operation on a column (such
as adding a constant, adding another column, or setting the
expression to be an absolute value) creates a derived
expression.
For example, you can create a derived attribute to calculate
age or anniversaries. By calculating the difference between
the columns Date of Birth and Current Date, you can create
an attribute to hold the age of a customer or an employee that
has been derived from the two columns. By creating an
attribute to calculate age in this manner, the attribute’s value
150 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
is automatically updated as the age changes. If you created an
attribute for age in which you included a constant number,
the attribute would need to be updated every time a customer
or an employee has a birthday.
Example: creating an attribute form with a derived expression
In your database, you store Customer names in two different
columns, CUST_FIRST_NAME and CUST_LAST_NAME.
However, you want reports to display a customer’s first name
and last name together as a single entry on a report. You can
achieve this using a derived form expression Name, which
consists of the two strings. Using the Customer attribute, the
syntax of the derived expression for Name reads:
CUST_FIRST_NAME + “ “ + CUST_LAST_NAME
On a report, this information is displayed as Mary Jones
under the Name column. As another example, you could
create a derived expression for Name in the format of Last
Name, First Name using the following syntax:
CUST_LAST_NAME + “, “ + CUST_FIRST_NAME
Using this expression, the information is displayed as
Jones, Mary under the Name column.
and functions used in a derived
Calculations
expression can assist in deriving data from the
database, but you must make sure you use expressions
that meet the requirements of your database-specific
SQL syntax. If you use syntax that is not supported by
your database or other data source, the SQL query and
resulting report can fail.
To create an attribute form with a derived expression
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
in to MicroStrategy Tutorial.
2 Navigate to the Schema Objects folder, open the
Attributes folder, and then the Customers folder.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
151
6
The Context of Your Business Data: Attributes
Project Design Guide
3 Double-click the Customer attribute. The Attribute
Editor opens.
4 Click New. The Create New Attribute Form dialog box
opens.
5 From the Source table drop-down list, select the
LU_CUSTOMER table. This is the table that contains
customers’ first and last names.
6 Double-click the CUST_LAST_NAME column to add it to
the Form expression pane on the right.
7 In the Form expression pane, place the cursor to the right
of [CUST_LAST_NAME] and type + “, “ +.
8 Double-click the CUST_FIRST_NAME column to add it
to the Form expression pane on the right. Your expression
should be defined as shown below.
9 Select Automatic as the mapping method.
10 Click OK. The Create New Attribute Form dialog box
opens.
11 In the Form general information area, in the Name field,
type Last Name, First Name.
12 From the Category used drop-down list, select None
since Last Name, First Name is neither the ID form of
Customer nor the primary description form.
13 Click OK. The new attribute form is added to the Attribute
form pane in the Attribute Editor.
14 Because this is only an example, close the Attribute Editor
without saving your changes.
152 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
Joining dissimilar column names:
Heterogeneous mappings
Heterogeneous mapping allows Intelligence Server to
perform joins on dissimilar column names. If you define
more than one expression for a given form, heterogeneous
mapping automatically occurs when tables and column
names require it.
Because different source systems may store information in
various contexts, your company may have multiple columns
in different tables that all represent the same business
concept. For example, in the MicroStrategy Tutorial, the ID
form of the attribute Day contains two expressions. The
Day_Date column occurs in the LU_DATE table and the
Order_Date column occurs in the ORDER_DETAIL and
ORDER_FACT tables.
In the above example, you can use heterogeneous mapping to
map the Day attribute to all of the columns in the data
warehouse that represent the same concept of Day. You can
map Order_Date and Day_Date to the Day attribute—this
ensures that both columns are used when information about
the Day attribute is displayed on a report.
Each expression is linked to a set of source tables that contain
the columns used in the expression. Of all the tables in which
the columns exist, you can select as many or as few as you
want to be used as part of the attribute’s definition.
the Attribute Editor, you can view the chosen tables
Inin the
source Tables area to the right of the Form
Expressions area.
data types of columns used in a heterogeneous
The
mapping for a given attribute must be identical or
similar enough for your particular RDBMS to join
them properly. For example, most databases cannot
join a data type of Text to a data type of Number.
However, depending on your database platform, you
might be able to join columns with data types of
Number and Integer.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
153
6
The Context of Your Business Data: Attributes
Project Design Guide
To create an attribute form with a heterogeneous column
mapping
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
in to MicroStrategy Tutorial.
2 Navigate to the Schema Objects folder, open the
Attributes folder, and then the Time folder.
3 Double-click the Day attribute. The Attribute Editor
opens.
4 Click New. The Create New Form Expression dialog box
opens.
5 From the Source table drop-down list, select the
LU_DAY table.
6 Double-click the DAY_DATE column to add it to the
Form expression pane on the right. The mapping method
is selected as Automatic by default.
7 Click OK. The Create New Attribute Form dialog box
opens.
8 Click New. The Create New Form Expression dialog box
opens.
9 From the Source table drop-down list, select the
ORDER_DETAIL table.
10 Double-click the ORDER_DATE column to add it to the
Form expression pane on the right. The mapping method
is selected as Automatic by default.
11 Click OK. The Create New Attribute Form dialog box
opens.
Notice that there are now two expressions for the attribute
form definition, both of which use different tables as the
source of their information. You could continue this
process to add as many heterogeneous columns as part of
one attribute form as necessary.
154 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
12 In the Form general information area, in the Name field,
type Date Example.
13 From the Category used drop-down list, select None
since this is simply an example scenario.
14 Click OK. The new Date Example attribute form is added
to the Attribute form pane in the Attribute Editor.
15 Because this is only an example, close the Attribute Editor
without saving your changes.
Implicit expressions
While most attributes map directly to one or more physical
columns in the warehouse, an implicit attribute is a virtual or
constant attribute that does not physically exist in the
warehouse. Such an attribute has an implicit expression,
which is a constant value, although nothing is saved in an
actual column. Implicit expressions are not defined by
column names; they are defined by constants you specify.
Any constant is acceptable, for example, RushOrder=‘Yes’.
Some attribute definitions can be implied by the existence of
a row in a certain table, rather than being defined in terms of
columns. Implicit attributes are useful in analyzing and
retrieving relevant information.
For example, the Rush Order attribute in MicroStrategy
Tutorial is an example of an implicit attribute. Suppose you
want a report to display which orders are rush orders so you
can better keep track of your shipments. An implicit attribute
such as Rush Order is useful for this purpose.
The Rush Order attribute is defined by two expressions: the
Rush_Order column in the Order_Fact table and the implicit
expression “Y”, which stands for “Yes.” This implicit
expression is used to keep track of which orders are rush
orders. On a report with the Order and Rush Order attributes
on the template, for each order that is a rush order, a “Y” is
displayed in the Rush Order column.
attributes are not commonly used, but are
Implicit
useful in special cases such as the scenario described
above.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
155
6
The Context of Your Business Data: Attributes
Project Design Guide
Modifying attribute data types: Column aliases
A column alias is a new data type that you can specify in place
of the default data type for a given attribute form. Column
aliases allow you to specify a more appropriate data type that
can help avoid errors in your SQL. They can also help you
take more advantage of the data in your data warehouse. For
attributes, a column alias performs the same function as it
does for facts. By default, the data type for an attribute form
is inherited from the data type of the column on which the
form is defined. This inheritance is governed by
MicroStrategy, which attempts to use a data type as similar as
possible to the data type in your database or other data
source (see Appendix D, Data Types for more information
on how MicroStrategy selects a matching data type).
However, there are cases where you may need to change the
data type. The following are some examples of such cases.
In your data warehouse you have a lookup table for an
Accounts attribute where the ID is Account Number and the
ID is stored in the database as DECIMAL(18, 0). Because this
column stores high-precision values, you must modify the
column alias for the attribute form and map it to a special
data type, Big Decimal. By doing so, the precision can be
preserved when performing filtering, drilling, or page-by on
the Account attribute.
Another example could be a case in which your warehouse
does not have a lookup table for year information, but you
would like to create a Year attribute. Many database
platforms have functions that can extract parts of a date from
a Date data type. For example, SQL Server has a Year
function that extracts just the year from a date. In such a
case, you can create a Year attribute using the following form
expression:
ApplySimple("Year(#0)",[Date_Id])
ApplySimple expression above is syntactically
The
correct for SQL Server. However, depending on your
database or data source type, you may need to use a
different syntax.
156 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
The data type for this attribute is automatically set to a Date
data type. This is because Date_ID is a Date data type.
However, the result of the calculation is a year, such as 2002,
and it is an integer.
When a temporary SQL table is created, if you do not change
the data type of the column alias, the system uses a Date data
type and tries to insert integer data into this column. While
this does not create a problem in all database platforms, some
databases will return an error. To avoid the possibility of an
error due to conflicting data types, modify the column alias
for the attribute form and change the default Date data type
to an Integer data type.
In addition to specifying the data type to be used for an
attribute form, the column alias also lets you specify the
column alias name to be used in the SQL generated by
MicroStrategy. When you create a form expression using a
custom expression or multiple columns (as discussed in
Attribute form expressions, page 147), the column alias for
the attribute form defaults to CustCol (or CustCol_1,
CustCol_2, and so on). The following piece of SQL shows, in
bold, where the column alias name is used:
SELECT Year(a12.Date_Id) CustCol_1,
sum(a11.Tot_Dollar_Sales) WJXBFS1
FROM YR_CATEGORY_SLS a11
cross join TRANS_DATE_LW_LY a12
GROUP BY Year(a12.Date_Id)
While the column alias name does not affect the actual results
or your report, you can change the column alias name to be
more meaningful. The above example is a simple one, but this
can be useful for troubleshooting the SQL for a particularly
complex report.
You can use the Attribute Editor to create column aliases.
To create a column alias for an attribute
procedure assumes you have already created an
This
attribute with a valid attribute expression for which to
create a new column alias.
1 In MicroStrategy Desktop, log in to the project source that
contains the attribute to create a new column alias for.
© 2007 MicroStrategy, Inc.
Column data descriptions and identifiers: Attribute forms
157
6
The Context of Your Business Data: Attributes
Project Design Guide
2 Right-click the attribute and select Edit. The Attribute
Editor opens.
3 Select an attribute form and click Modify. The Modify
Attribute Form dialog box opens.
4 Select the Column Alias tab.
5 In the Column alias area, click Modify. The Column
Editor - Column Selection dialog box opens.
6 Select New to create a new column alias. The Column
Editor - Definition dialog box opens.
7 You can modify the following properties for the column
alias:
•
Column name: The name for the column alias which
is used in any SQL statements which include the fact
column.
•
Data type: The data type for the fact. For a description
of the different data types supported by MicroStrategy,
see Appendix D, Data Types.
•
Depending on the data type selected, you can specify
the byte length, bit length, precision, scale, or time
scale for your column alias. For a detailed description
on each of these properties, see the MicroStrategy
Desktop online help.
8 Click OK to save your changes and return to the Column
Editor - Column Selection dialog box.
9 Click OK to save your changes and return to the Attribute
Editor.
10 Select Save and Close to save your changes.
Attribute forms versus separate attributes
Attribute forms can be considered as additional descriptions
for an attribute, whereas attributes themselves can be
considered as report elements or group-by elements that
have a one-to-many or a many-to-many relationship with
158 Column data descriptions and identifiers: Attribute forms
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
other attributes. The data that you map to attributes can be
represented as separate attributes or as an attribute form of
an attribute.
In general, you should map data to an attribute form rather
than a separate attribute if:
•
There is a one-to-one relationship between an attribute
and the data.
•
You do not group by the data.
The decision to model data as an attribute form for a given
attribute or as a separate attribute is usually determined
during the logical data modeling phase of project design. For
more information on whether to model data as an attribute
form or as a separate attribute, see Attribute forms, page 36.
Attribute relationships
You link directly related attributes to each other by defining
parent-child relationships, as explained in Attribute
relationships, page 24. Attribute elements, or the actual data
values for an attribute, dictate the relationships that you
define between attributes.
The parent-child relationships you create determine the
system hierarchy within the project. In other words, these
relationships define how the engine generates SQL, how
tables and columns are joined and used, and which tables are
related to other tables.
The implications of whether attributes are related become
clear when you begin building reports. You can run a report
with two attributes that are related—Country and City, for
example—without any problems. A report with two unrelated
attributes, however, must include a metric based on a fact
that is on or below the level of the two attributes, or else a
Cartesian join occurs, which is generally undesirable. A
Cartesian join, or cross join, is very database intensive as
every row in one table is joined to every row in the other
table.
© 2007 MicroStrategy, Inc.
Attribute relationships
159
6
The Context of Your Business Data: Attributes
Project Design Guide
In MicroStrategy Desktop, you can define relationships for
the attributes in your project. This step is covered in
Simultaneously creating multiple attributes, page 129, as
part of the initial project design effort and in Viewing and
editing the parents and children of attributes, page 161, after
a project has already been created.
Attributes can be either related or unrelated to one another:
•
Related: A parent-child relationship is defined between
two or more attributes. The relationship is defined
through the attribute’s lookup table or a relationship
table.
Three types of direct relationships can exist between
related attributes, and these relationships are defined by
the attribute elements that exist in the related attributes.
One-to-one: Each element in the parent attribute has
one and only one corresponding element in the child
attribute. A common example of a one-to-one
relationship is citizen and Taxpayer ID. A citizen can
have only one Taxpayer ID and a Taxpayer ID can be
assigned to only one citizen.
One-to-many: Each element in the parent attribute
corresponds to one or more elements in the child
attribute. These are the most common types of
attribute relationships. Year has a one-to-many
relationship to quarter. One year has many quarters,
but a specific quarter can be in one year only. This
assumes that quarters are defined with an
accompanying year such as Q4 2006, Q1 2007, and so
on.
Many-to-many: Each element in the parent attribute
can have multiple children and each child element in
the child attribute can have multiple parents. In
banking, customers and accounts are an example of a
many-to-many relationship. One customer may have
many accounts, and each account may be associated
with many customers, such as in the case of a joint
checking account.
Attributes can also be related to other attributes through a
chain of attribute relationships. Attributes of this type are
often in the same hierarchy. For example, consider the
Geography hierarchy of the Customer Analysis Analytics
160 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
Module of the MicroStrategy BIDK, which contains the
attributes Customer Region, Customer State, and
Customer City:
In this scenario, Customer Region and Customer State are
directly related to each other and Customer State and
Customer City also have a direct relationship. While
Customer City is not directly related to Customer Region,
these two attributes are related through Customer State.
This allows you to include Customer Region and
Customer City on a report and view the different customer
cities for each customer region.
•
Unrelated: No parent-child relationship has been defined
and the attributes are not related through a chain of
attribute relationships. No relationship is present in the
lookup tables or relationship tables for these attributes.
Unrelated attributes can exist together in fact tables,
giving context to the fact. For example, the Customer and
Day attributes have no relationship to one another. A
particular customer and a particular day only make sense
together if a fact is associated with that combination. For
example, a certain customer, Don Addison, spent $2,500
on January 5, 2003 on behalf of the health care company
in which he works. In this case, care must be taken when
using unrelated attributes on a single report. In general,
however, these attributes are relatively straightforward to
deal with from a project design perspective.
Viewing and editing the parents and children of attributes
The relationships that exist between attributes rely on the
parent-child specifications that you assign to attributes. How
attributes relate to one another and the types of relationships
they share define the system hierarchy which is used to
generate SQL. This SQL, in turn, determines the output of a
report.
© 2007 MicroStrategy, Inc.
Attribute relationships
161
6
The Context of Your Business Data: Attributes
Project Design Guide
Parent-child relationships were designated when attributes
were selected for the new project. However, you can continue
to make changes to the relationships between attributes even
after creating your project.
For example, the Distribution Center attribute is the parent
of the Call Center attribute. A one-to-one relationship exists
between Distribution Center and Call Center. This means that
only one call center exists in each distribution center.
Country, in turn, is the parent of Distribution Center and
multiple distribution centers exist in each country. So these
two attributes have a one-to-many relationship.
Assigning parent-child relationships to attributes allows you
to connect attributes to one another in user hierarchies, as
discussed in Creating Hierarchies to Organize and Browse
Attributes, page 193. Also, when a report generates
inaccurate SQL and results, viewing and changing
parent-child relationships may be a necessary
troubleshooting method.
Follow the procedure below to view and edit the parents and
children of the Distribution Center attribute.
For a general procedure to view and edit the parents and
children of an attribute, refer to the MicroStrategy Desktop
online help.
To view and edit the parents and children of an attribute
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
in to MicroStrategy Tutorial.
2 Navigate to the Schema Objects folder, open the
Attributes folder, and then the Geography folder.
3 Double-click the Distribution Center attribute. The
Attribute Editor opens.
4 Click the Children tab. The Call Center attribute is listed,
along with the relationship type it shares with
Distribution Center, and the relationship table in which
the relationship exists.
162 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
Consider a scenario in which multiple call centers now
exist in the same distribution center so they no longer
have a one-to-one relationship; in this case, you must
change the relationship type between Call Center and
Distribution Center.
5 To change the relationship type, select One to Many from
the Relationship type drop-down list.
6 You also want the relationship between the two attributes
to be defined in the LU_Employee table instead of the
LU_Call_Ctr table in which it is defined now. To change
the relationship table, select the LU_Employee table
from the Relationship table drop-down list.
7 Because this is only an example, close the Distribution
Center attribute without saving your changes.
Supporting many-to-many and joint child relationships
Two forms of attribute relationships, many-to-many
relationships and joint child relationships, can introduce
additional complexity to the schema and warehouse design
process. The following sections discuss the considerations
you must make to ensure an effective warehouse design in
light of the unique nature of these relationships.
While the topics are largely related to logical model design, a
working knowledge of physical schemas is helpful when
dealing with the challenges involved with these topics.
Before reading this section, you should know what logical
data models and physical warehouse schemas are, and how to
read and interpret them. Logical data models and physical
warehouse schemas are discussed in Chapter 2, The Logical
Data Model and Chapter 3, Warehouse Structure for Your
Logical Data Model respectively. These chapters discuss how
to plan and create a conceptual framework for your business
intelligence data.
© 2007 MicroStrategy, Inc.
Attribute relationships
163
6
The Context of Your Business Data: Attributes
Project Design Guide
Many-to-many relationships
The presence of many-to-many relationships introduces
complexity during the warehouse design process. With the
presence of many-to-many relationships, you must make
additional considerations to effectively plan your design.
Below are some real-life examples of many-to-many
relationships which must be carefully handled in the data
model and schema:
•
In a certain organization, each salesperson can work in
more than one calling center. Likewise, each calling center
has many salespeople.
•
In a car manufacturing plant, many models of cars are
produced, and each comes in several colors. That is, there
are many colors for a single type of car, and many types of
cars can be associated with the same color.
The following sections use the example of items and colors to
demonstrate a many-to-many relationship and the options
you have for dealing with them. One item can come in many
colors—red hats, blue hats, green hats—and one color can be
associated with many items—red dress, red hat, red shoes,
red socks.
Potential problems with many-to-many relationships usually
come in the following forms, both of which can be avoided by
correctly modeling the relationship:
•
Loss of analytical capability
•
Multiple counting
Loss of analytical capability
With the color/item many-to-many relationship, there are
usually two business questions for which users want answers:
1 In what colors are certain items available?
2 How much of a particular item/color combination was
sold?
164 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
Answering the first question requires a table that contains a
list of all possible item/color combinations. Recall that
one-to-many relationships are usually in the child’s lookup
table.
In many-to-many relationships this is not feasible. Rather, a
distinct relationship table needs to be present in your
warehouse. The following diagram shows the lookup and
relationship tables for item and color:
The Rel_Color_Item table provides a row for every possible
item/color combination.
Answering the second question requires a fact table that has
sales information as well as color and item information. The
following diagram shows the same scenario as before, but in
addition it shows a simple fact table containing sales data
keyed by item, color, and date.
© 2007 MicroStrategy, Inc.
Attribute relationships
165
6
The Context of Your Business Data: Attributes
Project Design Guide
fact table in the above diagram alone is not
The
sufficient to answer the first question. Only item/color
combinations that were actually sold—and therefore
have sales recorded—can be retrieved from this table.
If you have item/color combinations that are available
but that have never been sold, this fact table cannot
provide a complete list of item/color combinations to
answer question one.
In summary, to prevent any loss of analytical flexibility when
dealing with a many-to-many attribute relationship, the
following requirements must be met:
•
A distinct relationship table to identify all the possible
combinations of attribute elements between attributes
•
Both the attribute ID columns in the fact table
can implement the above points in several
You
different ways, which are discussed in Working with
many-to-many relationships, page 168.
Multiple counting
When dealing with many-to-many relationships, loss of
analytical capability is only one challenge. Another equally
significant issue is multiple counting. Multiple counting
occurs when all of the following takes place:
166 Attribute relationships
•
You attempt to aggregate data to the level of one of the
attributes in the many-to-many relationship, or a higher
level than one of the attributes in the many-to-many
relationship.
•
The relationship exists in a distinct relationship table.
•
All of the attributes in the many-to-many relationship are
not in the fact table.
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
Recall the example from above, but make the following
change: remove color from the fact table.
Assume that there are three items—hats, dresses, and
socks—and that they come in three colors—red, blue, and
green—with the exception of socks, which come in only green
and blue. The following diagram shows this data in the
lookup tables as well as some simple sales data:
The risk of multiple counting occurs when you run a query
requesting the sales by color, effectively aggregating to the
item attribute level in the many-to-many relationship. This
query would require both the fact table—which has the sales
information by item—and the relationship table—since color
is not recorded in the fact table.
© 2007 MicroStrategy, Inc.
Attribute relationships
167
6
The Context of Your Business Data: Attributes
Project Design Guide
The difficulty lies in the fact that color is not in the fact table.
There is no way to directly relate the sales of an item in the
fact table to the color of that particular item. For example,
instead of calculating the sales of red items, the query
aggregates sales for all items that come in red according to
the relationship table. The sum includes all hats and all
dresses, including blue ones and green ones. This obviously
leads to numbers that are higher than the true sales for red
items.
For example, using the given data, the following questions
cannot all be answered accurately:
•
What are the total sales for hats?
The answer is $35, which can be calculated directly from
the fact table.
•
What are the total sales for red items?
You cannot determine an accurate answer. The answer
you get is $85, which is the total for all hats and dresses,
since socks do not come in red. It is entirely possible that
all the dresses sold are green; however, you cannot
confirm this since color is not recorded in the fact table.
•
What are the total sales for red dresses?
Again, you cannot determine an accurate answer. If all the
dresses sold are indeed green, the correct answer is $0,
but the answer you will get based on the data in the fact
table is $50.
The following section describes several ways to prevent
multiple counting when dealing with many-to-many
relationships.
Working with many-to-many relationships
As you can see, seemingly simple questions can require you to
take a number of steps to answer them when many-to-many
relationships are involved.
You can use one of three techniques to provide physical
support to answer the types of questions that cannot be
answered accurately when using many-to-many
relationships. The three techniques all have differing levels of
168 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
flexibility, and flexibility is always a trade-off with
complexity. In all cases, the two fundamental components
remain in place in one form or another:
•
A relationship table to define the attribute relationship
•
Both the attribute’s ID columns in the fact table
builds the rules that MicroStrategy SQL
MicroStrategy
Engine uses to generate SQL when a report request is
made. If you make both of the above physical
implementations, the SQL Engine uses the related
table when no metric is included on the report. When a
metric is included, the fact table is used to answer the
query.
of the following methods require additional data in
All
the fact table. This means that you must capture the
additional data in the source system. For example, you
need to have data in the source system as to what the
color is of each item sold. If this additional data was
never captured in the source system, you cannot fully
resolve the many-to-many relationship to calculate the
amount of sales for items of a certain color.
Method 1
This method is the most straightforward way to effectively
manage many-to-many relationships.
Method 1 requires you to create a separate relationship table
(in this case, Rel_Color_Item) and add both attribute IDs to
the fact table as shown in the following diagram.
© 2007 MicroStrategy, Inc.
Attribute relationships
169
6
The Context of Your Business Data: Attributes
Project Design Guide
Method 2
Method 2 eliminates the many-to-many relationship and the
need for a distinct relationship table.
Here the many-to-many relationship is converted into a
compound attribute relationship. You treat one attribute as a
child of the other and have a compound key for the lower
level attribute. Also, you add both attribute IDs, in this case
Item_ID and Color_ID, to the fact table as shown in the
following diagram.
While this method eliminates the need for a separate
relationship table, you lose the ability to view items
independent of color, or vice versa.
Method 3
Method 3 is the most versatile solution and has the following
characteristics:
•
Further simplifies the compound attribute relationship
from Method 2 into a simple attribute relationship
•
Provides the ability to view item and color together or
independently
•
Requires only one attribute column in the fact table for
complete flexibility, rather than two
Here you must create a new attribute, lower in level than
either Color or Item. This attribute is essentially a
concatenation of Color and Item, which gives it a
170 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
one-to-many relationship between itself and each of its
parent attributes. This is the SKU attribute, particularly
common in retail data models or situations.
Finally, rather than including Color and Item in the fact table,
you only need to include this new child attribute SKU, as
shown in the following diagram.
This method is actually quite similar to Method 1. The major
difference is that the distinct relationship table from Method
1 has an additional column, SKU, which extends the
relationship of each item/color combination into a single
value. Consequently, you can use this single value in the fact
table.
The major disadvantage of Method 3 lies in creating the new
attribute if your business model does not already use a
similar structure, as well as possibly adding complexity to the
ETL process.
Joint child relationships
Some attributes exist at the intersection of other indirectly
related attributes. Such attributes are called joint children.
Joint child relationships connect special attributes that are
sometimes called cross-dimensional attributes, text facts, or
qualities. They do not fit neatly into the modeling schemes
you have learned about thus far. These relationships can be
modeled and conceptualized like traditional attributes but,
like facts, they exist at the intersection of multiple attribute
levels.
© 2007 MicroStrategy, Inc.
Attribute relationships
171
6
The Context of Your Business Data: Attributes
Project Design Guide
source systems refer to these special attributes
Many
as flags. Therefore, if flags are referenced in your
source system documentation, these are likely
candidates for joint child relationships.
Joint child relationships are really another type of
many-to-many relationship where one attribute has a
many-to-many relationship to two otherwise unrelated
attributes. For example, consider the relationship between
three attributes: Promotion, Item, and Quarter. In this case,
Promotion has a many-to-many relationship to both Item
and Quarter, as shown in the following diagram.
An example of a promotion might be a “Red Sale” where all
red items are on sale. A business might run this promotion
around Valentine's Day and again at Christmas time.
Supporting joint child relationships
One way to resolve a many-to-many relationship is to have a
relationship table for the attributes involved in the
many-to-many relationships. In this case, you might create
172 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
two relationship tables, one to relate Promotion and Item.
The second relates Promotion and Quarter as shown in the
following diagram.
These two tables are sufficient to answer questions such as:
•
What items have been in what promotions?
•
What quarters have had what promotions?
However, these tables are not sufficient to answer the
following more detailed and insightful questions:
•
What items were in what promotions in a given quarter?
•
In what quarters was a certain item involved in a certain
type of promotion?
To answer these questions, you must combine the two
relationship tables, creating one table to relate all three
attributes.
relationship in the distinct relationship table must
The
exist for a joint child relationship to be properly
defined. However, it does not necessarily have to be in
its own, distinct relationship table. Defining the
relationship directly in the lookup table for the parent
of the joint child—in this case, Promotion—would be
fine. Alternatively, you can build the relationship
directly into the fact table.
© 2007 MicroStrategy, Inc.
Attribute relationships
173
6
The Context of Your Business Data: Attributes
Project Design Guide
In these examples, It is important to notice the relationship
between the three attributes. The Promotion attribute is
related to a particular Item-Quarter pair, as opposed to it
being related to Item and Quarter separately. This is the
essence of a joint child relationship and is shown in the
following diagram.
that a joint child relationship can be
Notice
one-to-many or many-to-many. The issues with
many-to-many relationships—loss of analytical
capability and multiple counting—also apply to
many-to-many joint child relationships.
If you have a joint child relationship in your data, it is
important for you to define it in MicroStrategy so that you get
the correct data for reports that use the parent attribute in a
joint child attribute. This ensures that when you need to join
the fact table to the parent attribute of a joint child
relationship—for example, to see sales by promotion—the
join will always use both joint children rather than just one or
the other.
174 Attribute relationships
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
Attributes that use the same lookup table:
Attribute roles
Attribute roles allow you to use the same data to define and
support two separate attributes. Suppose you define two
attributes that have the same data definition but play
different roles in your business model. For example, in the
following image, notice that the attributes Origin Airport and
Destination Airport are defined using the same lookup table,
LU_AIRPORT, and column, AIRPORT_ID.
Although it makes sense to see JFK as either an origin or
destination airport on a report, it is understood that
destination airport data differs from origin airport data. You
need to support the logical concepts of an origin airport and a
destination airport, but you do not want to create two
separate lookup tables with identical data. Creating two
separate lookup tables would create redundancy, and thus
take up more storage space and be harder to maintain.
When multiple attributes are defined using the same lookup
table and column, the attributes are essentially playing
different attribute roles. How an attribute plays multiple
roles depends on the specific attribute.
© 2007 MicroStrategy, Inc.
Attributes that use the same lookup table: Attribute roles
175
6
The Context of Your Business Data: Attributes
Project Design Guide
The Origin Airport and Destination Airport attributes share
the same attribute forms, or various aspects about them, such
as description, location, and so on. In the fact table, however,
a separate column exists for each of their roles; the fact
columns are ORIGIN_AIRPORT_ID and
DESTINATION_AIRPORT_ID, as shown below.
If a report designer places both the Origin Airport and
Destination Airport attributes on a report to obtain the
number of flights that originated from MIA and arrived at
LGA, an empty result set is returned. This occurs because the
SQL statement tries to obtain the description of an airport
that is both MIA and LGA at the same time (Airport_ID =
"MIA" AND Airport_ID = "LGA").
If you identify that one of your attributes needs to play
multiple roles, you must create an attribute in the logical
model for each of the roles, as explained in Specifying
attribute roles, page 177. This ensures that a report with
attributes playing multiple roles returns correct data.
In the following diagram, State is another example of an
attribute that can have two roles since it relates to both the
Vendor and Store attributes. In one case, it refers to the
176 Attributes that use the same lookup table: Attribute roles
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
location of a vendor. In the other, it refers to the location of a
store. The State attribute is therefore said to be playing two
roles.
In an OLTP system, roles are most often implemented as a
single table, as shown in the above diagram. In the data
warehouse, a query involving both Vendor State and Store
State needs to use the State table twice in the same query. For
example, a report is created to display vendors from Arkansas
who sold to New York stores. The results may be blank if the
data warehouse structure was set up incorrectly. The SQL
statement tries to obtain the description of a state that is both
Arkansas and New York simultaneously, generating the
empty result set.
Specifying attribute roles
To see both roles on the same report, you must treat them as
different attributes. That is, they must have different
attribute names. To create unique attributes, you have the
following options:
•
© 2007 MicroStrategy, Inc.
Automatic attribute role recognition, where you create
multiple attributes that have the same lookup table and
allow MicroStrategy to automatically detect the multiple
roles. Automatic recognition is enabled by the VLDB
Attributes that use the same lookup table: Attribute roles
177
6
The Context of Your Business Data: Attributes
Project Design Guide
property Engine Attribute Role Options at the database
instance level. For more information, refer to the
MicroStrategy System Administration Guide.
•
Explicit table aliasing, where you create multiple logical
tables pointing to the same physical table and define those
two logical tables as the lookup tables for the two
attributes.
a MicroStrategy project in which automatic
Inattribute
role recognition is enabled (meaning that
the database instance-level VLDB property, Engine
Attribute Role Options, is enabled), you can have a
maximum of 99 attributes defined on the same
column of the same lookup table. If you create
more than this number of attributes, you encounter
an error, and are unable to update the project
schema or restart Intelligence Server.
Table aliasing provides advanced users with more control. If
you are upgrading or have a very complex schema, it may be
the better alternative. If you are new to MicroStrategy,
however, it is easier to use automatic attribute role
recognition. MicroStrategy recommends that you take
advantage of automatic role recognition if you do not know
the details of the modeling logic or the database.
recognition does not work if the attributes
Automatic
are in the same hierarchy, meaning that a child
attribute is shared. For example, in the State example
provided above, the two State attributes do not have a
common child attribute.
In summary, if you identify that any one of your attributes
needs to play multiple roles, an attribute must be created in
the logical model for each of the roles. Remember this rule to
help you identify attribute roles: If you want to see the same
attribute multiple times on one report, as Ship Month and
Order Month, for example, the attribute has multiple roles. In
this example, Month is the attribute that has multiple roles.
You can use either automatic attribute role recognition or
explicit table aliasing to create the attribute roles.
178 Attributes that use the same lookup table: Attribute roles
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
Using automatic attribute role recognition
In the data warehouse, a query involving both Vendor State
and Store State needs to use the State table twice in the same
query to get correct results. You can set up two attributes,
Store State and Vendor State, both of which use the same
lookup table. The resulting SQL code contains a self-join with
the LU_State table. The logical model would look like the
following:
Note that both roles for the State attribute are included in the
logical model so that “State” can be considered from two
different perspectives. Since the state in which a vendor
resides and the state in which one of the stores is located are
two different things, the logical model must reflect that.
Automatic recognition allows these two attributes, Vendor
State and Store State, to access the same lookup table, using
different attribute names for the same expression.
role recognition works only when the
Automatic
attributes use exactly the same expression, which in
most cases simply represents a column or columns in a
lookup table.
Consider the following sample desired report:
Vendor_State_ID=15 (Arkansas)
Metrics
Vendor State Vendor
Store
Dollar
Sales
Store State
In this case, the request is, “Show me total sales by Store
State for all my vendors in Arkansas (Store State ID = 15).”
The same lookup table, LU_State, can be used for both
© 2007 MicroStrategy, Inc.
Attributes that use the same lookup table: Attribute roles
179
6
The Context of Your Business Data: Attributes
Project Design Guide
attributes, Store State and Vendor State, if attribute roles are
used. The two attributes refer to the same columns of that
table.
To use automatic attribute role recognition, you must select
the Engine Attribute Role Options, found in the database
instance-level VLDB Properties under Query Optimization.
See the MicroStrategy Desktop online help or the
MicroStrategy System Administration Guide for steps to set
this VLDB property.
Explicitly aliasing tables to specify attribute
roles
Explicit table aliasing provides more robust functionality
than automatic recognition, so advanced users are
encouraged to take advantage of this solution.
An attribute such as State can play more than one role in the
data warehouse; it can represent the Vendor State or the
Store State. In this case, the State attribute is said to play two
roles: it refers to both the location of a vendor as well as the
location of a store.
When you use explicit table aliasing to designate attributes
that have multiple roles, both roles for the State attribute are
included in the logical model so that State can be considered
from two different perspectives. The logical model would look
like the following, just as it would if you used automatic
recognition:
180 Attributes that use the same lookup table: Attribute roles
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
The difference between automatic recognition and explicit
table aliasing is that when you use explicit table aliasing, you
create separate lookup tables in the schema, but point them
each to the same physical table.
If you use explicit table aliasing for the Store attribute, one
table (LU_State_Store) contains the attribute Store State
while the other (LU_State_Vendor) contains Vendor State,
as shown in the following diagram.
Consider the following sample desired report that should
provide data about the total sales by Store State for all
vendors in Arkansas (Store State ID = 15):
Vendor_State_ID=15 (Arkansas)
Metrics
Vendor State Vendor
Store
Dollar
Sales
Store State
When explicit table aliasing is used, the two lookup tables
LU_State_Store and LU_State_Vendor are used. Since
they are just different names for the same physical table, the
report accesses the same physical table, LU_State, for both
state names, as shown by this sample SQL:
SELECT a12.State_Desc as State_Desc
SELECT a13.State_Desc as State_Desc
FROM LU_State a12
LU_State a13
© 2007 MicroStrategy, Inc.
Attributes that use the same lookup table: Attribute roles
181
6
The Context of Your Business Data: Attributes
Project Design Guide
You create table aliases in the Schema Objects/Tables
folder in MicroStrategy Desktop. When you create a table
alias, the selected table is copied, allowing you to rename a
copy of the same table. When you are ready to create new
attributes—as in the example discussed above—you can map
the appropriate table to each attribute. In the case above, you
would select the LU_State_Store table for the Store State
attribute and LU_State_Vendor for Vendor State.
aliases are one kind of logical table. For
Table
information about logical tables, refer to Appendix C,
Logical Tables.
To create attribute roles with explicit table aliasing
procedure provides steps to re-create the example
This
of explicit table aliasing described in this section. You
can use the same high-level procedure and concepts as
guidelines to create attribute roles in your project
setup.
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
into MicroStrategy Tutorial.
2 Navigate to the Schema Objects folder, and then select
the Tables folder.
3 Right-click the LU_State table and select Create Table
Alias. An LU_State(1) table is created.
4 Right-click LU_State(1), select Rename, and rename the
table as LU_State_Store.
5 Right-click the LU_State table and select Create Table
Alias. An LU_State(1) table is created.
6 Right-click LU_State(1), select Rename, and rename the
table as LU_State_Vendor.
Create the attributes
7 Select the Attributes folder.
182 Attributes that use the same lookup table: Attribute roles
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
8 From the File menu, select New, and then Attribute. The
Create New Form Expression dialog box opens.
9 From the Source table drop-down list, select
LU_State_Store.
10 In the Available columns pane, double-click STATE_ID.
11 Select Manual mapping and click OK. The Create New
Attribute Form dialog box opens.
12 In the Source tables pane, select the LU_State_Store
table.
NOT select the LU_State_Vendor table as a
Do
source table, otherwise the attributes cannot have
separate roles.
13 Click OK. The Attribute Editor opens.
14 Click New to map any other columns to attribute forms
for the State Store attribute. You must make sure to map
any State Store attribute forms to columns from the
LU_State_Store table.
15 Save the State Store attribute once you are finished
mapping attribute forms to columns of the
LU_State_Store table.
16 Create a Vendor State attribute with the same
sub-procedure (Create the attributes, page 182) used to
create State Store above, except you must use the
LU_State_Vendor table instead of the LU_State_Store
table.
Attributes with more than one ID column:
Compound attributes
A compound attribute is an attribute with more than one
column specified as the ID column. This implies that more
than one ID column is needed to uniquely identify the
elements of that attribute. Generally, you build a compound
© 2007 MicroStrategy, Inc.
Attributes with more than one ID column: Compound attributes
183
6
The Context of Your Business Data: Attributes
Project Design Guide
attribute when your logical data model reflects that a
compound key relationship is present. In the relational
database, a compound key is a primary key that consists of
more than one database column.
For example, a retail project has two attributes, Class and
Item. Class is the parent of Item and has a one-to-many
relationship with it. The values in the Item_ID column do
not uniquely identify an item. The item shirt has an Item_ID
of 1. However, there are different shirts, depending on the
class—men’s, women’s, and children’s. Therefore, to uniquely
identify a man’s shirt, Item_ID and Class_ID must be
grouped together, creating a compound attribute.
of the ID forms of the compound attribute should
All
be grouped together using form groups. They should
also use the same lookup table. For information about
form groups, see Collections of attribute forms: Form
groups, page 186.
Example: Creating compound attributes
Distribution Center is an example of a compound attribute in
the MicroStrategy Tutorial. It is an attribute that requires
that two different columns are specified as the ID column. To
uniquely identify a distribution center, one must know two
details about the distribution center: the ID of the
distribution center and the country in which it exists. This
data is represented by the Dist_Ctr_ID and Country_ID
columns respectively. The same Distribution Center
identification numbers can exist for different distribution
centers, but in the same country, each distribution center has
a unique identification number.
Therefore, both the Country_ID and Dist_Ctr_ID
columns must be mapped to the Distribution Center attribute
to ensure that data about distribution centers is displayed
correctly and completely on a report.
You can create a compound attribute, Distribution Center,
with two attribute forms, ID and Description. When defining
the ID form, select the source table columns for Country ID
and Distribution Center ID. This creates a unique identifier
for each distribution center, regardless of country.
184 Attributes with more than one ID column: Compound attributes
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
Follow the procedure below to create the Distribution Center
compound attribute. For a general procedure to create
compound attributes, refer to the MicroStrategy Desktop
online help.
To create the Distribution Center compound attribute
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
into MicroStrategy Tutorial.
2 Navigate to the My Personal Objects folder, and open
the My Objects folder.
3 From the File menu, select New, and then Attribute. The
Attribute Editor opens, with the Create New Form
Expression dialog box displayed on top of it.
4 From the Source table drop-down list, select the
LU_DIST_CTR table. This is the table in which the two ID
columns of Distribution Center reside.
5 Double-click the COUNTRY_ID column to add it to the
Form expression pane on the right.
6 Select Automatic mapping and click OK. The Create New
Attribute Form dialog box opens.
7 In the Form general information area, in the Name field,
type Country ID.
8 Keep all other defaults, and click OK.
9 In the Attribute Editor, click New to create the other
attribute ID form. This attribute form maps to the
distribution center ID column necessary to complete the
definition of the Distribution Center attribute.
10 Double-click the DIST_CTR_ID column to add it to the
Form expression pane on the right.
11 Select Automatic mapping and click OK. The Create New
Attribute Form dialog box opens.
© 2007 MicroStrategy, Inc.
Attributes with more than one ID column: Compound attributes
185
6
The Context of Your Business Data: Attributes
Project Design Guide
12 In the Form general information area, in the Name field,
type Distribution Center ID Number.
13 In the Form category section, select ID from the Category
drop-down list. Click OK.
must designate this attribute form as an ID
You
column so that it can be combined with the
Country_ID form to create one unique identifier
ID for the Distribution Center attribute.
Create a form group
14 A dialog box notifies you that another form (in this case,
COUNTRY_ID) is already using the ID form category and
that you must create a form group to combine the two ID
columns. Click Yes. The Create New Attribute Form
dialog box opens.
basic information and examples about form
For
groups, refer to Collections of attribute forms:
Form groups, page 186.
15 In the Name field, type Distribution Center and click OK.
The Attribute Editor opens, with the form group you
created in the Attribute forms pane.
16 Because this is only an example, close the Distribution
Center attribute without saving your changes.
Collections of attribute forms: Form groups
A form group is a grouping of attribute forms that are related
in a way that justifies combining the forms into a single form.
In general, you create form groups to create compound
attributes, which are attributes with more than one column
specified as the ID column. You must create a form group to
create a compound key, which identifies that an attribute
form requires more than one ID column to uniquely identify
its elements. This is necessary when creating compound
attributes.
You can also use form groups to link similar forms together
so that they are displayed together on a report.
186 Collections of attribute forms: Form groups
© 2007 MicroStrategy, Inc.
Project Design Guide
The Context of Your Business Data: Attributes
6
Supporting compound attributes
Compound attributes are required when an attribute requires
two or more columns to uniquely identify its elements. In the
Attribute Editor, a compound attribute is created by using a
form group to group together two forms to create the
attribute’s ID. In the MicroStrategy Tutorial, Distribution
Center is an example of a compound attribute. To uniquely
identify a distribution center, one needs information from
both the Country_ID and Dist_Ctr_ID tables. This is
because all countries identify distribution centers with
numbers starting at 1. For example, you have a distribution
center in London, England which has Dist_Ctr_ID=1, and
you also have a distribution center in Paris, France which has
a Dist_Ctr_ID=1 as well. To uniquely identify the two
distribution centers you must include the Country_ID as part
of the attribute ID. Therefore, the Distribution Center
attribute is identified using a form group that combines these
two forms.
When you create a form group, choose the same form
category for both forms—you are then prompted to name
your new form group. By grouping forms, you can design a
uniquely defined form that groups two or more forms under
an attribute. When you create a form group, the included
forms are joined together and act as one form.
For an example of creating a form group (form group creation
is a subtask of the complete procedure), see the procedure To
create the Distribution Center compound attribute,
page 185.
© 2007 MicroStrategy, Inc.
Collections of attribute forms: Form groups
187
6
The Context of Your Business Data: Attributes
Project Design Guide
Displaying and organizing related forms
Form groups are also used to conveniently organize common
attribute forms that can be paired on a report. For example,
the form group in the diagram below joins the forms
Last_Name and First_Name to create the form group
Name for the attribute Customer:
By grouping these two forms, the user can simply display the
Name form and the report then includes both the customers’
first and last names.
You can group two or more attribute forms together while
creating the attribute forms as described in To create the
Distribution Center compound attribute, page 185. You can
also group two or more attribute forms as a form group after
creating all of the attribute forms, as described in the
procedure below.
To group attribute forms as a form group
1 In MicroStrategy Desktop, log in to the project source that
contains the MicroStrategy Tutorial project and then log
into MicroStrategy Tutorial.
188 Collections of attribute forms: Form groups
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
2 Navigate to the Schema Objects folder, open the
Attributes folder, and then the Item folder.
3 Double-click the Item attribute. The Attribute Editor
opens.
4 Select New. The Create New Form Expression dialog box
opens.
5 Double-click the ITEM_NAME column to add it to the
Form expression pane on the right.
6 Select Automatic mapping and click OK. The Create New
Attribute Form dialog box opens.
7 In the Form general information area, in the Name field,
type Item Name2.
8 In the Form category area, in the Category used
drop-down list, select None.
9 Click OK. The Attribute Editor opens.
10 Select the Item Name 2 and Foreign Name attribute
forms, and then right-click the selected attribute forms
and select Group. The Create New Attribute Form dialog
box opens.
11 In the Name field, type Item and Foreign Name and click
OK. The Attribute Editor opens.
A form group which includes an item’s name and foreign
name is created for the Item attribute. Since this is only an
example of how to create a form group, do not save the
changes to the Item attribute.
Using attributes to browse and report on data
Once attributes are built, they are used in two primary
ways—browsing and reporting. Users browse through
attributes to locate an attribute to use on a report, and users
place an attribute on a report to display details about the
particular attribute and how it relates to fact data. Each
© 2007 MicroStrategy, Inc.
Using attributes to browse and report on data
189
6
The Context of Your Business Data: Attributes
Project Design Guide
attribute can be displayed in a variety of forms so you must
specify the default display of each of the attributes in the
project. You can do this on a report-by-report basis, but you
still must specify the global, or project-wide, default for each
attribute.
You must choose a default attribute display for browsing and
another for reporting. Report display forms are the attribute
forms that appear as columns in a completed report. Browse
forms are the attribute forms that appear as a user browses
through the element list of an attribute in the Data Explorer
in a project. Therefore, browse forms identify attribute
elements. This separation allows for greater attribute display
flexibility depending on the application.
creating attributes, all forms are included as
When
report display forms and browse forms by default. The
only exception is if you create multiple attribute forms,
the first form you create is not included as a report
display or browse form.
An attribute’s report display forms determine which attribute
forms are displayed by default when the report is executed.
By selecting different forms for the attribute, you select a
different set of values for display. For example, a report
includes Region as an attribute. If ID is selected as the
attribute form, the display could be a number such as four. If
Description is selected as the attribute form, the display could
be a name, such as Northwest. If a report lists the cities in
which you have stores, then you might choose to display the
Long Description form, such as Chicago, instead of the URL
attribute form, that is, www.chicago.com.
You can also select which attribute forms are retrieved with
the report results but not displayed on the grid. These browse
forms are found in the Report Objects pane. In Grid view, you
can add the attribute forms in Report Objects to the report
without re-executing the report. For example you can include
a cities URL attribute form as a browse attribute form so that
your users can choose to display the form on a report.
You can modify the attribute forms displayed by:
•
Right-clicking an attribute on a report or template and
selecting the desired attribute forms
190 Using attributes to browse and report on data
© 2007 MicroStrategy, Inc.
Project Design Guide
6
The Context of Your Business Data: Attributes
•
From the Data menu, selecting Attribute Display to open
the Attribute Display dialog box
For steps to display attribute forms on a report or template,
see the online help and the section below.
Setting how attribute forms are displayed by default
You can generally display attribute forms in a number of
ways. For example, the Distribution Center attribute in the
MicroStrategy Tutorial consists of an ID form group and a
Description form. The ID form group is made up of two
separate ID columns, Country_ID and Dist_Ctr_ID.
Displayed on a report, the Dist_Ctr_ID form shows the
identification numbers of specific distribution centers in the
data warehouse. The Description form of Distribution Center,
however, displays the actual name of the Distribution Center
such as “San Diego.”
You can use the Attribute Editor to determine how the
attribute forms are displayed on a report. In the case of the
Distribution Center attribute, you can specify whether the
identification number of each distribution center, the
distribution center names, or both are displayed. You can
also determine which attribute forms are displayed when
browsing a project with the Data Explorer.
Follow the example procedure below to set one of the
Distribution Center attribute’s forms to be displayed in
reports and while browsing the MicroStrategy Tutorial
project.
For a general procedure to set how attribute forms are
displayed by default, refer to the MicroStrategy Desktop
online help.
© 2007 MicroStrategy, Inc.
Using attributes to browse and report on data
191
6
The Context of Your Business Data: Attributes
Project Design Guide
To display an attribute form in reports and in the Data
Explorer
1 In the MicroStrategy Tutorial, navigate to the Schema
Objects folder, open the Attributes folder, and then the
Geography folder.
2 Double-click the Distribution Center attribute. The
Attribute Editor opens.
3 Click the Display tab.
On the right, in the Report display forms pane, the
description form of the Distribution Center is set as the
only display form. This means that, when the Distribution
Center attribute is used on a report, the actual names of
the distribution centers are displayed. The ID 2 form in
the Available forms pane represents the distribution
centers’ identification numbers.
4 You can set the ID 2 form to be displayed in the following
ways:
•
To set the ID 2 form as a form that is displayed on a
report by default: Select ID 2 from the Available forms
pane and click the top > button to add the form to the
Report display forms pane on the right.
•
To set the ID 2 form so it is displayed in the Data
Explorer when a user browses the Distribution Center
attribute: Select ID 2 from the Available forms pane
and click the bottom > button to add the form to the
Browse forms pane on the right.
The Data Explorer makes hierarchies available for
users to facilitate placing objects on reports. The Data
Explorer is discussed in Enabling hierarchy browsing
in reports: Data Explorer, page 209.
5 Because this is only an example, close the Attribute Editor
without saving your changes.
You can also determine how attributes are displayed while
users are editing and viewing reports. See the MicroStrategy
Basic Reporting Guide for details.
192 Using attributes to browse and report on data
© 2007 MicroStrategy, Inc.
7
7.
CREATING HIERARCHIES TO
ORGANIZE AND BROWSE
ATTRIBUTES
Introduction
Hierarchies are groupings of attributes that can be displayed,
either ordered or unordered, to reflect the relationships that
exist between the attributes in a project.
In Chapter 2, The Logical Data Model, you learned how to
use hierarchies to group related attributes in practical
business areas. For example, you can include a Time
hierarchy in your model that consists of Day, Week, Month,
and Year attributes.
This chapter discusses hierarchies as they exist in the
MicroStrategy environment and provides information on the
two different types of hierarchies in MicroStrategy. These
types of hierarchies include the system hierarchy and the user
hierarchy. The system hierarchy is automatically created
when you create a project and is maintained by the
© 2007 MicroStrategy, Inc.
193
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
relationships that exist among the project’s schema objects.
The user hierarchy is a hierarchy which you create specifically
for your report designers.
This chapter explores how to create and configure user
hierarchies in MicroStrategy and provides additional
information about hierarchy functionality in MicroStrategy
Desktop.
Creating user hierarchies
In MicroStrategy Desktop, you create user hierarchies using
the Hierarchy Editor. For information on user hierarchies
and system hierarchies, see Types of hierarchies, page 196.
Follow the procedure below to learn how to create a user
hierarchy.
194 Creating user hierarchies
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating Hierarchies to Organize and Browse Attributes
7
To create a new user hierarchy
1 In MicroStrategy Desktop, log into the project source that
contains your project and open the project.
2 In the Folder List, navigate to and open the Schema
Objects folder.
3 Open the Hierarchies folder, and then the Data Explorer
folder.
4 From the File menu, select New, and then Hierarchy. The
Hierarchy Editor opens, followed immediately by the
Select Objects dialog box.
5 In the Select Attributes dialog box, in the Available objects
window, select the attributes to use in the hierarchy and
click the arrow to add them to the Selected objects
window. Click OK to close the Select Attributes dialog
box. The attributes you selected appear in the Hierarchy
Viewer.
arrows that connect certain attributes denote the
The
presence of a relationship between the connected
attributes. If arrows do not appear between attributes
you know are related, you must edit the attribute(s) in
the Attribute Editor, assign the appropriate parent or
child relationship to the attributes, and update the
schema. This procedure is covered in Viewing and
editing the parents and children of attributes,
page 161. Once you save and re-open the hierarchy,
arrows appear between related attributes.
6 In the Hierarchy Editor, you can view the details of each
attribute in the hierarchy. To do so, from the View menu,
select Show Details. These details include whether or not
the attribute is locked, an entry point, or filtered.
7 Click Save and Close. Type a name for the hierarchy. If
the Use as a drill hierarchy check box at the bottom of
the Hierarchy Editor is selected, a dialog box opens
notifying you that the hierarchy you are about to save is
drillable in reports. Drill hierarchies are discussed in
Drilling using hierarchies, page 209.
© 2007 MicroStrategy, Inc.
Creating user hierarchies
195
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
8 In the Save As dialog box, navigate to the location in
which you want to save the hierarchy.
You can save user hierarchies in any folder. However, to
make the user hierarchy available for element browsing in
the Data Explorer, you must place it in the Data Explorer
sub-folder within the Hierarchies folder.
9 Update the project schema by selecting Update Schema
from the Schema menu.
Types of hierarchies
The two types of hierarchies that exist in MicroStrategy
include:
196 Types of hierarchies
•
System hierarchy: The system hierarchy is created
according to the relationships defined between the
attributes in your project. You do not need to create the
system hierarchy; it is automatically created in Desktop
when you create a project. Although the system hierarchy
specifies an ordered set of all attributes in the project, it
does not define ordering or grouping among attributes.
The ordering and grouping of attributes, among other
configurations, is defined in user hierarchies.
•
User hierarchy: User hierarchies are named sets of
attributes and their relationships to each other, arranged
in specific ways that make sense to a business
organization. They are user-defined and do not need to
follow the logical data model. As the structure of your
business intelligence evolves, you can easily change the
design of a user hierarchy to include additional attributes
or limit user access to certain attributes. This type of
hierarchy is created to provide flexibility in element
browsing and report drilling. Steps to create user
hierarchies are discussed in Creating user hierarchies,
page 194.
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating Hierarchies to Organize and Browse Attributes
7
System hierarchy: Project schema definition
The system hierarchy is the default hierarchy that
MicroStrategy sets up for you each time you create a project.
It contains all of the attributes in the project and is actually
part of the schema definition. When you first create a project,
the only hierarchy it contains is the system hierarchy.
The system hierarchy holds information on the relationships
between attributes in the project. The system hierarchy
cannot be edited but is updated every time you add or remove
attribute children or parents in the Attribute Editor, or when
you define attribute children in the Project Creation
Assistant.
The system hierarchy is useful in determining relationships
between all objects in the project. Attributes from the system
hierarchy do not need to be part of an explicitly-defined user
hierarchy. Any attributes that are not assigned to a user
hierarchy remain available to the system as report objects,
filter conditions, and components of consolidations. These
report objects are discussed in detail in the MicroStrategy
Advanced Reporting Guide.
You can view the system hierarchy in the Data Explorer or in
the Hierarchy Viewer, but not the Hierarchy Editor. You can
access the Hierarchy Viewer from Graphical View in the
Schema menu. The Hierarchy Viewer is discussed in detail in
Using the Hierarchy Viewer, page 211.
User hierarchies: Logical business relationships
User hierarchies are sets of attributes and their relationships,
arranged in specific sequences for a logical business
organization. You create user hierarchies to define the browse
and drill relationships between attributes. For example, you
can create a Time hierarchy that contains the Year, Quarter,
Month, and Day attributes. When you browse the attributes
in the Data Explorer, you can double-click Year to get to
Quarter and double-click Quarter to get to Month, and so on.
© 2007 MicroStrategy, Inc.
Types of hierarchies
197
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
Whereas browsing occurs through the Data Explorer, in
drilling the user actually chooses to move to higher or lower
levels on a report or move across to levels within different
hierarchies. For example, if the user drills on the Quarter
attribute in a report, he or she can drill down to Month, up to
Year, or across to an attribute within another hierarchy.
You can create user hierarchies in the Hierarchy Editor using
one or more attributes from the system hierarchy.
A user hierarchy is the only type of hierarchy you can define,
and you can create any number of user hierarchies for each
project. You should define user hierarchies that correspond
to specific areas of your company business model and data
warehouse schema.
Hierarchy organization
The best design for a user hierarchy is to organize or group
attributes into logical business areas. This allows users to
more easily locate attributes in a project and navigate from
one attribute to another. For example, you can place related
attributes into hierarchies by their level.
The example below demonstrates the Location and Customer
hierarchies. Within the Location hierarchy, State, City, and
Store are organized according to their relationships to each
other. The Customer hierarchy also groups together the
attributes Company, Contact, and Customer.
198 Hierarchy organization
© 2007 MicroStrategy, Inc.
Project Design Guide
7
Creating Hierarchies to Organize and Browse Attributes
When creating user hierarchies, keep in mind that
hierarchies do not have to be separate from one another or
necessarily follow the dimensional structure of your logical
data model.
Hierarchy structure
While both a system hierarchy and user hierarchy allow you
to navigate attributes in your project, only the user hierarchy
allows you to logically define and order groups of attributes.
The rest of this chapter discusses user hierarchies and how to
create and configure them in your project.
When you group attributes together into user hierarchies,
you are developing a working design of the display and
browse functions of the attributes. In the example below,
there are two instances of the Region hierarchy. One
hierarchy demonstrates Region having multiple States and
the States having multiple Stores.
This hierarchy allows you to create drilling and browsing
options to the lower levels to view Region, State, and Store on
a report. However, if you only include Store in the Region
hierarchy, as in the second example, then the only options for
drilling or browsing are the Region and Store levels.
© 2007 MicroStrategy, Inc.
Hierarchy organization
199
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
Viewing hierarchies: Hierarchy Viewer
The Hierarchy Viewer graphically represents user hierarchies
and the system hierarchy. In the system hierarchy, the
connections between the attributes represent the
parent-child relationships. In user hierarchies, the
connections show the browse paths between the attributes.
The Aerial perspective provides an overview of hierarchies;
its decreased scale allows you to navigate through the entire
project.
The Hierarchy Viewer is accessed from the Graphical View
option in the Schema menu. The Hierarchy Viewer is
discussed in further detail in Using the Hierarchy Viewer,
page 211.
Configuring hierarchy display options
Each attribute in a user hierarchy has properties that affect
how that attribute is displayed and accessed in a hierarchy.
You can use the Hierarchy Editor to configure each of these
properties, as shown in the following procedures:
•
Element Display: Determines the elements a user can see.
The element display may be locked, unlocked, or limited
(see Controlling the display of attribute elements,
page 201).
•
Attribute Filters: Specifies whether the data retrieved and
displayed should be complete or filtered by any specific
criteria. A filter on a hierarchy acts like a filter in a report.
Only data satisfying the filter criteria is displayed (see
Filtering attributes in a hierarchy, page 203).
•
Entry Point/Not an Entry Point: Specifies whether the
user can begin browsing in this hierarchy using this
attribute (see Entry point, page 205).
•
Browse Attributes: Shows the attributes to which users
can browse from a given attribute. Represented by lines
that connect one attribute to others (see Hierarchy
browsing, page 206).
200 Configuring hierarchy display options
© 2007 MicroStrategy, Inc.
Project Design Guide
7
Creating Hierarchies to Organize and Browse Attributes
The following sections explain these properties and how to
use the Hierarchy Editor to configure each.
Controlling the display of attribute elements
Locked/Unlocked attribute elements
Locking a hierarchy prevents a user from viewing all
elements of the specific attribute and any lower level
attributes in the hierarchy. A hierarchy is referred to as
locked when at least one attribute within that hierarchy has
the Element Display option set to Locked. Anything higher in
the hierarchy is still visible.
You can lock the hierarchy to restrict the user from viewing
elements and lower level attributes for security reasons or to
better manage lengthy hierarchies. By restricting the view of
attribute elements and lower level attributes in the Data
Explorer, you can prevent the expansion of long attribute
element lists that can consume system resources. When you
set the element display to locked, a padlock icon appears next
to the attribute name.
For example, the attribute Order is locked in the Data
Explorer sample shown below.
While the user can view the attribute elements of Customer
Region and Customer City, he or she cannot view information
about each customer’s order. The Order attribute may be
locked in order to prevent unauthorized users from accessing
sensitive information about customer orders.
© 2007 MicroStrategy, Inc.
Configuring hierarchy display options
201
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
To lock or unlock an attribute in a hierarchy
1 Double-click the hierarchy to edit. The Hierarchy Editor
opens.
2 Right-click the attribute to lock or unlock.
3 To lock an attribute, from the right-click menu, select
Element display, and then Locked. A padlock icon
appears next to the locked attribute, and users can no
longer view elements of this attribute.
4 To unlock a locked attribute, from the right-click menu,
select Element display, and then Unlocked. The padlock
icon is removed from the attribute, and users can now
view the elements of this attribute.
5 In the Hierarchy Editor, click Save and Close.
6 Update the project schema by selecting Update Schema
from the Schema menu.
can also lock and unlock attributes when you edit
You
them in the Display tab of the Attribute Editor.
However, this locks and unlocks the attributes within
the system hierarchy, not any user hierarchies that
contain the attributes. For example, if the attribute
Year is locked in the Attribute Editor, no elements for
Year display in the Data Explorer when Year is
expanded.
Limited attribute elements
Another way to restrict users from viewing attribute elements
in the Data Explorer is to limit the number of elements that
appear at one time. This method is useful when there are
extensive attribute elements in a hierarchy. Instead of
loading all attribute elements at once, you can set the limit to
five or ten at a time. Also, retrieving a large number of
elements at once can negatively impact system performance.
The user can then click the arrows to see the next set of
elements for that attribute.
202 Configuring hierarchy display options
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating Hierarchies to Organize and Browse Attributes
7
For example, the Chocolate subcategory, shown below,
contains many items. Rather than displaying all of them at
once and overwhelming the user, a limit of five items has
been set. The following graphic displays this view in the Data
Explorer.
To limit the display of attributes in a hierarchy
1 In the Hierarchy Editor, right-click the attribute to limit.
2 From the right-click menu, select Element display, and
then Limit.
3 In the Limit dialog box, type the number of elements you
want to see at one time and click OK.
4 In the Hierarchy Editor, click Save and Close.
5 Update the project schema by selecting Update Schema
from the Schema menu.
Filtering attributes in a hierarchy
Before reading this section, refer to the Filters chapter in the
MicroStrategy Advanced Reporting Guide to understand
what filters are and how to create them in MicroStrategy.
You can add filters to a hierarchy to control how data is
retrieved and displayed. With a filter you can choose exactly
which attribute elements to display in a hierarchy. For
example, you can filter a hierarchy so that data for only one
© 2007 MicroStrategy, Inc.
Configuring hierarchy display options
203
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
quarter is displayed, or data for only a few days of one
quarter. Filters make data retrieval faster by only allowing
specific data to be displayed.
cannot use a prompt-based filter to filter a
You
hierarchy.
Each attribute in the hierarchy can have multiple filters
applied to it. When filtering attributes in a hierarchy, you are
limiting the elements of the data returned when you browse
the Data Explorer. Creating a limited hierarchy reduces the
number of elements displayed at one time. Filters, however,
limit the elements a user is allowed to see and therefore,
perform a type of security.
Filters increase efficiency when retrieving data because you
can limit user access to parts of a hierarchy when you apply
filters to attributes. The filters allow the Data Explorer to
display only the criteria you select, and the user is unable to
see additional data in the hierarchy.
For example, you want to view only those customers who are
younger than 30 years old. First, create a filter on Customer
Age less than 30. In the Hierarchy Editor, add the filter to the
Customer attribute. Update the project schema, and view the
Customer hierarchy in the Data Explorer. Only those
customers younger than 30 years old are displayed.
adding filters to an attribute in a hierarchy, you
When
need to make sure that each filter is relevant to the
attribute’s information. MicroStrategy does not
validate that the associated filter makes sense on that
attribute.
To apply a filter to an attribute in a hierarchy
1 Create a filter in MicroStrategy Desktop. See the
MicroStrategy Desktop online help for more details.
2 In the Hierarchy Editor, right-click the attribute to filter
and select Define Attribute Filters.
3 If a tip about filtering opens, click OK.
204 Configuring hierarchy display options
© 2007 MicroStrategy, Inc.
Project Design Guide
7
Creating Hierarchies to Organize and Browse Attributes
4 In the Select Filters dialog box, in the Available objects
list, select the filters to apply and click > to add them to
the Selected objects list.
5 Click OK to close the Select Filters dialog box.
6 In the Hierarchy Editor, click Save and Close. The
attribute to which you applied the filter appears in the
hierarchy with a filter icon.
Entry point
An entry point is a shortcut to an attribute in the Data
Explorer. Creating an entry point grants users faster access to
the attribute without having to browse through multiple
attributes to reach different levels in a hierarchy. This is
especially useful when accessing frequently-used attributes.
When you create a user hierarchy, the hierarchy, the
attributes, and their elements appear in the Data Explorer.
When you set an attribute to be an entry point, you are
creating a shorter route to access that attribute. For example,
a typical hierarchy is Time. When you click on Time,
elements for each Year, such as 2007, 2006, and 2005, open.
When you click on 2006, an element for each Quarter, such
as Q1, Q2, Q3, and Q4, opens. If you are seeking Week 24, you
need to open several levels of attributes to reach the correct
data level, which is Week. If you set the attribute Week as an
entry point, the attribute Week appears in the Data Explorer
at the same level as Year. If an attribute is not set to be an
entry point, it appears in its normal position within the
hierarchy structure.
If you set a locked attribute as an entry point, it still appears
in the hierarchy but with a padlock icon. You can see the
locked attribute, but are unable to access elements or
attributes below that level.
To create entry points in a hierarchy
1 In the Hierarchy Editor, right-click the attribute to set as
an entry point.
© 2007 MicroStrategy, Inc.
Configuring hierarchy display options
205
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
2 From the right-click menu, select Set as entry point.
of the attributes in the Hierarchy Viewer may
Some
already be set as entry points; attributes set as
entry points are denoted by a green check. To
remove an entry point from an attribute, select
Remove Entry Point from the right-click menu.
3 In the Hierarchy Editor, click Save and Close.
4 Update the project schema by selecting Update Schema
from the Schema menu.
Hierarchy browsing
Once you choose which attributes to place in a hierarchy, you
can define the relationships between them. These
relationships determine how users can browse the attributes
from the Hierarchies folder.
For example, if Catalog, Category, Subcategory, and Item are
the attributes that comprise the user hierarchy Catalog Items,
the hierarchy resembles the example below, showing the
parent/child relationships between the attributes. For
example, in the hierarchy below, Category is a parent
attribute of Category and Category is the child attribute of
Category.
206 Configuring hierarchy display options
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating Hierarchies to Organize and Browse Attributes
7
user hierarchy does not need to have these direct
Arelationships
defined. It can simply be a collection of
attributes.
Attributes in a hierarchy can have both browsing and drilling
relationships between them. Browse attributes are attributes
you specify a user can directly browse to from a given
attribute in the user hierarchy. When you apply browse
attributes to attributes in a hierarchy, you are specifying what
levels of detail are visible when browsing the Data Explorer.
Including hierarchies in the Data Explorer makes the
hierarchies available for reports and to users in the project.
For more information on including hierarchies in the Data
Explorer, see Enabling hierarchy browsing in reports: Data
Explorer, page 209.
For each attribute in a hierarchy, you can assign one or more
browse attributes to it. Using the example above, some of
these attributes have been assigned a browse attribute.
Specifically:
Hierarchy Attribute
Browse Attribute(s)
Catalog
Category, Subcategory
Category
Subcategory
Subcategory
Catalog, Item
Item
The addition of these browse attributes allows users to see
the Subcategory elements directly from the Catalog attribute,
without having to first browse down through the Category
© 2007 MicroStrategy, Inc.
Configuring hierarchy display options
207
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
attributes to get to Subcategory. The ability to browse more
directly through the hierarchy can be represented as shown
below.
In the Data Explorer, the hierarchy described above
resembles the example below.
Users can now view the subcategories in the catalog without
first having to browse through the categories.
208 Configuring hierarchy display options
© 2007 MicroStrategy, Inc.
Project Design Guide
7
Creating Hierarchies to Organize and Browse Attributes
Enabling hierarchy browsing in reports: Data
Explorer
You can make hierarchies available for browsing and
including in reports by storing the hierarchies in the Data
Explorer. Moving hierarchies to and from this folder also
allows you to keep some hierarchies visible to users while
hiding others. The Data Explorer is a tool in the Object
Browser that holds the system hierarchy and the user
hierarchies. When you create a new project, the system
hierarchy for that project is automatically placed in the Data
Explorer.
You can save user hierarchies in any folder. However, to
make a user hierarchy available for browsing in the Data
Explorer you must place it in the Data Explorer folder—a
subfolder of the Hierarchies folder, which is located in the
Schema Objects folder.
Drilling using hierarchies
Drilling is a function in MicroStrategy reports that allows
users to browse different levels of attributes along specified
paths. Depending on the level of the attributes included in the
drilling specification, reports can allow users to drill down,
up, and across to different levels of detail.
When a user selects a drilling path in a report, the report
refreshes to display the selected level of detail. For example,
on a report with the Year attribute and Revenue metric, the
user can drill down on the Year attribute to a lower level
attribute such as the Month attribute. A new report is
automatically executed; on the new report, Revenue data is
reported at the Month level.
You can make user hierarchies available for drilling. This
option enables you to determine, at a project level, the
attributes to which users can drill from other attributes. In
the example of the Year and Month attributes, drilling is
enabled in the Time hierarchy, which contains the two
attributes. This allows a user to drill down from Year to
Month and, if they need to, drill back up from Month to Year.
© 2007 MicroStrategy, Inc.
Configuring hierarchy display options
209
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
To enable a user hierarchy as a drill path, you must enable the
user hierarchy to be used as a drill hierarchy in the Hierarchy
Editor. If a user hierarchy is not enabled, the default drill
path is defined by the System Hierarchy.
Therefore, you can think of browsing paths in a user
hierarchy as potential drilling paths. For example, in the
following hierarchy, Subcategory is a browse attribute of
Catalog, which means that you can access the elements of
Subcategory without having to necessarily access the
elements of Catalog in Data Explorer. If you enable drilling in
this hierarchy, you can drill from Catalog down to
Subcategory—and any other browse attributes of Catalog—on
a report.
See Hierarchy browsing, page 206 for more details about
browsing attributes.
To enable drilling in a user hierarchy
1 Open the hierarchy in which to enable drilling.
2 At the bottom of the Hierarchy Editor, select the Use as a
drill hierarchy check box.
3 In the Hierarchy Editor, click Save and Close.
4 Update the project schema by selecting Update Schema
from the Schema menu.
210 Configuring hierarchy display options
© 2007 MicroStrategy, Inc.
Project Design Guide
7
Creating Hierarchies to Organize and Browse Attributes
After a user hierarchy is enabled for drilling, the hierarchy
contributes to the drilling path of any attributes in it. For
instance, assume Week is a browsing attribute assigned to
Year. When a user right-clicks on Year and selects Drill
Down, the attribute Week appears in the drill-down list.
Additional information on drilling is available in the
MicroStrategy Advanced Reporting Guide.
Using the Hierarchy Viewer and Table Viewer
Through the Hierarchy Viewer, MicroStrategy Architect gives
you the ability to view the system hierarchy as well as all of
your user hierarchies in a single place. The Table Viewer is
another tool within MicroStrategy Architect that provides you
with a bird’s eye view of some of the information within your
project. It is used to view all of the tables in your project
graphically.
Using the Hierarchy Viewer
The Hierarchy Viewer allows you to select the hierarchy you
want to examine, and also allows you direct access to the
attributes that comprise it. You can use the Hierarchy Viewer
to view either the system hierarchy or any of your user
hierarchies.
•
When you view the system hierarchy, you can see the
actual relationships between attributes, as defined by the
system when the project was created.
•
When you view a user hierarchy, you do not see true
attribute relationships, but rather the structure of the user
hierarchy as defined by a project designer, to facilitate
user browsing and report development.
The Hierarchy Viewer gives you flexibility over how much of a
given hierarchy you choose to view at once. You can see all of
the entry points into a hierarchy at once, or you may select
only one at a time. For details on entry points, see Entry
point, page 205.
© 2007 MicroStrategy, Inc.
Using the Hierarchy Viewer and Table Viewer
211
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
The Hierarchy Viewer also gives you direct access to any of
the attributes in the hierarchy you choose to view. When you
access a hierarchy’s attributes directly, you can define them
as entry points. See Entry point, page 205 for more details on
creating entry points.
To view the system hierarchy in the Hierarchy Viewer
1 In MicroStrategy Desktop, from the Schema menu, select
Graphical View.
2 Select Hierarchies.
To view a user hierarchy in the Hierarchy Viewer
1 In the Hierarchy Viewer, from the Hierarchy menu, select
the hierarchy to view.
2 Attributes that have a green check mark next to them are
entry points. See Entry point, page 205 for more details
on creating entry points.
To edit an attribute from the Hierarchy Viewer
1 In the Hierarchy Viewer, right-click the attribute to edit.
2 Select Edit.
In the Hierarchy Viewer, the Aerial perspective provides an
overview of the hierarchies in your project. Its decreased
scale allows you to navigate through the entire project.
To access Aerial perspective mode in the Hierarchy Viewer
1 In the Hierarchy Viewer, from the View menu, select
Aerial perspective. An aerial view of the hierarchy you
are currently viewing is displayed. The green squares
indicate attributes that are entry points.
212 Using the Hierarchy Viewer and Table Viewer
© 2007 MicroStrategy, Inc.
Project Design Guide
7
Creating Hierarchies to Organize and Browse Attributes
2 The hierarchy in the Hierarchy Viewer shifts according to
where you navigate in the aerial view. Click a section of
the aerial view display to shift your view of a hierarchy to
that particular section.
Using the Table Viewer
The Table Viewer allows you to view all of the tables in your
project as well as the joins and/or relationships between
those tables and the names of the individual columns in each
table.
The tables that are displayed here are logical tables. They
represent and indicate how Architect sees the tables that were
brought into the project when it was created.
you make changes to the actual tables in the data
Ifwarehouse,
you will need to update the logical table
structure. See The size of tables in a project: Logical
table size, page 249 for information on updating
logical table structures.
To view your project’s tables in the Table Viewer
1 In MicroStrategy Desktop, from the Schema menu, select
Graphical View.
2 Select Tables.
To view more or less information about each table in the
project
1 Open the Table Viewer, as described above.
2 In the Table Viewer, select Options.
© 2007 MicroStrategy, Inc.
Using the Hierarchy Viewer and Table Viewer
213
7
Creating Hierarchies to Organize and Browse Attributes
Project Design Guide
3 From the Options menu, select or clear the options for any
of the following, depending on what you want to see in the
Table Viewer:
•
Show joins
•
Use circular joins
•
Show relationships
•
Show relationship types
•
Show columns
214 Using the Hierarchy Viewer and Table Viewer
© 2007 MicroStrategy, Inc.
8
8.
OPTIMIZING AND MAINTAINING
YOUR PROJECT
Introduction
Once your MicroStrategy project is set up and populated with
schema objects, you are ready to start thinking about ways to
better maintain the project and optimize it for both the short
and long term.
This chapter introduces you to maintenance and optimization
concepts such as tuning the interaction between your data
warehouse and your project, creating aggregate tables, and
using partition mapping, and explains how to use these
methods to enhance your project. You can find this
information in the sections listed below:
•
© 2007 MicroStrategy, Inc.
Updating your MicroStrategy project schema,
page 216—As you continue to enhance the design and
functionality of your project, you will need to make
various schema changes. To see any enhancements and
changes to your project schema, you must update your
project schema.
215
8
Optimizing and Maintaining Your Project
Project Design Guide
•
Data warehouse and project interaction: Warehouse
Catalog, page 218—As your data warehouse changes to
meet new data logging requirements, your project must
reflect these changes. This can include adding new tables
to your project or removing tables that are no longer used.
You can also tune the interaction between your data
warehouse and your MicroStrategy project to bring your
data into MicroStrategy in a way that meets your
requirements.
•
Using summary tables to store data: Aggregate tables,
page 241—Aggregate tables store data at higher levels
than the data was originally collected in the data
warehouse. These summary tables provide quicker access
to frequently-used data, reduce input/output and other
resource requirements, and minimize the amount of data
that must be aggregated and sorted at run time.
•
Dividing tables to increase performance: Partition
mapping, page 250—Partition mapping involves the
division of large logical tables into smaller physical tables.
Partitions improve query performance by minimizing the
number of tables and records within a table that must be
read to satisfy queries issued against the warehouse.
Updating your MicroStrategy project schema
All of the schema objects—facts, attributes, hierarchies,
transformations, and so on—in your project come together to
form your project’s schema.
Although the concepts are related, the project schema is not
the same as the physical warehouse schema. Rather, the
project schema refers to an internal map that MicroStrategy
uses to keep track of attribute relationships, fact levels, table
sizes, and so on within the project.
Whenever you make any changes to a schema object you
must indicate to MicroStrategy that new schema object
definitions have been included and that these definitions
need to be loaded into memory.
You can do any of the following to update your project
schema:
216 Updating your MicroStrategy project schema
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
•
Stop and restart MicroStrategy Intelligence Server, if in
server-connected (3-tier) mode.
•
Disconnect and reconnect to the project or the project
source, if in direct (2-tier) mode.
•
Manually update the schema.
updating the schema allows you to
Manually
determine which specific elements of the schema are
updated.
To manually update the schema
1 In MicroStrategy Desktop, from the Schema menu, select
Update Schema.
2 In the Schema Update dialog box, select or clear the
following check boxes:
•
Update schema logical information: Use this option
if you added, modified, or deleted a schema object.
•
Recalculate table keys and fact entry levels: Use
this option if you changed the key structure of a table
or if you changed the level at which a fact is stored.
•
Recalculate table logical sizes: Use this option to
use MicroStrategy Desktop’s algorithm to recalculate
logical table sizes and override any modifications that
you have made to logical table sizes.
table sizes are a significant part of how the
Logical
MicroStrategy SQL Engine determines the tables to
use in a query.
•
Recalculate project client object cache size: Use
this option to update the object cache size for the
project.
3 Click Update.
can also update the schema with the last saved
You
settings by clicking the Update Schema icon in the
toolbar.
© 2007 MicroStrategy, Inc.
Updating your MicroStrategy project schema
217
8
Optimizing and Maintaining Your Project
Project Design Guide
Data warehouse and project interaction:
Warehouse Catalog
This section discusses how the Warehouse Catalog can
control the interaction between the data warehouse and the
database instance for a project. The Warehouse Catalog
queries the data warehouse and lists the tables and columns
that exist in it. From this list, you can select the tables to add
to your project. Every project can have a unique set of
warehouse tables.
You can add warehouse tables to your project with the
Warehouse Catalog or MicroStrategy Project Builder. The
Warehouse Catalog is better for maintaining the warehouse
tables used for an existing project. Adding tables through
Project Builder is useful only when you are creating a project
for the first time, as later, adding tables in the project through
Project Builder can become a cumbersome process.
This section also discusses customizing catalog SQL
statements, the structure of the SQL catalogs, and the default
SQL statements used for each database.
This section covers the following topics:
•
What should I know before I use the Warehouse
Catalog?, page 219
•
Accessing the Warehouse Catalog, page 219
•
Adding and removing tables for a project, page 220
•
Managing warehouse and project tables, page 221
•
Modifying data warehouse connection and operation
defaults, page 226
•
Customizing catalog SQL statements, page 233
•
Troubleshooting table and column messages, page 239
218 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
Note the following:
•
You can also add tables to a project using
MicroStrategy Query Builder. For more
information on Query Builder, see the
MicroStrategy Advanced Reporting Guide.
•
You can connect to OLAP cube sources such as SAP
BW, Hyperion Essbase, and Microsoft Analysis
Services instead of a relational database. In this
case, the OLAP Cube Catalog handles tasks similar
to the Warehouse Catalog. For more information,
refer to Appendix B, Connecting to OLAP Cube
Sources.
What should I know before I use the Warehouse Catalog?
Before you begin using the Warehouse Catalog, you need to
be familiar with:
•
Your schema, so you know how the information in your
data warehouse should be brought into MicroStrategy
•
How to create a project
Accessing the Warehouse Catalog
To access the Warehouse Catalog
1 On the Windows Start menu, point to Programs, then to
MicroStrategy, then Desktop, and then select Desktop.
2 Log in to the project source that contains your project in
MicroStrategy Desktop, and expand your project.
must use a login that has Architect privileges.
You
For more information about privileges see the
Permissions and Privileges appendix of the
MicroStrategy System Administration Guide.
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
219
8
Optimizing and Maintaining Your Project
Project Design Guide
3 Select a project and then from the Schema menu, select
Warehouse Catalog. The Warehouse Catalog opens after
it retrieves the table information from the warehouse
database.
Adding and removing tables for a project
As you become aware of the additional needs of report
designers and users, it may become necessary to add
additional tables from the data warehouse to your project.
Also, as your project matures, you may need to remove tables
from your project that are no longer used and are taking up
space in the metadata.
You can access the Warehouse Catalog at any time to add
additional tables from your data warehouse to your project
and remove tables from your project.
To add or remove tables after creating a project
1 Access the Warehouse Catalog for your project as
described in To access the Warehouse Catalog, page 219.
Log in to the project source that contains your project in
MicroStrategy Desktop, and expand your project.
2 The left side of the Warehouse Catalog lists all available
tables and the number of rows each table contains. The
list on the right shows all the tables already being used in
the project:
•
To add tables—From the left side, select the tables
you want to add to the Warehouse Catalog, and click >
to add the selected tables. Click >> to add all the listed
tables.
•
To remove tables—From the left side, select the
tables you want to add to the Warehouse Catalog, and
click > to add the selected tables. Click >> to add all the
listed tables.
220 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
3 In the toolbar, click Save and Close to save your changes
to the Warehouse Catalog. The table definitions are
written to the metadata. This process can take some time
to complete.
4 Update the project schema from the Schema menu, by
selecting Update Schema.
Managing warehouse and project tables
The Warehouse Catalog allows you to view tables that have
been included in the project, as well as those tables that are
available in the warehouse but have not been included in the
project. To access the Warehouse Catalog for a project, see
Accessing the Warehouse Catalog, page 219.
As you make changes to the tables in the warehouse, you need
to periodically load the updates into the Warehouse Catalog.
You can update it by selecting Read the Warehouse Catalog
from the Actions menu.
The Warehouse Catalog has the following sections:
•
Tables available in the warehouse: Displays tables that
are located in the warehouse, but have not been included
in the project. You can add tables to the project by
double-clicking the tables or by selecting the tables and
then clicking >.
•
Tables being used in the project: Displays tables that
have been selected to be part of the project. You can
remove tables from the project by double-clicking the
tables or by selecting the tables and then clicking <.
can add or remove all the tables from one section
You
to the other by clicking << and >> buttons.
Warehouse Catalog has the following menu options.
Menu
Description
File
• Save
© 2007 MicroStrategy, Inc.
Saves the current settings and status of the
Warehouse Catalog.
Data warehouse and project interaction: Warehouse Catalog
221
8
Optimizing and Maintaining Your Project
Menu
• Exit
Project Design Guide
Description
Exits the Warehouse Catalog.
Tools
• View Partitions
Displays the list of tables referred to by the
selected partition mapping table in the Table
Partitions dialog box. This option is enabled
when a partition mapping table is selected.
• Table Structure
Displays the structure of a table selected in
the Warehouse Catalog.
• Calculate Table Row
Count
Calculates the number of rows in the
selected tables.
• Table Prefix
Allows you to add or remove a table prefix for
the selected table.
• Table Database
Instances
Allows you to assign or update a database
instance for the project. For more
information, see Data warehouse connection
and read operations, page 227 of this
appendix.
• Import Prefix
Allows you to import the prefixes from the
warehouse table name space.
• Options
Allows you to specify various settings for the
Warehouse Catalog such as changing the
database instance, changing or assigning
default table prefixes and structures,
automatic mapping, row calculation, and so
on.
Actions
• Read the Warehouse
Catalog
Help
Allows you to update and reflect the changes
done to tables in the warehouse.
Displays MicroStrategy help options
Some of these options are also available through toolbar
buttons and through right-click menus for quick access.
Viewing table structure
To view the table structure of a table, right-click any table in
the Warehouse Catalog (see Accessing the Warehouse
Catalog, page 219) and choose Table Structure from the
222 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
shortcut menu. You can also select Table Structure from the
Tools menu. The table structure of the selected table is
displayed in the dialog box.
The dialog box displays the columns available in the selected
table and the data type of each column. You can also click
Update Structure to reflect any recent changes done to that
table (see Updating table structure, page 223).
When the data type of one or more columns is modified, you
get a warning message of this change, which provides the
following options:
•
Click OK to apply the change to this column in all the
tables it appears.
•
Click Cancel to undo all data type changes. This action
results in no changes being applied to any tables or
columns.
warning message appears only if you have selected
The
the Display a warning if the columns data types are
modified when updating the table structure option
in the Warehouse Catalog Options dialog box. This
option is selected by default.
Updating table structure
Whenever the structure of the warehouse table changes you
have to update the table structure in the Warehouse Catalog
for the changes to reflect in the MicroStrategy system. Some
examples of these type of changes are when you add, delete,
or rename a column in a table associated with a project,
To update the structure of a table
1 Access the Warehouse Catalog for your project (see
Accessing the Warehouse Catalog, page 219). The
Warehouse Catalog opens.
2 In the Tables being used in the project list, right-click the
table that has changed and select Update Structure.
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
223
8
Optimizing and Maintaining Your Project
Project Design Guide
If the data type of one or more columns is modified, you
receive a message warning of this change. Verify the
changes from the information dialog box that opens and
click OK to apply the change in this column to all the
tables in which it appears.
3 Click Save and Close to close the Warehouse Catalog
dialog box.
•
If no object definitions have changed, the warehouse
structure gets updated completely with the Update
Structure command. For example, this would apply if
you rename a column in the table and the column is
not being used in any fact expression.
•
If any of the object definitions have changed, the table
structure is only partially updated with the Update
Structure command. Then, you have to manually
update the schema objects that depend on the
outdated structure.
For example, if you rename a column in a table, you
have to manually update the facts that use this
column. The procedure for manually updating the fact
is as follows:
– Right-click the fact and select Edit. The Fact Editor
opens.
– Select the fact expression and click Modify. The
Modify Fact Expression dialog box opens.
– From the list of source tables select the source table
from which the fact has been created. Edit the fact
expression and click OK. You are returned to the
Fact Editor.
– Click Save and Close to save the changes and
close the Fact Editor.
– From the Schema menu, select Update Schema.
The Schema Update dialog box opens.
– Click Update.
– Repeat the first to steps of this procedure to open
the Warehouse Catalog and update the table
structure.
224 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
– Click Save and Close to save the changes and
close the Warehouse Catalog dialog box.
Viewing sample data
To view sample data from a table, right-click a table in the
Warehouse Catalog (see Accessing the Warehouse Catalog,
page 219) and choose Show Sample Data from the shortcut
menu. You can also select Show Sample Data from the Tools
menu. The first 100 rows of the table are returned as sample
data in the Values dialog box.
To refresh the table data, click Reload table values.
Specifying a secondary database to support
database gateways
MicroStrategy allows you to specify a secondary database
instance for a table, which is used to support database
gateways. For example, in your environment you might have
a gateway between two databases such as an Oracle database
and a DB2 database. One of them is the primary database and
the other is the secondary database. The primary database
receives all SQL requests and passes them to the correct
database. From the perspective of MicroStrategy products in
this environment, you need to define two database instances,
one for the primary database and another for the secondary
database. The default database instance for the project is set
to be the primary database. In the Warehouse Catalog, you
must set the secondary database instance for any tables that
are found in the secondary database. This way, MicroStrategy
products know how to generate SQL for each table.
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
225
8
Optimizing and Maintaining Your Project
Project Design Guide
To specify a secondary database for a table
1 Access the Warehouse Catalog for your project (see
Accessing the Warehouse Catalog, page 219). The
Warehouse Catalog opens.
2 Right-click a table being used in the project, (in the pane
on the right side) and select Table Database Instances.
The Available Database Instances dialog box opens.
3 In the Primary Database Instance drop-down list, select
the primary database instance for the table.
4 Select one or more Secondary Database Instances.
cannot select the primary database instance as
You
a secondary database instance.
5 Click OK to accept your changes and return to the
Warehouse Catalog.
6 From the toolbar, select Save and Close to save your
changes and close the Warehouse Catalog.
Modifying data warehouse connection and operation defaults
You can specify various settings for data warehouse
connection and operation defaults using the Warehouse
Catalog. Example settings include changing the database
instance, changing or assigning default table prefixes and
structures, automatic mapping, row calculation, and so on.
The settings are available from the Warehouse Catalog, by
choosing Options from the Tools menu (see Accessing the
Warehouse Catalog, page 219 for steps to access the
Warehouse Catalog). The Warehouse Catalog Options dialog
box opens, which allows you to perform the following tasks:
•
Data warehouse connection and read operations
•
Displaying table prefixes, row counts, and name spaces
•
Mapping schema objects and calculating logical sizes for
tables
226 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
Data warehouse connection and read operations
You can modify the database instance and database login
used to connect the data warehouse to a project, as well as
change how the database catalog tables are read. You can
make these type of modification from the Catalog category,
which is divided into the following subcategories:
•
Warehouse Connection: Select the desired database
instance to use for the project as well as the custom
database login.
Database Instance: You can select the database
instance for the Warehouse Catalog from the
drop-down list.
If the desired database instance does not appear in the
Database Instance box, or if it does but needs to be
modified, you can select from the following:
– Click Edit to modify the selected database instance.
The General tab of the Database Instances dialog
box opens.
– Click New to create a new database instance. The
Database Instance Wizard opens.
to the MicroStrategy System Administration
Refer
Guide for more information on either of these
dialog boxes.
Custom Database Login: You can either select the
database login or clear the login to use no database
login.
more information on the database login, see
For
the online help.
•
© 2007 MicroStrategy, Inc.
Read Settings: You can customize the SQL that reads the
Warehouse Catalog for every platform except Microsoft
Access. Clicking Settings allows you to directly edit the
catalog SQL statements that are used to retrieve the list of
available tables from the Warehouse Catalog and the
columns for the selected tables. When connected to a
Microsoft Access data source, the Settings option is
disabled. The default catalog SQL retrieves a DISTINCT
list of tables and columns from all users. You could
restrict the information returned, for example, by
Data warehouse and project interaction: Warehouse Catalog
227
8
Optimizing and Maintaining Your Project
Project Design Guide
specifying certain conditions and table owners (see
Customizing catalog SQL statements, page 233). You can
also select the following check boxes:
Count the number of rows for all tables when
reading the database catalog: Select this option if
you want to control whether or not the Warehouse
Catalog should get the number of rows each table has
when loading from the data warehouse. This option is
helpful when you want to identify fact tables and
aggregation tables. If performance is more important
than obtaining the row count, do not select this option
as it will have a negative effect on performance. By
default this option is selected when you open the
Warehouse Catalog for the first time.
Ignore current table name space when reading
from the database catalog and update using new
table name space: This option allows you to switch
between warehouses found in different database name
spaces. For more information, see Ignoring table
name spaces when migrating tables, page 232 of this
appendix. By default this option is selected.
Display a warning if the column data types are
modified when updating the table structure: Select
this option if you want to be warned when the data
type for a column stored in the project is different
from the one read from the data warehouse. The check
for the data type change is only performed when
updating a table’s structure. By default this option is
selected.
Automatically update information for all Partition
Mapping tables when reading the database
catalog: Select this option to read the latest
information for the partition mapping tables (PMTs)
currently present in the project. This setting should be
cleared when the number of PMTs in the project is so
large that reading their structure is causing
performance problems when opening the Warehouse
Catalog. By default this option is selected.
Column Merging Options: When you add a new table
to your data warehouse, it may redefine the data type
for a column included in the project. For example,
your project includes a table named Table1 that has
228 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
column C1 of data type char(1). Then a new table
named Table2 is added to the project, but it has
column C1 set to data type char(4). This example is
used to illustrate the options described below. When
you update the table structure, the column data types
are modified to maintain a consistent schema in one of
three ways, depending on the option you select.
options below do not handle the merge if the
The
data type has changed to an incompatible data
type. For example, a column is changed from data
type char to data type integer. If the data type has
changed to an incompatible data type, a warning is
displayed and you are asked if you want to use the
new data type.
– Use most recent data type: This option updates
the column data type to use the most recent
column definition. In the example above, the
column data type for C1 would be changed to
char(4) since Table2 was added after Table1.
– Use maximum denominator data type: This
option updates the column data type to use the
data type with the largest precision or scale. In the
example above, the column data type for C1 would
be changed to char(4), as defined in Table2. This is
because char(4) has a higher precision than char(1)
defined in Table1. If the data type has been
changed to a different compatible data type, the
data type with the largest precision or scale is used,
as illustrated in the image below.
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
229
8
Optimizing and Maintaining Your Project
Project Design Guide
– Do not merge: This option renames the column in
the newly added table, which allows the columns to
have different data types. From the example above,
column C1 uses the char(1) data type for Table1.
Column C1 in Table2 is defined as a separate copy
of C1 and uses the char(4) data type. This option
can cause unwanted schema changes and should be
used only when necessary.
•
Read Mode: The Warehouse Catalog can be
automatically read upon opening the Warehouse Catalog,
or restricted to only be read when a read is manually
requested:
Automatic: This option sets the Warehouse Catalog
tables to be read as soon as the catalog browser is
loaded.
Manual: This option sets the Warehouse Catalog
tables to be read only when the read catalog action is
selected.
Displaying table prefixes, row counts, and name
spaces
You can choose to show or hide table prefixes, row counts,
and name spaces, by using the View category. This category is
divided into the following subcategories:
•
Table Prefixes: You can specify whether table prefixes
are displayed in table names and how prefixes are
automatically defined for tables that are added to the
project. You have the following options:
Display table prefixes in the main dialog: Select this
option to display all prefixes in table names, including
new tables added to the project. By default this option
is selected.
Automatically define prefixes for all tables that are
added to this project: This setting enables/disables
the following options:
– Set a prefix based on the warehouse table
name space or owner (import prefix): When this
option is selected, the Warehouse Catalog reads the
230 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
name space for each table being added, creates a
prefix having the same text as the name space, and
associates it with the table being added.
– Set a default prefix: Select this to add a prefix to
tables when they are added to a project. This
option is only active when the database supports
prefixes. You can select the default prefix from the
Default prefix box drop-down list or create a new
table prefix by clicking Modify prefix list.
– Modify prefix list: You can create a new tables
prefix or delete an existing prefix by selecting this
option. The Table Prefixes dialog box opens. For
more information on modifying the prefix list, see
the online help.
•
Table Row Counts: You can show or hide the number of
rows per table, using the check box:
•
Display the number of rows per table: You can show
or hide the values calculated for the number of rows
for the tables. By default, this option is selected and
the number of rows are shown.
Table Name Spaces: You can show or hide the name
space for each table, using the check box:
Display the name space for each table (if
applicable): You can show or hide the owner or table
name space where the table is located in the
warehouse. By default, this option is selected and table
name spaces are shown.
Mapping schema objects and calculating logical
sizes for tables
The Schema category is divided into the following
subcategories:
•
© 2007 MicroStrategy, Inc.
Automatic Mapping: When you add new tables to the
Warehouse Catalog, you can determine whether existing
schema objects in the project are mapped to these new
tables automatically, using the following options:
Data warehouse and project interaction: Warehouse Catalog
231
8
Optimizing and Maintaining Your Project
Project Design Guide
Map schema objects to new tables automatically:
Existing objects in the schema automatically map to
tables you add to the project.
Do not map schema objects to the new tables:
Objects in the schema are not automatically mapped
to tables you add to the project.
These automatic mapping methods are only applied to
existing schema objects when tables are added to the
Warehouse Catalog. For example, the attribute Year with
an attribute form mapped to YEAR_ID is included in a
project. Then a new table which includes a YEAR_ID
column is added to the Warehouse Catalog. With the Map
schema objects to new tables automatically option
selected, the Year attribute is automatically mapped when
the new table is added.
to the Warehouse Catalog
Iffirsttheandtablethenwastheadded
attribute was created, the
Warehouse Catalog automatic mapping settings do
not determine whether the attribute and table are
automatically mapped. Automatically mapping
tables to schema objects when adding attributes or
facts to a project is controlled by the Attribute
Editor and Fact Editor, respectively.
•
Table Logical Sizes: You can select whether the
Warehouse Catalog calculates logical sizes for new tables
using one of the following options:
Calculate the logical table sizes automatically:
Logical sizes are automatically calculated for tables
you add to the project.
Do not calculate table logical sizes: Logical sizes are
not calculated for the tables you add to the project.
Ignoring table name spaces when migrating
tables
It is a common practice to establish a secondary warehouse
with less information than the primary warehouse for
development and testing. Before going into production, you
change the project to point to the primary warehouse.
232 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
Most database management systems (Oracle, DB2, and
others) support the concept of a table name space, which is a
way of organizing database tables into different storage
spaces. This method allows you to repeat the same table
name in different table name spaces. For instance, you can
have LU_STORE in a table name space called dbo and another
table LU_STORE in another table name space called admin.
You now have two tables dbo.LU_STORE and
admin.LU_STORE. The table name space provides an extra
piece of information that uniquely identifies the table.
When you add tables to a project, the Warehouse Catalog
saves information to the appropriate table name space. This
can cause a problem when you migrate from a warehouse that
resides in a certain table name space to another warehouse in
a different table name space. The Warehouse Catalog
interprets the table as already in the project and not found in
the new warehouse. This is because the Warehouse Catalog is
looking for a table named dbo.LU_STORE, and the table is
actually stored as admin.LU_STORE in the new production
warehouse.
To solve this problem, select the Ignore current table name
space when reading from the database catalog and
update using new table name space check box. You can
find this option in the Warehouse Catalog Options dialog box
under the Catalog - Read Settings options subcategory. If you
select this option, the Warehouse Catalog ignores the current
table name space when it reads the catalog information.
Thus, the Warehouse Catalog recognizes the two tables as the
same table and saves the new table name space information.
This setting allows you to migrate much more easily between
warehouses. If the check box is cleared, the Warehouse
Catalog defaults to identifying the table by both table name
space and table name.
Customizing catalog SQL statements
In all supported warehouse platforms other than Microsoft
Access, MicroStrategy uses SQL statements to query the
relational database management system (RDBMS) catalog
tables to obtain warehouse catalog information. This
information includes catalog tables, columns, and their data
types.
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
233
8
Optimizing and Maintaining Your Project
Project Design Guide
These catalog SQL statements vary from platform to platform
and can be customized according to the characteristics of the
specific warehouse.
Access does not have catalog tables, so an
Microsoft
ODBC call must be used to retrieve information about
tables and columns in Access. By default, a similar
ODBC call is used for the Generic DBMS database
type, but you can choose to use custom catalog SQL for
the generic type if you wish.
The MicroStrategy Warehouse Catalog can be configured to
read the catalog information in one- or two-pass SQL mode.
In two-pass SQL mode, it first reads only the tables from the
database. The structure of individual tables is read only when
the table is selected. This is the recommended option for
interactive warehouse catalog building because no
unnecessary catalog information is read from the database,
which increases processing speed. One-pass SQL mode, on
the other hand, reads all the tables and columns in one SQL
statement. This option is recommended only if the catalog
SQL is well customized to limit the amount of data returned
by it.
The two retrieval options use different catalog SQL, but both
can be customized in the Warehouse Catalog Options dialog
box. In the following sections, the name Catalog Table SQL
refers to the catalog SQL to retrieve the tables in the
warehouse; that is, the first SQL used in a two-pass catalog
retrieval.
The name Full Catalog SQL refers to the SQL used to read all
the tables and columns in one pass.
234 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
To customize a catalog SQL, you must understand several
important concepts and procedures:
•
The table name space, page 235
•
SQL placeholder strings and incomplete catalog SQL,
page 235
•
Structure of Catalog Table SQL, page 236
•
Structure of Full Catalog SQL, page 236
•
Modifying catalog SQL, page 237
•
Default catalog SQL, page 238
The table name space
In a typical RDBMS platform, a table name does not uniquely
identify it in a particular database installation. A table name
space is a partition of the database installation in which table
names are unique. Depending on the type of RDBMS, this
name space can be the name of the database, the owner of the
table, or a combination of both database and owner. In both
the Catalog Table SQL and Full Catalog SQL, a name space
gives each table a unique name. This helps you to avoid
confusing tables that share the same table name.
The table name space is optional. A customized catalog SQL
can omit the name space if duplicate table names do not
present a problem in the warehouse database.
SQL placeholder strings and incomplete catalog
SQL
The default system catalog SQL can contain certain
placeholder strings that can be resolved at run time or must
be completed manually by the user. These placeholders are:
•
© 2007 MicroStrategy, Inc.
#LOGIN_NAME#—This placeholder is automatically
replaced at run time with the login name used to connect
to the database. You can leave this template in the
customized SQL if you want the catalog SQL to yield
Data warehouse and project interaction: Warehouse Catalog
235
8
Optimizing and Maintaining Your Project
Project Design Guide
different results depending on the warehouse login used.
Otherwise, this template is replaced with the name of the
database user who owns the warehouse tables of interest.
•
#?Database_Name?#, #?Schema_Name?#—This
catalog SQL placeholder is an incomplete SQL string that
must be completed by the user before it can be executed.
The string starts with #? and ends with ?#. The command
#?Database_Name?#, used with Teradata, must be
replaced with the name of the database containing the
database tables. #?Schema_Name?#, used with DB2
AS/400, must be replaced with the name of the schema in
which the database tables reside.
Structure of Catalog Table SQL
Catalog Table SQL is expected to return two columns, one
identifying the name space of the table and the other the
name of the table. If a name space is not provided, only the
table name column is required. Each row of the SQL result
must uniquely identify a table. Duplicates are not allowed.
The column that identifies the table name space uses the SQL
column alias NAME_SPACE. The column that identifies the
table name has the alias TAB_NAME. The following example is
the default Catalog Table SQL for Oracle 8.0:
SELECT DISTINCT OWNER NAME_SPACE,
TABLE_NAME TAB_NAME
FROM ALL_TAB_COLUMNS
WHERE OWNER = '#LOGIN_NAME#'
Structure of Full Catalog SQL
Full Catalog SQL is expected to return between five and seven
columns, depending on the RDBMS platform and the
customization.
The following aliases identify each column returned:
•
NAME_SPACE (optional): the table name space
•
TAB_NAME (required): name of the table
236 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
•
COL_NAME (required): name of the column
•
DATA_TYPE (required): a string or a number that
identifies the major data type of the column
•
DATA_LEN (required): a number that describes the length
or size of the column data
•
DATA_PREC (optional): a number that describes the
precision of the column data
•
DATA_SCALE (optional): a number that describes the
scale of a floating point column data
Full Catalog SQL must return its rows ordered first by
NAME_SPACE, if available, and then by TAB_NAME.
The following example is the default Full Catalog SQL for
Microsoft SQL Server 7.0:
SELECT U.name NAME_SPACE, T.name TAB_NAME,
C.name COL_NAME, C.type DATA_TYPE,
C.length DATA_LEN, C.prec DATA_PREC,
C.scale DATA_SCALE
FROM sysobjects T, syscolumns C, sysusers
WHERE T.id = C.id and T.type in ('U', 'V')
AND T.uid = U.uid
ORDER BY 1, 2
Modifying catalog SQL
You can customize and modify the catalog SQL that is run
against your database for each project. The catalog SQL can
be modified in the Warehouse Catalog options for your
project.
To modify the catalog SQL for your project
1 Access the Warehouse Catalog for your project (see
Accessing the Warehouse Catalog, page 219). The
Warehouse Catalog opens.
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
237
8
Optimizing and Maintaining Your Project
Project Design Guide
2 From the Tools menu, select Options. The Warehouse
Catalog Options dialog box opens.
3 Expand the Catalog Category, and select Read Settings.
The Catalog - Read Settings options are displayed.
4 Click the Settings button, the catalog SQL options are
displayed as shown below.
catalog SQL settings are unavailable if your
The
project is connected to a Microsoft Access
database.
The top pane controls the Catalog Table SQL and the bottom
pane controls the Full Catalog SQL.
Default catalog SQL
When customizing the catalog SQL that is executed on your
database, it is recommended you consult the default catalog
SQL that MicroStrategy uses to support different database
238 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
platforms. You can generate the default catalog SQL in
MicroStrategy for the database platform your project
connects to.
To generate and view the default catalog SQL
1 Access the catalog SQL options for your project (see
Modifying catalog SQL, page 237). A dialog box for the
catalog SQL options is displayed.
•
The top pane controls the Catalog Table SQL, which
retrieves a list of available tables in the Warehouse
Catalog.
•
The bottom pane controls the Full Catalog SQL, which
retrieves column information for the selected tables.
performing the next step, cut and paste the SQL
Before
statements in the two panes into any text editor. This
allows you to save any modifications you have made
previously to the catalog SQL statements, and then
compare them to the default statements you are about
to generate.
2 Generate and view the default catalog SQL for your
database platform. Any text in the panes is overwritten
with the default catalog SQL statements:
•
To generate and view the default Catalog Table SQL
for your database platform, click the upper-most Use
Default button.
•
To generate and view the default Full Catalog SQL for
your database platform, click the bottom-most Use
Default button.
You can use the default catalog SQL statements or compare
and combine them with your own customized catalog SQL
statements.
Troubleshooting table and column messages
You may encounter the following messages while using the
Warehouse Catalog:
© 2007 MicroStrategy, Inc.
Data warehouse and project interaction: Warehouse Catalog
239
8
Optimizing and Maintaining Your Project
•
Tables missing
•
Columns data type changed
•
Columns missing
Project Design Guide
Tables missing
This happens when one or more tables already in the project
are removed from the data warehouse. Two cases can be
seen:
•
•
When the Warehouse Catalog is starting and retrieving
the table information from the data warehouse and it
detects that one or more tables already in the project are
missing, it displays an error message which gives you the
following options:
Leave the Table in the project: This leaves
everything as is in the project metadata. However the
definition in the project may be inconsistent with the
real physical structure in the warehouse. This can
result in SQL errors when running reports that need
data from a “missing” table.
Remove the table from the project. In this case, the
Warehouse Catalog does not check for any
dependencies until you save the changes. If there are
any dependencies, they are presented to you, and you
have the option to proceed or cancel the operation.
When the Warehouse Catalog tries to update the structure
of a table that is missing in the warehouse, a message is
shown which explains that the table structure update
cannot proceed because the table was not found in the
warehouse. In this case, no changes occur and the original
table structure remains intact.
Columns data type changed
When the table structure is updated for one or more tables in
which the column data types have been changed, you get a
warning message showing the table name, column name,
240 Data warehouse and project interaction: Warehouse Catalog
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
original data type, and new data type. You can click Cancel at
any time to undo all data type changes. This results in no
changes being applied to the tables and columns.
Columns missing
Missing columns are detected when Update Structure is
performed. If this happens, the Warehouse Catalog checks for
the following:
•
Column is not mapped to any schema object: If this is
the case, then no error message is shown.
•
Column is mapped to a schema object: If this is the
case, then a message is displayed that gives details on
objects, which are mapped to the missing column and the
update structure operation is canceled. You are asked to
remove the mapping before continuing with the update
structure and original table structure is restored.
Using summary tables to store data: Aggregate
tables
Aggregate tables are summary tables that store data at
higher levels than it was stored when the data was initially
captured and saved. Aggregate tables provide quicker access
to frequently requested information, while retaining the
traditional power of ROLAP to directly query the database to
answer any questions. This section describes how and why
aggregate tables are used.
MicroStrategy creates aggregates only on fact tables since
lookup tables and relationship tables are usually significantly
smaller. To understand aggregate tables, you should be
familiar with fact tables in the context of data modeling and
data warehousing. For more information on these topics, see
Chapter 2, The Logical Data Model, Chapter 3, Warehouse
Structure for Your Logical Data Model, and Chapter 5, The
Building Blocks of Business Data: Facts.
© 2007 MicroStrategy, Inc.
Using summary tables to store data: Aggregate tables
241
8
Optimizing and Maintaining Your Project
Project Design Guide
When to use aggregate tables
MicroStrategy uses optimized SQL to query the relational
database directly to answer users’ questions. Users can ask
any question that is supported by the data in their warehouse
and then analyze the results until they find a precise answer.
The disadvantage to this relational OLAP (ROLAP)
methodology is that accessing huge fact tables can be
potentially time-consuming. Multidimensional OLAP
(MOLAP) is sometimes considered by some to be the answer
to this problem. However, MOLAP is not scalable for large
projects because of the difficulty of maintaining every
possible combination of aggregates as the number of
attributes and the amount of data increases. MicroStrategy’s
solution is the use of aggregate tables to provide quicker
access to frequently-accessed data while still retaining the
power to answer any user query.
Aggregate tables are advantageous because they
•
Reduce input/output, CPU, RAM, and swapping
requirements
•
Eliminate the need to perform dynamic calculations
•
Decrease the number of physical disk reads and the
number of records that must be read to satisfy a query
•
Minimize the amount of data that must be aggregated and
sorted at run time
•
Move time-intensive calculations with complicated logic
or significant computations into a batch routine from
dynamic SQL executed at report run time
In summary, the MicroStrategy SQL Engine, in combination
with aggregate tables and caching, can produce results at
about the same speed as MOLAP. This combined solution
allows questions to be answered on the fly and is also scalable
for large databases.
242 Using summary tables to store data: Aggregate tables
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
Aggregation versus pre-aggregation
Whenever the display level of data on a report must differ
from the level at which the data is initially captured,
aggregation, that is, the rolling up of data, must occur. By
default, aggregation occurs dynamically with a SQL
statement at report run-time.
For example, sales data is stored by day in a fact table. A
report requesting month-level data is executed. The daily
values from the fact table are selected, sorted, and added to
produce the monthly totals, as shown below.
Aggregation can also be completed before reports are
executed; the results of the aggregation are stored in an
aggregate table. This process is called pre-aggregation. You
can build these pre-aggregated—or aggregate—tables as part
of the ETL process. If sales data is frequently requested at the
month level, as in the previous example, an aggregate table
with the sales data rolled up to the month level is useful.
© 2007 MicroStrategy, Inc.
Using summary tables to store data: Aggregate tables
243
8
Optimizing and Maintaining Your Project
Project Design Guide
Pre-aggregation eliminates the reading, sorting, and
calculation of data from many database rows in a large,
lower-level fact table at run time, as shown in the following
example.
If the daily sales fact table is the lowest-level fact table and
contains atomic-level data, it is referred to as a base table. In
these terms, an aggregate table is any fact table whose data is
derived by aggregating data from an existing base table.
Degree of aggregation
While MOLAP can provide fast performance when it answers
a question, it requires a completely aggregated schema to
answer most questions. That is, every possible combination
of aggregate associations must be generated when the
multidimensional cube is built. This ensures that all possible
244 Using summary tables to store data: Aggregate tables
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
questions can be answered. This scenario becomes very
difficult to maintain as the number of attributes and the
amount of data increase, and therefore is not very scalable.
In a ROLAP environment, the degree of aggregation can be as
dense or as sparse as is appropriate for your users. A densely
aggregated warehouse has a large number of aggregate tables
while a sparsely aggregated warehouse has fewer. Sparse
aggregation refers to the fact that a given project only
requires as many aggregate fact tables as is useful to its users.
ROLAP, therefore, provides much greater flexibility than
MOLAP. Only the aggregate combinations that you
determine are beneficial must be created. That is, if the
aggregate table is useful in answering frequently-asked
queries, its presence provides a response as fast as a MOLAP
system can provide. However, if a certain aggregate
combination is rarely or never used, the space in the RDBMS
does not need to be consumed and the resources to build that
table during the batch process do not need to be used.
Not every attribute level or hierarchy intersection is suitable
for pre-aggregation. Build aggregate tables only if they can
benefit users, since the creation and maintenance of
aggregate tables requires additional work by the database
administrator. Also, do not waste database space for tables
that will not be used.
Consider the following factors when deciding whether to
create aggregate tables:
© 2007 MicroStrategy, Inc.
•
The frequency of queries at that level—Determining the
frequency of queries at a specific level, page 246
•
The relationship between the parent and
child—Considering any related parent-child
relationships, page 246
•
The compression ratio—Compression ratio, page 247
Using summary tables to store data: Aggregate tables
245
8
Optimizing and Maintaining Your Project
Project Design Guide
Determining the frequency of queries at a specific level
Build aggregate tables only if they can be useful to your users.
If aggregate tables are never accessed, they consume disk
space and impose unnecessary burdens on the extraction,
translation, and loading process, as well as the database
backup routines.
However, usefulness is not always easy to quantify. For
example, consider the following hierarchy:
A summary of data at the department level seems to be a
good candidate for an aggregate table. However, if users
frequently want to exclude inactive items, the query must use
item-level data and summarize the department data
dynamically. Therefore, the department aggregate tables
would not be used in this situation.
Once your warehouse is in production, trace the usage of any
aggregate tables to determine how frequently they are used in
a day-to-day business environment. If any table is not used,
eliminate it from the warehouse.
MicroStrategy Enterprise Manager allows you to easily track
table usage. For more information on Enterprise Manager,
see the MicroStrategy System Administration Guide.
Considering any related parent-child relationships
When an aggregate table is created, the child records are
usually summarized into the parent record, based on the key
combinations in a relationship table. In any hierarchical
relationship, when the parent-child relationship is altered, all
246 Using summary tables to store data: Aggregate tables
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
tables that hold that relationship or data relevant to it must
be updated. Whether these relationships are dynamic or
static change how they are aggregated into tables.
Dynamic relationships
When the relationship between parent and child elements
change, the relationship is called dynamic. These changes
often occur because of organizational restructuring;
geographical realignment; or the addition, reclassification, or
discontinuation of items or services. For example, a store can
decide to reclassify the department to which items belong.
Aggregate tables that contain dynamic relationships must be
recalculated every time a change is made. If the tables are
large, this process can take time, consume resources, and
complicate the batch process. Frequent changes can mean
aggregate tables are not optimal for this situation. Consider
the frequency of the changes, the table size, and the impact
on the batch process, and then balance the disadvantages
against the advantages of having an aggregate table.
Also, rolling up an entire hierarchy can avoid many problems
with relationship changes. For example, a table contains one
value for the sum of all stores. It is not affected by a
reorganization within the geography hierarchy.
Static relationships
When elements rarely or never change relationships, they are
a part of static relationships. In these cases, maintaining
aggregate tables is very easy. For example, time hierarchies
are seldom dynamic—days do not migrate into different
weeks, and fiscal weeks do not move into different months.
Compression ratio
The process of data aggregation applies an aggregate
function, such as sum or average, to a set of child records to
produce a single parent record. The average number of child
records combined to calculate one parent record is called the
© 2007 MicroStrategy, Inc.
Using summary tables to store data: Aggregate tables
247
8
Optimizing and Maintaining Your Project
Project Design Guide
compression ratio. One measure of effectiveness of an
aggregate table can be estimated from this number, since it
represents the decrease in records that must be read to
respond to a query at that level.
Recall that some of the reasons to build aggregate tables
include the reduction of disk I/O and the number of records
that must be dynamically sorted and aggregated. Therefore,
pre-aggregating data is effective only if the compression ratio
is significant. For example, if the compression ratio is 3:2, the
aggregate table requires 2/3 of the base table’s storage space
but yields only a 1/3 reduction in the number of records. In
contrast, if the compression ratio is 4:1, the aggregate table
reduces the number of records by 3/4 and uses only 1/4 of the
storage space.
When the number of elements differs significantly between
two attributes in the same hierarchy, the compression ratio
suggests that an aggregate table can provide more efficient
queries. Also, for smaller base tables, the resource demands
placed on the database server by dynamic aggregations
decrease and therefore so does the effectiveness of
pre-aggregation. To determine when pre-aggregation is
worthwhile for your system, you must balance the
importance of speed of query response time and the
availability of disk space and resources to maintain the
schema.
For more information on ratios, refer to Cardinalities and
ratios, page 35.
Creating aggregate tables
You can integrate aggregate tables in your project using the
Warehouse Catalog in MicroStrategy Desktop, as outlined in
the following procedure.
248 Using summary tables to store data: Aggregate tables
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
To use an aggregate table in an existing project
1 Using the Warehouse Catalog, add the table to the project.
For steps to add tables using the Warehouse Catalog, see
Adding and removing tables for a project, page 220.
2 Use the new table in the desired fact expressions and
attribute form expressions.
If your aggregate table structure is consistent with your base
fact table structure, Architect automatically adds it to the
definitions of your existing attributes and facts. In other
words, Architect is aggregate-aware. How does Architect
know to use the aggregate table rather than the base fact
table, when either could provide the answer to a query? The
answer is logical table size.
The size of tables in a project: Logical table size
MicroStrategy Desktop assigns a size to every table in the
project when you first add them to the project. These size
assignments are stored in the metadata and are calculated
based on the table columns and their corresponding
attributes. Because Desktop uses the conceptual or logical
attribute definitions when assigning sizes, this measurement
is known as the logical table size.
When you run a report, the Analytical Engine chooses the
smallest of all tables, based on logical table size, that contains
enough data to answer the query.
Changing the logical table size
The initial logical table size is based on the number of
attribute columns and the various levels at which they exist in
their respective hierarchies. Suppose the base fact table
contains millions of rows of transaction-level detail. The
other tables, however, have only higher-level or summary
data. Because the attribute levels are lower in the base fact
© 2007 MicroStrategy, Inc.
Using summary tables to store data: Aggregate tables
249
8
Optimizing and Maintaining Your Project
Project Design Guide
table, the table as a whole is assigned a higher value for the
logical table size than are the summary tables with
higher-level attributes.
Logically, a table with a higher-level attribute should be
smaller in size. Of course, this is not always true in a real
warehouse. Therefore, the Logical Table Editor allows you to
alter the logical table sizes based on their true relative sizes.
For steps to use the Logical Table Editor, see the
MicroStrategy Desktop online help. Logical tables are
discussed in detail in Appendix C, Logical Tables.
Dividing tables to increase performance:
Partition mapping
Partition mapping involves the division of large logical tables
into smaller physical tables; this division is based on a
definable data level, such as month or department. Partitions
improve query performance by minimizing the number of
tables and records within a table that must be read to satisfy
queries issued against the warehouse. By distributing usage
across multiple tables, partitions improve the speed and
efficiency of database queries.
Time is the most common category for partitioning
databases. Partitioning by time limits growth of the database
tables and increases stability.
Server versus application partitioning
Partitioning can be managed by either the database server or
the MicroStrategy application. Either way, tables are
partitioned at the database level. The terms “application” and
“server” refer to what manages the partitioned tables, not
where the tables are split.
250 Dividing tables to increase performance: Partition mapping
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
Server-level partitioning
The database server, rather than MicroStrategy, manages the
partitioned tables in RDBMS server-level partitioning. The
original fact table is not physically broken into smaller tables.
Instead, the database server logically partitions the table
according to parameters specified by the database
administrator. You do not need to take any action in
MicroStrategy to support the partitioning.
Since only the logical table is displayed to the end user, the
partitioning is transparent to MicroStrategy. In contrast, in
application-level partitioning the relational database is
unaware of the partitioned tables.
Refer to your database documentation for details on server
partitioning for your particular platform.
Application-level partitioning
In application-level partitioning the application, rather than
the RDBMS server, manages the partition tables. A partition
base table (PBT) is a warehouse table that contains one part
of a larger set of data. Partition tables are usually divided
along logical lines, such as time or geography. MicroStrategy
supports two types of partitioning:
•
Metadata partition mapping, page 251—stores the
mapping information in the project metadata
•
Warehouse partition mapping, page 254—uses a
specialized warehouse table to determine which table to
access
Metadata partition mapping
Metadata partition mapping is the mapping of partitions
where the mapping of partitions is performed and
maintained in the project metadata by the application, in this
case, MicroStrategy. MicroStrategy manages the mapping
between the logical table and the physical tables. This
approach makes it easier for you to specify a flexible
partitioning schema.
© 2007 MicroStrategy, Inc.
Dividing tables to increase performance: Partition mapping
251
8
Optimizing and Maintaining Your Project
Project Design Guide
In metadata partition mapping, you specify one or more
partitioning attributes in the Metadata Partition Mapping
Editor. Next you define what attribute elements within those
attributes should point to which PBT. You create all of the
rules for choosing the appropriate PBT here and the rules are
stored in the MicroStrategy metadata.
For steps to create a metadata partition mapping, refer to the
MicroStrategy Desktop online help.
Homogenous and heterogeneous partitions
Metadata partitions can be homogenous or heterogeneous.
With heterogeneous partitioning, the PBTs can have different
amounts of data stored in them at different levels. For
example, one table can contain six months of sales data, while
another stores an entire year. The PBT level, or key, refers to
how the data is stored. For example, sales data for the current
year can be stored at the daily level, while historical sales data
is saved by month only. Heterogeneous partitions can
therefore require additional long-term maintenance and
organization because the data contained in them is stored at
various levels throughout the partition.
MicroStrategy stores one PBT level for each partition. If all
the PBTs within a partition are not stored at the same level,
the highest PBT level is used as the PBT level of the partition.
For instance, if all the sales data in the previous example is
stored in one partition, you cannot access current sales at the
day level. This is because the PBT level for the partition is
month, which is higher than day. If you save current data in a
partition at the daily level and the historical data in another
partition at the month level, you are able to fully access the
data.
In contrast, homogenous partitions must have the same
amount of data stored at the same PBT level. The logical
structure of the PBTs must be the same, that is, they must
have the same facts and attributes defined. To continue with
the previous examples, each table must store one year of data
at the month level. Homogeneous partitions work well for
frequently-accessed data such as information about the
previous year.
252 Dividing tables to increase performance: Partition mapping
© 2007 MicroStrategy, Inc.
Project Design Guide
8
Optimizing and Maintaining Your Project
When you define the particular PBT to which an attribute is
linked in MicroStrategy, you do not need to specify whether
or not the PBT is homogeneous or heterogeneous.
MicroStrategy makes the distinction automatically
depending, in part, on how the data is stored in the PBT.
Data slices
After PBTs are created, you define a data slice. The data slice
acts as a filter that describes what portions of data are placed
in the partition table. Based on this data slice, the
MicroStrategy engine knows which table to get data from
when generating the SQL.
A data slice holds the parameters that a partition is based
upon, for example, Month=January. Instead of retrieving
data for all months, the server knows to access a particular
table that contains the data for January only. By creating a
data slice with the partition, you can retrieve specific data
quickly without time-consuming joins and searches.
It is important to create a reasonable and valid data slice
because MicroStrategy cannot verify its accuracy or
relevance. The data slice must make sense for the data. A
poorly crafted data slice can lead to errors from generating
incorrect SQL and retrieving the wrong data.
Data slicing displays and can be modified only for the
metadata partitioning. Each partition mapping table must
include at least one data slice. In a heterogeneous mapping,
data slices can exist at different levels and can be composed
of different keys.
Attribute qualifications
To create data slices, you use attribute qualifications.
Attribute qualifications are types of filters that are applied to
attribute forms. These qualifications allow you to limit the
type and amount of data that is returned for a report. For
example, if you create a report that contains the attribute
Country but you want to return only the data for France, you
can create a qualification on the attribute Country and select
France as the element that appears on the report.
© 2007 MicroStrategy, Inc.
Dividing tables to increase performance: Partition mapping
253
8
Optimizing and Maintaining Your Project
Project Design Guide
For steps to create a data slice, refer to the MicroStrategy
Desktop online help.
Warehouse partition mapping
Warehouse partition mapping is the mapping of partitions,
where the mapping is performed by and maintained in the
data warehouse. You can define a warehouse partition by
using the MicroStrategy Warehouse Catalog to add a table
with a special structure. This table contains the map for the
partition, and is stored in the warehouse. Warehouse
partitions divide tables physically along any number of
attributes, although this is not visible to the user.
Warehouse partitions must be homogenous, unlike metadata
partitions, so that the same amount of data is stored at the
same PBT level and the same facts and attributes are defined.
Homogenous partitioning divides data of equal levels, like
January and February. A sample fact table and warehouse
partitioning table are shown below for months. Note how the
data exists at equal levels, for example, different months of
the same year.
The original fact table, which contains all of the data, is not
brought into the project. Rather, the database administrator
creates multiple smaller physical tables in the data
warehouse. Each table contains a subset of the data in the
original fact table. The database administrator is responsible
for keeping the partitions consistent and up-to-date. He or
254 Dividing tables to increase performance: Partition mapping
© 2007 MicroStrategy, Inc.
Project Design Guide
Optimizing and Maintaining Your Project
8
she must also create and maintain a partition mapping table
(PMT), which is used to identify and keep track of the
partitioned base tables as part of a logical whole.
After the PMT is created, when you run a report in Desktop or
Web that requires information from one of the PBTs, the
Query Engine first runs a pre-query to the PMT to determine
which PBT to access to bring the data back for the report. The
pre-query requests the PBT names associated with the
attribute IDs from the filtering criteria. When it finds the
name of the PBT, it calls the SQL Engine to write the
appropriate SQL for the warehouse.
using warehouse partition mapping, it is usually
When
not necessary to bring in the individual PBT tables into
the project. Doing so can cause errors if such tables are
mistakenly mapped directly to schema objects. You
should only include the PMT table in the project. With
this strategy you can map all related schema objects to
the PMT, which then accesses the correct PBT in the
warehouse.
Note the following:
•
There are no data slices in a warehouse partition.
•
MicroStrategy supports warehouse partitions on
both upgraded and newly created projects. These
are added using the Warehouse Catalog Browser.
For steps to add warehouse partitions, refer to the
MicroStrategy Desktop online help.
Metadata versus warehouse partition mapping
Metadata partition mapping does not require any additional
tables in the warehouse. Metadata partition mapping is
generally recommended over warehouse partition mapping
in MicroStrategy. However, if you already have warehouse
partition tables set up and are migrating to a newer version of
MicroStrategy, you can continue to use the warehouse
partitions. If you are creating partitions for the first time,
however, it is recommended you implement metadata
partition mapping.
© 2007 MicroStrategy, Inc.
Dividing tables to increase performance: Partition mapping
255
8
Optimizing and Maintaining Your Project
Project Design Guide
Metadata partition mapping is recommended because you
create the rules in MicroStrategy that the Query Engine uses
to generate the SQL to run reports. Because you create the
partitions directly in the metadata, it is easier to maintain.
Metadata partition mapping also allows both heterogeneous
and homogenous partitions, unlike warehouse partition
mapping. With heterogeneous partitions, the PBTs can have
different amounts of data stored in them at different levels.
Only homogenous partitions can be used in warehouse
partition mapping. For steps to map partitions, refer to the
MicroStrategy Desktop online help.
256 Dividing tables to increase performance: Partition mapping
© 2007 MicroStrategy, Inc.
9
9.
CREATING TRANSFORMATIONS
TO DEFINE TIME-BASED AND
OTHER COMPARISONS
Introduction
Suppose you want to compare how much revenue your
company grew last year to how much it grew this year. This
type of analysis, called a TY/LY comparison (This Year versus
Last Year), is a commonly used form of time-series analysis
and is relevant to many different industries, including retail,
banking, and telecommunications.
Transformations—schema objects you can create using
attributes in your project—are one of the many MicroStrategy
techniques used to perform time-series analysis.
To calculate a variance or a growth percentage such as last
year’s revenue versus this year’s revenue, it is very convenient
to use a transformation. Transformations are often the most
generic approach and can be reused and applied to other
time-series analyses. To use a transformation, a report
designer creates a metric and applies the transformation to it.
This chapter discusses the different types of transformations
and how to create them. It is assumed that you have some
understanding of what metrics are, as transformation metrics
© 2007 MicroStrategy, Inc.
257
9
Creating Transformations to Define Time-Based and Other Comparisons
Project Design Guide
are discussed in this chapter. For information on metrics and
using transformations in metrics and reports, see the Metrics
chapter of the MicroStrategy Advanced Reporting Guide.
Creating transformations
A transformation is a schema object that typically maps a
specified time period to another time period, applying an
offset value, such as current month minus one month.
Usually defined by a project designer, transformations are
used in the definition of a metric to alter the behavior of that
metric. Such a metric is referred to as a transformation
metric. For example, time-related transformations are
commonly used in metrics to compare values at different
times, such as this year versus last year or current date versus
month-to-date. Any transformation can be included as part of
the definition of a metric and multiple transformations can
be applied to the same metric. Transformation metrics are
beyond the scope of this guide; for information about
transformation metrics, refer to the MicroStrategy Advanced
Reporting Guide.
Recall the example used in the introduction, the TY/LY
comparison. To calculate this year’s revenue, you can use the
Revenue metric in conjunction with a filter for this year.
Similarly, to calculate last year's revenue, you can use the
Revenue metric in conjunction with a filter for last year.
However, a more flexible alternative is to use a previously
created Last Year transformation in the definition of a new
metric, last year’s revenue. With a single filter, on 2003 for
example, the two metrics Revenue and Last Year Revenue
give you results for 2003 and 2002, respectively.
Since a transformation represents a rule, it can describe the
effect of that rule for different levels. For instance, the Last
Year transformation intuitively describes how a specific year
relates to the year before. It can in addition express how each
month of a year corresponds to a month of the prior year. In
the same way, the transformation can describe how each day
of a year maps to a day of the year before. This information
defines the transformation and abstracts all cases into a
258 Creating transformations
© 2007 MicroStrategy, Inc.
Project Design Guide
9
Creating Transformations to Define Time-Based and Other Comparisons
generic concept. That is, you can use a single metric with a
last year transformation regardless of the time attribute
contained on the report.
While transformations are most often used for discovering
and analyzing time-based trends in your data, not all
transformations have to be time-based. An example of a
non-time-based transformation is This Catalog/Last Catalog,
which might use Catalog_ID-1 to perform the
transformation.
Expression-based versus table-based transformations
The definition of the association between an original value
and a transformed one can be represented in an expression
that uses columns of the warehouse, constants, arithmetic
operators, and mathematical functions. This is known as an
expression-based transformation. However, it is sometimes
desirable to precalculate these values and store them in a
table designed for the transformation. This method is
sometimes referred to as a table-based transformation.
The advantage of a table-based transformation is the possible
use of indexing to speed query times. Another advantage is
that table-based transformations provide additional
flexibility beyond what formula expressions can produce. The
drawback of this kind of transformation is that it requires the
creation and management of an additional table in the
warehouse. However, once the table is created, it usually
significantly decreases the query time. Returning to the
TY/LY example, you have the option of using a simple
formula such as Year_ID - 1 in the definition of the
transformation or precalculating the data and storing it in a
column in a table.
table-based transformation is required when a
Amany-to-many
transformation is performed. An
example is a year-to-date calculation.
A significant advantage to the dynamic calculation of an
expression-based transformation is that the database
administrator does not have to create and maintain a
transformation table. The drawback is that the system must
perform the calculation every time.
© 2007 MicroStrategy, Inc.
Creating transformations
259
9
Creating Transformations to Define Time-Based and Other Comparisons
Project Design Guide
A single transformation can use a combination of table-based
and expression-based transformations. For example, you can
create a last year transformation based on Year and Month.
The ID of the Year attribute is in the format YYYY, so the
transformation can use the expression Year_ID - 1. The ID
for the Month attribute is in the format ‘MonthName,’ so you
cannot easily use a mathematical expression. You must use a
table instead. The following sections walk you through
creating both a table-based transformation and an
expression-based one.
Building a table-based transformation
The following example shows how to create a last year
transformation based on a lookup table in MicroStrategy
Tutorial, which pairs each year with the previous year. This
transformation is used in the report displayed below, which
compares revenue for this year and last year.
the transformation metric and the report are
Creating
discussed in the Transformation metrics section in
the Metrics chapter of the MicroStrategy Advanced
Reporting Guide.
260 Creating transformations
© 2007 MicroStrategy, Inc.
Project Design Guide
9
Creating Transformations to Define Time-Based and Other Comparisons
To create a last year transformation based on a table
1 Log in to the project source that contains your project in
MicroStrategy Desktop and expand your project.
2 From the File menu, point to New, and select
Transformation. The Transformation Editor opens with
the Select a Member Attribute dialog box displayed.
3 Double-click Time to open the folder, then double-click
Year. The Year - Define a new member attribute
expression dialog box opens.
4 Select the LU_Year table from the Table drop-down list.
The table's columns appear in the Available columns list.
Notice that this table contains a previous year column,
which maps this year to last year.
5 Double-click the PREV_YEAR_ID column to place it in
the expression box.
6 Click OK.
7 Click Save and Close on the toolbar. Name the
transformation Last Year (Table).
You have now created the transformation. A report designer
can now use the transformation in a revenue metric to
calculate last year’s revenue, then create a report using that
transformation metric to obtain last year’s revenue.
Building an expression-based transformation
This example shows how to create a last year transformation
using an expression rather than a table. The Year_ID is in the
format YYYY, so the previous year is simply Year_ID minus
one. For example, one subtracted from the year 2005 results
in the previous year, 2004.
© 2007 MicroStrategy, Inc.
Creating transformations
261
9
Creating Transformations to Define Time-Based and Other Comparisons
Project Design Guide
This transformation is added to the report shown in the
table-based transformation example above. The resulting
report is displayed below.
creating the transformation metric and the
Again,
report are discussed in the Transformation metrics
section in the Metrics chapter of the MicroStrategy
Advanced Reporting Guide.
To create a last year transformation based on an expression
1 In MicroStrategy Desktop, from the File menu, point to
New, and select Transformation. The Transformation
Editor opens with the Select a Member Attribute dialog
box displayed.
2 Double-click Time to open the folder, then double-click
Year. The Year - Define a new member attribute
expression dialog box opens.
3 Select the LU_Year table from the Table drop-down list.
The table's columns appear in the Available columns list.
4 Double-click the YEAR_ID column to place it in the
expression box.
5 Type -1 in the expression box. The transformation will
subtract 1 from the Year ID to calculate last year’s ID.
262 Creating transformations
© 2007 MicroStrategy, Inc.
Project Design Guide
9
Creating Transformations to Define Time-Based and Other Comparisons
6 Click Validate. The message “Valid expression” appears
with a green check mark.
7 Click OK.
8 Click Save and Close on the toolbar. Name the
transformation Last Year (Expression).
You have now created the last year transformation. A report
designer can now use the transformation in a revenue metric
to calculate last year’s revenue, then add it to the report
created in the previous example.
Transformation components
All transformations have the following components:
•
Member attributes: This component contains the
attributes to which the transformation applies, that is, the
different levels to which the rule applies.
For example, in the Last Year transformation in the
MicroStrategy Tutorial, the member attributes are Year,
Quarter, Month, and Day.
•
•
© 2007 MicroStrategy, Inc.
Member tables: These tables store the data for the
member attributes.
For an expression-based transformation, each
member expression is based on a specific table,
generally the lookup table corresponding to the
attribute being transformed.
For a table-based transformation, this is the
transformation table defining the relationship. For
example, in the Last Year transformation, the member
tables are LU_YEAR, LU_QUARTER, LU_MONTH,
and LU_DAY, for the member attributes Year,
Quarter, Month, and Day, respectively.
Member expressions: Each member attribute has a
corresponding expression.
Transformation components
263
9
Creating Transformations to Define Time-Based and Other Comparisons
Project Design Guide
For an expression-based transformation, this is a
mathematical expression. In the most generic case,
this expression uses constants, arithmetic operators,
mathematical functions, and columns from the
warehouse, typically the attribute ID column.
For example, you can create a Last Year
transformation using Year_ID-1 as the expression.
However, many cases can exist where the data is not
conducive to such calculation. For instance, if you
store Month as 200001 (January 2000), you cannot
subtract one and receive December 1999 as the result.
For a table-based transformation, this is simply a
column from a specific warehouse table specifically
populated with data supporting the transformation.
The rule is then not encapsulated in an expression but
directly in the data of the column. Since the data
defines the rule, this approach provides considerable
flexibility in the transformation definition. It is
particularly effective when no straightforward formula
can express the rule. In fact, in the case of a
many-to-many transformation, a separate table is
required.
For example, in the Last Year transformation, the
member expressions are LY_DAY_DATE,
LY_MONTH_ID, LY_QUARTER_ID, and
PREV_YEAR_ID. These are all columns from the
lookup tables set in the Member tables field.
•
Mapping type: This component determines how the
transformation is created based on the nature of the data.
The mapping can be one of the following:
One-to-one: A typical one-to-one relationship is “last
year to this year.” One day or month this year maps
exactly to one day or month from last year.
Many-to-many: A typical many-to-many relationship
is year-to-date. For one date, many other dates are
included in the year-to-date calculation.
transformations can lead to
Many-to-many
double-counting scenarios. For example, consider
YearToDate defined as a many-to-many
transformation and Revenue (YTD) as a
transformation metric. Suppose this metric is used on
264 Transformation components
© 2007 MicroStrategy, Inc.
Project Design Guide
Creating Transformations to Define Time-Based and Other Comparisons
9
a report that does not include the Day attribute, which
is the member attribute on the template. In the report,
a range of dates is specified in the filter. In this
instance, the Revenue (YTD) metric will double count.
Transformation metrics and joint child
attributes
the discussion of joint child attributes and
Review
relationships in Joint child relationships, page 171
before proceeding in this section.
In a report, a transformation metric displays the current
attribute with transformed data, that is, the values for the
transformation. For example, a report contains Quarter and
the transformation metric Last Year’s Revenue. Each quarter
is displayed, with the previous year’s revenue, as shown
below:
When a joint child attribute—an attribute that exists at the
intersection of other indirectly related attributes—is added, a
conflict arises.
For more information about joint child attributes, see Joint
child relationships, page 171.
For example, the joint child attribute Promotion is added to
the previous report. The joint child attribute cannot be
transformed because not all of its joint children—Quarter and
Item—are time-related. The report displays the quarter, the
© 2007 MicroStrategy, Inc.
Transformation metrics and joint child attributes
265
9
Creating Transformations to Define Time-Based and Other Comparisons
Project Design Guide
promotion associated with a given quarter, and the revenue
data from the date-promotion combination, minus one year.
A sample report is shown below:
The displayed attributes should still be current, displaying
transformed data. However, since the joint child attribute
Promotion essentially exists in both the time dimension and a
non-time dimension, it is not intuitive how the
transformation should be performed.
Notice that the Valentine’s Day promotion existed in 2003
but not in 2002. While you may want to see it listed for 2002,
remember that only the metric values are transformed, not
the attributes. That is, since the Valentine’s Day promotion
was not run in 2002, the Valentine’s Day-Q1 2002
combination cannot be displayed on the report. In summary,
the Valentine’s Day promotion is not listed for Q1 2002
despite the existence of the last year transformation. This is
the case because, again, transformations “transform” metric
values such as Revenue, but not attributes such as
Promotion.
266 Transformation metrics and joint child attributes
© 2007 MicroStrategy, Inc.
A
A.
MICROSTRATEGY TUTORIAL
Introduction
This appendix provides information on the MicroStrategy
Tutorial, including the data model and physical warehouse
schema.
What is the MicroStrategy Tutorial?
The MicroStrategy Tutorial is a MicroStrategy project, which
includes a metadata and warehouse, and a set of
demonstration applications designed to illustrate the features
of the MicroStrategy platform.
A project is the highest-level of intersection of a data
warehouse, metadata repository, and user community.
Conceptually, the project is the environment in which all
related reporting is done. A typical project contains reports,
filters, metrics, and functions. You create projects that users
access to run reports.
© 2007 MicroStrategy, Inc.
What is the MicroStrategy Tutorial?
267
A
MicroStrategy Tutorial
Project Design Guide
The theme of the MicroStrategy Tutorial project is a retail
store for the time 2003 to 2006 that sells electronics, books,
movies and music. The key features include the following:
•
Hierarchies—Customer, Geography, Products,
Promotions, and Time. Each hierarchy can be viewed
graphically through MicroStrategy Desktop and
MicroStrategy Web.
•
Numerous customers and purchased items.
•
Reporting areas: Customer Analysis, Enterprise
Performance Management, Human Resources Analysis,
Inventory and Supply Chain Analysis, Sales and
Profitability Analysis, and Supplier Analysis.
•
Options to create reports from MicroStrategy Desktop
and MicroStrategy Web focusing on a particular analysis
area, such as Customer, Inventory, Time, Products,
Category, Employee, or Call Center.
MicroStrategy Tutorial reporting areas
MicroStrategy Tutorial reports are grouped into four folders:
•
Business Roles: This folder contains subfolders that
reflect different types of business intelligence users within
an organization, including Billing Managers, Brand
Managers, Category Managers, Company Executives,
District Sales Managers, Operations Managers, Regional
Sales Managers, and Suppliers.
Each subfolder contains reports that would be of interest
to the type of business user for which the subfolder is
named. For instance, the Billing Managers folder
contains an Invoice report and a customer-level
transaction detail report. The Supplier folder contains a
Supplier Sales report, and the Brand Managers subfolder
contains a report called Brand Performance by Region.
•
Enterprise Reporting Documents: This folder contains
various examples of different types of standard enterprise
reporting documents, such as scorecards and dashboards,
managed metrics reports, production and operational
reports, invoices and statements, and business reports.
They are a sampling of the types of reporting documents
that can be built using MicroStrategy Report Services.
268 What is the MicroStrategy Tutorial?
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
•
MicroStrategy Platform Capabilities: This folder
contains examples of many of the sophisticated
capabilities within the MicroStrategy platform. Evaluators
of the software, as well as customers, can use the
examples to get a better feel for many of the platform’s
capabilities. Customers can use the examples to guide
their own development.
The subfolders under these folders are named according
to the capabilities that their reports exemplify. For
instance, the Graph Styles folder contains examples of
most of the graph types that can be created in
MicroStrategy, and the Analytics and Data Mining
folder contains examples of Linear Regression models
built within MicroStrategy.
•
© 2007 MicroStrategy, Inc.
Subject Areas: This folder contains reports that are
categorized further by topic. Topics covered include
Customer Analysis, Enterprise Performance
Management, Human Resource Analysis, Inventory and
Supply Chain Analysis, Sales and Profitability Analysis,
and Supplier Analysis.
Customer Analysis: Reports analyzing the customer
base, studying areas such as Customer Income,
Customer Counts, Revenue per Customer, and
Revenue Growth.
Enterprise Performance Management: Reports
containing information on revenue amounts, trends
and forecasts, profits, profit margins, and profit
forecasts. These reports make it easy for an executive
at any level of the company to understand how the
company is performing as a whole or at the region,
category, and subcategory levels.
Human Resource Analysis: Reports containing
information on employees, including headcount,
birthdays, length of employment, and the top five
employees by revenue. These reports are based on
employees, time, geography, and sales. The Human
Resources Analysis reports provide insight into
human capital so that managers can boost the
efficiency and effectiveness of their employees.
Human Resource Representatives can highlight
under-performing employees and misallocated
headcount. Managers at all levels can focus on the
What is the MicroStrategy Tutorial?
269
A
MicroStrategy Tutorial
Project Design Guide
performance of their employees, drill down to an
individual employee detail level, view trends, and
extract intelligence not otherwise evident.
Inventory and Supply Chain Analysis: Reports
containing information based on supplier, product,
cost, revenue and profit, such as Inventory and Unit
Sales, or Inventory Received from Suppliers by
Quarter. The Inventory reports track inventory
information within the company and through to
suppliers. Essentially, these reports show how many
units of an item are on hand, how many are expected
from a particular supplier, and how many units have
been sold. Inventory reports are used to ensure that
the supply chain is as efficient as possible. Using these
reports, employees can analyze trends and details,
quickly adjust inventory and distribution, and
understand underlying supply chain costs and
inefficiencies.
Sales and Profitability Analysis: Reports analyzing
revenue and profit from multiple perspectives.
Examples include Sales by Region, Revenue over
Time, and Brand Performance by Region. The Product
Sales reports allow managers and analysts to monitor
and analyze sales trends, track corporate revenue
goals, compare store-to-store performance, and
respond more quickly and accurately to feedback from
the marketplace. In turn, executives can analyze sales
trends and details, quickly adjust pricing and
promotions, identify product affinities and key profit
centers, and understand costs and revenue trends.
Supplier Analysis: Reports containing supplier,
sales, profit, and revenue information, such as Brand
Sales by Supplier, Supplier Sell-Through Percentage,
and Units Sold and Profit by Supplier. The Supplier
reports allow managers and analysts to monitor and
analyze vendor performance so that they can quickly
identify performance problems. These reports track
brands and items sold that came from a particular
vendor. They also correlate profit and revenue
information with particular suppliers so that
relationships with key vendors can be strengthened.
270 What is the MicroStrategy Tutorial?
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
These reports and documents are located in the Public
Objects/Reports folder of the MicroStrategy Tutorial
project.
Once the areas of analysis are determined, a data model is
created.
MicroStrategy Tutorial data model
A logical data model graphically depicts the flow and
structure of data in a business environment. It provides a way
of organizing facts so that they can be analyzed from different
business perspectives. For example, a simple logical data
model for a retail company can organize all necessary facts by
store, product, and time, which are the three common
business perspectives typically associated with retail
business.
For detailed information about data modeling, see Chapter 2,
The Logical Data Model.
For MicroStrategy Tutorial, the areas of analysis discussed
earlier, Customer Analysis, Human Resources Analysis, and
so on, are organized into the following hierarchical
groupings:
•
Geography
•
Products
•
Customers
•
Time
•
Promotions
These MicroStrategy Tutorial hierarchies are displayed on
the following pages for your reference.
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial data model
271
A
MicroStrategy Tutorial
Project Design Guide
Data modeling notations
The following notations are used in graphical depictions of
hierarchies.
Symbol
Indicates
Definition
entry point
An entry point is a shortcut to an attribute element in the Data Explorer.
Creating an entry point grants you faster access to the attribute without
having to browse through multiple attributes to reach different levels of
the hierarchy.
attribute
A data level defined by the system architect and associated with one or
more columns in the data warehouse lookup table. Attributes include
data classifications like Region, Order, Customer, Age, Item, City, and
Year. They provide a handle for aggregating and filtering at a given
level.
one-to-many
relationship
An attribute relationship in which every element of a parent attribute
relates to multiple elements of a child attribute, while every element of
the child attribute relates to only one element of the parent. The
one-to-many attribute relationship is the most common in data models.
Geography hierarchy
The Geography hierarchy contains attributes, such as
Country and Region, as well as Distribution Center, Call
Center, and employee-specific attributes. It is easy to
understand why Country and Region are in the Geography
hierarchy, but what about Distribution Center, Call Center,
and the employee-related attributes?
The data used in MicroStrategy Tutorial is based upon a
fictitious company that sells electronics, movies, music, and
books. The company does not have physical stores, but
instead does its business from catalog and Web sales.
Customers review the products in a printed or online catalog
and call in their order over the phone. The order is then
processed by an employee located at one of the call centers.
The order is then fulfilled by a distribution center that holds
the correct item and sends it through one of the shippers.
272 MicroStrategy Tutorial data model
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
The Geography hierarchy contains the following attributes.
Attribute
Description
Example
Country
Countries where the company does or hopes to do business in
the future. Also refers to countries where employees work.
USA, Spain, France.
Region
Each country is split into regions.
Central, Northeast,
Southwest.
Call Center
Where product phone-in orders are taken. Each call center is
located in a different city.
Atlanta, Boston,
Charleston.
Distribution
Center
The location where product orders are sent out to customers.
Currently, each is located in the same city as the call center it
services.
Miami, New Orleans,
Fargo.
Manager
Person responsible for a specific call center.
Peter Rose, Alice
Cooper.
Employee
Experience
The number of years an employee has worked for the
organization.
3, 5, 6.
Hire Date
The date on which a particular employee was hired.
2/16/97, 3/15/99.
Salary
The amount of money an employee makes per year.
24,000, 35,000.
Employee
Age
The age of each employee.
29, 36, 52.
Employee
Birth Date
The date each employee was born.
5/6/66, 1/1/77.
Employee
The lowest level in the Geography hierarchy, representing the
individual responsible for each order placed.
Jennifer Lee, Laura
Kelly.
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial data model
273
A
MicroStrategy Tutorial
Project Design Guide
Refer to the following image to see how all these attributes
are organized into the MicroStrategy Tutorial Geography
hierarchy.
Products hierarchy
The products hierarchy contains attributes, such as Category,
Brand, Catalog, and Supplier.
The Products hierarchy contains the following attributes.
Attribute
Description
Example
Category
Products are organized into categories at the highest level.
Electronics, Music.
Subcategory
Used to further differentiate a subset of products within a
category.
Business, Cameras,
Drama.
274 MicroStrategy Tutorial data model
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
Attribute
Description
Example
Warranty
The time period in months during which a manufacturer
repairs a broken item (specific to Narrowcast Server).
3, 5.
Brand
The manufacturer or artist for a particular product.
Ayn Rand, 3Com, Sony.
Catalog
The medium used to sell products.
Spring 2002, Fall 2003.
Supplier
The distributor for a set of brands.
McGraw Hill, Disney
Studios.
Discontinued
Code
0 = discontinued product, 1 = non-discontinued product.
0, 1
Item
The individual product sold.
The Great Gatsby, Sony
Discman.
Refer to the following image to see how all these attributes
are organized into the MicroStrategy Tutorial Products
hierarchy.
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial data model
275
A
MicroStrategy Tutorial
Project Design Guide
Customers hierarchy
The Customers hierarchy contains customer demographic
and purchase information, such as Customer Age, Income
Bracket, Payment Method, and Ship Date.
The Customers hierarchy contains the following attributes.
Attribute
Description
Example
Customer
Country
The highest level of differentiation for where
Customers live
USA, Spain, France
Customer
Region
The highest level of differentiation for where
customers live.
Northeast, South, France.
Customer State
Each Customer Region is divided into multiple
States.
Maine, North Dakota.
Customer City
Each Customer State is broken down into cities.
Albany, Chicago, Memphis.
Customer Age
The age of a particular customer at a current point in
time.
26, 38, 59.
Customer Birth
Date
The date on which the Customer was born.
8/4/50, 4/30/72.
Income Bracket
The salary range reported by the customer.
$31,000 - 40,000, $61,000 70,000.
Zip Code
The lowest level of differentiation for where
customers live.
07026, 36303.
Customer
The name of the individual customer.
Selene Allen, Chad Laurie.
Shipper
The vendor used to send products to the customer.
Pronto Packages, MailFast.
Rush Order
(Currently not implemented in the project.) Indicates
whether a customer chose to expedite delivery of an
order.
Payment
Method
The way a customer pays for an order.
Amex, Check.
Ship Date
The date on which an order is shipped from the
distribution center.
9/15/02, 3/26/03.
Order
The tracking number associated with a particular
group of items purchased.
167, 2635.
276 MicroStrategy Tutorial data model
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
Refer to the following image to see how all these attributes
are organized into the MicroStrategy Tutorial Customers
hierarchy.
Time hierarchy
The Time hierarchy contains time-specific attributes, Year,
Quarter, Month, and Day.
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial data model
277
A
MicroStrategy Tutorial
Project Design Guide
The Time hierarchy contains the following attributes.
Attribute
Description
Example
Year
Calendar year of purchase.
2002, 2003.
Quarter
Calendar quarter of purchase.
Q2 02, Q3 03.
Month of Year
Calendar month of purchase.
January, November.
Month
Month of purchase.
Jul 02, Aug 03.
Day
Calendar date of purchase.
5/14/02, 12/26/03.
Refer to the following image to see how all these attributes
are organized into the MicroStrategy Tutorial Time
hierarchy.
Promotions hierarchy
The Promotions hierarchy contains Promotion and
Promotion Type. This hierarchy is useful for recording
whether a sale was a promotional purchase.
278 MicroStrategy Tutorial data model
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
The Promotions hierarchy contains the following attributes.
Attribute
Description
Example
Promotion Type
(Currently not implemented in the project.) Type of
discount period offered (Sale type).
Mother’s Day, Labor
Day.
Promotion
(Currently not implemented in the project.) Date range
for a particular discount period under which an item is
purchased (Sales Date).
9/1/02 - 9/4/02, 2/16/03 2/19/03.
Refer to the following image to see how all these attributes
are organized into the MicroStrategy Tutorial Promotions
hierarchy.
Viewing the MicroStrategy Tutorial data model
Although the MicroStrategy Tutorial data model is displayed
in the previous pages, you can also view it directly in the
product.
To view the MicroStrategy Tutorial data model
1 If you are not already using the MicroStrategy Tutorial,
log on to the project source containing the MicroStrategy
Tutorial and expand the MicroStrategy Tutorial project.
You must log on as an Administrator. Specify the user
name as Administrator and provide a blank password to
complete these steps.
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial data model
279
A
MicroStrategy Tutorial
Project Design Guide
2 From the Schema menu, point to Graphical View, and
then choose Hierarchies. Once loaded, the HierarchiesMicroStrategy Tutorial dialog box opens.
3 To view a different hierarchy, select it from the Hierarchy
drop-down list on the toolbar.
4 To focus on a different entry point, select it from the Entry
Point drop-down list in the toolbar.
5 To view the entire hierarchy in the window, click Fit in
window from the toolbar.
6 You can rearrange the attributes by dragging and
dropping them.
does not affect the browse order, but allows
This
you to view the hierarchy in a way meaningful to
you.
7 To return to the default view, click Auto arrange in the
toolbar.
8 To save the layout view of the hierarchy, click Save in the
toolbar. The next time you open the Hierarchy Viewer,
this saved view is displayed.
After the data model is created, the next step is to create the
schema.
MicroStrategy Tutorial schema
A schema is a logical and physical definition of warehouse
data elements, physical characteristics, and
interrelationships.
The logical data model is a picture of all the pieces of
information necessary to understand your data and how it
relates to your business. It is a graphic-intensive technique
that results in a data model representing the definition,
characteristics, and relationships of data in a business,
technical, or conceptual environment.
280 MicroStrategy Tutorial schema
© 2007 MicroStrategy, Inc.
Project Design Guide
MicroStrategy Tutorial
A
The physical warehouse schema is based on the logical data
model, such as Day, Item, Store, or Account. Several physical
warehouse schemas can be derived from the same logical
data model. While the logical data model tells you what facts
and attributes to create, the physical warehouse schema tells
you where the underlying data for those objects is stored. The
physical warehouse schema describes how your data is stored
in the data warehouse.
This appendix shows the physical warehouse schema,
including data types.
For more detailed information on the physical schema, refer
to earlier chapters in this guide.
The MicroStrategy Tutorial schema is divided into the
following parts:
•
Geography
•
Products
•
Customers
•
Time
•
Promotions
•
Fact tables
Schema notations
The following notations are used in the graphical depictions
of the MicroStrategy Tutorial schema.
Symbol
Indicates
LU_
a lookup table A database table used to uniquely identify attribute elements. They
typically consist of descriptions of dimensions. Lookup tables are
usually joined to fact tables in order to group the numeric facts in the
fact table by dimensional attributes in the lookup tables.
a primary key
© 2007 MicroStrategy, Inc.
Definition
In a relational database, the set of columns required to uniquely
identify a record in a table.
MicroStrategy Tutorial schema
281
A
MicroStrategy Tutorial
Project Design Guide
Symbol
Indicates
Definition
REL_
a relationship
table
While lookup tables store information about one or more attributes,
relate tables store information about the relationship between two
attributes. Relate tables contain the ID columns of two or more
attributes, thus defining associations between them.
PMT_
a partition
A warehouse table that contains information used to identify the
mapping table partitioned base tables as part of a logical whole. Also referred to as a
PMT.
schema also contains fact tables. A fact table is a
The
database table containing numeric data that may be
aggregated along one or more dimensions. Fact tables
may contain atomic or summarized data. The basic
facts from which all metrics in the MicroStrategy
Tutorial were created from are listed below.
Fact
Description
Cost
The total amount charged by the supplier to the company.
Discount
A monetary reduction made from a regular price.
End on hand
The number of individual items remaining at the close of each month.
Begin on hand The number of individual items available at the beginning of each month.
Freight
The compensation paid for the transportation of goods.
Profit
The excess of the selling price of goods over their cost.
Revenue
The total income produced by a given source accounting for all product sales deducting
discounts.
Rush Charge
The amount of money charged to expedite delivery service.
Unit Cost
The amount of money charged by the supplier to the company per individual item
purchased.
Unit Price
The amount of money charged by the company to the customer per individual item sold.
Unit Profit
Unit price - unit cost.
Units
Received
The number of individual items acquired from a supplier.
Units Sold
The number of individual items bought by customers.
282 MicroStrategy Tutorial schema
© 2007 MicroStrategy, Inc.
Project Design Guide
MicroStrategy Tutorial
A
Geography schema
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial schema
283
A
MicroStrategy Tutorial
Project Design Guide
Products schema
284 MicroStrategy Tutorial schema
© 2007 MicroStrategy, Inc.
Project Design Guide
MicroStrategy Tutorial
A
Customers schema
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial schema
285
A
MicroStrategy Tutorial
Project Design Guide
Time schema
286 MicroStrategy Tutorial schema
© 2007 MicroStrategy, Inc.
Project Design Guide
MicroStrategy Tutorial
A
Promotions schema
Sales fact tables
© 2007 MicroStrategy, Inc.
MicroStrategy Tutorial schema
287
A
MicroStrategy Tutorial
Project Design Guide
Inventory fact tables
Miscellaneous fact tables
288 MicroStrategy Tutorial schema
© 2007 MicroStrategy, Inc.
Project Design Guide
A
MicroStrategy Tutorial
Viewing the MicroStrategy Tutorial schema
Although the MicroStrategy Tutorial physical schema is
displayed in the previous pages, you can also view it or the
logical schema directly in the product.
To view the MicroStrategy Tutorial schema
1 If you are not already using the Tutorial, log in to the
project source containing the MicroStrategy Tutorial and
expand the MicroStrategy Tutorial project. You must
login as an Administrator to complete these steps.
2 From the Schema menu, point to Graphical View, and
then choose Tables. Once loaded, the TablesMicroStrategy Tutorial dialog box opens with the physical
view displayed.
3 To switch to the logical view, select View, then Logical
View.
4 To change display preferences for the physical view, use
the following options from the Options menu:
•
Show joins: Select whether to connect the tables to
represent the joins between the warehouse tables.
•
Use circular joins: Select whether to use circular
joins.
•
Show column data types: Select whether to show the
data type and size for each column.
•
Show table prefixes: Select whether to display the
table prefix as part of the table name.
5 To change display preferences for the logical view, use the
following options from the Options menu:
© 2007 MicroStrategy, Inc.
•
Show joins: Select whether to connect the tables to
represent the joins between the table columns.
•
Use circular joins: Select whether to use circular
joins.
MicroStrategy Tutorial schema
289
A
MicroStrategy Tutorial
Project Design Guide
•
Show relationships: Choose whether to map the
relationships between the tables.
•
Show relationship types: Choose whether to
differentiate between one-to-one, one-to-many,
many-to-one, and many-to-many relationships.
•
Show columns: Select whether to display the
warehouse columns that define each attribute, as a
link between the logical and physical views.
6 To switch back to the physical view, select View, then
Physical View.
7 To view the entire schema in the window, click the Fit in
window button on the toolbar.
8 You can rearrange the tables by dragging and dropping
them.
does not affect the relationships or joins, but
This
allows you to view the tables in a way meaningful
to you.
9 To return to the default view, click Auto arrange in the
toolbar.
10 To save the layout view of the tables, click Save in the
toolbar. The next time you open the Table Viewer, this
saved view is displayed.
11 To copy the layout view, select Copy as Metafile from the
File menu.
290 MicroStrategy Tutorial schema
© 2007 MicroStrategy, Inc.
B
CONNECTING TO OLAP CUBE
SOURCES
B.
SAP BW, Hyperion Essbase, and
Microsoft Analysis Services
Introduction
Many companies have both a data warehouse and an OLAP
cube source such as SAP Business Intelligence Warehouse
(SAP BW), Microsoft Analysis Services (Analysis Services), or
Hyperion Essbase (Essbase). This system setup requires an
integrated business intelligence (BI) solution, such as
MicroStrategy, that can concurrently access OLAP cube
sources and the data warehouse effectively.
This appendix describes how MicroStrategy Intelligence
Server integrates with these products using
MultiDimensional Expressions (MDX). The integration with
SAP BW uses SAP’s OLAP Business Application
Programming Interface (BAPI). Integration with Analysis
Services 2000, Analysis Services 2005, and Essbase uses
XML for Analysis (XMLA). Specifically, this appendix
discusses the following topics:
© 2007 MicroStrategy, Inc.
•
MicroStrategy integration with OLAP cube sources,
page 292
•
Understanding the SAP BW terminology, page 298
291
B
Connecting to OLAP Cube Sources
Project Design Guide
•
Relating objects from SAP BW to MicroStrategy,
page 302
•
Relating objects from Essbase to MicroStrategy,
page 311
•
Relating objects from Analysis Services 2000 to
MicroStrategy, page 317
•
Relating objects from Analysis Services 2005 to
MicroStrategy, page 322
•
Connecting to SAP BW servers, page 327
•
Connecting to Essbase servers, page 334
•
Connecting to Analysis Services 2000 servers, page 337
•
Connecting to Analysis Services 2005 servers, page 340
•
Integrating OLAP cubes into MicroStrategy, page 343
MicroStrategy integration with OLAP cube
sources
MicroStrategy provides a rich set of functionality ranging
from OLAP Services and Report Services to Narrowcast
capabilities, all of which can be exposed via a unified Web
interface. Using the MicroStrategy standard interface,
Intelligence Server can join data from different OLAP cube
sources, in addition to relational databases, and bring the
data into one single MicroStrategy project. These additional
OLAP cube sources include the following:
•
SAP BW 3.1 and 3.5 and SAP BI 7.0
version 7.0, SAP has renamed SAP BW to
With
SAP BI. MicroStrategy refers to SAP BW/SAP BI
OLAP cube sources as SAP BW.
•
Microsoft Analysis Services 2000
•
Microsoft Analysis Services 2005
•
Hyperion Essbase 7.1
292 MicroStrategy integration with OLAP cube sources
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
MicroStrategy’s support status with the OLAP
For
cube sources listed above, see the MicroStrategy
readme.
It is important to understand that the MicroStrategy
integration with OLAP cube sources does not change the
overall structure of the MicroStrategy product. Rather,
integration allows MicroStrategy to gain additional data
sources for analysis. In other words, each of these products is
simply another data warehouse that holds data for report
generation.
SAP BW obtains data from R/3, CRM, SEM, or another SAP
data source system. This data is stored in cubes or other SAP
objects. Likewise, Analysis Services and Essbase store data in
cubes obtained from various sources. To access the data, the
Intelligence Server generates MDX. Defined by Microsoft,
MDX is similar to SQL but is used to query cubes. An MDX
expression returns a multidimensional result set (dataset)
that consists of axis data, cell data, and properties data. For
more information on MDX syntax, refer to
http://msdn.microsoft.com/ and search for MDX.
With the SAP BW OLAP BAPI Certification on MicroStrategy
8.0, MicroStrategy Intelligence Server is certified to connect
and execute reports against SAP BW cubes. As SAP’s
proprietary API for accessing SAP BW data and functionality,
the OLAP BAPI provides an open interface through which
Intelligence Server can access the SAP BW data.
MicroStrategy has chosen to use the OLAP BAPI approach
because it is the most native interface that SAP provides.
With the Powered by Net Weaver Certification on
MicroStrategy 7i -7.5.3, MicroStrategy Web Universal is
certified to run on SAP Web Application Server, and
MicroStrategy Web and SDK are certified to run with SAP
Enterprise Portal through iView Packages.
The XMLA integration provides a Web Service interface for
OLAP and data mining functions. Version 1.1 of the
specification is available at www.xmla.org and is the basis
for the MicroStrategy implementation.
If you use OLAP cube sources and MicroStrategy as your
combined BI solution, you can get the best out of both
products, including the following:
© 2007 MicroStrategy, Inc.
MicroStrategy integration with OLAP cube sources
293
B
Connecting to OLAP Cube Sources
Project Design Guide
•
Access to OLAP cube sources and a regular data
warehouse
•
Five styles of BI
•
Custom development of reports and applications
•
Transaction-level analysis
•
Integration with other systems via Web Services
troubleshooting and diagnostics logging routines
For
related to OLAP cube sources, see the Troubleshooting
the System chapter of the MicroStrategy System
Administration Guide.
Understanding MicroStrategy architecture
The MicroStrategy platform offers OLAP Services, Report
Services, and Narrowcast Server functionality, all of which
can be accessed through MicroStrategy Web. Support for SAP
BW, Analysis Services, Essbase, Freeform SQL, and Query
Builder provides additional mechanisms for pulling data into
the MicroStrategy platform for analysis, as illustrated in the
following diagram.
For information on Freeform SQL and Query Builder
reporting, refer to the MicroStrategy Advanced Reporting
Guide.
Data is pulled from multiple OLAP cube sources using MDX
and operational systems using Freeform SQL or Query
Builder. Once the data is retrieved, it is treated in the same
294 MicroStrategy integration with OLAP cube sources
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
manner as data pulled from the relational data warehouse.
This means that core MicroStrategy capabilities are available
no matter what the original data source is.
To understand the current MicroStrategy architecture better,
it is helpful to review the basic object model of MicroStrategy
7i and how various data sources were accessed then.
Object model in MicroStrategy 7i
In the 7i metadata model, shown below, you could have
multiple MicroStrategy projects, each pointing to a data
warehouse, which was represented by the database instance.
One database instance could be referenced by multiple
projects in a configuration. Each project contained one
project schema that held the logical model for that project.
© 2007 MicroStrategy, Inc.
MicroStrategy integration with OLAP cube sources
295
B
Connecting to OLAP Cube Sources
Project Design Guide
When a report was executed, the SQL Engine would
implicitly reference the schema to determine which table(s)
should be queried.
In addition, a Report Services document can contain multiple
datasets, but the only source is the data warehouse.
Object model in MicroStrategy 8
The MicroStrategy 8 model shown below highlights how a
project can be extended to access OLAP cube sources through
a separate database instance. However, note that instead of
pointing to the project schema, each OLAP cube report points
directly to one cube in MicroStrategy, which is a logical
placeholder for a physical cube that exists in an OLAP cube
source. Each report can only reference one specific cube, due
to the structure in OLAP cube sources where queries can only
be run against one cube at a time. You can create multiple
reports to run against one cube, and a single MicroStrategy
project can reference multiple database instances, each of
which can represent a distinct OLAP cube source.
296 MicroStrategy integration with OLAP cube sources
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
The model also shows how you can include any number of
standard reports, Freeform SQL reports, Query Builder
reports, and OLAP cube reports in one Report Services
document. By bringing these different types of reports
together inside a document, report designers can create rich
reports and analytics that take advantage of data from both
data warehouses and OLAP cube sources. For information on
Report Services documents, refer to the MicroStrategy
Document Creation Guide. For information on Freeform SQL
and Query Builder reports, refer to the MicroStrategy
Advanced Reporting Guide.
Authentication
Most of the standard MicroStrategy platform authentication
features also apply to OLAP cube sources and OLAP cube
reports, described as follows:
© 2007 MicroStrategy, Inc.
MicroStrategy integration with OLAP cube sources
297
B
Connecting to OLAP Cube Sources
Project Design Guide
•
Standard authentication and LDAP authentication: are
supported independent of the data source that is being
used, for example, relational databases or OLAP cube
sources.
•
NT authentication: used for database logins are not
supported with OLAP cube sources. NT Authentication
can be used to authenticate the user to the Intelligence
Server, but not to the cube sources.
•
Connection mapping: is supported the same way as for
standard MicroStrategy reports. In addition, specific
connection mappings may be designated for each
database instance and user or group combination.
•
Warehouse pass-through authentication: is supported
in the same way as for relational data providers. If
multiple sources are configured for warehouse
pass-through execution, then the same login information
must be applicable to all sources.
enforce OLAP cube source security in
ToMicroStrategy,
it is recommended that you use
connection mapping or pass-through authentication.
For information on authentication in general, refer to the
MicroStrategy System Administration Guide.
Understanding the SAP BW terminology
Before looking in depth into how MicroStrategy integrates
with SAP BW, you need to be familiar with the terms that are
used to describe the SAP BW objects. Some of these terms are
provided in the following section. Further information is
provided later in this appendix on how the SAP BW objects
are related to those in the MicroStrategy environment. This is
explained in Relating objects from SAP BW to
MicroStrategy, page 302.
For a comprehensive and detailed explanation on SAP BW
objects, refer to your SAP documentation.
298 Understanding the SAP BW terminology
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
•
InfoObject: are the building blocks for individual cubes.
They include objects such as characteristics and key
figures, which are roughly equivalent to attributes and
facts in a MicroStrategy project.
•
InfoProvider: is a generic term defining all SAP BW data
structures available for reporting and analysis purposes
such as the following:
InfoCube: is a multi-dimensional cube, which is
described below.
ODS object: is an operational data store object. ODS
objects are flat relational tables and are similar to
MicroStrategy fact tables.
MultiProvider: is a logical union of two or more
InfoProviders that are used to combine data from two
different subject areas, for example, three InfoCubes
or two ODS objects.
•
InfoCube: is the primary object that SAP BW uses to store
data for analysis. InfoCubes define a specific domain of
analysis in special areas, for example, finance or sales.
Data is organized by dimension and stored physically in a
star schema. The fact table at the center of an InfoCube
contains the data available for analysis.
•
Query cube (or query): defines a subset of data from an
InfoCube or another InfoProvider. A query cube includes
characteristics (dimensions/attributes) and key figures
(metrics) from its source provider. The relationship
between the InfoCube and the query cube is very similar
to how a MicroStrategy report includes a subset of
modeled attributes and metrics that are available in the
data warehouse.
Query cubes generally offer better performance than
InfoCubes because they are smaller and can be scheduled
and cached within SAP BW. Query cubes also provide
MicroStrategy users access to additional InfoProviders
including ODS objects, InfoSets, and MultiProviders.
Any existing query can be released for analysis within
MicroStrategy. To release a query for analysis in
MicroStrategy, select the Allow External Access to This
Query check box under the Extended tab in the SAP
Query Properties dialog box in the Query Analyzer
© 2007 MicroStrategy, Inc.
Understanding the SAP BW terminology
299
B
Connecting to OLAP Cube Sources
Project Design Guide
interface. With this option enabled, designers can quickly
access existing query cubes and business content when
working in MicroStrategy.
•
Characteristic: provides classification possibilities for a
dataset, such as sales region, product, customer group,
fiscal year, and period. For example, a Sales Region
characteristic can have North, Central, and South
specifications.
SAP BW characteristics are similar to MicroStrategy
attributes. However, when each characteristic is
translated into a cube, it is treated as a separate
dimension for analysis. In addition, hierarchies can be
associated with a specific characteristic within SAP BW.
These hierarchies are also available when you work with a
cube in MicroStrategy.
BW also has an object called an attribute, but
SAP
it is equivalent to an attribute form in
MicroStrategy.
•
Key figure: describes numeric data, such as revenue,
profit, and number of call centers. There are five types of
key figures: amount, quantities, numbers, date, and time,
all of which can be used in InfoCubes, ODS objects, and
master data attributes. You can also create calculated key
figures and restricted key figures in the query definition in
the Business Explorer. This is similar to creating derived
metrics and conditional metrics within the MicroStrategy
environment.
•
Hierarchy: is a way of defining the relationships among
elements within a characteristic. For example, the Item
characteristic might have a hierarchy that includes
Category, Subcategory, and finally Item. This is a different
paradigm from MicroStrategy’s model where each
attribute defines its own level. However, as noted later,
when the levels of a hierarchy are viewed in
MicroStrategy, they are presented with the traditional
attribute-based parent-child relationships.
•
Variable: is used as a parameter of a query in SAP BW.
Defined in the Query Designer, variables can be of such
types as characteristic values, hierarchies, hierarchy
nodes, texts, and formulas. When the query is executed,
these variables are filled with values by the system or by
the user.
300 Understanding the SAP BW terminology
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
When an OLAP cube is imported into a MicroStrategy
project, all the variables in this cube are represented as
prompts. When the OLAP cube is used to create a
MicroStrategy report, the report inherits all those
prompts. In addition, standard prompts can also be
created for this report. For more information on variables,
see Supporting SAP BW variables, page 308.
When working in MicroStrategy, you will find a list of
available cubes for reporting, including all of the published
query cubes, InfoCubes, and MultiProviders. For
step-by-step instructions on how to create MicroStrategy
reports from the data in SAP BW cubes, refer to the
MicroStrategy Desktop online help.
Besides the above-mentioned terminology, you also need to
have a basic understanding of the SAP Query Designer, where
you define queries. You can select and combine InfoObjects
or reusable structures for an InfoProvider and specify the
view of the data (query view) by distributing them to filters,
rows, columns, and free characteristics. For more
information, refer to documentation provided by SAP BW.
© 2007 MicroStrategy, Inc.
Understanding the SAP BW terminology
301
B
Connecting to OLAP Cube Sources
Project Design Guide
Relating objects from SAP BW to MicroStrategy
As a Web or Desktop Analyst, you can treat SAP BW reports
as if they were standard MicroStrategy reports. However, if
you are a report designer, it is helpful to understand how
SAP’s metadata model is translated into MicroStrategy’s
metadata model.
The translation process involves the following steps:
1 From SAP BW to ODBO: SAP exposes its query cubes
and InfoCubes to Intelligence Server through the ODBO
model. ODBO stands for OLE database for OLAP and is a
protocol defined by Microsoft. ODBO defines an object
model that is used in conjunction with MDX to query
cubes. The ODBO model is similar to SAP’s standard
model, but not identical. Thus, when thinking about SAP
objects, keep in mind how those objects appear in ODBO.
302 Relating objects from SAP BW to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
2 From ODBO to MicroStrategy: After SAP objects are
translated into the ODBO model, they are then translated
into the MicroStrategy metadata model. You can then
interact with SAP content while working within the
paradigm that is consistent with the rest of
MicroStrategy’s products.
The following image demonstrates how SAP BW objects are
exposed in ODBO and then how they are related to objects in
the MicroStrategy environment.
The following sub-sections—each starting with a
table—describe each level of comparison from top to bottom
as shown in the above illustration.
SAP BW --->
ODBO --->
MicroStrategy
InfoCube
catalog
(catalog)
•
SAP BW: InfoCube
Each InfoCube that has queries associated with it is
exposed as a catalog in ODBO. Query cubes are accessed
through their respective InfoCube catalogs.
© 2007 MicroStrategy, Inc.
Relating objects from SAP BW to MicroStrategy
303
B
Connecting to OLAP Cube Sources
•
Project Design Guide
ODBO: Catalog
Catalogs are used to group cubes. Therefore, ODBO
catalogs are exposed in a few editors when selecting and
managing cubes.
•
MicroStrategy: (Catalog)
Each catalog includes one InfoCube and associated query
cubes, if any. Catalogs in MicroStrategy are represented in
a folder.
SAP BW --->
ODBO --->
MicroStrategy
N/A
schema
N/A
•
SAP BW: not supported
•
ODBO: schema
Schema in ODBO provides another grouping mechanism.
•
MicroStrategy: not supported
SAP BW --->
ODBO --->
MicroStrategy
InfoCube/
query cube
cube
cube
•
SAP BW: InfoCube/query cube
•
ODBO: cube
•
MicroStrategy: cube
A MicroStrategy cube is an object that is used to map the
levels of an SAP BW cube into the MicroStrategy
environment. Cubes are treated in a manner very similar
to tables in the MicroStrategy metadata. In the same way
that a regular table maps the physical columns of a
relational table to attributes and metrics, a MicroStrategy
cube maps the physical columns of an SAP BW cube to
attributes and metrics. The cube can be used to represent
InfoCubes, MultiProviders, and query cubes.
304 Relating objects from SAP BW to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
SAP BW --->
ODBO --->
MicroStrategy
characteristic
dimension
dimension
•
SAP BW: characteristic
Characteristics in SAP BW are similar to attributes in
MicroStrategy. For example, an InfoCube might include
the Month characteristic, which represents months just
like it does in MicroStrategy.
A characteristic appears as a dimension for MicroStrategy
users. Each characteristic (dimension) has at least one
hierarchy with two levels: the first level is an aggregate of
all the data, and the second level is the detailed data. A
characteristic can have any number of additional
hierarchies, each with an arbitrary number of levels. The
SAP BW characteristic hierarchies appear as hierarchies
to MicroStrategy users.
For example, you can build a Time hierarchy that is
attached to the Month characteristic. This hierarchy
defines a number of levels including Year, Quarter, and
Month. However, these same levels could either be
specifically defined as part of the hierarchy, or they could
be other characteristics that are used to define the levels
of this one hierarchy. For more information, see the
following sub-section.
in SAP BW are used to group
Dimensions
characteristics and are not exposed through the ODBO
interface. They can only be seen inside the SAP BEx
Query Designer when you build a query cube.
Shared dimensions allow a designer to use only one
definition for a dimension across multiple cubes. Each
characteristic in SAP is modeled as a dimension in
ODBO and is shared across cubes. Therefore, all
dimensions in cubes coming from SAP BW are shared.
•
ODBO: dimension
A dimension in ODBO defines a logical category of
analysis. For example, Time and Geography are
dimensions along which you can slice data.
© 2007 MicroStrategy, Inc.
Relating objects from SAP BW to MicroStrategy
305
B
Connecting to OLAP Cube Sources
Project Design Guide
Measures (metrics) are stored in a special measure
dimension. In this way, measures are simply one more
dimension of a cube.
Measures in ODBO are called key figures in SAP BW,
which are very similar to metrics in MicroStrategy, and
they are represented as physical columns.
•
MicroStrategy: dimension
A dimension object in MicroStrategy is very similar to an
ODBO dimension. It is used to group attributes and define
parent-child relationships.
SAP BW --->
ODBO --->
MicroStrategy
hierarchy
hierarchy
hierarchy
•
SAP BW: hierarchy
•
ODBO: hierarchy
•
MicroStrategy: hierarchy
Hierarchies are used to group attributes (levels) together
and define the relationships between these attributes.
MicroStrategy reuses the hierarchy objects to represent
both dimensions and hierarchies from ODBO.
SAP BW --->
ODBO --->
MicroStrategy
virtual level
level
attribute
•
SAP BW: virtual level
Levels are generated automatically based on either the
definition of the characteristic or the hierarchies
associated with a characteristic.
BW levels have names such as Region Level
SAP
01, Region Level 02, and so on. The inclusion of the
term “Level” is an SAP BW convention. In
MicroStrategy, architects have the option to
rename the levels of a cube with a more readable
convention.
306 Relating objects from SAP BW to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
•
ODBO: level
•
MicroStrategy: attribute (ID/DESC)
B
MicroStrategy attributes map to ODBO levels. However,
each ODBO level generates two physical columns and
forms in MicroStrategy—ID and DESC.
SAP BW --->
ODBO --->
MicroStrategy
characteristic value
member
(attribute element)
•
SAP BW: characteristic value
•
ODBO: member
•
MicroStrategy: (attribute element)
Element values come from either the database or a cube.
For example, 2003 and 2004 are elements of the Year
attribute.
SAP BW --->
ODBO --->
MicroStrategy
characteristic
attribute
property
attribute form
•
SAP BW: characteristic attribute
•
ODBO: property
•
MicroStrategy: attribute form
Attribute forms provide additional information about a
given attribute. For example, the Customer attribute may
have the forms First Name and Last Name. This concept
also applies to ODBO and SAP BW.
SAP BW, forms are sometimes referred to
Indirectly
as attributes. SAP BW also supports
navigational attributes. These attributes are
presented as distinct dimensions when working in
MicroStrategy.
© 2007 MicroStrategy, Inc.
Relating objects from SAP BW to MicroStrategy
307
B
Connecting to OLAP Cube Sources
Project Design Guide
Supporting SAP BW variables
Variables are used in SAP BW to enter values as parameters
for the queries on a cube. There are several types of variables,
including characteristic values, hierarchies, hierarchy nodes,
texts, and formula elements. When the query is being
executed, these variables are filled with values. For detailed
information on variables, refer to your SAP documentation.
Variable types with the Customer Exit/SAP Exit and
Authorization processing types are automatically resolved by
the SAP BW system. Only variables with the Manual
Entry/Default processing type are presented to users for
resolution.
BW variables of type Replacement Path cannot be
SAP
imported into MicroStrategy. If your SAP BW cube
included variables of type Replacement Path, you must
remove them before importing the cube into
MicroStrategy. Otherwise, an error occurs when you
attempt to import the SAP BW cube.
Originally created in an SAP query cube, variables are
represented as prompts in the MicroStrategy environment.
The conversion process involves the following general steps:
1 When an SAP query cube is imported into a MicroStrategy
project, variables are automatically turned into prompts
in the MicroStrategy OLAP cube.
2 When a MicroStrategy report is created using a
MicroStrategy OLAP cube, the report inherits the
prompts included in the OLAP cube.
On top of the “inherited” variable prompts, additional
standard
MicroStrategy prompts can also be created
for the report. For more information, see the Prompts
section of the Creating OLAP Cube Reports chapter of
the MicroStrategy Advanced Reporting Guide.
308 Relating objects from SAP BW to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
Mapping between variables and prompts can be viewed in the
OLAP Cube Catalog. The OLAP Cube Catalog lists all the
prompts that were converted from variables, in addition to
cube names, dimensions, and measures/key figures, as
shown in the following image.
In the OLAP Cube Catalog, you can view any variable’s
properties by right-clicking its name and then selecting
Properties. Details about this variable in SAP BW are
displayed on the Variable tab, including Variable Name,
Variable Type, Selection Type, Entry Type, Default Low,
Default Low Description, and Variable Ordinal.
In addition, using the right-mouse click you can Edit the
prompt in the Prompt Generation Wizard, Rename the
prompt, or Map the variable to a prompt in an existing
MicroStrategy project.
© 2007 MicroStrategy, Inc.
Relating objects from SAP BW to MicroStrategy
309
B
Connecting to OLAP Cube Sources
Project Design Guide
prompt can be mapped to more than one variable
One
across cubes. When executing a Report Services
document with multiple datasets using these cubes, a
prompt is displayed only once. This allows the same
prompt answer to be used to resolve multiple variables
during document execution.
After an OLAP cube report is executed, you can view the
prompt details in the Report Details pane in the Report
Editor. This is especially useful if you want to get a summary
of the variable elements that are used in answering the
variable prompts. For more information about prompts in
OLAP cube reports, see the Prompts section of the Creating
OLAP Cube Reports chapter of the MicroStrategy Advanced
Reporting Guide.
The following table contains information on how the different
types of SAP BW variables are mapped to MicroStrategy
prompts.
SAP Variable Type --->
MicroStrategy Prompt
Notes
Characteristic Value
variable
Element list prompt or attribute
qualification prompt
See the note below for more information.
Hierarchy variable
N/A
Not supported.
Hierarchy Node variable Hierarchy element list prompt
Both single and multiple selection are
supported.
Text variable
N/A
Not available from SAP BW.
Formula variable
Value prompt: all types
No major changes.
value variables offer an
Characteristic
“Including/Excluding” option. Qualifications in the
Including section cause the data to be brought into the
query, while those in the Excluding section restrict the
data from being displayed in the query. To be
consistent with the SAP functionality, the
MicroStrategy interface qualifies on the key value of
each element by default.
If you use any SAP BW key date variables in your query, you
need to manually set the variable’s property in the OLAP
Cube Catalog, so it is distinguished from a simple
characteristic variable on date.
310 Relating objects from SAP BW to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
Set the properties for key date variables
1 Right-click the variable name and select Properties. The
Properties [variable name] dialog box is displayed.
2 On the Variable tab, select the Set Key Date check box,
and then click OK.
SAP BW structures
Structures in an SAP BW query cube define the two axes of a
query (rows and columns) and are of two types: key figure
structures and characteristic structures.
Each element of a key figure structure is represented as a
unique metric in the MicroStrategy environment. In addition
to key figure structures, a query could also have characteristic
structures, each of which is represented as a single flat
dimension with one level. This representation is consistent
with how characteristic variables are represented in SAP BW
through the OLAP Business Application Programming
Interface (BAPI).
MicroStrategy report, you cannot drill down into
Intheaelements
of characteristic structures.
Relating objects from Essbase to MicroStrategy
As a Web or Desktop Analyst, you can treat OLAP cube
reports from an Essbase OLAP cube as if they were standard
MicroStrategy reports. However, if you are a report designer,
it is helpful to understand how Essbase’s metadata model is
translated into MicroStrategy’s metadata model.
© 2007 MicroStrategy, Inc.
Relating objects from Essbase to MicroStrategy
311
B
Connecting to OLAP Cube Sources
Project Design Guide
The translation process involves the following steps:
1 From Essbase to XMLA: Essbase exposes its databases
through the XMLA model which is derived from the
ODBO model used by SAP. XMLA defines an object model
that is used in conjunction with MDX to query cubes. The
Essbase model predates XMLA so there are some
differences. When thinking about Essbase objects, keep in
mind how those objects appear in XMLA.
2 From XMLA to MicroStrategy: After Essbase objects are
translated into the XMLA model, they are then translated
into the MicroStrategy metadata model. You can then
interact with Essbase content while working within the
paradigm that is consistent with the rest of
MicroStrategy’s products.
The following image demonstrates how Essbase objects are
exposed in XMLA and then how they are related to objects in
the MicroStrategy environment.
312 Relating objects from Essbase to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
The following subsections (each starting with a table)
describe each level of comparison from top to bottom as
shown in the above illustration.
Essbase --->
XMLA --->
MicroStrategy
Application
catalog
(catalog)
•
Essbase: Application
Each Application is exposed as a catalog in XMLA.
Databases are accessed through their respective catalogs.
•
XMLA: catalog
Catalogs are used to group cubes. Therefore, XMLA
catalogs are exposed in editors when selecting and
managing cubes.
•
MicroStrategy: (catalog)
Each catalog includes one application and associated
databases, if any. Catalogs in MicroStrategy are
represented as a folder.
Essbase --->
XMLA --->
MicroStrategy
N/A
schema
N/A
•
Essbase: not supported
•
XMLA: schema
Schema in XMLA provides another grouping mechanism.
•
© 2007 MicroStrategy, Inc.
MicroStrategy: not supported
Essbase --->
XMLA --->
MicroStrategy
database
cube
cube
•
Essbase: database
•
XMLA: cube
Relating objects from Essbase to MicroStrategy
313
B
Connecting to OLAP Cube Sources
•
Project Design Guide
MicroStrategy: cube
A MicroStrategy cube is an object that is used to map the
levels of an Essbase cube into the MicroStrategy
environment. Cubes are treated in a manner very similar
to tables in the MicroStrategy metadata. A MicroStrategy
cube maps the physical columns of an Essbase cube to
attributes and metrics in the same way that a regular table
maps the physical columns of a relational table to
attributes and metrics. The cube represents an Essbase
database.
Essbase --->
XMLA --->
MicroStrategy
dimension
dimension
dimension
•
Essbase: dimension
In Essbase, a dimension represents the highest
consolidation level in the database outline. The dimension
therefore is both the highest level member in the
dimension and the dimension itself. Each dimension has a
single root node or member and is a child of the outline
root node which is the database.
An Essbase dimension appears as a dimension for
MicroStrategy users. Each dimension has a single
hierarchy with the number of levels determined by the
greatest depth in the outline.
•
XMLA: dimension
A dimension in XMLA defines a logical category of
analysis. For example, Time and Geography are
dimensions along which you can slice data.
Measures (metrics) are stored in a special measure
dimension. In this way, measures are simply one more
dimension of a cube.
Measures in ODBO are the members of the dimension of
type=Accounts in Essbase. These can be raw data or
formulas with associated calculation or aggregation rules.
•
MicroStrategy: dimension
314 Relating objects from Essbase to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
A dimension object in MicroStrategy is very similar to an
XMLA dimension. It is used to group attributes and
define parent-child relationships.
Essbase --->
XMLA --->
MicroStrategy
dimension
hierarchy
hierarchy
•
Essbase: dimension
An Essbase dimension is defined as part of the database
outline. The outline is a hierarchical structure of database
members with a parent containing its children. As a
result, the outline defines a single hierarchy. Therefore
the dimension is the same as the hierarchy in Essbase.
•
XMLA: hierarchy
•
MicroStrategy: hierarchy
Hierarchies are used to group attributes (levels) together
and define the relationships between these attributes.
MicroStrategy reuses the hierarchy objects to represent
both dimensions and hierarchies from XMLA.
Essbase --->
XMLA --->
MicroStrategy
level
level
attribute
•
Essbase: level
Levels group together members in an Essbase database
outline.
levels may have default names such as
Essbase
Time.Levels(0). In MicroStrategy, architects have
the option to rename the levels of a cube with a
more readable convention.
© 2007 MicroStrategy, Inc.
•
XMLA: level
•
MicroStrategy: attribute (ID/DESC)
Relating objects from Essbase to MicroStrategy
315
B
Connecting to OLAP Cube Sources
Project Design Guide
MicroStrategy attributes map to XMLA levels. However,
each XMLA level generates the two physical columns and
forms ID and DESC in MicroStrategy.
Essbase --->
XMLA --->
MicroStrategy
member
member
attribute element
•
Essbase: member
•
XMLA: member
•
MicroStrategy: attribute element
Element values come from either the database or a cube.
For example, 2003 and 2004 are elements of the Year
attribute.
Essbase --->
XMLA --->
MicroStrategy
N/A
property
attribute form
•
Essbase: N/A
Essbase as of version 7.1.3 does not return any properties
in the XMLA property schema rowset. However,
properties can be defined for a database as user defined
attributes or attribute dimensions and used in an MDX
statement. Until they are returned as rows in the property
schema rowset they are not available as attribute forms in
MicroStrategy.
•
XMLA: property
•
MicroStrategy: attribute form
Attribute forms provide additional information about a
given attribute. For example, the Customer attribute may
have the forms First Name and Last Name.
316 Relating objects from Essbase to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
Relating objects from Analysis Services 2000 to
MicroStrategy
Microsoft Analysis Services 2000 (Analysis Services 2000)
cubes are exposed directly for XMLA access. If you are a
report designer, it is helpful to understand how Analysis
Services 2000’s metadata model is translated into
MicroStrategy’s metadata model.
The translation process involves the following steps:
1 From Analysis Services 2000 to XMLA: Analysis
Services 2000 exposes its cubes through the XMLA model
which is derived from the ODBO model. XMLA defines an
object model that is used in conjunction with MDX to
query cubes.
2 From XMLA to MicroStrategy: After Analysis Services
2000 objects are translated into the XMLA model, they
are then translated into the MicroStrategy metadata
model. You can then interact with Analysis Services 2000
content while working within the paradigm that is
consistent with the rest of MicroStrategy’s products.
© 2007 MicroStrategy, Inc.
Relating objects from Analysis Services 2000 to MicroStrategy
317
B
Connecting to OLAP Cube Sources
Project Design Guide
The following image demonstrates how Analysis Services
2000 objects are exposed in XMLA and then how they are
related to objects in the MicroStrategy environment.
The following sub-sections—each starting with a
table—describe each level of comparison from top to bottom
as shown in the above illustration.
Analysis Services 2000 ---> XMLA --->
MicroStrategy
database
(catalog)
•
catalog
Analysis Services 2000: database
Each database is exposed as a catalog in XMLA. Cubes are
accessed through their respective catalogs.
•
XMLA: catalog
Catalogs are used to group cubes. Therefore, XMLA
catalogs are exposed in editors when selecting and
managing cubes.
•
MicroStrategy: (catalog)
318 Relating objects from Analysis Services 2000 to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
Each catalog includes one database and associated cubes,
if any. Catalogs in MicroStrategy are represented as a
folder.
Analysis Services 2000 ---> XMLA --->
MicroStrategy
N/A
N/A
schema
•
Analysis Services 2000: not supported
•
XMLA: schema
Schema in XMLA provides another grouping mechanism.
•
MicroStrategy: not supported
Analysis Services 2000 ---> XMLA --->
MicroStrategy
cube
cube
cube
•
Analysis Services 2000: cube
•
XMLA: cube
•
MicroStrategy: cube
A MicroStrategy cube is an object that is used to map the
levels of an Analysis Services 2000 cube into the
MicroStrategy environment. Cubes are treated in a
manner very similar to tables in the MicroStrategy
metadata. In the same way that a regular table maps the
physical columns of a relational table to attributes and
metrics, a MicroStrategy cube maps the physical columns
of an Analysis Services 2000 cube to attributes and
metrics. The cube represents an Analysis Services 2000
cube.
Analysis Services 2000 ---> XMLA --->
MicroStrategy
dimension
dimension
•
© 2007 MicroStrategy, Inc.
dimension
Analysis Services 2000: dimension
Relating objects from Analysis Services 2000 to MicroStrategy
319
B
Connecting to OLAP Cube Sources
Project Design Guide
In Analysis Services 2000, a dimension is defined from
one or more tables of data.
An Analysis Services 2000 dimension appears as a
dimension for MicroStrategy users. Each dimension can
have one or more hierarchies.
•
XMLA: dimension
A dimension in XMLA defines a logical category of
analysis. For example, Time and Geography are
dimensions along which you can slice data.
Measures (metrics) are stored in a special measure
dimension. In this way, measures are simply one more
dimension of a cube.
Measures in XMLA are the members of the Measures
dimension in Analysis Services 2000. These can be
columns in the table or calculated members represented
by formulas with associated aggregation rules.
•
MicroStrategy: dimension
A dimension object in MicroStrategy is very similar to an
XMLA dimension. It is used to group attributes and
define parent-child relationships.
Analysis Services 2000 ---> XMLA --->
MicroStrategy
dimension
hierarchy
•
hierarchy
Analysis Services 2000: dimension
Using a structured naming approach, related dimensions
can be grouped together so that they represent hierarchies
of the same dimension from an XMLA perspective.
•
XMLA: hierarchy
•
MicroStrategy: hierarchy
Hierarchies are used to group attributes (levels) together
and define the relationships between these attributes.
MicroStrategy reuses the hierarchy objects to represent
both dimensions and hierarchies from XMLA.
320 Relating objects from Analysis Services 2000 to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
Analysis Services 2000 ---> XMLA --->
MicroStrategy
level
attribute
•
level
B
Analysis Services 2000: level
Levels are mapped to columns in a table and are
organized into hierarchies and dimensions.
•
XMLA: level
•
MicroStrategy: attribute (ID/DESC)
MicroStrategy attributes map to XMLA levels. However,
each XMLA level generates two physical columns and
forms in MicroStrategy—ID and DESC.
Analysis Services 2000 ---> XMLA --->
MicroStrategy
member
attribute element
member
•
Analysis Services 2000: member
•
XMLA: member
•
MicroStrategy: attribute element
Element values come from a cube. For example, 2003 and
2004 are elements of the Year attribute.
Analysis Services 2000 ---> XMLA --->
MicroStrategy
member property
attribute form
•
property
Analysis Services 2000: member property
A member property is a descriptive piece of information
associated with the element of a level. Member properties
are returned in the XMLA property schema rowset.
© 2007 MicroStrategy, Inc.
•
XMLA: property
•
MicroStrategy: attribute form
Relating objects from Analysis Services 2000 to MicroStrategy
321
B
Connecting to OLAP Cube Sources
Project Design Guide
Attribute forms provide additional information about a
given attribute. For example, the Customer attribute may
have the forms First Name and Last Name.
Relating objects from Analysis Services 2005 to
MicroStrategy
Microsoft Analysis Services 2005 (Analysis Services 2005)
has a unique modeling approach for building cubes. This
section is limited to information on the basic cube object and
how it relates to the XMLA model.
The translation process involves the following steps:
1 From Analysis Services 2005 to XMLA: Analysis
Services 2005 exposes its cubes through the XMLA model
which is derived from the ODBO model. XMLA defines an
object model that is used in conjunction with MDX to
query cubes.
2 From XMLA to MicroStrategy: After Analysis Services
2005 objects are translated into the XMLA model, they
are then translated into the MicroStrategy metadata
model. You can then interact with Analysis Services 2005
content while working within the paradigm that is
consistent with the rest of MicroStrategy’s products.
322 Relating objects from Analysis Services 2005 to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
The following image demonstrates how Analysis Services
2005 objects are exposed in XMLA and then how they are
related to objects in the MicroStrategy environment.
The following sub-sections—each starting with a
table—describe each level of comparison from top to bottom
as shown in the above illustration.
Analysis Services 2005 ---> XMLA --->
MicroStrategy
database
(catalog)
•
catalog
Analysis Services 2005: database
Each database is exposed as a catalog in XMLA. Cubes are
accessed through their respective catalogs.
•
XMLA: catalog
Catalogs are used to group cubes. Therefore, XMLA
catalogs are exposed in editors when selecting and
managing cubes.
•
© 2007 MicroStrategy, Inc.
MicroStrategy: (catalog)
Relating objects from Analysis Services 2005 to MicroStrategy
323
B
Connecting to OLAP Cube Sources
Project Design Guide
Each catalog includes one database and associated cubes,
if any. Catalogs in MicroStrategy are represented as a
folder.
Analysis Services 2005 ---> XMLA --->
MicroStrategy
N/A
N/A
schema
•
Analysis Services 2005: not supported
•
XMLA: schema
Schema in XMLA provides another grouping mechanism.
•
MicroStrategy: not supported
Analysis Services 2005 ---> XMLA --->
MicroStrategy
perspective
cube
•
cube
Analysis Services 2005: perspective
A perspective in Analysis Services 2005 is a view of the
defined cube and the list of perspectives includes the
original cube.
•
XMLA: cube
•
MicroStrategy: cube
A MicroStrategy cube is an object that is used to map the
levels of an Analysis Services 2005 cube into the
MicroStrategy environment. Cubes are treated in a
manner very similar to tables in the MicroStrategy
metadata. In the same way that a regular table maps the
physical columns of a relational table to attributes and
metrics, a MicroStrategy cube maps the physical columns
of an Analysis Services 2005 cube to attributes and
metrics. The cube represents an Analysis Services 2005
cube.
324 Relating objects from Analysis Services 2005 to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
Analysis Services 2005 ---> XMLA --->
MicroStrategy
dimension
dimension
•
dimension
B
Analysis Services 2005: dimension
In Analysis Services 2005, a dimension is defined from
one or more data source tables. Unlike Analysis Services
2000, a data source does not always map directly to the
tables in a relational database. All columns in the tables
are eligible to become attributes of the dimension. Each
attribute is used to define a hierarchy within the
dimension and multi-level hierarchies can be defined as
well. An Analysis Services 2005 dimension appears as a
dimension for MicroStrategy users. Each dimension can
have one or more hierarchies.
•
XMLA: dimension
A dimension in XMLA defines a logical category of
analysis. For example, Time and Geography are
dimensions along which you can slice data.
Measures (metrics) are stored in a special measure
dimension. In this way, measures are simply one more
dimension of a cube.
Measures in XMLA are the members of the Measures
dimension in Analysis Services 2005. These can be
columns in the data source table or calculated members
represented by formulas with associated aggregation
rules.
•
MicroStrategy: dimension
A dimension object in MicroStrategy is very similar to an
XMLA dimension. It is used to group attributes and
define parent-child relationships.
© 2007 MicroStrategy, Inc.
Analysis Services 2005 ---> XMLA --->
MicroStrategy
hierarchy
hierarchy
hierarchy
Relating objects from Analysis Services 2005 to MicroStrategy
325
B
Connecting to OLAP Cube Sources
•
Project Design Guide
Analysis Services 2005: hierarchy
Analysis Services 2005 allows the definition of one or
more hierarchies within a dimension as collections of
attributes which become levels of the hierarchy.
•
XMLA: hierarchy
•
MicroStrategy: hierarchy
Hierarchies are used to group attributes (levels) together
and define the relationships between these attributes.
MicroStrategy reuses the hierarchy objects to represent
both dimensions and hierarchies from XMLA.
Analysis Services 2005 ---> XMLA --->
MicroStrategy
level
attribute
•
level
Analysis Services 2005: level
Each attribute in a hierarchy becomes a level.
•
XMLA: level
•
MicroStrategy: attribute (ID/DESC)
MicroStrategy attributes map to XMLA levels. However,
each XMLA level generates two physical columns and
forms in MicroStrategy—ID and DESC.
Analysis Services 2005 ---> XMLA --->
MicroStrategy
member
attribute element
member
•
Analysis Services 2005: member
•
XMLA: member
•
MicroStrategy: attribute element
Element values come from a cube. For example, 2003 and
2004 are elements of the Year attribute.
326 Relating objects from Analysis Services 2005 to MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
Analysis Services 2005 ---> XMLA --->
MicroStrategy
member property
attribute form
•
property
B
Analysis Services 2005: member property
Attributes can be related as member properties when
defining the levels of a dimension. Member properties are
returned in the XMLA property schema rowset.
•
XMLA: property
•
MicroStrategy: attribute form
Attribute forms provide additional information about a
given attribute. For example, the Customer attribute may
have the forms First Name and Last Name.
Connecting to SAP BW servers
In addition to relational databases, MicroStrategy can also
use SAP BW as a data source to conduct enterprise reporting
and analysis. Before creating any reports using the SAP BW
data, you need to establish a connection to the SAP BW
system. For more information on establishing a connection to
SAP BW, refer to the MicroStrategy Desktop online help.
MicroStrategy certifies connecting to SAP BW 3.1, 3.5, and
7.0. For any late-breaking changes to the certification status
of connecting to various SAP BW versions, see the
MicroStrategy readme.
This section discusses how to connect to SAP BW servers in
the following environments:
© 2007 MicroStrategy, Inc.
•
Connecting to SAP BW servers on Windows
•
Connecting to SAP BW servers on UNIX and Linux
Connecting to SAP BW servers
327
B
Connecting to OLAP Cube Sources
Project Design Guide
Connecting to SAP BW servers on Windows
Important note from SAP:
“Starting with JCo 2.1.4 and JCo 2.0.11, you are
required to install the new Visual Studio .NET C/C++
run-time libraries on Windows platforms. See SAP
Note 684106 for details on how to install them.”
on your system and SAP BW setup, you
Depending
may have to perform some extra configuration and
troubleshooting steps to connect to SAP BW servers.
For more information, refer to the Tech Note
TN5800-800-0559.
Take the following steps to connect to SAP BW servers in
Windows.
To connect to SAP BW servers on Windows
1 Open the SAP Service Marketplace and download the
SAP Java Connector. You can use the following URL to
download the Java Connector:
https://service.sap.com/~form/sapnet?_SHOR
TKEY=01100035870000463649
certifies version 2.1.3 and also
MicroStrategy
supports more recent versions.
2 Install the SAP Java Connector.
3 Place the following SAP Java Connector files in any
directory that is referenced in the Path environment
variable:
•
Librfc32.dll
•
Sapjcorfc.dll
the Path environment variable from your
Locate
machine’s System Properties dialog (right-click on
My Computer and select Properties), on the
Advanced tab, select Environment Variables. In
328 Connecting to SAP BW servers
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
the list of System Variables, locate Path. Verify
that the directory is included in the value for the
Path variable.
4 Place the Sapjco.jar in the Common Files
MicroStrategy folder. For example, C:\Program
files\Common files\MicroStrategy.
To create a database instance for your SAP BW connection
5 In Desktop, open a project source and expand
Administration from the folder list.
6 From the folder list, select Database Instance Manager.
7 Select New, and then Database Instance from the File
menu. The Database Instance editor opens.
8 Create a database instance with SAP BW as the database
connection type, as shown below.
To specify database connection parameters
9 For the database instance, select a database connection or
create a new database connection that provides the
following information as required:
© 2007 MicroStrategy, Inc.
•
Application Server is the name of the SAP BW Server
or IP address.
•
SAP Router String if you use an SAP Router.
•
System Number from the SAP BW system.
•
Client Number from the SAP BW system.
Connecting to SAP BW servers
329
B
Connecting to OLAP Cube Sources
Project Design Guide
•
Language is the language code provided by your SAP
administrator. For example, EN is the language code
for English.
Note the following:
•
You can get the above information from your SAP
Logon.
•
You can use either the Database Instances Editor
or the Database Instance Wizard to create a
database instance for SAP BW. For more
information, refer to the MicroStrategy Desktop
online help.
To specify a database login
10 Create a database login with the user and password to use
to connect to SAP BW.
more detailed steps on creating a database
For
instance and related components to connect to SAP
BW, refer to the MicroStrategy online help.
Connecting to SAP BW servers on UNIX and Linux
Take the following steps to connect to SAP BW servers in
UNIX.
on your system and SAP BW setup, you
Depending
may have to perform some extra configuration and
troubleshooting steps to connect to SAP BW servers.
For more information, refer to the MicroStrategy Tech
Note TN5300-802-0734.
To connect to SAP BW servers on UNIX/Linux
1 Open the SAP Service Marketplace and download the
SAP Java Connector. You can use the following URL to
download the Java Connector:
https://service.sap.com/~form/sapnet?_SHOR
TKEY=01100035870000463649
330 Connecting to SAP BW servers
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
•
MicroStrategy certifies version 2.1.3 and also supports
more recent versions.
2 Select the zip file for the platform you want to use and
unzip it. For example, use the command gunzip [file
name] or gzip [file name].
3 Search for the files listed in the following table, copy them
onto your machine, and create a new directory for them.
For example, /opt/var/MicroStrategy/SAP.
AIX
SUN
Linux
librfccm.o
librfccm.so
librfccm.so
libsapjcorfc.so
libsapjcorfc.so
libsapjcorfc.so
sapjco.jar
sapjco.jar
sapjco.jar
4 Edit the SAP.sh file in the MicroStrategy installation
directory [INSTALL_PATH]/env/SAP.sh by doing the
following:
•
Add the Write and Execute privileges to this file. The
default is Read Only. You can type the command
“chmod+wx SAP.sh” in the UNIX/Linux console.
•
Open the SAP.sh file and enter the information for
XXXX_SAP_LIBRARY_PATH=’’. This information
indicates where the server needs to point to use the
downloaded files.
For example, for AIX:
#
# set up the environment for SAP
#
XXXX_SAP_LIBRARY_PATH='/opt/var/MicroStr
ategy/SAP'
if [ -n "${XXXX_SAP_LIBRARY_PATH}" ];
then xxxx_append_path
LD_LIBRARY_PATH
"${XXXX_SAP_LIBRARY_PATH:?}"
export LD_LIBRARY_PATH
fi
© 2007 MicroStrategy, Inc.
Connecting to SAP BW servers
331
B
Connecting to OLAP Cube Sources
Project Design Guide
For example, for Solaris:
#
# set up the environment for SAP
#
XXXX_SAP_LIBRARY_PATH='/opt/var/MicroStr
ategy/SAP’
if [ -n "${XXXX_SAP_LIBRARY_PATH}" ];
then xxxx_append_path LIBPATH
"${XXXX_SAP_LIBRARY_PATH:?}"
export LIBPATH
fi
•
Save the file.
5 Add sapjco.jar to the installation directory,
/install/jar.
sure you have Write privilege to this
Make
directory.
6 Restart the server to get the latest updates.
To create a database instance for your SAP BW
connection
7 In Desktop (available only in Windows), open a project
source and expand Administration from the folder list.
8 From the folder list, select Database Instance Manager.
9 Select New, and then Database Instance from the File
menu. The Database Instance editor opens.
332 Connecting to SAP BW servers
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
10 Create a database instance with SAP BW as the database
connection type, as shown below.
To specify database connection parameters
11 For the database instance, select a database connection or
create a new database connection that provides the
following information as required:
•
Application Server: name of the SAP BW Server or IP
address
•
SAP Router String, if you use an SAP Router
•
System Number from the SAP BW system
•
Client Number from the SAP BW system
•
Language: the language code provided by your SAP
administrator, for example, EN for English
Note the following:
© 2007 MicroStrategy, Inc.
•
You can get the above information from your SAP
Logon.
•
You can use either the Database Instances Editor
or the Database Instance Wizard to create a
database instance for SAP BW. For more
information, refer to the MicroStrategy Desktop
online help. You can also refer to Tech Note
TN5300-802-0734 for more information on
setting up SAP BW with Intelligence Server
Universal.
Connecting to SAP BW servers
333
B
Connecting to OLAP Cube Sources
Project Design Guide
To specify a database login
12 Create a database login with the user and password to use
to connect to SAP BW.
more detailed steps on creating a database
For
instance and related components to connect to SAP
BW, refer to the MicroStrategy online help.
Connecting to Essbase servers
In addition to relational databases, MicroStrategy can also
use Essbase as a data source to conduct enterprise reporting
and analysis. Before creating any reports using the Essbase
data, you need to establish a connection to the Essbase
servers.
This section discusses how to connect to Essbase servers in
the Windows or UNIX/Linux environment.
can perform a test of the XMLA connection to
You
your OLAP cube servers completely separate of any
MicroStrategy dependencies with the XMLA
Connectivity Test Tool provided with your
MicroStrategy installation. For information on how to
use the XMLA Connectivity Test Tool, refer to
MicroStrategy Tech Note TN1100-000-0635.
Configuring the XMLA Provider
The material in this section assumes familiarity with the
XMLA 1.1 specification found at www.xmla.org, and the
configuration of the XMLA provider for each of these
products.
You can think of XMLA as a Web Service that supports
metadata and data queries against an OLAP Cube source. A
Discover request supports queries to metadata and the
results are packaged in a DiscoverResponse message. The
Execute request queries cube data and results are returned in
an ExecuteResponse message.
334 Connecting to Essbase servers
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
Make sure the XMLA 1.1 provider is correctly deployed and
security settings are configured correctly. You can verify it is
working by connecting to the provider URL from your
browser. You should receive a confirmation from the provider
that includes a display of currently configured properties.
Note the following:
•
For the latest information on the 3rd-party
connection prerequisites given below, see
MicroStrategy Tech Note TN5300-802-0794.
•
Information for correctly installing the XMLA
provider can be found in the 3rd-party
documentation for Hyperion’s Enterprise
Deployment Services product.
•
The Hyperion XMLA Provider must be installed
and configured on a compatible web application
server. The Hyperion XMLA provider supports
BEA WebLogic 6.1 and Apache Tomcat. The web
application server may be installed on a different
machine from the Essbase server. Consult your
3rd-party documentation for further details on
system requirements and the latest updates.
•
Install Hyperion Enterprise Deployment Services
7.1 on the application server machine to verify that
access is available to the Essbase server via the
Service Console. For information on installation
procedures, refer to your 3rd-party
documentation.
•
The application server that hosts the Hyperion
XMLA provider must enable anonymous access to
the XMLA application.
Creating a database instance
Perform the following steps to connect to Hyperion Essbase
servers.
© 2007 MicroStrategy, Inc.
Connecting to Essbase servers
335
B
Connecting to OLAP Cube Sources
Project Design Guide
To create a database instance for Essbase
1 From the Desktop Folder List, connect to a project source.
2 Expand Administration from the Folder List and select
Database Instance Manager.
3 From the File menu, select New, and then Database
Instance. The Database Instance editor opens.
4 Create a database instance with Hyperion Essbase as the
database connection type, as shown below.
To specify database connection parameters
5 For the database instance, select a database connection or
create a new database connection that provides the
following information as required:
•
URL: This is the URL of the XMLA Provider that was
configured for HTTP access. For example,
http://fully-qualified-machinename:8080/
xmla/EssbaseXmlForAnalysis.
fully-qualified-machinename is usually
The
of the form machine.domain.company.com.
You can also use the IP address as the
fully-qualified-machinename. For Essbase
the URL is most likely case sensitive.
•
336 Connecting to Essbase servers
DSI: The DataSourceInfo (DSI) value is of the form:
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
Provider=Essbase;Data source=<machine
name>
The value is split between the DSI setting and an
additional connection string parameters setting.
•
Catalog: The Essbase Catalog value is the Essbase
Application containing the database you want to work
with in MicroStrategy. Use the Essbase
Administration Console to view the applications and
databases available on the server. A cube in XMLA is a
database in Essbase.
To specify a database login
6 Create a database login with the user and password to use
to connect to the Web service hosting the Essbase XML
Provider.
more detailed steps on creating a database
For
instance and related components to connect to
Analysis Services, refer to the MicroStrategy online
help.
Connecting to Analysis Services 2000 servers
In addition to relational databases, MicroStrategy can also
use Analysis Services 2000 as a data source to conduct
enterprise reporting and analysis. Before creating any reports
using the Analysis Services 2000 data, you need to establish a
connection to the Analysis Services 2000 servers.
This section discusses how to connect to Analysis Services
2000 servers in the Windows or UNIX/Linux environment.
Note the following:
© 2007 MicroStrategy, Inc.
•
Before connecting to your Analysis Services 2000
servers, you should check that you meet all of the
requirements listed in the tech note
TN5200-802-0540.
•
You can perform a test of the XMLA connection to
your OLAP cube servers completely separate of any
MicroStrategy dependencies with the XMLA
Connecting to Analysis Services 2000 servers
337
B
Connecting to OLAP Cube Sources
Project Design Guide
Connectivity Test Tool provided with your
MicroStrategy installation. For information on how
to use the XMLA Connectivity Test Tool, refer to
MicroStrategy Tech Note TN1100-000-0635.
Configuring the XMLA Provider
The material in this section assumes familiarity with the
XMLA 1.1 specification found at www.xmla.org, and the
configuration of the XMLA provider for each of these
products. You can think of XMLA as a Web service that
supports metadata and data queries against an OLAP Cube
source. A Discover request supports queries to metadata and
the results are packaged in a DiscoverResponse message. The
Execute request queries cube data and results are returned in
an ExecuteResponse message.
Make sure the XMLA 1.1 provider is correctly deployed and
security settings are configured correctly. You can verify
Analysis Services 2000 is working by connecting to the
provider URL from your browser. You should receive an XML
response indicating that the site is available as an XMLA
provider.
for correctly installing the XMLA
Information
provider can be found in your Microsoft
documentation.
Creating a database instance
Perform the following steps to connect to Microsoft Analysis
Services 2000 servers.
Creating a database instance for Analysis Services 2000
1 In Desktop, open a project source and expand
Administration from the folder list.
2 From the folder list, select Database Instance Manager.
338 Connecting to Analysis Services 2000 servers
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
3 From the File menu, select New, and then Database
Instance. The Database Instance Editor opens.
4 Create a database instance with Microsoft Analysis
Services as the database connection type, as shown
below.
To specify database connection parameters
5 For the database instance, select a database connection or
create a new database connection that provides the
following information as required:
•
URL: This is the URL of the XMLA Provider that was
configured for HTTP access. For example,
http://fully-qualified-machinename/xmla/
msxisapi.dll
fully-qualified-machinename is usually
The
of the form machine.domain.company.com.
You can also use the IP address as the
fully-qualified-machinename. For Analysis
Services XMLA running on IIS, the URL is not
case-sensitive.
© 2007 MicroStrategy, Inc.
•
DSI: With Analysis Services 2000 the DataSourceInfo
(DSI) value is the configuration setting for your data
source labeled as DataSourceName in the
datasources.xml file.
•
Catalog: Use Microsoft’s Analysis Manager to view
the Analysis Server containing the cubes you want to
work with in MicroStrategy. The database that
contains the cube becomes the catalog for XMLA.
Connecting to Analysis Services 2000 servers
339
B
Connecting to OLAP Cube Sources
Project Design Guide
To specify a database login
6 Create a database login with the user and password to use
to connect to Analysis Services.
information on setting up authentication for
For
Intelligence Server with Analysis Services, refer to
the tech note TN5300-802-0755.
more detailed steps on creating a database
For
instance and related components to connect to
Analysis Services, refer to the MicroStrategy online
help.
Connecting to Analysis Services 2005 servers
In addition to relational databases, MicroStrategy can also
use Analysis Services 2005 as a data source to conduct
enterprise reporting and analysis. Before creating any reports
using the Analysis Services 2005 data, you need to establish a
connection to the Analysis Services 2005 servers.
This section discusses how to connect to Analysis Services
2005 servers in the Windows or UNIX/Linux environment.
Note the following:
•
Before connecting to your Analysis Services 2005
servers, you should check that you meet all of the
requirements listed in the tech note
TN5200-802-0542.
•
You can perform a test of the XMLA connection to
your OLAP cube servers completely separate of any
MicroStrategy dependencies with the XMLA
Connectivity Test Tool provided with your
MicroStrategy installation. For information on how to
use the XMLA Connectivity Test Tool, refer to
MicroStrategy Tech Note TN1100-000-0635.
340 Connecting to Analysis Services 2005 servers
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
Configuring the XMLA Provider
The material in this section assumes familiarity with the
XMLA 1.1 specification found at www.xmla.org, and the
configuration of the XMLA provider for each of these
products. You can think of XMLA as a Web Service that
supports metadata and data queries against an OLAP Cube
source. A Discover request supports queries to metadata and
the results are packaged in a DiscoverResponse message. The
Execute request queries cube data and results are returned in
an ExecuteResponse message.
XMLA is the native access method for Analysis Services
2005. However, by default, only the TCP/IP transport is
configured. Follow Microsoft documentation to make sure
that the XMLA provider is correctly configured for HTTP
access, which includes configuring security settings.
for correctly installing the XMLA
Information
provider can be found in your Microsoft
documentation.
Creating a database instance
Perform the following steps to connect to Microsoft Analysis
Services 2005 servers.
Creating a database instance for Analysis Services 2005
1 In Desktop, open a project source and expand
Administration from the folder list.
2 From the folder list, select Database Instance Manager.
3 From the File menu, select New, and then Database
Instance. The Database Instance Editor opens.
© 2007 MicroStrategy, Inc.
Connecting to Analysis Services 2005 servers
341
B
Connecting to OLAP Cube Sources
Project Design Guide
4 Create a database instance with Microsoft Analysis
Services as the database connection type, as shown
below.
To specify database connection parameters
5 For the database instance, select a database connection or
create a new database connection that provides the
following information as required:
•
URL: This is the URL of the XMLA Provider that was
configured for HTTP access. For example,
http://fully-qualified-machinename/xmla/
msmdpump.dll
fully-qualified-machinename is usually
The
of the form machine.domain.company.com.
You can also use the IP address as the
fully-qualified-machinename. For Analysis
Services 2005 XMLA running on IIS, the URL is
not case sensitive.
•
DSI: For Analysis Services 2005, the DSI entry can be
left blank. Unlike Analysis Services 2000, each URL
will be configured to support only one data source.
•
Catalog: Use Microsoft’s SQL Server Management
Studio to view the Analysis Server which contains the
cubes to work with in MicroStrategy. The database
that contains the cube becomes the catalog for XMLA.
To specify a database login
6 Create a database login with the user and password to use
to connect to Analysis Services.
342 Connecting to Analysis Services 2005 servers
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
information on setting up authentication for
For
Intelligence Server with Analysis Services, refer to
the tech note TN5300-802-0755.
more detailed steps on creating a database
For
instance and related components to connect to
Analysis Services, refer to the MicroStrategy online
help. For information on setting OLAP cube schema
loading options for an OLAP cube source database
instance, refer to Chapter 5, Configuring and
Connecting to Intelligence Server of the
MicroStrategy Installation and Configuration Guide.
Integrating OLAP cubes into MicroStrategy
Once you understand the relationships among the objects in
an OLAP cube source and MicroStrategy and connect to your
OLAP cube source, you can start working with the OLAP cube
data in MicroStrategy. The best place to start is with the
OLAP Cube Catalog, where you can import OLAP cubes and
remap the OLAP cubes before you create any OLAP cube
reports. Like the Warehouse Catalog, the OLAP Cube Catalog
can be accessed from the Schema menu on Desktop.
Note the following:
•
Once an OLAP cube is imported, you can remap an
OLAP cube to MicroStrategy objects and create
metrics within an OLAP cube with the OLAP Cube
Editor. For more information, see Mapping OLAP
cubes, page 349 and Creating metrics from OLAP
cube data with MDX and compound metric
techniques, page 359.
•
The OLAP Cube Catalog is available only after an
OLAP cube source database instance has been
created. To learn how to create a database instance
for an OLAP cube source, see one of the following
sections:
– Connecting to SAP BW servers, page 327
– Connecting to Analysis Services 2000 servers,
page 337
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
343
B
Connecting to OLAP Cube Sources
Project Design Guide
– Connecting to Analysis Services 2005 servers,
page 340
– Connecting to Essbase servers, page 334
This section discusses how you can use the OLAP Cube
Catalog to bring the OLAP cube data into a MicroStrategy
project and what functions you can perform once the data is
brought into MicroStrategy. SAP BW is used as the OLAP
cube source but the procedure is similar for Analysis Services
and Essbase. For details on how to use the OLAP Cube
Catalog, refer to the MicroStrategy Desktop online help
(search for “OLAP Cube Catalog”).
You can choose to load the schema for imported OLAP cubes
when Intelligence Server starts or during OLAP cube report
execution. For information on setting OLAP cube schema
loading options for an OLAP cube source database instance,
refer to Chapter 5, Configuring and Connecting to
Intelligence Server of the MicroStrategy Installation and
Configuration Guide.
Importing OLAP cubes
OLAP cube importing is performed on the Cube Selection tab,
as shown in the image below. When you open the OLAP Cube
Catalog, all the OLAP cubes are displayed, by default, under
their respective catalog names in the Available Cubes pane.
Using the plus (+) or minus (-) sign next to a catalog name,
you can expand or hide the cubes contained in this catalog.
cubes can be imported into a MicroStrategy
OLAP
project only by an architect with the “Import OLAP
cube” privilege.
344 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
A catalog is marked with an icon showing a folder containing
a cube, an InfoCube is marked with a cube icon in blue, and a
query cube is marked with a cube icon in green.
you create new cubes in Analysis Services and the
Ifcubes
are not being displayed in the OLAP Cube
Catalog, you may have to modify some permissions in
Analysis Services. For details on how to make Analysis
Services cubes available for import in the OLAP Cube
Catalog, see MicroStrategy Tech Note
TN4100-802-1879.
To import OLAP cubes
1 In Desktop, log in to a project that is connected to an
OLAP cube source.
2 From the Schema menu, select OLAP Cube Catalog.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
345
B
Connecting to OLAP Cube Sources
Project Design Guide
•
If you have a single OLAP cube source database
instance created for the project, the OLAP Cube
Catalog opens.
•
If you have multiple OLAP cube source database
instances created for the project, a Database Instance
dialog box opens. You can edit, create, and select an
OLAP cube source database instance to connect to,
using this dialog box. Once you select a valid OLAP
cube source database instance, click OK, and the
OLAP Cube Catalog opens.
3 Select the Cube Selection tab.
4 From the Catalog drop-down list, select the OLAP cube to
import. The catalog contains all the OLAP cubes
associated with it. You can also select All to display the
OLAP cubes for all catalogs.
Select Find from the Edit menu or click the Find
icon
on the toolbar to open the Find dialog box to
search for a specific OLAP cube that you want to
import.
5 Click the plus (+) sign to expand the catalog folder and
display the OLAP cubes in the Available Cubes pane on
the left.
6 Use one of the following methods to import the OLAP
cubes:
•
To import the selected OLAP cubes, click the single
arrow (>).
•
To import all OLAP cubes, click the double arrows
(>>).
7 Once imported, the imported OLAP cubes are displayed in
the Selected Cubes pane on the right.
8 Click Save to save your progress.
After importing OLAP cubes, you can use the OLAP Cube
Catalog to map the OLAP cube data to MicroStrategy objects
(see Mapping OLAP cubes, page 349.) Once the data is
mapped to MicroStrategy objects, you can build reports that
access the imported OLAP cubes.
346 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
To remove an OLAP cube, you can right-click any OLAP cube
in the Selected Cubes pane, and select Remove [cube
name]. Using the right-mouse click, you can also select the
Update Structure option to synchronize with the updated
definition of cube structures in the OLAP cube source. For
example, when a new characteristic or key figure has been
added to the InfoCube in SAP BW you can use the Update
Structure option to update the MicroStrategy OLAP cube to
include these modifications.
the first OLAP cube for an OLAP cube source is
Once
imported into MicroStrategy, a Data Explorer for that
OLAP cube source is added to the MicroStrategy
project. You can find the Data Explorer in the Folder
List of Desktop, under the associated MicroStrategy
project.
Importing OLAP cubes during report creation
When you create an OLAP cube report, you choose OLAP
cubes for your report from the Select Cube dialog box. This
dialog box can also be used by an architect with the “Import
OLAP cubes” privilege to import cubes by using the Retrieve
cubes option. This option is available only after a database
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
347
B
Connecting to OLAP Cube Sources
Project Design Guide
instance has been defined. For detailed information, see the
related sections above on connecting to the different OLAP
cube sources.
You can click Find at the bottom of this dialog box to open the
Find dialog box, where you can search for a specific cube for
your report by the cube’s name. For details, refer to the
MicroStrategy Desktop online help.
Managed objects
When an OLAP cube is imported into a project, managed
objects (attributes, metrics, columns, tables, and so on) are
created to describe the OLAP cube. A managed object is just
like a normal object except that it is created by the system
and is stored in a special system folder that is hidden from
users. However, one way to access managed objects is by
using the Search for Objects function from the Tools menu on
Desktop.
In the Search for Objects dialog box, from the Tools menu
select Options, and then select the Display Managed
Objects option so that managed objects are displayed in the
348 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
search result. Once the managed objects are listed in the
search result, you can rename or edit any of them by
right-clicking its name.
A managed object can be removed once it is no longer
referenced by another object in the project. The removal of
unused managed objects is usually performed by an
administrator. For more information on removing a database
instance and its related managed objects, see the Managing
Your Applications chapter of the MicroStrategy System
Administration Guide.
Mapping OLAP cubes
When an architect defines a project, much of the process
centers on identifying logical entities, such as attributes and
facts, that exist in physical tables. For example, an architect
might identify that the key for the Customer attribute exists
in the table LU_CUSTOMER. Once the logical entities are
identified, the architect can then define a logical and physical
model in the MicroStrategy metadata. This model is
referenced by the SQL Engine to generate SQL at run time.
In the context of OLAP cube sources, an OLAP cube, instead
of a single table, contains all the metadata information
necessary to define a logical model and physical model. When
you, as the architect, need to add an OLAP cube to a project in
MicroStrategy, you can simply select a cube by using the
OLAP Cube Catalog or Select Cube dialog box, as described in
Importing OLAP cubes, page 344.
you have imported an OLAP cube, you can
After
perform the same mapping tasks available in the Cube
Mapping tab of the OLAP Cube Catalog by editing the
OLAP cube with the OLAP Cube Editor. To do this,
right-click an OLAP cube in Desktop and select Edit.
By default, a MicroStrategy OLAP cube is created that maps
to the definition of the source cube in the OLAP cube source,
such as SAP BW. When an OLAP cube is imported into
MicroStrategy, Intelligence Server creates new attributes,
metrics, and hierarchies that reflect the data and levels of the
imported OLAP cube. Although these objects, referred to as
managed objects, are new and are part of the project, they
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
349
B
Connecting to OLAP Cube Sources
Project Design Guide
are not related to the project’s schema and schema objects
(see Managed objects above.) For example, a new managed
object named Year has no relation to the Year attribute in the
Tutorial project connected to the data warehouse. A new
schema is created for each OLAP cube source database
instance used in a MicroStrategy project.
Once an OLAP cube is mapped, it can be used to build reports
and documents in MicroStrategy. For more information on
managed objects in OLAP cube reports, see the Reporting on
External Data Sources: OLAP Cube Reports chapter of the
MicroStrategy Advanced Reporting Guide.
you decide to discontinue the use of OLAP cube
Ifreports,
you can remove the OLAP cube source
database instance and all of its associated managed
objects. For steps on how to perform these schema
cleanup tasks, see the Managing Your Applications
chapter of the MicroStrategy System Administration
Guide.
In addition, you can remap OLAP cube data to existing
attributes in a MicroStrategy project rather than new
managed objects. This allows data to be joined across sources
in Report Services documents, which ensures that a
consistent logical model is maintained. Remapping OLAP
cube data to existing attributes can also facilitate the use of
MicroStrategy features such as security filters. For more
information on the benefits of remapping OLAP cube data to
project attributes, see Why do you need to remap OLAP
cubes?, page 356.
350 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
Using the Cube Mapping feature in the OLAP Cube Catalog
shown below, you can map attribute forms for each attribute
contained in the imported cube. By default, only the ID and
DESC forms are automatically mapped for each attribute.
As shown in the image above:
•
The Physical View in the left-hand column represents the
cube structure in the OLAP Cube Source. For SAP BW, the
characteristic (dimension) is located at the very top with a
green chart and box symbol, hierarchy is below the
dimension with a green stacked boxes symbol, and
attributes are represented by a green symbol with two
side-by-side rectangles.
•
The Logical View in the right-hand column represents
the equivalent structure in MicroStrategy, with the same
symbols for hierarchies and attributes as in standard
reports.
In the Physical View column, you can use the plus (+) sign
next to the attribute levels to display the attribute forms.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
351
B
Connecting to OLAP Cube Sources
Project Design Guide
By default, only the ID and DESC forms are displayed. Use
the Display All Columns icon on the toolbar to show
additional attribute forms in the Physical View column and
then map each one to an attribute form in the Logical View
pane. An ID form must be mapped for each attribute.
You can also use the Show Technical Names icon on
the
toolbar to display the SAP BW terms for each
attribute and its attribute forms. The Show Technical
Names option applies to SAP BW OLAP cubes only.
For MicroStrategy attributes and metrics, you can perform
the following manipulations by right-clicking the name in the
Logical view column:
•
Edit the attribute or metric. This option opens the
Attribute Editor to edit attributes and the Metric Editor to
edit metrics.
•
Rename the attribute or metric so it has a different name
in the MicroStrategy project from the name of the
characteristic or key figure it is mapped to in SAP BW.
•
Map the characteristic or key figure to an existing
attribute or metric in the MicroStrategy project.
•
Check the Properties of the characteristic or key figure.
In the Properties dialog box, you can view the information
on its Name, Technical Name, and Description in SAP
BW.
For variables, you can also perform the above-mentioned
manipulations. However, note that when you select Edit, the
Prompt Generation Wizard is displayed. This is because
variables in SAP BW are represented as prompts in
MicroStrategy. For more information, refer to Supporting
SAP BW variables, page 308.
Manually setting column data types for OLAP
cube data
When OLAP cube data is mapped to MicroStrategy objects,
MicroStrategy retrieves the column data type through MDX.
In the case of OLAP cube data that is mapped to attributes,
the columns are often returned as a string of characters. This
can be the case even with ID columns of data that are of a
352 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
numeric type such as integer. Returning data such as ID
columns of attributes as strings can make it impossible to
group attributes with common data as the same attribute in
Report Services documents.
cube data that is mapped to MicroStrategy
OLAP
metrics is automatically converted to a numeric data
type and thus does not need its column data type to be
manually set.
Starting in MicroStrategy 8.1.0 you can manually select the
column data type that is applied to a column of OLAP cube
data mapped to an attribute. This allows the OLAP cube data
to be correctly represented in MicroStrategy and facilitates
the grouping of related attributes as the same attribute in a
Report Services document. For example, you have OLAP cube
data that is mapped to a Product attribute in MicroStrategy.
The ID attribute form for Product is returned as a string, but
you know that its associated OLAP cube column is of type
integer. You can do this same mapping for another OLAP
cube and create reports including the Product attribute. By
setting the Product ID attribute form to read the OLAP cube
data as an integer, you can then include the two OLAP cube
reports as datasets of a Report Services document and group
the two Product attributes.
To manually set column data types for OLAP cube data
You manually set column data types for OLAP cube data
when you are mapping OLAP cube data to MicroStrategy
objects. You can perform this task during the initial import
and mapping procedure for an OLAP cube with the OLAP
Cube Catalog, or as a later modification with the OLAP Cube
Editor. The following procedure uses the OLAP Cube Catalog,
but the same steps apply for the OLAP Cube Editor, starting
with the step to expand data in the Physical view column. You
can access the OLAP Cube Editor by right-clicking an
imported OLAP cube and selecting Edit.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
353
B
Connecting to OLAP Cube Sources
Project Design Guide
1 Log in to a project that is connected to an OLAP cube
source. For information on connecting to an OLAP cube
source, see one of the following sections depending on
your OLAP cube source:
•
Connecting to SAP BW servers, page 327
•
Connecting to Essbase servers, page 334
•
Connecting to Analysis Services 2000 servers,
page 337
•
Connecting to Analysis Services 2005 servers,
page 340
2 From the Schema menu, select OLAP Cube Catalog.
•
If the project connects to only one OLAP cube source,
the OLAP Cube Catalog: Cube Selection tab opens.
•
If the project connects to more than one OLAP cube
source the Database Instance dialog box opens. From
the Select the Database Instance drop-down list,
select the OLAP cube source database instance you
want to connect to and click OK. The OLAP Cube
Catalog: Cube Selection tab opens.
3 Move all OLAP cubes you want to import from the
Available Cubes pane to the Selected Cubes pane by using
the > button.
4 Select the Cube Mapping tab. The Cube Mapping tab
opens.
5 From the Catalog\Cube drop-down list, select the OLAP
cube you want to map to MicroStrategy objects. The OLAP
cube data is displayed in the pane below.
6 In the Physical view column, expand the OLAP cube data
until you find the OLAP cube column data for which to
manually set the data type.
7 Right-click the OLAP cube column data and select Data
Type. The Column Editor — Definition dialog box opens.
8 Clear the Use default from source check box.
354 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
9 From the Data type drop-down list, select which data type
to map the OLAP cube data as.
10 Depending on the data type selected, specify the byte
length, precision, and scale for the data type.
11 Click OK to save your changes and return to the OLAP
Cube Catalog.
12 Click Save and Close to save your changes to the OLAP
cube and exit the OLAP Cube Catalog.
Unbalanced and ragged hierarchies
By default, all hierarchies of an OLAP cube are treated as
balanced hierarchies. However, if you know that the structure
of a hierarchy is unbalanced or ragged you must set the
hierarchy’s properties to reflect its structure. The terms
balanced, unbalanced, and ragged are used to describe the
different set of characteristics of hierarchical sets of data.
© 2007 MicroStrategy, Inc.
•
Balanced hierarchies have an equal number of levels in
each branch of the hierarchy. For example, in a Product
hierarchy that includes Category, Subcategory, and Item
each branch would descend to a particular item.
•
Unbalanced hierarchies have at least one branch that
does not descend to the lowest level. For example, in a
Time hierarchy that includes Year, Quarter, and Month
one branch might only have data down to the Quarter
level.
•
Ragged hierarchies have at least one branch that includes
a member whose logical parent is not the level above that
member. For example, a Product hierarchy may contain
the levels Category, Subcategory, and Item but Item
number 22 does not have a Subcategory associated with it.
When Category, Subcategory, and Item are displayed on
the report there is an empty cell for the Subcategory of
Item number 22.
•
Unbalanced and ragged hierarchies include at least one
branch that does not descend to the lowest level and one
branch that includes a skipped level.
Integrating OLAP cubes into MicroStrategy
355
B
Connecting to OLAP Cube Sources
Project Design Guide
The steps below are necessary for any unbalanced or ragged
hierarchy to prevent inaccurate results when applying certain
types of filters.
Set a hierarchy as unbalanced or ragged
1 In the OLAP Cube Catalog, right-click the hierarchy name
in the Physical View column and select Properties. The
Properties dialog box is displayed.
hierarchy in the Physical View column is
Arepresented
with a green stacked boxes symbol.
2 On the Hierarchies tab, select the check box This
hierarchy is unbalanced or ragged and then click OK.
The word “(Unbalanced)” will be displayed next to the
name of the hierarchy in the Logical View column.
For detailed steps on mapping and remapping objects from
OLAP cube sources to MicroStrategy objects, refer to the
MicroStrategy Desktop online help (search for the “Mapping
OLAP cubes” topic).
Date form support for MDX properties
You can support mapping MicroStrategy date forms to MDX
property data of the date data type by performing a special
modification of a VLDB property. This modification also
allows you to perform date qualifications on the mapped
MDX property data. For information on how to support these
date forms and qualifications, please refer to MicroStrategy
Tech Note TN1100-000-0636.
Why do you need to remap OLAP cubes?
Although you can use the automatically generated managed
object attributes, metrics, and hierarchies you may want to
remap OLAP cube data to existing attributes in the
MicroStrategy project for the following reasons:
356 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
•
Report designers can integrate the logical model of the
project with the data in the imported OLAP cube, thus
creating a relation between the two sets of data.
•
Data can be joined across sources within a Report
Services document. For example, if an OLAP cube report
and a standard report both use the Year attribute, then
Year can be used to group the data within a document.
•
Administrators can search for dependents and manage
access control lists (ACLs) for attributes that map both to
the data warehouse and an OLAP cube source.
•
MicroStrategy security filters can be applied to attributes
in OLAP cube reports. For example, you can map an
OLAP cube level to the Year attribute in your project. If a
user with a security filter on Year runs the OLAP cube
report that contains Year, the security filter on Year is
applied.
You can remap the levels of an OLAP cube, but the nature of
the cube is not changed. Remapping simply replaces the
managed object attributes that are used to represent the
OLAP cube’s structure with attributes in an existing
MicroStrategy project. In the case of attributes, they can be
remapped to project attributes that participate in the ROLAP
schema. However, metrics and hierarchies can only be
remapped to other managed object metrics and hierarchies
that are mapped to OLAP cube source data. For example,
three OLAP cubes can share the same managed object metric
named Revenue.
When should you remap cubes?
Although you can remap the columns either when an OLAP
cube is first imported or later on after you have created a
project, it is recommended that you do the remapping
initially so that subsequent users can take advantage of the
mapping. This also prevents maintenance issues because
reports need to be modified if an OLAP cube is remapped
after the report is created.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
357
B
Connecting to OLAP Cube Sources
Project Design Guide
Example 1: Unmapped cube
You can map managed object attributes for your OLAP cubes
instead of using project attributes. This feature allows you to
quickly start creating reports for your OLAP cube data.
The drawback with this setup is that you cannot create a
relation between your OLAP cube data and your project data.
Since this relation is not created, you cannot join data from
these different sources in a Report Services document and
you cannot support project security filters in OLAP cube
reports.
The diagram below shows two logical models. The one on the
left exists in a specific OLAP cube, and the one on the right
exists in a MicroStrategy project. Although both models have
a Time hierarchy, none of the individual attributes are
shared.
C u b e A ttr ib u te s
C u s to m e r
R e g io n
P r o je c t A ttr ib u te s
Ye a r
R e g io n
C u b e Ye a r
Q u a r te r
C u s to m e r
S ta te
C u b e Q u a r te r
C a ll C e n te r
M onth of
Ye a r
M onth
C ube M o nth
C u s to m e r
C ity
E m p lo ye e
Da y
Example 2: Partially mapped cube
After an OLAP cube source has been included in
MicroStrategy as an OLAP cube, you can map the attributes
within the OLAP cube to existing project attributes.
Example 2, shown in the diagram below, also shows two
logical models. The difference between the two examples is
that the OLAP cube has been partially remapped so that it
shares the attributes Year, Quarter, and Month. With this
technique, you can create a Report Services document that
contains Year, Quarter, and Month information for both your
358 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
data warehouse and OLAP cube sources. In addition, any
security filters for Year, Quarter, and Month are applied to
OLAP cube reports that include these mapped attributes.
Cu b e A ttrib u te s
C usto m e r
R e gio n
Proje c t A ttrib u te s
R e gio n
Ye a r
Ye a r
Q ua rte r
C usto m e r
S ta te
Q ua rte r
C a ll C e nte r
M o nt h o f
Ye a r
M o nt h
M o nt h
C usto m e r
C ity
Em plo ye e
Da y
The dimensions of OLAP cubes are always shared. Therefore,
when a level is remapped, that change applies to all the OLAP
cubes that share that dimension. In this case, changes to the
Time dimension apply to OLAP cubes in the project that
contain this dimension.
Creating metrics from OLAP cube data with MDX and
compound metric techniques
When you map your OLAP cube data into MicroStrategy, you
can take advantage of MDX (MultiDimensional eXpressions)
to create advanced metrics. Metrics created with MDX
combine the robust set of MDX functions and expressions
with MicroStrategy analytical tools such as prompts. You can
also use basic arithmetic expressions to create these
advanced metrics from OLAP cube data.
Metrics created to map to your OLAP cube data are related
only to their associated OLAP cube. Therefore, these metrics
cannot be directly integrated with data from a separate
relational data source, except by using calculated expressions
in Report Services documents. For information on creating
calculated expressions, see the Designing Documents chapter
of the MicroStrategy Report Services Document Creation
Guide.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
359
B
Connecting to OLAP Cube Sources
Project Design Guide
You can create metrics that map to OLAP cube data using
either of the following techniques:
•
Compound metrics: A compound metric is any
MicroStrategy metric with an expression that includes a
MicroStrategy metric and an arithmetic expression. The
expression can be as simple as a metric multiplied by a
constant value, such as Discount * 1.5, where
Discount is a metric mapped to data in the OLAP cube.
These metrics can also reference multiple MicroStrategy
metrics within the OLAP cube with an expression such as
Revenue - Total Expenses, where Revenue and
Total Expenses are both metrics, to build a Profit metric.
You can use MicroStrategy analytical and aggregation
functions with metrics mapped to OLAP cube data only if
the metric you create is defined as a smart metric. If you
do not make the metric a smart metric you can only use
basic operators (+,-,/,*, and so on). For general
information on smart metrics, see the MicroStrategy
Basic Reporting Guide. For examples of smart metrics,
see the MicroStrategy Advanced Reporting Guide.
•
MDX customization: Rather than relying only on
MicroStrategy to create MDX to return data from your
OLAP cube source, you can create your own custom MDX
to return data for a metric. This technique allows you to
use MDX functions and flexibility to query and report on
your OLAP cube data. The MDX you create is passed to
your OLAP cube source to be executed and to return the
data. You can reference one or more MicroStrategy
metrics mapped to OLAP cube data using custom MDX
just as you can with a standard arithmetic expression. To
use MDX to create your calculated measures you must
enclose MDX in double quotes (“”). For tips and insights
on how to build analysis with MDX in MicroStrategy, see
How to build analysis into metrics with custom MDX,
page 363.
Once you create metrics using these techniques you can
include them in your MicroStrategy reports and report filters
in the same ways that you can include any MicroStrategy
metric. You can also use prompts in these compound and
custom MDX metrics (see Using prompts within OLAP cube
metrics, page 366). The metrics created in this way for an
OLAP cube are stored in a Compound Metrics folder within
the Metrics folder for the OLAP cube.
360 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
You can create these metrics during the initial importing and
mapping procedure of your OLAP cube data with the OLAP
Cube Catalog. These metrics can also be created as a later
modification to an OLAP cube with the OLAP Cube Editor.
The following procedure uses the OLAP Cube Catalog. After
right-clicking an OLAP cube and selecting Edit to access the
OLAP Cube Editor, the steps below apply for the OLAP Cube
Editor, starting with the step to access the Edit menu.
To create a metric from OLAP cube data with MDX and
compound metric techniques
1 Log in to a project that is connected to an OLAP cube
source. For information on connecting to an OLAP cube
source, see one of the following sections, depending on
your OLAP cube source:
•
Connecting to SAP BW servers, page 327
•
Connecting to Essbase servers, page 334
•
Connecting to Analysis Services 2000 servers,
page 337
•
Connecting to Analysis Services 2005 servers,
page 340
2 From the Schema menu, select OLAP Cube Catalog.
•
If the project connects to only one OLAP cube source,
the OLAP Cube Catalog: Cube Selection tab opens.
•
If the project connects to more than one OLAP cube
source the Database Instance dialog box opens. From
the Select the Database Instance drop-down list,
select the OLAP cube source database instance to
connect to and click OK. The OLAP Cube Catalog:
Cube Selection tab opens.
3 Move all the OLAP cubes to import from the Available
Cubes pane to the Selected Cubes pane by using the >
button.
4 Select the Cube Mapping tab.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
361
B
Connecting to OLAP Cube Sources
Project Design Guide
5 From the Catalog\Cube drop-down list, select the OLAP
cube to map to MicroStrategy objects. The OLAP cube
data is displayed in the pane below.
6 From the Edit menu, select Add New Compound Metric.
The Metric Editor opens.
7 Create the expression for your metric:
•
If you are creating a compound metric, you can simply
drag and drop metrics from the OLAP cube’s Metrics
folder, while also including any required constants,
arithmetic operators, and MicroStrategy analytical
and aggregation functions. For example, if you have
Revenue and Cost metrics in your OLAP cube you can
create the expression Revenue - Cost to create a
Profit metric.
can use MicroStrategy analytical and
You
aggregation functions with metrics mapped to
OLAP cube data only if the metric you create is
defined as a smart metric.
•
If you are creating a metric using custom MDX, enter
your custom MDX in the Definition pane of the
Metric Editor. Make sure to enclose the entire
expression in double quotes. For example, you can
enter the following:
“[Measures].[Discount Amount] * 1.5”
cannot validate MDX in the Metric Editor as
You
you can for a standard expression that is not
enclosed by double quotes. Validating MDX
verifies that the entire expression is enclosed in
double quotes; it does not validate the syntax of the
expression.
For an example of creating a metric that includes a
prompt, see Using prompts within OLAP cube metrics,
page 366.
8 Click Save and Close. The Save As dialog box opens.
9 In the Object name text field, enter a name for your
metric.
10 Click Save to save your metric.
362 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
11 Click Save and Close to save your changes to the OLAP
cube.
How to build analysis into metrics with custom
MDX
You can build sophisticated analysis into your OLAP cube
metrics by creating your own custom MDX. This allows you
to further combine the analysis capabilities of MDX and
MicroStrategy. This section provides some tips and best
practices on how to build analysis into metrics with custom
MDX. For additional best practices and examples, refer to the
following MicroStrategy Tech Notes:
•
TN5200-81x-2345—How to create customized metric
expressions for OLAP cube sources in MicroStrategy 8.1.x.
•
TN5200-81x-2342—How to write a custom metric
formula in MDX to ignore grouping on a cube dimension
in MicroStrategy 8.1.x
•
TN5200-81x-2343—How to write a custom metric
formula in MDX to filter on an attribute in MicroStrategy
8.1.x
•
TN5200-81x-2344—How to write a custom metric
formula in MDX to implement a transformation in
MicroStrategy 8.1.x
such analysis requires appropriate
Creating
knowledge of both MDX and MicroStrategy. Be aware
that MicroStrategy does not validate any custom MDX
created by users to build metrics for OLAP cubes.
MDX syntax and functionality is not described in
depth in this section; only basic principles of analysis
with the use of MDX and MicroStrategy is provided.
Basics
Creating your own custom MDX allows you to draw further
analysis from your OLAP cube source into MicroStrategy. To
use MDX to create your metrics you must enclose MDX in
double quotes (“”). For example, “[Measures].[Total
Sales]” is valid syntax for a metric defined with MDX.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
363
B
Connecting to OLAP Cube Sources
Project Design Guide
The expression shown above is a simple expression that
returns the Total Sales data from an OLAP cube. You can also
perform basic arithmetic in your MDX. For example, the
following expression applies a multiplier to the Total Sales
data:
“[Measures].[Total Sales] * .06”
Along with these simple expressions, you can also utilize
MDX functions to create more advanced analysis. When you
include an MDX function in your custom MDX, the function
is passed to the OLAP cube source and processed as a
pass-through function. For example, you can use the MDX
year-to-date (YTD) function to create transformation-style
analysis on your OLAP cube data, as shown below:
“sum(YTD([Quarter].CurrentMember),
[Measures].[Profit])”
This expression returns year-to-date values by quarter for
profit data, as shown in the report below.
Conditional metrics
Using MDX, you can create conditional metrics in
MicroStrategy from your OLAP cube data. A conditional
metric allows you to apply a filter to only one metric on a
report while not affecting the other metrics. Report designers
can include these metrics on reports to view multiple
perspectives of data on the same report. For example, along
with viewing your total revenue on a report, you can also
display revenue for a certain category such as electronics. In
364 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
Connecting to OLAP Cube Sources
B
the example expression below, bold highlights the part of the
expression (including the comma) that applies the condition
to the revenue data:
“([Measures].[Revenue],[Category].[2])”
the example above, 2 identifies the electronics
Incategory.
The values that identify data depend on how
you have defined data in your OLAP cube source.
The report shown below uses this metric to compare total
revenue with electronics revenue.
You can include more than one condition for each metric. For
example, you can create the same metric to return electronics
revenue for only the year 2006. In the example expression
below, a second condition on the year is included by adding
another comma and conditional expression:
“([Measures].[Revenue],[Category].[2],[Year].
[2006])”
Prompts
All of the MDX examples in the sections above are static
expressions, meaning they will produce the same MDX every
time. Using the ApplySimple function, you can include
prompts in your MDX to provide dynamic analysis on your
OLAP cube data. Prompts are objects in MicroStrategy that
provide users the ability to dynamically select what data is
returned to their report to analyze. The example below shows
the basic structure of an ApplySimple statement to create
metrics with custom MDX.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
365
B
Connecting to OLAP Cube Sources
Project Design Guide
ApplySimple(“MDX expression with placeholders
for objects”,object0,object1,...,objectN)
A simple application of this technique is to use a constant
value prompt in your project as a multiplier of metric data as
shown below.
ApplySimple(“([Measures].[Total Sales] / #0)”
,?valueprompt)
In the example syntax above, #0 is a placeholder in the MDX
expression for the value prompt. The syntax for including a
prompt as an object to replace a placeholder is
?promptname.
You can also use this technique with the conditional metrics
techniques described in Conditional metrics, page 364. For
example, rather than always returning the revenue data for
electronics, you can allow users to choose what category to
view revenue for. To provide this analysis to users, you can
include an element list prompt on the Category attribute of
the OLAP cube as shown below.
ApplySimple(“([Measures].[Revenue],#0)”,
?elementlistprompt)
For more information on and a procedure for creating
metrics in OLAP cubes with prompts, see the Using prompts
within OLAP cube metrics section below.
Using prompts within OLAP cube metrics
If you are creating new metrics in your OLAP cube, you can
also include MicroStrategy prompts with the metrics. When
the metrics are included on a report and the report is run, the
prompts are displayed to the user for completion. This adds
flexibility to your queries, allowing users to determine the
data to see on the report.
For metrics created with compound metric techniques
without any custom MDX, you can simply include a prompt
in the metric definition. For metrics created using MDX
expressions, you must use the ApplySimple function to
366 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
Project Design Guide
B
Connecting to OLAP Cube Sources
include prompts in the metric definition. The following types
of prompts can be included with metrics built from custom
expressions:
•
Element list prompts defined on an attribute of the
associated OLAP cube
•
Value prompts
•
Object prompts defined on objects of the associated OLAP
cube
To use prompts within OLAP cube metrics
1 Follow the steps in the procedure above (To create a
metric from OLAP cube data with MDX and compound
metric techniques, page 361) until the step to create an
expression for the metric.
2 Enter your expression in the Definition pane of the
Metric Editor. Make sure to enclose the entire expression
in double quotes. For example, you can enter expressions
similar to the following:
•
([Discount Amount] * ?constantprompt)
This expression applies a special discount amount,
entered by the user running the report. In this
example it is assumed that constantprompt is the
name of a value prompt in the project and Discount
Amount is a metric within the OLAP cube.
•
ApplySimple(“([Measures].[Revenue],#0)”,
?CategoryElementPrompt)
This expression creates a Revenue metric, which is
conditional on an element list prompt answered by the
user running the report. Users can then choose to view
revenue data for different categories such as Books or
Music. In this example it is assumed that
CategoryElementPrompt is the name of an element
list prompt in the project that references a Category
attribute within the OLAP cube.
3 Click Save and Close. The Save As dialog box opens.
© 2007 MicroStrategy, Inc.
Integrating OLAP cubes into MicroStrategy
367
B
Connecting to OLAP Cube Sources
Project Design Guide
4 In the Object name text field, enter a name for your
metric.
5 Click Save to save your metric and return to the OLAP
Cube Catalog.
6 Click Save and Close to save your changes to the OLAP
cube and exit the OLAP Cube Catalog.
Removing compound metrics from OLAP cubes
When you remove metrics based on multiple metrics of an
OLAP cube, dependencies may need to be resolved before you
can remove the metric. When you try to remove a metric with
dependent metrics, a list of metrics that are dependent on the
metric you are removing is returned. If a compound metric of
an OLAP cube has been added to any reports, a list of reports
that depend on the metric is also returned. You must remove
all of the metrics and reports which depend on the metric you
are trying to remove. Then you can remove the metric.
can remove the compound metric from the report
You
rather than deleting the report. This removes the
dependency between the metric and the report, and
you can then remove the metric from the OLAP cube.
For example, you import an OLAP cube, and its data is
automatically mapped to MicroStrategy metrics. You then
create a new compound metric named Profit within the OLAP
cube by subtracting the OLAP cube’s cost data from its
revenue data. Once this metric is created in your OLAP cube,
you create a Profit Margin metric that uses the Profit metric
you just created. This makes the Profit Margin metric
dependent on the Profit metric. If you try to remove the Profit
metric, a search for dependent objects is automatically
triggered, and the Profit Margin metric is returned. To
remove the Profit metric, you must first remove the Profit
Margin metric. If the Profit metric is included on any reports,
you need to also delete those reports or remove the Profit
metric from the reports before you can remove the Profit
metric from the OLAP cube.
368 Integrating OLAP cubes into MicroStrategy
© 2007 MicroStrategy, Inc.
C
C.
LOGICAL TABLES
Introduction
Logical tables represent tables in the data warehouse. There
are three types of logical tables in the MicroStrategy
environment: logical tables, table aliases, and logical views.
While logical tables are set up in a project by using the
Warehouse Catalog, logical views are created using the Table
Editor. Different from the logical tables, which point to
physical tables in the data warehouse, logical views are
defined using SQL queries against the data warehouse.
This chapter introduces you to the different types of logical
tables, with a focus on how you can use the logical view
feature to take advantage of the enhanced schema support in
MicroStrategy.
© 2007 MicroStrategy, Inc.
369
C
Logical Tables
Project Design Guide
Logical tables
Logical tables are MicroStrategy objects that form the
foundation of a schema. While physical tables in a data
warehouse consist of columns, logical tables in the
MicroStrategy schema consist of attributes and facts. These
attributes and facts are part of the report definition that the
MicroStrategy Engine refers to when a report is executed.
There are three types of logical tables:
1 Logical table: is a logical representation of a table that
the Engine uses to generate SQL. A logical table is created
for each physical table that is imported into a project,
using the Warehouse Catalog. This type of logical table
maps directly to physical tables in the data warehouse.
These physical tables are referenced in the SQL that is
generated for the report.
2 Table alias: is an additional logical table that points
directly to an existing physical table. A table alias is
created outside of the Warehouse Catalog. A table alias
can have a different name from the physical table. One
physical table can have more than one table aliases. Table
aliasing is used to create attribute roles (see Attributes
that use the same lookup table: Attribute roles, page 175).
3 Logical view: is a logical table that points to a SQL
statement instead of directly to a physical table. It does
not point directly to a physical table and is defined using a
SQL query against the warehouse. Once created, the
logical view can be used in the same way as the Type 1
logical table, based on which attributes, facts, and other
schema objects can be defined. The logical view is also
referenced in the SQL that is generated for the report; the
whole SQL query is displayed in the place of physical
tables as for Type 1 logical tables. Logical views are
created using the Table Editor.
In the MicroStrategy Tutorial, logical tables and all the other
schema objects are stored in the Schema Objects folder.
Using the Logical Table Editor, you can define your logical
view using the SQL statement as well as view the content of
all the logical tables and their associated warehouse tables.
370 Logical tables
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
How should I use logical tables?
The most common logical tables are the ones that are
imported into the project from the data warehouse using the
Warehouse Catalog, which is accessed from the Schema
menu. Based on these tables, you can create MicroStrategy
schema objects, such as attributes and facts. For more
information on how to use the Warehouse Catalog, please
refer to the MicroStrategy online help (search for
“Warehouse Catalog”).
When an attribute plays more than one role, you need to
create an attribute in the logical model for each of the roles.
One way to do this is to create explicit table aliases. Basically,
you create multiple logical tables pointing to the same
physical table and define those logical tables as the lookup
tables for the attributes in different roles.
For example, if the Customer table is used to represent both
Ship to Customer and Bill to Customer, you can create a table
alias to resolve the double usage case. First, create a table
alias by copying an existing logical table and giving it a new or
different name; then define the new attributes using the
appropriate tables.
For detailed information on attribute roles, please refer to
Attributes that use the same lookup table: Attribute roles,
page 175. To create a table alias, right-click the logical table
name and select Create Table Alias. For step-by-step
instructions, please refer to the MicroStrategy online help
(search for “Step-by-step instructions to create a table alias”).
Logical views are a little different from the above-mentioned
logical tables and table aliases for the following reasons:
© 2007 MicroStrategy, Inc.
•
Logical views do not map directly to physical tables in the
data warehouse.
•
Logical views are defined using SQL queries.
•
Logical views are created from scratch, instead of being
imported from a data warehouse or duplicated from
existing logical tables.
How should I use logical tables?
371
C
Logical Tables
Project Design Guide
However, once logical views are created, they can be used in
the same way as the regular logical tables (brought into the
project using the Warehouse Catalog). This means that you
can use the logical views to build attributes and facts and that
you can also create table aliases for the logical views.
The biggest benefit of using logical views is that you can
model a MicroStrategy schema that cannot be supported with
only the physical database structures in the warehouse. There
are many common modeling scenarios that are easier to
manage with the use of logical views, such as the following:
•
Slowly-changing dimensions
•
Attribute form expressions from multiple tables
•
Consolidated dimension tables
•
Recursive hierarchies
For common usage examples, please refer to Logical view
examples, page 376.
you create or add logical tables, table
Whenever
aliases, or logical views to the project, you need to
update the schema. The Update Schema option can be
accessed from the Schema menu.
372 How should I use logical tables?
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
Creating logical tables
Most logical tables are brought into the project by using the
Warehouse Catalog, and table aliases are created by
duplicating existing logical tables. Detailed instructions on
how to create them are provided in the online help (search for
“Tables”).
Logical views, on the other hand, are created in
MicroStrategy Desktop using the Table Editor. One way to
access the Table Editor is to select New from the File menu
and choose Logical Table.
As illustrated in the following image, Object Browser lists all
tables and columns that have been imported into the project.
Any physical table in the project database instance can be
used in the SELECT statement. The SQL statement panel is
where you type in your SQL query, while the Mapping panel
is where you map for the columns returned by the SQL query.
Creating a Logical View involves a few simple steps that
require you to provide your own SQL statement and map the
columns in the statement to the correct data types (see the
following information). For detailed instructions, please refer
to the online help (search for “Creating logical views”).
© 2007 MicroStrategy, Inc.
Creating logical tables
373
C
Logical Tables
Project Design Guide
To create a logical table in the Table Editor
1 From the File menu, select New and then Logical Table.
The Table Editor is displayed with the Physical View tab
selected by default.
2 In the SQL Statement panel, type in your SQL statement.
You can drag and drop columns from the Object Browser
to insert into the statement).
is recommended that you use derived tables to
Itdefine
logical views because the logical view SQL
syntax becomes nested inside SQL statements
generated by the Engine. Although common table
expressions (CTEs) are also supported for some
databases, these expressions cannot be nested in
the SQL because this would result in invalid SQL
syntax. Please check your database for best usage.
3 Click Add to map columns returned by the SQL
statement.
4 Type in the column name under Column Object. This
creates a new column.
Alternatively, you can also drag and drop columns from
the Object Browser to the Column Object cell. By doing
this, you map an existing column to the logical view.
names of the columns must match exactly the
The
column aliases defined in the SQL statement.
However, the order of the columns does not have to
match the order in which the column aliases
appear in the SQL statement.
5 Select a Data Type for the column by using the
drop-down list.
an existing column in the mapping in
IfStepyou5,used
you inherited the data type of that column.
Keep in mind that if you change the data type, the
change will affect all the tables with that column.
374 Creating logical tables
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
6 Modify the Precision and Scale of the column, if
applicable.
7 Save and close the logical table.
8 From the Schema menu, select Update Schema to ensure
that the new logical table is loaded into the project.
Using SQL for logical views
Since SQL queries are the key to creating logical views, you
should be experienced with using SQL before you use the
logical view feature. It is your responsibility to ensure the
accuracy and validity of your SQL statements. In addition,
you should also understand that the SQL query entered for
logical views is not modified in any way by MicroStrategy.
Therefore, make sure that your RDBMS is optimized to
answer the query that you create.
Because the MicroStrategy Engine does not parse through the
SQL syntax, the statistics log does not contain any
information about the actual physical tables accessed; the
logical view is logged instead. The same holds true if you use
a view in the database, in which case table objects accessed
would are not logged either.
In the SQL generated for a report, logical views are generated
as either a derived table or a common table expression (CTE)
depending on the type of database that you use. It is
recommended that you use derived tables to define logical
views, although CTEs are also supported by some databases.
Derived tables are advantageous because they are nested in
the SQL generated by the Engine. CTEs, however, are not
nested in the SQL because this would result in invalid SQL
syntax. For best usage, please check your database.
When the Engine needs to use a logical table that maps
directly to a physical database table, it inserts the name of the
table into the FROM clause. For a logical view—which maps
to a SQL statement—the Engine inserts the SQL syntax in the
FROM clause. The Engine generates derived table syntax to
represent the logical view.
© 2007 MicroStrategy, Inc.
Creating logical tables
375
C
Logical Tables
Project Design Guide
results of logical views are not cached; the logical
The
view simply appears as additional syntax in the report
SQL generated by MicroStrategy.
Logical view examples
The following business cases are intended to help you
understand how you can use the logical view feature in your
applications.
Business case 1: Distinct attribute lookup table
Many star schemas feature a single lookup table that is
shared by all the attributes in one dimension (see the
following example). While it is possible to model a schema
with such a dimension table, often two problems arise:
•
The model cannot support fact tables at the level of
attributes that are not keys. This restriction applies to
summary tables as well as to intermediate results that
may be generated by the SQL Engine.
Usually, in one-SQL-pass reports, the MicroStrategy
Engine joins the fact table with one lookup table and does
the aggregation. If there is no distinct list of attribute
elements, you may double count if you have to join to a
table where that attribute is part of the key.
•
Too many rows in the dimension table may slow down the
SELECT DISTINCT query, thus affecting element
browsing requests that display a list of attribute elements,
for example, when populating pick lists for prompts.
The following is an example lookup table for Store, Market,
and Region.
Lookup_store
Store_ID
Store_Name
376 Logical view examples
Market_ID
Market_Name
Region_ID
Region_Name
Level
© 2007 MicroStrategy, Inc.
Project Design Guide
Logical Tables
C
In this table, Market and Region are not the keys. Therefore,
if the requested fact table is at the Market or Region level, a
direct join between the fact table and the above lookup table
may result in double-counting. To avoid that, you can use the
Logical View feature to define another logical table
Lookup_Market as follows:
Select Market_ID, Market_Name,Region_ID
From Lookup_store
Where level=1
Then use this table as the lookup table for Market. When it is
joined with a Market-level fact table (Market_Sales), the
following report SQL is generated:
Select a11.Market_ID,a11.Market_Desc,
SUM(a12.Sales)
From (select Market_ID, Market_Name,Region_ID
from Lookup_Store
where level=1) a11,
Market_Sales a12
Where a11.Market_ID = a12.Market_ID
Group by a11.Market_ID,
a11.Market_Name
Business case 2: Attribute form expression across multiple
tables
Customers often request the ability to generate an attribute
form expression across multiple tables. Usually, the case is on
Date columns. For example, you want to define an attribute
based on the Date difference between two Date columns
(Ship_Date and Order_Date) in two different tables as
follows.
F_Table1
Ship_Date
© 2007 MicroStrategy, Inc.
Order_ID
Fact1
Logical view examples
377
C
Logical Tables
Project Design Guide
F_Table2
Order_Date
Order_ID
Fact2
Using the Logical View feature, you can use the following SQL
query to create a logical table to calculate the Date difference
and then define the attribute on that new column:
Select Ship_Date-Order_Date Cycle_time,
F_table1.Order_ID, Fact1,Fact2
From F_table1, F_table2
Where F_table1.Order_ID=F_table2.Order_ID
The new logical table (logical view) looks like the following
table, and a new attribute can be defined on the Cycle_Time
column.
Logical view
Cycle_Time
Order_ID
Fact1
Fact2
Business case 3: Slowly changing dimensions
Slowly changing dimensions (SCDs) are a common
characteristic in many business intelligence environments.
Usually, dimensional hierarchies are presented as
independent of time. For example, a company may annually
reorganize their sales organization or recast their product
hierarchy for each retail season. “Slowly” typically means
after several months or even years. Indeed, if dimensional
relationships change more frequently, it may be better to
model separate dimensions.
SCDs are well documented in the data warehousing
literature. Ralph Kimball has been particularly influential in
describing dimensional modeling techniques for SCDs (see
The Data Warehouse Toolkit, for instance). Kimball has
further coined different distinctions among ways to handle
SCDs in a dimensional model. For example, a Type I SCD
378 Logical view examples
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
presents only the current view of a dimensional relationship,
a Type II SCD preserves the history of a dimensional
relationship, and so forth.
The discussion below is based on an example sales
organization that changes slowly in time as the territories are
reorganized; for example, sales representatives switch
districts in time.
As-is vs. as-was analysis
One of the capabilities available with slowly changing
dimensions is the ability to perform either “as-is” analysis or
“as-was” analysis:
•
“As-is” analysis presents a current view of the slowly
changing relationships. For example, show me sales by
District according to the way Districts are organized
today.
•
“As-was” analysis presents a historical view of the slowly
changing relationships. For example, show me sales by
District according to the way Districts were organized at
the time the sales transactions occurred.
The techniques described here provide the flexibility to
perform either type of analysis. They also provide you an easy
way to specify which type of analysis you would like to
perform.
Example 1: Compound key with Effective Date
and End Date
One way to physically store an SCD is to employ Effective
Date and End Date columns that capture the period of time
during which each element relationship existed. In the
example below, Sales Rep Jones moved from District 37 to
District 39 on 1/1/2004, and Kelly moved from District 38 to
39 on 7/1/2004.
information on compound keys, please refer to
For
Lookup tables: Attribute storage, page 43.
© 2007 MicroStrategy, Inc.
Logical view examples
379
C
Logical Tables
Project Design Guide
LU_SALES_REP
Sales_Rep_ID
Sales_Rep_Name
District_ID
Eff_Dt
End_Dt
1
Jones
37
1/1/1900
12/31/2003
2
Smith
37
1/1/1900
12/31/2099
3
Kelly
38
1/1/1900
6/30/2004
4
Madison
38
1/1/1900
12/31/2099
1
Jones
39
1/1/2004
12/31/2099
3
Kelly
39
7/1/2004
12/31/2099
When using this type of dimensional lookup table, the fact
table must include a date field, such as a transaction date.
FACT_TABLE
Sales_Rep_ID
Trans_Dt
Sales
1
9/1/2003
100
2
9/10/2003
200
3
9/15/2003
150
1
3/1/2004
200
2
3/10/2004
250
3
3/15/2004
300
2
9/5/2004
125
3
9/15/2004
275
4
9/20/2004
150
To specify the MicroStrategy schema
1 Create a logical view to represent just the current
District-Sales Rep relationships.
LVW_CURRENT_ORG
380 Logical view examples
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
select Sales_Rep_ID, District_ID
from LU_SALES_REP
where End_Dt = '12/31/2099'
2 Create another logical view that performs the “as-was”
join between the lookup table and fact table, resulting in a
fact view at the District level.
resulting view is an “as-was” or historical view,
The
which captures the Sales Rep-District relationships
that existed at the time the transactions occurred.
LVW_HIST_DISTRICT_SALES
select District_ID, Trans_Dt, sum(sales)
sales
from LU_SALES_REP L
join FACT_TABLE F
on(L.Sales_Rep_ID = F.Sales_Rep_ID)
where F.Trans_Dt between L.Eff_Dt and
L.End_Dt
group by District_ID, Trans_Dt
3 Create a table alias LU_CURRENT_DISTRICT for
LU_DISTRICT.
4 Define the following attributes:
•
Sales Rep:
– @ID = sales_rep_id; @Desc = sales_rep_name
– Tables: LU_SALES_REP (lookup),
LVW_CURRENT_ORG, FACT_TABLE
•
Current District:
– @ID = district_id; @Desc = district_name
– Tables: LU_CURRENT_DISTRICT (lookup),
LVW_CURRENT_ORG
– Child: Sales Rep
•
Historical District:
– @ID = district_id; @Desc = district_name
© 2007 MicroStrategy, Inc.
Logical view examples
381
C
Logical Tables
Project Design Guide
– Tables: LU_DISTRICT (lookup),
LU_SALES_REP, LVW_HIST_DISTRICT_SALES
– Child: Sales Rep
•
Date:
– @ID = date_id, trans_dt
– Tables: LU_TIME (lookup) , FACT_TABLE,
LVW_HIST_DISTRICT_SALES
•
Month:
– @ID = MONTH_ID
– Tables: LU_TIME (lookup)
5 Define the Sales fact:
•
Expression: sales
•
Tables: FACT_TABLE,
LVW_HIST_DISTRICT_SALES
6 Define the metric as required:
•
Sales: SUM(sales)
The result of this is a logical schema that looks like the
following:
LU_CURRENT_DISTRICT
LU_CURRENT_ORG
LU_SALES_REP
FACT_TABLE
Current District
Sales Rep
Sales Rep
Sales Rep
Current District
Historical
District
Date
LU_TIME
Sales
Date
LVW_HISTORICAL_
DISTRICT_SALES
Month
Historical District
Date
Sales
382 Logical view examples
© 2007 MicroStrategy, Inc.
Project Design Guide
Logical Tables
C
As-was analysis
Specify the “as-was” analysis by using the Historical District
attribute on reports:
•
Report definition: Historical District, Month, Sales
•
Resulting SQL
Select a11.District_ID District_ID,
max(a13.District_Name) District_Name,
a12.Month_ID Month_ID,
sum(a11.SALES) WJXBFS1
From (select District_ID, Trans_dt,sum(sales)
sales
from LU_SALES_REP L
join FACT_TABLE F
on (L.Sales_rep_ID = F.Sales_rep_ID)
where F.trans_dt between L.EFF_DT and
L.END_DT
group by District_ID, Trans_dt)
a11
join LU_TIME a12
on (a11.Trans_dt = a12.Date_ID)
join LU_DISTRICT a13
on (a11.District_ID =a13.District_ID)
group by a11.Distrcit_ID,
a12.Month_ID
•
Report results
As-is analysis
Specify the “as-is” analysis by using the Current District
attribute on reports:
© 2007 MicroStrategy, Inc.
•
Report definition: Current District, Month, Sales
•
Resulting SQL
Logical view examples
383
C
Logical Tables
Project Design Guide
select a12.District_ID District_ID,
max (a14.District_Name) District_Name,
a13.Month_ID Month_ID,
sum(a11.SALES) WJXBFS1
from FACT_TABLE a11
join (select Sales_rep_ID, District_ID
from LU_SALES_REP
where END_DT = '12/31/2099')a12
on (a11.Sales_Rep_ID =
a12.Sales_Rep_ID)
join LU_TIME a13
on (a11.Trans_dt = a13.Date_ID)
join LU_DISTRICT a14
on (a12.District_ID = a14.District_ID)
group by a12.District_ID,
a13.Month_ID
•
Report result
Example 2: New surrogate key for each changing
element
A more flexible way to physically store a SCD is to employ
surrogate keys and introduce new rows in the dimension
table whenever a dimensional relationship changes. Another
common characteristic is to include an indicator field that
identifies the current relationship records. An example set of
records is shown below.
LU_SALES_REP
Sales_Rep_CD
Sales_Rep_ID
Sales_Rep_Name
District_ID
Current_Flag
1
1
Jones
37
0
2
2
Smith
37
1
3
3
Kelly
38
0
384 Logical view examples
© 2007 MicroStrategy, Inc.
Project Design Guide
Logical Tables
C
Sales_Rep_CD
Sales_Rep_ID
Sales_Rep_Name
District_ID
Current_Flag
4
4
Madison
38
1
5
1
Jones
39
1
6
3
Kelly
39
1
When using this type of dimensional lookup table, the fact
table must also include the surrogate key. A transaction date
field may or may not exist.
FACT_TABLE
Sale-Rep_CD
Sale
1
100
2
200
3
150
5
200
2
250
3
300
2
125
6
275
4
150
Specifying the MicroStrategy schema
1 Create a logical view to represent just the current
District-Sales Rep relationship.
LVW_CURRENT_ORG
select Sales_rep_ID, District_ID
from LU_SALES_REP
where Current_flag = 1
2 Create a table alias LU_CURRENT_DISTRICT for
LU_DISTRICT.
© 2007 MicroStrategy, Inc.
Logical view examples
385
C
Logical Tables
Project Design Guide
3 Define the following attributes:
•
Sales Rep Surrogate:
– @ID = sales_rep_cd
– Tables: LU_SALES_REP (lookup), FACT_TABLE
•
Sales Rep:
– @ID = sales_rep_id; @Desc = sales_rep_name
– Tables: LU_SALES_REP (lookup),
LVW_CURRENT_ORG
– Child: Sales Rep Surrogate
•
Current District:
– @ID = district_id; @Desc = district_name
– Tables: LU_CURRENT_DISTRICT (lookup),
LVW_CURRENT_ORG
– Child: Sales Rep
•
Historical District:
– @ID = district_id; @Desc = district_name
– Tables: LU_DISTRICT (lookup), LU_SALES_REP
– Child: Sales Rep
•
Date:
– @ID = date_id, trans_dt
– Tables: LU_TIME (lookup), FACT_TABLE
•
Month:
– @ID = MONTH_ID
– Tables: LU_TIME (lookup)
– Child: Date
4 Define the Sales fact:
•
386 Logical view examples
Expression: sales
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
•
Tables: FACT_TABLE,
LVW_HIST_DISTRICT_SALES
5 Define the metric as required:
•
Sales: SUM(sales)
The result is a logical schema as follows:
LU_CURRENT_DISTRICT
LU_CURRENT_ORG
LU_SALES_REP
FACT_TABLE
LU_TIME
Current District
Sales Rep
Sales Rep
Surrogate
Sales Rep
Surrogate
Date
Current District
Sale rep
Date
Month
Historical
District
Sales
LVW_HISTORICAL_
DISTRICT_SALES
Historical District
As-was analysis
Specify the “as-was” analysis by using the Historical District
attribute on reports:
•
Report definition: Historical District, Month, Sales
•
Resulting SQL
select a12.District_ID District_ID,
max(a14.Distrcit_Name) Distrcit_Name,
a13.Month_ID Month_ID,
sum(a11.SALES) WJXBFS1
from FACT_TABLE a11
join LU_SALES_REP a12
on (a11.Sales_Rep_CD =
a12.Sales_Rep_CD)
join LU_TIME a13
on (a11.Trans_dt = a13.Date_ID)
join LU_DISTRICT a14
on (a12.District_ID =
© 2007 MicroStrategy, Inc.
Logical view examples
387
C
Logical Tables
Project Design Guide
a14.District_ID)
group by a12.District_ID,
a13.Month_ID
•
Report results
As-is analysis
Specify the “as-is” analysis by using the Current District
attribute on reports:
•
Report definition: Current District, Month, Sales
•
Resulting SQL:
select a13.District_ID District_ID,
max(a15.Distrcit_Name) District_Name,
a14.Month_ID Month_ID,
sum(a11.SALES) WJXBFS1
from FACT_TABLE a11
join LU_SALES_REP a12
on (a11.Sales_Rep_CD =
a12.Sales_Rep_CD)
join (select Sales_rep_ID, District_ID
from LU_SALES_REP
where current_flag = 1)
a13
on (a12.Sales_Rep_ID =
a13.Sales_Rep_ID)
join LU_TIME a14
on (a11.Trans_dt = a14.Date_ID)
join LU_DISTRICT a15
on (a13.District_ID =
a15.District_ID)
group by a13.District_ID,
a14.Month_ID
388 Logical view examples
© 2007 MicroStrategy, Inc.
Project Design Guide
C
Logical Tables
•
Report result
Business case 4: One-to-many transformation tables
In order to support time-series analysis, such as
month-to-date and year-to-date calculations, you need to
define transformations. Although one-to-one
transformations, such as Last Month, can be defined in terms
of an expression, one-to-many transformations require tables
in the database that map each date to all the previous dates
that make up “month-to-date”.
If you do not already have such a table in the warehouse and
your circumstances do not allow you to add additional tables
to the database, then you can use the logical view approach to
address this issue as long as you already have a lookup table
for the Day attribute.
The SQL below can be used to define a logical MTD_DATE
table, which contains the Day attribute. The MTD
transformation can then be defined using the MTD_DATE
column.
Select day_date day_date, B.day_date mtd_date
From lu_day A, lu_day B
Where A.day_date >= B.day_date
And MONTH(A.day_date)= MONTH(B.day_date)
The same technique can be used to define a year-t0-date
transformation.
Select A.day_date day_date, B.day_date
ytd_date
From lu_day A, lu_day B
Where A.day_date >= B.day_date
And YEAR(A.day_date) = YEAR(B.day_date)
© 2007 MicroStrategy, Inc.
Logical view examples
389
C
Logical Tables
Project Design Guide
Business case 5: Outer joins between attribute lookup tables
A common request is the ability to generate an outer join
between attribute lookup tables for a report that contains
only attributes (that is, no metrics). For example, consider
the tables below.
EMPLOYEE
EMERGENCY CONTACT
DEPARTMENT
EMP_ID
EMP_ID
DEPT_ID
FIRST_NAME
CONTACT_FIRST_NAME
DEPT_NAME
LAST_NAME
CONTACT_LAST_NAME
BUS_UNIT_ID
HIRE_DATE
CONTACT_PHONE_NUMBER
DEPT_ID
Given this structure, you could model an attribute hierarchy
as follows:
•
Business Unit -< Department -< Employee
•
Hire Date -< Employee
•
Emergency Contact -< Employee
In addition, the relationship between Employees and
Emergency Contacts is such that each employee may have up
to one contact, which means not all employees have contacts
on record. One of the reports you probably would like to
create may look like the following:
Employee
Department
Emergency Contact
Phone Number
Gonzalez, James
Marketing
Dawson, John
Finance
Dawson, Jane
555-1212
Larkins, Abraham
R&D
Taylor, Mary
555-3456
Walker, George
Finance
Walker, Martha
555-9876
...
...
...
...
are displayed for employees who do not have
NULLS
emergency contacts.
390 Logical view examples
© 2007 MicroStrategy, Inc.
Project Design Guide
Logical Tables
C
However, if you model the attributes as described below, you
would not get the desired output:
•
•
•
•
Employee:
@ID = EMP_ID, @[First Name] = FIRST_NAME,
@[Last Name] = LAST_NAME
Tables: EMPLOYEE (lookup),
EMERGENCY_CONTACT
Department:
@ID = DEPT_ID
Tables: DEPARTMENT (lookup), EMPLOYEE
Child: Employee
Hire Date:
@ID = HIRE_DATE
Tables: EMPLOYEE (lookup)
Child: Employee
Emergency Contact:
@ID = CONTACT_PHONE_NUMBER, @[First
Name] = CONTACT_FIRST_NAME, @[Last Name] =
CONTACT_LAST_NAME
Tables: EMERGENCY_CONTACT (lookup)
Child: Employee
Using the above model, the SQL generated would join the
EMPLOYEE table to the EMERGENCY_CONTACT table,
and only those employees who have emergency contacts
would appear in the final result. In order to see all employees,
you can perform an outer join using a logical view, described
as follows.
© 2007 MicroStrategy, Inc.
Logical view examples
391
C
Logical Tables
Project Design Guide
Using a logical view for an outer join
To perform an outer join for the case described above, you
can use the following SQL and the list of columns to map to
the view:
select E.EMP_ID,
E.FIRST_NAME,
E.LAST_NAME,
E.HIRE_DATE,
E.DEPT_ID,
C.CONTACT_FIRST_NAME,
C.CONTACT_LAST_NAME,
C.CONTACT_PHONE_NUMBER
from EMPLOYEE E
left outer join EMERGENCY_CONTACT C
on (E.EMP_ID = C.EMP_ID)
LVW_EMERGENCY_CONTACT
EMP_ID
FIRST_NAME
LAST_NAME
HIRE_DATE
DEPT_ID
CONTACT_FIRST_NAME
CONTACT_LAST_NAME
CONTACT_PHONE_NUMBER
Make sure to include all columns from the original child table
(for example, EMPLOYEE). The new logical table
LVW_EMERGENCY_CONTACT can then be used to define
attributes as follows:
•
392 Logical view examples
Employee:
@ID = EMP_ID, @[First Name] = FIRST_NAME,
@[Last Name] = LAST_NAME
Tables: EMPLOYEE (lookup),
LVW_EMERGENCY_CONTACT
© 2007 MicroStrategy, Inc.
Project Design Guide
Logical Tables
•
•
•
C
Department:
@ID = DEPT_ID
Tables: DEPARTMENT (lookup), EMPLOYEE,
LVW_EMERGENCY_CONTACT
Child: Employee
Hire Date:
@ID = HIRE_DATE
Tables: EMPLOYEE (lookup),
LVW_EMERGENCY_CONTACT
Child: Employee
Emergency Contact:
@ID = CONTACT_PHONE_NUMBER, @[First
Name] = CONTACT_FIRST_NAME, @[Last Name] =
CONTACT_LAST_NAME
Tables: EMERGENCY_CONTACT (lookup),
LVW_EMERGENCY_CONTACT
Child: Employee
Employee attribute is not represented in the
The
original EMERGENCY_CONTACT table and all
attributes represented in the EMPLOYEE table are
also represented in the
LVW_EMERGENCY_CONTACT table.
Now if we run a report with Employee and Emergency
Contact attributes, the EMPLOYEE table will be outer joined
to the EMERGENCY_CONTACT table, and NULLs will be
returned for any employees who do not have emergency
contacts. Also note that if we run a report that includes only
the Employee attribute, it will be executed against the
EMPLOYEE table; the EMERGENCY_CONTACT table will
be joined only when necessary.
This technique is applicable any time that the lookup tables
should always be outer joined. The technique does not work
when the lookup tables should sometimes be outer joined and
sometimes be inner joined.
© 2007 MicroStrategy, Inc.
Logical view examples
393
C
Logical Tables
394 Logical view examples
Project Design Guide
© 2007 MicroStrategy, Inc.
D
D.
DATA TYPES
Introduction
To generate SQL or retrieve data from data sources,
MicroStrategy must be aware of the data types that exist in
your database. As each RDBMS supports a different set of
data types, MicroStrategy generalizes them into a set of
MicroStrategy-specific data types.
Mapping of external data types to
MicroStrategy data types
When you create a project and add tables from your data
warehouse to the MicroStrategy Warehouse Catalog,
MicroStrategy automatically maps the columns within those
tables to MicroStrategy-specific data types. Each column
from your database becomes associated with a MicroStrategy
data type.
© 2007 MicroStrategy, Inc.
Mapping of external data types to MicroStrategy data types
395
D
Data Types
Project Design Guide
This external-to-internal mapping is necessary, in part,
because each database names data types in different ways.
Data types that may be conceptually the same can have
different names. Therefore, MicroStrategy must map every
column brought into the project schema to an internal data
type.
Suppose you add a table to the Warehouse Catalog. In your
relational database, a column within that table has a data
type of “SMALLINT.” MicroStrategy maps this column to a
MicroStrategy-specific data type, for example, “INTEGER.”
This allows MicroStrategy to maintain a consistent SQL
generation process.
The MicroStrategy data type stores data values internally and
in the metadata repository and is later used during SQL
generation when defining intermediate tables, and data mart
tables, and generating the correct syntax for literals. The data
type is also used whenever multi-pass SQL is used, as with
custom groups. For more information about data marts and
custom groups, see the MicroStrategy Advanced Reporting
Guide.
information about how your relational database’s
For
data types are mapped to MicroStrategy data types
and the specific mappings that pertain to your
RDBMS, refer to MicroStrategy Technical Note
TN5200-7X0-0166.
is strongly recommended that you do not alter the
Itmapping
file (DTMAPPING.pds) in any way.
396 Mapping of external data types to MicroStrategy data types
© 2007 MicroStrategy, Inc.
Project Design Guide
Data Types
D
MicroStrategy data types
When the data warehouse catalog is read from the
Warehouse Catalog, all columns in the database are
automatically mapped to one of the following MicroStrategy
data types.
Data Type
Description
Big Decimal
High-precision fixed point numbers.
Binary
Fixed-length bit strings.
Similar to ANSI BIT.
Char
Fixed-length character strings.
Similar to ANSI CHAR.
Date
Calendar dates.
Similar to ANSI DATE.
Decimal
Fixed point numbers up to 15 digits of precision.
Similar to ANSI DECIMAL.
Double
8-byte floating point numbers.
Similar to ANSI DOUBLE PRECISION.
Float
4-byte floating point numbers.
Similar to ANSI FLOAT.
Integer
Signed integer values.
Similar to ANSI INTEGER.
LongVarBin
Large strings of bits.
Similar to ANSI BLOB.
LongVarChar
Large strings of characters.
Similar to ANSI CLOB.
Numeric
Fixed point numbers up to 15 digits of precision.
Similar to ANSI NUMERIC.
Real
4-byte floating point numbers.
Similar to ANSI REAL.
Time
Time of day.
Similar to ANSI TIME.
Timestamp
Combinations of calendar date and time of day.
Similar to ANSI TIMESTAMP.
Unsigned
© 2007 MicroStrategy, Inc.
Unsigned integer values.
MicroStrategy data types
397
D
Data Types
Project Design Guide
Data Type
Description
Varbin
Variable-length bit strings.
Similar to ANSI BIT VARYING.
Varchar
Variable-length character strings.
Similar to ANSI VARCHAR.
Catalog displays a column with data
IftypetheasWarehouse
Unknown, it implies that the data type in the
database has not mapped to one of the MicroStrategy
data types.
Format types
Attribute forms are also associated with a MicroStrategy
format type, which specifies how attribute form values should
be displayed on MicroStrategy interfaces. You specify the
format type of an attribute form in the Form Format: Type
drop-down menu in the Attribute Editor.
The attribute form format types are described in the
following table.
398 Format types
Format Type
Description
Big Decimal
Information is stored and displayed in the Big Decimal
form, which represents high-precision fixed point
numbers. For more information about Big Decimal, see
Big Decimal, page 400.
Date
Information is stored and displayed as dates in a
sequential form to perform calculations on the dates. It
represents dates in the MM/DD/YYYY format.
Datetime
Information is stored and displayed both as date and
time in the format specific to the data. The date follows
the MM/DD/YYYY format and time follows the
HH:MM:SS format.
Email
Information is stored and displayed in the form of an
e-mail address.
HTML Tag
Information is stored and displayed as an HTML tag.
Number
Information is stored and displayed in a number format.
© 2007 MicroStrategy, Inc.
Project Design Guide
D
Data Types
Format Type
Description
Picture
stored and displayed the form of an image file, such as
bitmap, JPG, or GIF.
Text
Information is stored and displayed in a text format.
Time
Information is stored and displayed as time in the
HH:MM:SS format. This displays only the time and not
the date.
URL
Information is stored and displayed as either an
absolute or a relative Universal Resource Locator.
Data type and format type compatibility
If you change the MicroStrategy data type of one of the
columns in your project—using a column alias, for
example—you must also change the format type of the
attribute. The data type of your column must be consistent
with the format type you select because SQL generation
issues can occur if the format type and data type are
incompatible. You are warned in the Attribute Editor
whenever you have selected a format type that is
incompatible with the data type of your column.
For example, you edit the ID form of the Year attribute in the
Attribute Editor. In the Column Alias tab, you notice that the
Year attribute is assigned an “Integer” data type. However,
you create a new column alias and assign it the “Date” data
type.
When you return to the Definition pane in the Attribute
Editor, you must select an appropriate format type from the
Form Format: Type drop-down menu. This format type must
be compatible with the data type you assigned in the Column
Alias tab. If you select a format type that is incompatible with
the data type and click OK to exit the Attribute Editor, a
warning message appears notifying you of the
incompatibility. Although you have the option to continue by
clicking Yes, doing so can still result in SQL generation
issues.
© 2007 MicroStrategy, Inc.
Data type and format type compatibility
399
D
Data Types
Project Design Guide
The following chart is intended to guide you in assigning
format types that are compatible with the data type you have
assigned to a column.
format types are compatible with different
Different
data types given the specific data in your column.
Therefore, some of the data type-format type
combinations below may not work with your specific
data.
Data Type
Compatible Format Types
Big Decimal
Big Decimal
Binary
Number, Text, Picture
Char
Text, URL, E-mail, HTML Tag
Date
Date, Datetime
Decimal
Number
Double
Number
Float
Number
Integer
Number
LongVarBin
Picture, Text depending on data
LongVarChar
Picture, Text
Numeric
Number
Real
Number
Time
Time, Datetime
Timestamp
Datetime, Date or Time depending on data
Unsigned
Number
Varbin
Picture, Text
Varchar
Text, URL, E-mail, HTML Tag, Picture
Big Decimal
Big Decimal is a MicroStrategy-specific data type that allows
users to support high-precision attribute ID values that have
more than 15 digits of precision, such as BIGINT and
400 Big Decimal
© 2007 MicroStrategy, Inc.
Project Design Guide
Data Types
D
DECIMAL (precision, scale) data types. Examples of such
attribute ID values are account numbers, credit card
numbers, and long integers.
Using the Big Decimal data type
With the Big Decimal data type, MicroStrategy preserves the
precision of attribute ID values and attribute ID forms when
displaying IDs and performing operations such as filtering,
drilling, and page-by. For more information about these
operations, see the MicroStrategy Basic Reporting Guide.
You can define attributes that are identified by numeric
columns in the database. These numeric columns can have
more than 15 digits of precision, such as account numbers
and other long integers. You must use the Big Decimal data
type to handle these values, because these data values have
higher precision and cannot be stored in normal numeric
data types.
associate high-precision database fields
IfwithyouthedoBignotDecimal
data type, you may see numbers
truncated starting with the 16th digit. The WHERE
clause in the report SQL statement in drill reports may
truncate numbers starting from the 16th digit, and
page-by may not return results.
When using the Big Decimal data type, follow the rules listed
below:
© 2007 MicroStrategy, Inc.
•
Constant: You can force a constant to be stored as a Big
Decimal value by enclosing it in hash marks. For example,
you can define a filter as "Customer@ID exactly
#12345678#", even though 12345678 does not necessarily
require the Big Decimal data type.
•
Attribute form: If you change the column data type to Big
Decimal on the Column Alias tab in the Attribute Editor,
you must also select Big Decimal as the form format type
in the Form format: Type drop-down menu in the
Definition tab.
•
Attribute ID: Follow the steps in the topic Defining
attributes with high-precision ID forms in the
MicroStrategy Desktop online help.
Big Decimal
401
D
Data Types
Project Design Guide
•
Metric: Although it is possible to define Big Decimal as
the data type for metric values, consider the following
drawbacks:
Precision is lost when any Analytical Engine
calculation is performed, the metric is used in a
calculated field in a document, the metric is
subtotaled, or metric values are displayed in Graph
view.
Number formatting strings are not supported on the
Web.
Some number formatting strings are not supported in
MicroStrategy Desktop.
When qualifying on a Big Decimal metric, you must
explicitly identify high-precision constants by
enclosing the value within hash (#) symbols. For
example, #1234567890123456#.
Note that the Warehouse Catalog does not automatically map
DECIMAL(p, s) or NUMERIC(p, s) columns to the Big
Decimal MicroStrategy data type even when the precision is
greater than 15. This is because Big Decimal should only be
used when the column is used as an attribute ID form.
402 Big Decimal
© 2007 MicroStrategy, Inc.
GLOSSARY
aggregate function A numeric function that acts on a column of data and
produces a single result. Examples include SUM, COUNT,
MAX, MIN, and AVG.
aggregate table A fact table that stores data that has been aggregated along
one or more dimensions.
See pre-aggregation.
application-level In application-level partitioning, the application rather than
partition the database server manages the partition tables.
MicroStrategy supports two methods of application-level
partitioning: metadata partition mapping and warehouse
partition mapping.
Compare database-level partition.
application object An object used to provide analysis of and insight into relevant
data. The definition of application objects such as reports,
documents, filters, templates, custom groups, metrics, and
prompts are derived from schema objects. All of these objects
can be built and manipulated in MicroStrategy Desktop.
Reports and documents can also be created and manipulated
in MicroStrategy Web.
© 2007 MicroStrategy, Inc.
aggregate function 403
Glossary
Project Design Guide
attribute A data level defined by the system architect and associated
with one or more columns in a data warehouse lookup table.
Attributes include data classifications like Region, Order,
Customer, Age, Item, City, and Year. They provide a means
for aggregating and filtering at a given level.
See also:
•
attribute element
•
attribute form
•
child attribute
•
constant attribute
•
derived attribute
•
parent attribute
attribute element A unique set of information for an attribute, defined by the
attribute forms. For example, New York and Dallas are
elements of the attribute City; January, February, and March
are elements of the attribute Month.
attribute form One of several columns associated with an attribute that are
different aspects of the same thing. ID, Name, Last Name,
Long Description, and Abbreviation could be forms of the
attribute Customer. Every attribute supports its own
collection of forms.
attribute form A mapping to the columns in the warehouse that are used to
expression represent a specific attribute form in SQL.
attribute relationship See relationship.
attribute role A database column that is used to define more than one
attribute. For example, Billing City and Shipping City are two
attributes that have the same table and columns defined as a
lookup table.
404 attribute
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
axis A vector along which data is displayed. There are three
axes—Row, Column, and Page. When a user defines a
template for a report, he places template units—attributes,
dimensions, metrics, consolidations, and custom
groups—along each axis.
See also:
•
column
•
row
base fact column A fact column represented by a single column in a fact table.
browse attribute An attribute a user can directly browse to from a given
attribute in a user hierarchy.
business intelligence A system that facilitates the analysis of volumes of complex
(BI) system data by providing the ability to view data from multiple
perspectives.
cache A special data store holding recently accessed information for
quick future access. This is normally done for frequently
requested reports, whose execution is faster because they
need not run against the database. Results from the data
warehouse are stored separately and can be used by new job
requests that require the same data. In the MicroStrategy
environment, when a user runs a report for the first time, the
job is submitted to the database for processing. However, if
the results of that report are cached, the results can be
returned immediately without having to wait for the database
to process the job the next time the report is run.
cardinality The number of unique elements for an attribute.
© 2007 MicroStrategy, Inc.
axis 405
Glossary
Project Design Guide
child attribute The lower-level attribute in an attribute relationship.
See also:
•
parent attribute
•
relationship
column 1) A one-dimensional vertical array of values in a table.
2) The set of fields of a given name and data type in all the
rows of a given table.
3) MicroStrategy object in the schema layer that can
represent one or more physical table columns or no columns.
See also:
•
axis
•
row
column alias In a fact definition, the specific name of the column to be
used in temporary tables and SQL statements. Column
aliases also include the data type to be used for the fact and
allow you to modify the names of existing metrics for use in
data mart reports without affecting the original metric.
compound attribute An attribute that has more than one key (ID) form.
compound key In a relational database, a primary key consisting of more
than one database column.
compression ratio The average number of child records combined to calculate
one parent record. For example, the compression of ratio
between monthly data and yearly data is 12:1. This is used to
determine where aggregate tables would have the greatest
impact. The larger the compression ratio between two
attributes, the more you stand to gain by creating an
aggregate table that pre-calculates the higher-level data.
406 child attribute
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
conditionality Conditionality of a metric enables you to associate an existing
filter object with the metric so that only data that meets the
filter conditions is included in the calculation.
configuration object A MicroStrategy object appearing in the system layer and
usable across multiple projects. Configuration objects include
these object types: users, database instances, database login
IDs, schedules.
constant attribute See implicit attribute.
Data Explorer A portion of the interface used to browse through data
contained in the warehouse. Users can navigate through
hierarchies of attributes that are defined by the administrator
to find the data they need.
data source A data source is any file, system, or storage location which
stores data that is to be used in MicroStrategy for query,
reporting, and analysis.
A data warehouse can be thought of as one type of data
source, which refers more specifically to using a database as
your data source. Other data sources include text files, Excel
files, and OLAP cube sources such as SAP BW, Microsoft
Analysis Services 2000 and 2005, and Hyperion Essbase.
See also:
•
data warehouse
•
OLAP cube source
data warehouse 1) A database, typically very large, containing the historical
data of an enterprise. Used for decision support or business
intelligence, it organizes data and allows coordinated updates
and loads.
2) A copy of transaction data specifically structured for query,
reporting, and analysis.
See also data source.
© 2007 MicroStrategy, Inc.
conditionality 407
Glossary
Project Design Guide
database instance 1. A MicroStrategy object created in MicroStrategy Desktop
that represents a connection to the warehouse. A database
instance specifies warehouse connection information, such as
the data warehouse DSN, Login ID and password, and other
data warehouse specific information.
2. Database server software running on a particular machine.
Although it is technically possible to have more than one
instance running on a machine, there is usually only one
instance per machine.
degradation A type of fact extension in which values at one level of
aggregation are reported at a second, lower attribute level.
Compare allocation.
description column Optional columns that contain text descriptions of attribute
elements.
derived attribute An attribute calculated from a mathematical operation on
columns in a warehouse table. For example, Age might be
calculated from this expression:
Current Date–Birth Date
Compare implicit attribute.
derived fact column A fact column created through a mathematical combination
of other existing fact columns.
derived metric A metric based on data already available in a report. It is
calculated by Intelligence Server, not in the database. Use a
derived metric to perform column math, that is, calculations
on other metrics, on report data after it has been returned
from the database.
408 database instance
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
drill A method of obtaining supplementary information after a
report has been executed. The new data is retrieved by
re-querying the Intelligent Cube or database at a different
attribute or fact level.
See also:
•
page-by
•
pivot
•
sort
•
subtotal
•
surf
dynamic relationship When the relationship between elements of parent and child
attributes changes. These changes often occur because of
organizational restructuring; geographical realignment; or
the addition, reclassification, or discontinuation of items or
services. For example, a store may decide to reclassify the
department to which items belong.
element browsing Navigating through hierarchies of attribute elements. For
example, viewing the list of months in a year.
entity relationship A diagram that provides a graphical representation of the
diagram (ERD) physical structure of the data in the source system, which lets
you easily recognize tables and columns and the data stored
in those columns.
entry level The lowest level set of attributes at which a fact is available
for analysis.
entry point In a user hierarchy, a shortcut to an attribute in the Data
Explorer which is helpful in allowing users to more easily
access frequently-used attributes in the Data Explorer.
© 2007 MicroStrategy, Inc.
drill 409
Glossary
Project Design Guide
extraction, 1) The process used to populate a data warehouse from
transformation, and disparate existing database systems.
loading (ETL)
2) Third-party software used to facilitate such a process.
fact 1) A measurement value, often numeric and typically
aggregatable, stored in a data warehouse.
2) A schema object representing a column in a data
warehouse table and containing basic or aggregated
numbers—usually prices, or sales in dollars, or inventory
quantities in counts.
See also metric.
fact column A column in a database table that contains fact data.
fact expression A mapping of facts to physical columns in the warehouse.
Fact expressions can be as simple as a fact column name from
the warehouse or as sophisticated as a formula containing
fact columns and numeric constants. Facts can have multiple
fact expressions.
fact table A database table containing numeric data that can be
aggregated along one or more dimensions. Fact tables can
contain atomic or summarized data.
filter A MicroStrategy object that specifies the conditions that the
data must meet to be included in the report results. Using a
filter on a report narrows the data to consider only the
information that is relevant to answer your business
question, since a report queries the database against all the
data stored in the data warehouse.
A filter is composed of at least one qualification, which is the
actual condition that must be met for the data to be included
on a report. Multiple qualifications in a single filter are
combined using logical operators. Examples include "Region
= Northeast" or "Revenue > $1 million".
A filter is normally implemented in the SQL WHERE clause.
410 extraction, transformation, and loading (ETL)
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
form group A grouping of attribute forms that are related in a way that
justifies combining the forms into a single form. A form
group must be created to create a compound key, which
identifies that an attribute form requires more than one ID
column to uniquely identify its elements.
See also compound key.
heterogeneous column Columns in different tables in a database that store the same
naming data but have different names. For example, one column
named Customer in one table and one named Customer
Name in a different table, both containing customer names.
hierarchy A set of attributes defining a meaningful path for element
browsing or drilling. The order of the attributes is
typically—though not always—defined such that a higher
attribute has a one-to-many relationship with its child
attributes.
highly denormalized Schema type where not only are higher-level attribute ID
schema columns present within all related tables, but the description
columns are present as well.
highly normalized Schema type where lookup tables contain unique
schema developer-designed attribute keys.
homogeneous column Columns in different tables of a database that contain the
naming same data and have the same column name.
ID column A column that contains attribute element identification
codes. All attributes must have an ID column.
implicit attribute An attribute that does not physically exist in the database
because it is created at the application level. Such an attribute
has its expression defined as a constant value, though
nothing is saved in a column. For example, you may wish to
create columns in the database with a value of 1 for every row
to get around COUNT limitations. You do not have to actually
create the column, though, because in the Attribute Editor,
© 2007 MicroStrategy, Inc.
form group 411
Glossary
Project Design Guide
you can just enter a “1” in the expression to create a count.
Implicit attributes are useful in analyzing and retrieving
information. When analyzing data, you can use constant
attributes to create a COUNT to keep track of the number of
rows returned. You can use constant attributes when building
metrics, where you can sum the column holding the constant
to create a COUNT. Any constant is acceptable.
Compare derived attribute.
joint children Joint child relationships are another type of many-to-many
relationship where one attribute has a many-to-many
relationship to two otherwise unrelated attributes. These
relationships can be modeled and conceptualized like
traditional attributes, but like facts, they exist at the
intersection of multiple attribute levels.For example,
consider the relationship between three attributes:
promotion, item, and quarter. In this case, promotion has a
many-to-many relationship to both item and quarter. An
example of a promotion might be a “Red Sale” where all red
items are on sale. A business might run this promotion
around Valentine's Day (Q1) and again at Christmas time
(Q4).
locked hierarchy A hierarchy that has at least one attribute that may not be
browsed by end users. Hierarchies are usually locked if there
are so many attribute elements that element browsing is not
usable.
logical data model A graphical representation of data that is arranged logically
for the general user, as opposed to the physical data model or
warehouse schema, which arranges data for efficient
database use.
lookup table A database table used to uniquely identify attribute elements.
They typically consist of descriptions of dimensions. Lookup
tables are usually joined to fact tables to group the numeric
facts in the fact table by dimensional attributes in the lookup
tables.
412 joint children
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
managed object A schema object unrelated to the project schema, which is
created by the system and stored in a separate system folder.
Managed objects are used to map data to attributes, metrics,
hierarchies and other schema objects for Freeform SQL,
Query Builder, and OLAP cube reports.
many-to-many An attribute relationship in which multiple elements of a
parent attribute can relate to multiple elements of a child
attribute, and vice versa.
See also:
•
one-to-one
•
one-to-many
•
many-to-one
•
relationship
many-to-one An attribute relationship in which (1) multiple elements of a
parent attribute relate to only one element of a child
attribute, and (2) every element of the child attribute can
relate to multiple elements of the parent.
See also:
•
one-to-one
•
one-to-many
•
many-to-many
•
relationship
metadata A repository whose data associates the tables and columns of
a data warehouse with user-defined attributes and facts to
enable the mapping of the business view, terms, and needs to
the underlying database structure. Metadata can reside on
the same server as the data warehouse or on a different
database server. It can even be held in a different RDBMS.
See also metadata shell.
© 2007 MicroStrategy, Inc.
managed object 413
Glossary
Project Design Guide
metadata shell A set of blank tables that are created when you initially
implement a MicroStrategy business intelligence
environment.
See also metadata.
metric 1) A business calculation defined by an expression built with
functions, facts, attributes, or other metrics. For example:
sum(dollar_sales) or [Sales] - [Cost]
2) The MicroStrategy object that contains the metric
definition.
See also fact.
moderately normalized Schema type having the same basic structure as the highly
schema normalized schema, but here the higher-level attribute ID
columns are present within all related tables.
MOLAP Multidimensional online analytical processing.
multithreaded Characteristic of a process that supports the simultaneous
execution of multiple threads. The startup code initiates the
primary thread of a process by passing the main function
address to the operating system. When the primary thread
terminates, the process terminates.
narrowcast application In a business intelligence environment, an application that
allows for the distribution of personalized business
information to subscribed users. In MicroStrategy,
Narrowcast Server is a proactive information delivery server
that allows for this distribution of information through
e-mail, printers, file services, SMS, and mobile devices.
object Conceptually, an object is the highest grouping level of
information about one concept, used by the user to achieve
the goal of specified data analysis. More concretely, an object
is any item that can be selected and manipulated, including
folders, reports, facts, metrics, and so on.
414 metadata shell
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
OLAP cube An OLAP cube is a collection or set of data retrieved from an
OLAP cube source, which is imported into MicroStrategy and
mapped to various objects to allow query, reporting, and
analysis on the data.
See also OLAP cube source.
OLAP cube source When integrated with MicroStrategy, the third-party tools
SAP BW, Microsoft Analysis Services, and Hyperion Essbase
are referred to as OLAP cube sources. You can import and
map data from these different OLAP cube sources in
MicroStrategy to query, report on, and analyze data with
MicroStrategy.
MicroStrategy can integrate with OLAP cube source data as
well as access data from a relational database concurrently.
See also:
•
OLAP cube
•
data source
one-to-many An attribute relationship in which every element of a parent
attribute can relate to multiple elements of a child attribute,
while every element of the child attribute relates to only one
element of the parent. The one-to-many attribute
relationship is the most common in data models.
See also:
© 2007 MicroStrategy, Inc.
•
one-to-one
•
many-to-many
•
many-to-one
•
relationship
OLAP cube 415
Glossary
Project Design Guide
one-to-one An attribute relationship in which every element of the
parent attribute relates to exactly one element of the child
attribute, and vice versa.
See also:
•
one-to-many
•
many-to-one
•
many-to-many
•
relationship
online analytical A system with analytical processing that involves activities
processing (OLAP) such as manipulating transaction records to calculate sales
trends, growth patterns, percent to total contributions, trend
reporting, and profit analysis.
online transaction Typically, databases or mainframes that store transactional
processing (OTLP) data. Transactional processing involves the simple recording
of transactions such as sales, inventory, withdrawals, or
deposits.
page-by Segmenting data in a grid report by placing available
attributes, consolidations, and metrics on a third axis called
the Page axis. Since a grid is two-dimensional, only a slice of
the cube can be seen at any one time. The slice is
characterized by the choice of elements on the Page axis. By
varying the selection of elements, the user can page through
the cube.
See also:
416 one-to-one
•
drill
•
pivot
•
sort
•
subtotal
•
surf
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
parent attribute The higher-level attribute in an attribute relationship with
one or more children.
See also:
•
child attribute
•
relationship
partial relationship An attribute relationship in which elements of one attribute
relate to elements of a second attribute, while the opposite is
not necessarily true.
See also:
•
relationship
•
one-to-many
•
many-to-one
•
many-to-many
partition base table A warehouse table that contains one part of a larger set of
data. Partition tables are usually divided along logical lines,
such as time or geography. Also referred to as a PBT.
See also partition mapping.
partition mapping The division of large logical tables into smaller physical tables
based on a definable data level, such as month or department.
Partitions minimize the number of tables and records within
a table that must be read to satisfy queries issued against the
warehouse. By distributing usage across multiple tables,
partitions improve the speed and efficiency of database
queries.
© 2007 MicroStrategy, Inc.
parent attribute 417
Glossary
Project Design Guide
partition mapping table A warehouse table that contains information used to identify
the partitioned base tables as part of a logical whole. Also
referred to as a PMT.
See also:
•
partition base table
•
partition mapping
physical warehouse A detailed graphic representation of your business data as it
schema is stored in the data warehouse. It organizes the logical data
model in a method that make sense from a database
perspective.
See also schema.
pivot To reconfigure data on a grid report by placing report objects
(attributes, metrics, consolidations) on different axes. Also,
to reconfigure a grid report by interchanging row and column
headers, and hence the associated data. Subset of cross-tab.
See also:
•
drill
•
page-by
•
sort
•
subtotal
•
surf
port number The port number is how a server process identifies itself on
the machine on which it is running. For example, when the
Intelligence Server machine receives a network call from a
client (Desktop, Web, Narrowcast Server, Command
Manager, and so on), it knows to forward those calls to the
Intelligence Server port number that is specified in the call.
418 partition mapping table
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
pre-aggregation Aggregation, or the calculation of numeric data at a specific
attribute level, that is completed before reports are run, with
the results stored in an aggregate table.
See also:
•
aggregate table
•
aggregation
prefix A prefix is stored in the project metadata associated with a
table or tables and is used by the Engine to generate SQL.
Also, the Catalog Server uses it to obtain table sample values
and row counts. In most cases, it should match the name
space field since it is used to qualify on a specific table
belonging to a certain owner or name space. Prefixes can be
defined and modified from the Warehouse Catalog interface.
See also table name space.
process An executing application comprising one or more threads.
Processes use temporary private address spaces and control
operating system resources such as files, dynamic memory
allocations, pipes, and synchronization objects.
project 1) The highest-level intersection of a data warehouse,
metadata repository, and user community, containing
reports, filters, metrics, and functions.
2) An object containing the definition of a project, as defined
in (1). The project object is specified when requesting the
establishment of a session.
project source Defines a connection to the metadata repository and is used
by various MicroStrategy products to access projects. A direct
project source is a two-tier connection directly to a metadata
repository. A server project source is a 3-tier connection to a
MicroStrategy Intelligence Server. One project source can
contain many projects and the administration tools found at
the project source level are used to monitor and administer
all projects in the project source.
© 2007 MicroStrategy, Inc.
pre-aggregation 419
Glossary
Project Design Guide
prompt 1) MicroStrategy object in the report definition that is
incomplete by design. The user is asked during the resolution
phase of report execution to provide an answer that
completes the information. A typical example with a filter is
choosing a specific attribute on which to qualify.
2) In general, a window requesting user input, as in “type
login ID and password at the prompt.”
qualification The actual condition that must be met for data to be included
on a report. Examples include "Region = Northeast" or
"Revenue > $1 million". Qualifications are used in filters and
custom groups. You can create multiple qualifications for a
single filter or custom group, and then set how to combine
the qualifications using the logical operators AND, AND
NOT, OR, and OR NOT.
quality relationship The relationship between a parent attribute and two or more
“joint child” attributes. The parent attribute is referred to as a
“quality” because its definition is complete only with the
intersection of its joint children.
ratio The relationship in quantity, amount, or size between the
cardinalities of related attributes.
See also cardinality.
relate table A table containing the ID columns of two or more attributes,
thus defining associations between them.
relational database A relational database management system (RDBMS) is a
management system program that lets you create, update, and administer a
relational database. A relational database is a collection of
data items organized as a set of formally-described tables
from which data can be accessed or reassembled in many
different ways without having to reorganize the database
tables.
The leading RDBMS products are Oracle, IBM DB2 and
Microsoft SQL Server.
420 prompt
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
relationship An association specifying the nature of the connection
between one attribute (the parent) and one or more other
attributes (the children). For example, City is a child attribute
of State.
See also:
•
parent attribute
•
child attribute
•
partial relationship
•
quality relationship
•
one-to-one
•
one-to-many
•
many-to-one
•
many-to-many
report The central focus of any decision support investigation, a
report allows users to query for data, analyze that data, and
then present it in a visually pleasing manner.
See also:
•
filter
•
template
report creation The process of building reports from existing, predesigned
reports in MicroStrategy Desktop or in MicroStrategy Web.
report design The process of building reports from basic report
components using the Report Editor in MicroStrategy
Desktop or MicroStrategy Web.
© 2007 MicroStrategy, Inc.
relationship 421
Glossary
Project Design Guide
row The horizontal axis of a report.
See also:
•
axis
•
column
schema 1) The set of tables in a data warehouse associated with a
logical data model. The attribute and fact columns in those
tables are considered part of the schema itself.
2) The layout or structure of a database system. In relational
databases, the schema defines the tables, the fields in each
table, and the relationships between fields and tables.
schema object A MicroStrategy object created, usually by a project designer,
that relates the information in the logical data model and
physical warehouse schema to the MicroStrategy
environment. These objects are developed in MicroStrategy
Architect, which can be accessed from MicroStrategy
Desktop. Schema objects directly reflect the warehouse
structure and include attributes, facts, functions, hierarchies,
operators, partition mappings, tables, and transformations.
shortcut object A MicroStrategy object that represents a link to any other
MicroStrategy object such as report, filter, metric, and so
forth.
server definition A MicroStrategy object stored in the metadata containing
information about the configuration of an Intelligence Server.
server instance The combination of an Intelligence Server running with a
particular server definition.
simple key In a relational database, a primary key that requires only one
column to uniquely identify a record within a table.
422 row
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
sort Arranging data according to some characteristic of the data
itself (alphabetical descending, numeric ascending, and so
forth).
See also:
•
drill
•
page-by
•
pivot
•
subtotal
•
surf
source system Any system or file that captures or holds data of interest.
star schema A highly denormalized physical warehouse schema in which
lookup tables are consolidated so that every attribute ID and
description column for a given hierarchy exists in one table.
statistics tables Tables that are used to record a variety of statistical
information about the usage and performance of a
MicroStrategy system.
Structured Query The query language standardized in 1986 by the American
Language (SQL) National Standards Institute (ANSI) and used to request
information from tables in a relational database and to
manipulate the tables’ structure and data.
subtotal A totaling operation performed for a portion of a result set.
See also:
© 2007 MicroStrategy, Inc.
•
drill
•
page-by
•
pivot
•
sort
•
surf
sort 423
Glossary
Project Design Guide
surf To add filters, attributes, attribute elements, metrics, and
functions to existing analysis objects.
See also:
•
drill
•
page-by
•
pivot
•
sort
•
subtotal
system hierarchy The superset hierarchy containing all attributes in a project.
Unlike a browse hierarchy, it is not explicitly created but is
automatically deduced by the MicroStrategy platform from
all information available to it.
Compare user hierarchy.
table name space A field that is read from the warehouse catalog and used to
organize databases. This field cannot be modified from the
product since it is actually stored in the warehouse. Each
table object in the metadata stores the name space or owner
from which it came. This is needed to uniquely identify each
table saved in the project when comparing table information
in the metadata to the real one in the warehouse.
table size The estimated size of a database table in terms of number of
rows.
template The data definition portion of the template consists of the
group of objects (attribute, metrics, custom groups, and so
on) that defines the columns of data to be included in the
result set. The layout and format of these objects are defined
within the template's view definition.
424 surf
© 2007 MicroStrategy, Inc.
Project Design Guide
Glossary
transformation A schema object that maps a specified time period to another
time period, applying an offset value, such as current month
minus one month. Although the vast majority are based on
time, a transformation can also map different objects, such as
defunct product codes to new ones.
Time transformations are used in metrics to compare values
at different times, such as this year versus last year or current
date versus month-to-date.
transformation metric An otherwise simple metric that takes the properties of the
transformation applied to it. For example, a metric calculates
total sales. Add a transformation for last year and the metric
now calculates last year’s total sales.
threshold Used to create conditional formatting for metric values. For
example, if revenue is greater than $200, format that cell to
have a blue background with bold type.
user hierarchy A named set of attributes and their relationships, arranged in
specific sequences for a logical business organization. They
are user-defined and are used to define the browse and drill
relationships between attributes.
virtual cube 1) In an OLAP data model, a conceptual, multidimensional
representation of data. Unlike a physical cube, a virtual cube
does not perform data retrieval and consequently lacks the
performance problems and size limitations associated with a
physical cube. A virtual cube maps MicroStrategy objects
such as hierarchies and metrics to OLE DB for OLAP objects.
2) The result of mapping a logical data model to an OLE DB
for OLAP multidimensional model after hierarchies and
metrics have been selected from a project. No physical cube is
created or loaded, but a definition of the virtual cube
structure is stored in MicroStrategy metadata.
© 2007 MicroStrategy, Inc.
transformation 425
Glossary
426 virtual cube
Project Design Guide
© 2007 MicroStrategy, Inc.
INDEX
A
accessing
Project Creation Assistant 78
Warehouse Catalog 219
adding tables to a project 79
aerial perspective of hierarchy 200, 212
aggregate function defined on 247
aggregate table defined on 241
advantages 242
base table 244
compression ratio 248
effectiveness 248
integrate into project 249
logical table size 249
parent-child relationship 246
pre-aggregation 243
query frequency 246
aggregate-aware 249
aggregation defined on 243
degree of 244
dense 244
dynamic 243
sparse 244
alias
attribute column 156
© 2007 MicroStrategy, Inc.
fact column 96, 105
table 178, 180
allocation expression 121
Analysis Services 2000
catalog 339
connecting to 337
DSI 339
metadata models 317
relating objects to MicroStrategy 317
URL 339
Analysis Services 2000 to MicroStrategy
cube 319
database 318
database instance 338
dimension 319, 320
level 321
member property 321
relating objects 317
Analysis Services 2005
catalog 342
connecting to 340
DSI 342
hierarchy 326
relating objects to MicroStrategy 322
URL 342
427
Index
Analysis Services 2005 to MicroStrategy
cube 322
database 323
database instance 341
dimension 325
level 326
member 326
member property 327
perspective 324
relating objects 322
analysis, time-series 257
application for Essbase 313
application-level partition defined on 251
architecture, MicroStrategy 294
atomic defined on 244
attribute defined on 10
Attribute Creation Wizard 129
Attribute Editor 135
browse form 190
cardinality 35
child 24
column alias 156
component. See report display form
and browse form.
compound 183
compound key 184
creating in Project Creation
Assistant 130
creating using Attribute Editor 136
cross-dimensional. See joint-child relationship.
derived attribute 150
derived expression 150
display 189
element. See attribute element.
expression 127
filtering in a hierarchy 203
form. See attribute form.
428
Project Design Guide
heterogeneous mapping 153
identifying 30
implicit, attribute
constant 155
in hierarchy 25
joint child relationship 171
many-to-many relationship 160, 164
MicroStrategy to Analysis Services
2000 321
MicroStrategy to Analysis Services
2005 326
MicroStrategy to Essbase 315
MicroStrategy to SAP BW 307
multiple counting in relationship 166
nonrelated 161
one-to-many relationship 160
one-to-one relationship 160
overview 22
parent 24
properties 127, 128
qualification 253
ratio 35
relationship. See attribute relationship.
report display form 190
role. See attribute role.
simple expression 148
system hierarchy 159
attribute component. See report display
form and browse form.
Attribute Creation Wizard
about 129
using 130
Attribute Editor
about 135
creating attribute forms 146
creating attributes 136
updating hierarchies 197
attribute element defined on 23
about 140
© 2007 MicroStrategy, Inc.
Project Design Guide
for Analysis Services 2000 321
for Analysis Services 2005 326
for Essbase 316
for SAP BW 307
overview 23
attribute form defined on 37
creating using Attribute Editor 146
display 189
expression 147
for Analysis Services 2000 321
for Analysis Services 2005 327
for Essbase 316
for SAP BW 307
group 186
qualification 253
attribute relationship defined on 24
about 159
as property of attribute 127
identifying 31
in lookup table 44
overview 24
attribute role defined on 175
automatic recognition 179
automatic recognition of 177
explicit table alias 178, 180
authenticating OLAP cube reports 297
automatic attribute role recognition 177
B
base fact column 47
base table defined on 244
pre-aggregation 243
BI architecture 2
browse
attribute 207
form 190
browsing
© 2007 MicroStrategy, Inc.
Index
about 207
enabling in a hierarchy 209
building a logical data model 26
business intelligence (BI)
system defined on 1
C
calculating
growth percentage 257
variance 257
calculating logical table sizes 231
cardinality for an attribute 35
Cartesian join 159
catalog
for Analysis Services 2000 318
for Analysis Services 2005 323
for Essbase 313
for SAP BW 304
SQL 234
category. See hierarchy.
characteristic attribute vs. attribute
form 307
characteristic value 307
characteristics, SAP BW 300
child attribute 24
class. See hierarchy.
column defined on 41, 223
base fact column 47
data type. See column data type.
derived fact 47
description 41
fact 41
heterogeneous naming 49
homogeneous naming 50
ID 41
physical warehouse schema 40, 41
column alias
attribute 156
429
Index
fact 96, 105
column data type
changed 240
manually setting for OLAP cube 352
compound attribute defined on 183
creating 184
compound key defined on 42
and compound attributes 184
compound metric, creating for OLAP
cube 359
compression ratio defined on 248
Configuration Wizard 71
connecting
to a database 227
to Analysis Services 2000 337
to Analysis Services 2005 340
to Essbase 334
to SAP BW 327
consolidating lookup tables 58
constant attribute 155
creating
attributes 136
compound attributes 184
compound metric for OLAP cube 359
facts 87
logical data model 26
project 75
creating hierarchies 194
cross product join 116
cross-dimensional attribute. See joint child
relationship.
cube 319
for Analysis Services 2000 319
for Analysis Services 2005 324
for Essbase 314
for SAP BW 304
mapping 349
customizing catalog SQL 233
430
Project Design Guide
D
Data Explorer defined on 209
about 209
enabling hierarchy browsing 196, 209
data model. See logical data model.
data provider. See project source.
data slice 253
data source defined on 6
data type
and mapping 395
Big Decimal 400
changed in column 240
high-precision 400
warehouse catalog 397
data warehouse defined on 5
and physical schema 39
connecting to 72
schema type 51
structure 51
Warehouse Catalog 218
database 323
connection operations 227
custom login 227
gateway support 225
instance. See database instance.
read operations 227
secondary 225
database instance defined on 67
for Analysis Services 2000 338
for Analysis Services 2005 341
for Essbase 335
for SAP BW 329
for SAP BW (UNIX/Linux) 333
database management system 233
degradation defined on 118
dense aggregation 244
derived
© 2007 MicroStrategy, Inc.
Project Design Guide
attribute 150
fact 99
fact column 47
description column defined on 41
Desktop. See MicroStrategy Desktop.
dimension
for Analysis Services 2000 319, 320
for Analysis Services 2005 325
for Essbase 314, 315
for SAP BW 306
See also hierarchy.
direct access approach 292
disallowing fact entry level 122
drilling using hierarchies 209
dynamic aggregation 243
dynamic relationship defined on 247
E
element, attribute 140
entity relationship diagram
(ERD) defined on 29
entity. See hierarchy.
entry level defined on 87
entry point 205
ERD. See entity relationship diagram.
Essbase
catalog 337
connecting to 334
database instance 335
DSI (DataSourceInfo) 336
metadata models 311
relating objects to MicroStrategy 311
URL 336
Essbase to MicroStrategy
application 313
database 313
dimension 314, 315
level 315
© 2007 MicroStrategy, Inc.
Index
member 316
relating objects 311
ETL. See extraction, transformation, and
loading.
example
data model sample 26
physical schema 289
project 267
table data sample 225
explicit table alias 178, 180
expression map 98
expression, fact 98
expression-based transformation 259
creating 261
member expressions 264
member tables 263
extension, level 107
extraction, transformation, and loading
(ETL) process defined on 4, 6
F
fact defined on 85
allocation expression 121
base fact column 47
column defined on 41
column alias 96, 105
creating 87
cross product join 116
degradation defined on 118
derived 99
derived fact column 47
disallowing 122
expression 98
extension 107
Fact Creation Wizard 88
fact definition 96, 97
Fact Editor 88, 92
fact entry level 87
431
Index
fact relation 114
heterogeneous fact column 102
identifying 29
implicit 99
in hierarchy 25
level extension 96, 107
overview 21
table 46
table relation 110
table. See fact table.
fact column defined on 41
base 47
derived 47
heterogeneous 102
Fact Creation Wizard 88
Fact Editor 88, 93
fact expression 98
fact table defined on 86
column naming 51
in a warehouse 46
level 48
overview 21
filtered hierarchy 203
flag 172
form
attribute form 143
expression 147
group 186
G
gateway support for database 225
growth percentage calculation 257
H
heterogeneous
attribute mapping 153
column naming defined on 49
432
Project Design Guide
fact column 102
partition mapping 252
hierarchy defined on 193
aerial perspective 212
and the Data Explorer 196, 209
Attribute Editor 197
attribute filter 203
attributes in 25
browse attribute 207
browsing 207
browsing, enabling 209
creating 194
defining 32
displaying 201
drilling 209
entry point 205
facts in 25
filtering attributes in 203
for Analysis Services 2000 320
for Analysis Services 2005 326
for Essbase 315
for SAP BW 306
Hierarchy Editor 198, 200, 210
Hierarchy Viewer 200
in a logical data model 25
in SAP BW 300
limited 202
locked 201
organization 198
Project Creation Assistant 197
ragged 355
See also dimension.
structure 199
system hierarchy 197
unbalanced 355
user hierarchy 197
Hierarchy Editor 198, 200, 210
Hierarchy Viewer 200
© 2007 MicroStrategy, Inc.
Project Design Guide
Index
Java Connector 328, 330
join, cross product 116
joint child attribute
transformation metrics 265
joint child relationship 171
joint children defined on 171
for Analysis Services 2005 326
for Essbase 315
virtual 306
limited hierarchy 202
locating OLAP cubes 348
locked hierarchy defined on 201
logical data model defined on 17
attributes in 24
building 26
cardinality 35
conventions 33
design factors 59
for MicroStrategy Tutorial 271, 280
ratio 35
sample 26
schema type 51
source of structure 29
unique identifier 34
Logical Table Editor 250
logical table size 249
login, custom 227
lookup table defined on 43
attribute relationships and 44
consolidating 58
many-to-many relationship 44
one-to-one relationship 44
K
M
key
compound 42
figures 300
simple 42
managed object 349
managed objects
OLAP cubes 348
many-to-many
relationship defined on 160
design considerations 164
example 32
lookup table 44
relate table 45
many-to-many transformation
highly denormalized schema 57
higher level lookup tables 58
highly normalized schema 52
homogeneous
column naming 50
partition mapping 252, 254
Hyperion Essbase. See Essbase.
I
implicit
attribute 155
fact 99
importing OLAP cubes 343, 344
InfoCube 303, 304
InfoObjects 299
InfoProviders 299
international technical support xxiii
J
L
level
extension 107
for Analysis Services 2000 321
© 2007 MicroStrategy, Inc.
433
Index
and table-based transformations 259
double-counting 264
mapping
OLAP cubes 343
OLAP cubes examples 358
schema objects in Warehouse
Catalog 231
mapping type
about 264
many-to-many 264
one-to-one 264
MDX. See MultiDimensional Expressions.
member
attributes 263
expressions 263
for Analysis Services 2000 321
for Analysis Services 2005 326
for Essbase 316
property. See member property.
tables 263
member property
for Analysis Services 2000 321
for Analysis Services 2005 327
metadata defined on 8
connecting to 72
shell 65
table 71
metadata model
Analysis Services 2000 317
Essbase 311
SAP BW 302
metadata partition mapping
attribute qualification 253
data slice 253
overview 251
versus warehouse partition
mapping 255
metadata shell defined on 65
434
Project Design Guide
metric
creating compound metrics for OLAP
cube data 359
creating with custom MDX 359
prompts within custom MDX 366
removing compound metrics from
OLAP cubes 368
transformations 258
Microsoft Analysis Services 2000. See
Analysis Services 2000.
Microsoft Analysis Services 2005. See
Analysis Services 2005.
MicroStrategy
architecture 294
object model 7i 295
object model 8 296
MicroStrategy Desktop 11
MicroStrategy metadata. See metadata.
MicroStrategy Project Builder. See Project
Builder.
MicroStrategy to Analysis Services
2000 317
attribute 321
attribute element 321
attribute form 321
catalog 318
cube 319
dimension 320
hierarchy 320
MicroStrategy to Analysis Services
2005 322
attribute 326
attribute element 326
attribute form 327
catalog 323
cube 324
dimension 325
hierarchy 326
MicroStrategy to Essbase 311
© 2007 MicroStrategy, Inc.
Project Design Guide
attribute 315
attribute element 316
attribute form 316
catalog 313
cube 314
dimension 314
hierarchy 315
MicroStrategy to SAP BW 302
attribute 307
attribute element 307
attribute form 307
catalog 304
cube 304
dimension 306
hierarchy 306
MicroStrategy Tutorial 267
data model, viewing 279
logical data model 271, 280
physical warehouse schema 281
schema, general 280
view physical schema 289
MicroStrategy Web Universal 13
migrating tables 232
moderately normalized schema 54
MOLAP defined on 242
multidimensional data model. See logical
data model.
MultiDimensional Expressions
about 291
remapping objects 356
multiple counting 164
MultiProviders 299
N
nonrelated attributes 161
normalized schema 53, 55
© 2007 MicroStrategy, Inc.
Index
O
object models
in MicroStrategy 7i 295
in MicroStrategy 8 296
using SAP direct access 296
object, user 10
ODS object 299
OLAP
BAPI certification 293
Cube Catalog 309
Cube Editor 349
cube. See OLAP cube.
OLAP cube defined on 343
creating compound metrics 359
creating metrics with custom
MDX 359
importing 344
integration 292
manually setting column data type 352
mapping 349
prompts within custom MDX
metrics 366
remapping 356
removing 347
removing compound metrics 368
searching for 348
source 291
unbalanced and ragged
hierarchies 355
OLAP Cube Catalog 309, 343
OLAP Cube Editor 349
OLAP cube reports
authentication 297
managed objects 348
OLTP 3
one-to-many relationship defined on 160
example 31
relate table 45
435
Index
one-to-one relationship defined on 160
lookup table 44
online analytical processing. See OLAP.
online transaction processing. See OLTP.
opening
Project Creation Assistant 78
Warehouse Catalog 219
Operational Data Store object.See ODS object.
P
parent attribute 24
parent-child relationship 246
dynamic 247
overview 25
static 247
partition base table defined on 251, 255
partition mapping defined on 250
application-level 251
attribute qualification 253
data slice 253
heterogeneous 252
homogeneous 252, 254
metadata 251, 255
partition base table 255
server-level 251
table 222, defined on 255
types 251
warehouse 254, 255
PBT. See partition base table.
perspective 324
physical warehouse
schema defined on 39
design factors 59
for MicroStrategy Tutorial 281
sample 289
planning a project 76
PMT. See partition mapping table.
436
Project Design Guide
pre-aggregation defined on 243
aggregate table 241
base table 244
compression ratio 248
integrate aggregate table 249
logical table size 249
parent-child relationship 246
query frequency 246
prefix 230
project defined on 14
adding tables to 79, 80
aggregate table, integrating 248
creating 75
data warehouse 79
integrating aggregate tables 248
managing tables for 220
planning 76
Project Builder 74
Project Creation Assistant 78, 80
removing tables from 80
sample project 267
schema 216
source. See project source
tables, managing 220
Warehouse Catalog 79
warehouse tables in 79
Project Builder 74
Project Creation Assistant 77, 197
project source defined on 65
connecting to 72
creating 77
prompt, in metrics with custom MDX 366
properties for SAP BW 311
Q
qualification for an attribute form 253
quality. See joint child relationship.
© 2007 MicroStrategy, Inc.
Project Design Guide
query cubes 299
query frequency 246
R
ragged hierarchy 355
ratio for an attribute 35
RDBMS defined on 5
server-level partitioning 251
read operations for database 227
relate table 45
related attributes. See attribute relationship.
relating objects to MicroStrategy
from Analysis Services 2000 317
from Analysis Services 2005 322
from Essbase 311
from SAP BW 302
relation, fact 114
relational database management system.
See RDBMS.
relationship
dynamic 247
many-to-many 164
parent-child 246
relate table 45
static 247
remapping OLAP cubes 356
removing
compound metric from OLAP
cube 368
OLAP cube 347
table from project 80
report display form 190
row count for table 230
S
SAP BW
© 2007 MicroStrategy, Inc.
Index
characteristics 300
connecting to 327
on UNIX/Linux 330
on Windows 328
database instance 329, 333
hierarchies 300
InfoObjects 299
InfoProviders 299
Java Connector 328, 330
key figures 300
mapping cubes 349
metadata models 302
OLAP Cube Catalog 309, 343
query cubes 299
relating objects to MicroStrategy 302
SAP.sh 331
structures 311
terminology 298
variable properties 309
variables 300, 308
SAP BW to MicroStrategy
characteristic attribute 307
characteristic value 307
characteristics 305
hierarchy 306
InfoCube 303, 304
relating objects 302
virtual level 306
SAP.sh, configuring 331
schema
for project 216
highly denormalized 57
highly normalized 53
MicroStrategy Tutorial project 280
moderately normalized 55
object 14
physical warehouse defined on 39
star 58
437
Index
type. See schema type.
updating 217
schema type 51
comparison 60
searching for OLAP cubes 348
server-level partitioning 251
simple
expression 148
key 42
source system defined on 3, 5, 28
sparse aggregation 244
SQL defined on 5
attributes and columns in 22
catalog 233
default catalog SQL 239
facts and columns in 21
star schema 58
static relationship defined on 247
structure
in SAP BW query cube 311
of hierarchy 199
of table 222
Structured Query Language. See SQL.
summary table 241
support. See technical support.
system hierarchy 159, defined on 197
T
table
adding to a project 79
aggregate 241
alias 178, 180
calculating logical sizes 231
calculating size 231
compound key 42
fact table defined on 46, 86
key 42
438
Project Design Guide
Logical Table Editor 250
lookup 43, 44
managing for a project 221
migrating 232
name space 222, 228
name spaces 230
physical warehouse schema 40
prefixes 230
primary key 42
relation 110
row counts 230
sample data 225
simple key 42
size defined on 249
summary 241
transformation 259
updating structure 223
viewing structure 222
warehouse tables in Project Creation
Assistant 79
table-based
member expressions 264
transformations 259
creating 260
member tables 263
technical support xxv
international xxiii
text fact. See joint child relationship.
time-series analysis 257
transformation defined on 258
components 263
double-counting 264
expression-based 259, 261
many-to-many 259
mapping types 264
member attributes 263
member expressions 263
member tables 263
© 2007 MicroStrategy, Inc.
Project Design Guide
metric. See transformation metric.
metrics 258
one-to-one mapping types 264
table-based 259, 260
transformation metric defined on 258
joint child attributes 265
troubleshooting
column data type changed 240
column missing 241
data warehouse connection 239
tables missing 240
U
unbalanced and ragged hierarchy 355
unique identifier 34
UNIX/Linux, connecting to SAP BW 330
updating project schema 217
updating table structure 223
URL
for Analysis Services 2000 339
for Analysis Services 2005 342
for Essbase 336
user defined object. See fact expression.
user hierarchy defined on 197
browse attribute 207
browsing 207
browsing, enabling 209
creating 194
displaying 201
drilling 209
entry point 205
filtering attributes in 203
limited 202
locked 201
structure 199
user object 10
using attribute form vs characteristic
attribute 158
© 2007 MicroStrategy, Inc.
Index
V
variables
overview 300
properties, setting 311
supporting 308
variance calculation 257
viewing
sample data model 279
sample table data 225
sample warehouse schema 289
table structure 222
virtual level 306
W
Warehouse Catalog
accessing 219
column missing 241
connection operations 227
data types 240
database gateway support 225
default catalog SQL 239
displaying information 230
managing 221
mapping schema objects 231
read operations 227
troubleshooting 239
updating table structure 223
usage and settings 218
viewing table structure 222
warehouse partition mapping
overview 254
partition base table 255
partition mapping table 255
versus metadata partition
mapping 255
warehouse table in Project Creation
Assistant 79
439
Index
Project Design Guide
warehouse, physical
schema defined on 39, 281
Windows, connecting to SAP BW 327
X
XMLA 293
Analysis Services 2000 317
Analysis Services 2005 322
Essbase 312
provider for Analysis Services
2000 338
provider for Analysis Services
2005 341
provider for Essbase 335
440
© 2007 MicroStrategy, Inc.
Download PDF
Similar pages