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

Project Design Guide

2. The Logical Data Model

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

Introduction................................................................................ 63 Project connectivity components ................................................. 64 MicroStrategy metadata......................................................... 64 Metadata shell ....................................................................... 65 Project source ........................................................................ 65

vi

© 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

.................. 343 Importing OLAP cubes. 287 Sales fact tables ................................................................................................................................................. 344 Mapping OLAP cubes ................................ 334 Connecting to Analysis Services 2000 servers............... 330 Connecting to Essbase servers ............................ 291 MicroStrategy integration with OLAP cube sources ........................... 328 Connecting to SAP BW servers on UNIX and Linux.... 311 Relating objects from Essbase to MicroStrategy ......... 292 Understanding MicroStrategy architecture............................................ 340 Configuring the XMLA Provider ................. 302 Supporting SAP BW variables .... 327 Connecting to SAP BW servers on Windows .......................... 341 Integrating OLAP cubes into MicroStrategy. 317 Relating objects from Analysis Services 2005 to MicroStrategy......................................... 297 Understanding the SAP BW terminology .................................................. 283 Products schema ....................................................... 284 Customers schema .Contents Project Design Guide MicroStrategy Tutorial schema ........................................... Inc......... 288 Miscellaneous fact tables............................................................................................................................... 286 Promotions schema .................................................. 288 B............................................................. 308 SAP BW structures ........................................................................... 287 Inventory fact tables..................................................................................................................................... 298 Relating objects from SAP BW to MicroStrategy ................. 359 x © 2007 MicroStrategy......................................................................................... 334 Configuring the XMLA Provider ............... 349 Creating metrics from OLAP cube data with MDX and compound metric techniques . 280 Geography schema .............. 294 Authentication .................................................................................................................................... 338 Connecting to Analysis Services 2005 servers............... Connecting to OLAP Cube Sources Introduction........................................................................................ 337 Configuring the XMLA Provider ............................................................................ 311 Relating objects from Analysis Services 2000 to MicroStrategy......................................................... 322 Connecting to SAP BW servers...................................... ....... 285 Time schema ..............................

................ 399 Big Decimal...................................... 371 Creating logical tables ............................................ 377 Business case 3: Slowly changing dimensions................................................................. 397 Format types............... 376 Business case 2: Attribute form expression across multiple tables ...................................... 389 Business case 5: Outer joins between attribute lookup tables................................................................................................. Data Types Introduction............................................................... 378 Business case 4: One-to-many transformation tables ............... 403 Index ..................... 395 MicroStrategy data types ................ 401 Glossary ............... 395 Mapping of external data types to MicroStrategy data types..........................................................................................Project Design Guide Contents C................... xi ........................................ 376 Business case 1: Distinct attribute lookup table......................................................................................... 375 Logical view examples............ 398 Data type and format type compatibility..... 369 Logical tables. 400 Using the Big Decimal data type..................................... 390 D........................................... 427 © 2007 MicroStrategy......................................... Logical Tables Introduction....... Inc............................. 373 Using SQL for logical views ........................................... 370 How should I use logical tables? ................................................................................................................................................................................................................................

Contents Project Design Guide xii © 2007 MicroStrategy. . Inc.

including the following: • Chapter 1. provides a brief introduction to business intelligence architecture and some of the main components within the MicroStrategy platform. and modifying a project in MicroStrategy and covers a wide range of project-related topics. Chapter 2. Inc. describes the major components involved in project creation and guides you through the process of creating a project in MicroStrategy. explores logical data modeling and how it can help you identify the different elements within your business data and plan your project. • • • © 2007 MicroStrategy. Warehouse Structure for Your Logical Data Model.PREFACE Description of Guide The MicroStrategy Project Design Guide provides comprehensive information on planning. The 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. xiii . Creating and Configuring a Project. Chapter 3. Chapter 4. creating. BI Architecture and the MicroStrategy Platform.

provides a conceptual look at the structure of attributes and explores different types of attributes and how they relate to your business data. discusses the different types of hierarchies in MicroStrategy. • • • • The appendixes contain the following additional reference information. the different types of logical tables. or Hyperion® Essbase® for use within MicroStrategy. discusses logical tables. • • xiv © 2007 MicroStrategy. provides information about connecting to an OLAP Cube source such as SAP® BW. MicroStrategy Tutorial. describes the structure of facts and explores different types of facts and how they relate to your business data. Microsoft® Analysis Services. and how to create logical tables and views in MicroStrategy. Chapter 9. Appendix C. . Chapter 6. describes methods you can implement to better optimize and maintain your project for both the short and long term. Creating Hierarchies to Organize and Browse Attributes. The Context of Your Business Data: Attributes. Connecting to OLAP Cube Sources. and a set of demonstration applications designed to illustrate the features of the MicroStrategy platform. Creating Transformations to Define Time-Based and Other Comparisons. which you may or may not require depending on your specific needs: • Appendix A. provides information on the MicroStrategy Tutorial project. discusses the different types of transformations in MicroStrategy and describes how you can create transformations in your project. and explains how you can create user hierarchies to help organize and enhance your project. Chapter 7. Appendix B. Logical Tables. Chapter 8. The Building Blocks of Business Data: Facts. Inc. This chapter also covers all the steps necessary to create attributes for your project. which includes a metadata and warehouse. Optimizing and Maintaining Your Project.Preface Project Design Guide • Chapter 5. This chapter also covers all the steps necessary to create facts for your project.

Detailed examples of advanced reporting functionality can be found in the MicroStrategy Advanced Reporting Guide. © 2007 MicroStrategy. The following sections provide the location of additional examples. For examples of reporting functionality. Example analysis includes such business areas as financial reporting. provides information about the different data types in MicroStrategy. Information about the MicroStrategy Tutorial can be found in the MicroStrategy Basic Reporting Guide. many of the concepts discussed are accompanied by business scenarios or other descriptive examples. see the MicroStrategy Tutorial. How to find business scenarios and examples Within this guide. each from a different business area. Each module comes with a sample data model and a collection of packaged reports that allow dozens of analytical variations. and project. About this book xv . human resources. About this book This book is divided into chapters that begin with a brief overview of the chapter’s content. The Analytics Modules are part of a product bundle called the MicroStrategy Business Intelligence Developer Kit (BIDK). Business scenarios can be found in the Analytics Modules. which are a set of sample analytics. which is MicroStrategy’s sample warehouse. Data Types.Project Design Guide Preface • Appendix D. and customer analysis. and describe the user roles the information in this book was designed for. list prerequisites for using this book. metadata. Inc.

as described below. create.Preface Project Design Guide Prerequisites Before working with this document. In short. these two information sources provide different types of information. Inc. the following business intelligence application users should read this guide: • • Project Designers Database Administrators Resources Documentation MicroStrategy provides both manuals and online help. Manuals: MicroStrategy manuals provide • • • introductory information concepts checklists xvi Resources © 2007 MicroStrategy. . 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. and modify a MicroStrategy project using the MicroStrategy platform.

configuring. and using the MicroStrategy Evaluation Edition of the software. Adobe Acrobat Reader 4. as well as basic maintenance guidelines.adobe. UNIX. you can download it from www.com.0 or higher is required to view these documents. Manuals for Query. • MicroStrategy Upgrade Guide Instructions to upgrade existing MicroStrategy products. Reporting. If you do not have Acrobat Reader installed on your computer. • MicroStrategy Quick Start Guide Overview of the installation and evaluation process.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. and Analysis Products • MicroStrategy Installation and Configuration Guide Information to install and configure MicroStrategy products on Windows. and HP platforms. © 2007 MicroStrategy. Linux. The procedure to access them is below. MicroStrategy Overview • Introduction to MicroStrategy: Evaluation Guide Instructions for installing. Resources xvii . and additional resources. Inc.

hierarchies. and distribute business data. and how to analyze data in a report. Inc. Word. format. building on information in the Basic Reporting Guide and Advanced Reporting Guide. Includes the basics for creating reports. PowerPoint®. consolidations. • MicroStrategy Advanced Reporting Guide Instructions for advanced topics in the MicroStrategy system. and Outlook. and project optimization. and prompts. custom groups. tune. • MicroStrategy Basic Reporting Guide Instructions to get started with MicroStrategy Desktop and MicroStrategy Web. Covers installation and configuration of MicroStrategy Mobile and how a designer working in MicroStrategy xviii Resources © 2007 MicroStrategy. • MicroStrategy Office User Guide Instructions for using MicroStrategy Office to work with MicroStrategy reports and documents in Microsoft® Excel. deploy. Query Builder reports. • MicroStrategy Report Services Document Creation Guide Instructions to design and create Report Services documents. Topics include reports. metrics.Preface Project Design Guide • MicroStrategy System Administration Guide Concepts and high-level steps to implement. and prompts. filters. filters. • MicroStrategy Project Design Guide Information to create and modify MicroStrategy projects. Data Mining Services. maintain. and perform other business tasks with MicroStrategy reports and documents on a mobile device. . metrics. and understand facts. transformations. Freeform SQL reports. advanced schemas. attributes. building on information in the Basic Reporting Guide. to analyze. and troubleshoot a MicroStrategy business intelligence system. OLAP Cube reports. • MicroStrategy Mobile User Guide Instructions for using MicroStrategy Mobile to view and analyze data.

and troubleshoot MicroStrategy Web Services. and troubleshoot Narrowcast Server. • MicroStrategy Narrowcast Server System Administrator Guide Concepts and high-level steps to implement. examples of functions in business scenarios. • MicroStrategy Narrowcast Server Upgrade Guide Instructions to upgrade an existing Narrowcast Server. filters. tune. tune. © 2007 MicroStrategy. • MicroStrategy Narrowcast Server Installation and Configuration Guide Information to install and configure Narrowcast Server. maintain. Resources xix . 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.Project Design Guide Preface Desktop or MicroStrategy Web can create effective reports and documents for use with MicroStrategy Mobile. • MicroStrategy Narrowcast Server Application Designer Guide Fundamentals of designing Narrowcast Server applications. • MicroStrategy Web Services Administration Guide Concepts and tasks to install. instructions to use functions in metrics. Inc. • MicroStrategy Functions Reference Function syntax and formula components. attribute forms. configure.

then Product Manuals. object models. . code samples. To access installed online documentation 1 From the Windows Start menu. 2 Click the link for the desired manual. MicroStrategy. and so on. • MicroStrategy Web SDK The Web SDK is available in the MicroStrategy Developer Library. integrate Narrowcast Server with other systems. • Narrowcast Server SDK Guide Instructions to customize Narrowcast Server functionality. customization scenarios. and the Narrowcast Server SPI. and embed Narrowcast Server functionality within other applications. choose Programs. Documents the Narrowcast Server Delivery Engine and Subscription Portal APIs. Inc. including details about architecture. A Web page opens with a list of available manuals in PDF format.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. which is sold as part of the MicroStrategy SDK. xx Resources © 2007 MicroStrategy.

Select Open this file from its current location. Inc. F1 key: Press F1 to see context-sensitive help addressing the function or task you are currently performing. Resources xxi . click the Bookmarks and Page from the View menu. When you select one of these guides. Help menu: Select Contents and Index to see the main table of contents for the help system. the File Download dialog box opens. If bookmarks are not visible on the left side of an Acrobat (PDF) document. © 2007 MicroStrategy. and click OK. Online help MicroStrategy provides several ways to access online help: • • • Help button: Use the Help button at the bottom of most software screens to see context-sensitive help.Project Design Guide Preface 3 Some documentation is provided in HTML help format.

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. Type bold Indicates • button names.scp and press ENTER. lists. The following table lists these conventions. 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. + A keyboard command that calls for the use of more than one key (for example. UPPERCASE • keyboard command key (such as ENTER) • shortcut key (such as CTRL+V) Example: To bold the selected text. Inc. xxii Resources © 2007 MicroStrategy. italic • new terms defined within the text and in the glossary • names of other product manuals • when part of a command syntax. SHIFT+F1) A note icon indicates helpful information for specific situations. options.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. indicates variable information to be replaced by the user Example: The aggregation level is the level of calculation for the metric. Example: Type cmdmgr -f scriptfile. check boxes. dialog boxes. A warning icon alerts you to important information such as potential security risks. these should be read before continuing. press CTRL+B. .

The level of support is defined in terms of the components of a MicroStrategy business intelligence environment. For a detailed description of education offerings and course curriculums. collectively known as a configuration: • • • • • warehouse. support for date formats.microstrategy. Inc. and more. currency symbols. A MicroStrategy business intelligence environment consists of the following components. and more. visit www. project and testing strategies and recommendations. For a detailed description of consulting offerings. Offerings include complex security architecture designs. Consulting MicroStrategy Consulting Services provides proven methods for delivering leading-edge technology solutions.com/Education.Project Design Guide Preface Education MicroStrategy Education Services provides a comprehensive curriculum and highly skilled education consultants.microstrategy. and statistics databases MicroStrategy Intelligence Server MicroStrategy Web server MicroStrategy Desktop client Web browser © 2007 MicroStrategy. visit www. Many customers and partners from over 800 different organizations have benefited from MicroStrategy instruction. metadata. It also includes the availability of translated interfaces and documentation. Support for a locale typically includes native database and operating system support. performance and tuning. International support MicroStrategy supports several locales. Resources xxiii . decimal formats.com/Consulting. strategic planning.

Chinese (simplified) and Swedish. Upgrading an earlier installation from version 7. 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. xxiv Resources © 2007 MicroStrategy.3 The user language preference that was set previously in version 7. Italian. French.2. . Installation Fresh installation on a system in which MicroStrategy application has never been installed before Result The MicroStrategy Installation Wizard prompts you to select the language from the drop-down list.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). A translated user interface is available in each of the above languages. In addition. Inc. German.3 is the language of display of the installation routine and the user language of the product interface. Korean. Once the product is installed. The user language in the product interface is the language that you select during installation. the Online Help is displayed in the same language that the user selects in the language prompt of the installation routine. Spanish.2. MicroStrategy also provides limited support for heterogeneous configurations (where some of the components may lie in different locales). The following table lists the language selection possibilities for different installation cases. The user language in the product interface is also the language that you selected the first time you installed the product on the system. Japanese. translated versions of the online help files and product documentation are available in several of the above languages. Portuguese (Brazilian). Please contact MicroStrategy Technical Support for more details.

unless overridden by the command line parameter. the installation Online Help is displayed in English only.x Result The MicroStrategy Installation Wizard prompts you to select the language from the drop-down list. all subsequent executions of the installation routine for maintenance or for upgrade.2 or earlier. you should: 1 Consult the product guides. are displayed in the language that you selected during the upgrade installation. the user language of the product interface language remains the same as the one set in the product interface before running the upgrade installation. Technical Support If you have questions about a specific MicroStrategy product. including 7. 2 Consult the MicroStrategy Knowledge Base online at http://www. 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. However.1.2.microstrategy. Besides. it has no effect on the default language of the product interfaces.asp © 2007 MicroStrategy. Note: Even if you select a language from the language prompt in the installation routine.Project Design Guide Preface Installation Upgrading an earlier installation from version 7. Resources xxv . Inc. the MicroStrategy Installation Wizard prompts you to select the language from the drop-down list.com/support/ k_base/index. During installation. Paths to access each are described above. readme files. and release notes. online help. The installation routine is displayed in the selected language.

com/Support/ Expiration. 3 If the resources listed in the steps above do not provide you with a solution. 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. All customer inquiries and case communications must come through these named individuals. A Support Liaison is a person whom your company has designated as a point-of-contact with MicroStrategy’s support personnel. Your company may request to change their Support Liaisons two times per year with prior written notice to MicroStrategy Technical Support. MicroStrategy Technical Support may be contacted by your company’s Support Liaison.microstrategy. Inc. review the Policies and Procedures document posted at http://www.com/ Support/Policies. . To ensure the most effective and productive relationship with MicroStrategy Technical Support. Your company may designate two employees to serve as their Support Liaisons. xxvi Resources © 2007 MicroStrategy. 4 Minimize the complexity of the system or project object definition to isolate the cause.Preface Project Design Guide A technical administrator in your organization may be able to help you resolve your issues immediately.asp. 3 Attempt to reproduce the issue and determine whether it occurs consistently. contact MicroStrategy Technical Support directly. 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. Refer to the terms of your purchase agreement to determine the type of support available to you.

when.com Fax: (703) 842–8709 Phone: (703) 848–8700 Hours: 9:00 A.–6:00 P. Monday-Friday except holidays • Mainland Europe: 9:00 A. Inc.com.com Web: https://support. send e-mail or fax. GMT.M. Monday–Friday except holidays E-mail: eurosupp@microstrategy.M. the Middle East. and Africa (EMEA) © 2007 MicroStrategy.–6:00 P. Resources xxvii . or log a case using the Online Support Interface. If your Support Liaison is unable to reach MicroStrategy Technical Support by phone during the hours of operation. they can leave a voicemail message.M. North America E-mail: support@microstrategy. CET.M.com Web: https://support.–7:00 P.microstrategy.microstrategy. and how to contact MicroStrategy Technical Support.microstrategy.M. These holidays reflect the national public holidays in each country.Project Design Guide Preface 5 Determine whether the issue occurs on a local machine or on multiple machines in the customer environment. The table on the following page shows where. Monday-Friday except holidays Europe. 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.com Fax: +44 (0) 208 396 0001 The European Technical Support Centre is closed on certain public holidays. Eastern Time (1400–0000 GMT). 6 Discuss the issue with other users by posting a question about the issue on the MicroStrategy Customer Forum at https://forums.M.

–7:00 P. national holidays.M.com Web: https://support. JST (Tokyo).6303. In North America.com Web: https://support.S. New Zealand.8969 • Japan (supporting Japan. Australia. Although not a requirement. MicroStrategy Technical Support personnel may make recommendations that require administrative privileges on the MicroStrategy projects.M. Malaysia.com Fax: +55 11 3044 4088 Phone: LATAM (except Argentina): +55 11 3054 1010 Argentina: 0 800 444 MSTR Hours: 9:00 A.Preface Project Design Guide Asia Pacific E-mail: apsupport@microstrategy. This can eliminate security conflicts and improve case resolution time. During the course of troubleshooting and researching issues. Monday–Friday except holidays Latin America 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. Pakistan. BST (Sao Paulo). Required information when calling When contacting MicroStrategy Technical Support. India. China.microstrategy.M. Inc. and Sri Lanka): +65. and Latin America. Asia Pacific.M. 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. Hong Kong. these holidays reflect many U.microstrategy. Taiwan. The individual Technical Support Centers are closed on certain public holidays. Monday-Friday except holidays E-mail: latamsupport@microstrategy. . these holidays reflect the national public holidays in each country. please provide the following information: • xxviii Resources Personal information: © 2007 MicroStrategy. In Europe.–6:00 P. we recommend you designate Support Liaisons who have permissions to be MicroStrategy project administrators.com Fax: +81 3 5456 5464 Phone: • Korea: +82 2 560 6565 • Singapore (supporting Singapore. and all other Asia Pacific countries not listed in this section): +81 3 3511 6720 Hours: 9:00 A.

error messages(s). including MicroStrategy software product(s) and versions Full description of the case including symptoms. e-mail addresses) • Case details: Configuration information. 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.Project Design Guide Preface Name (first and last) Company and customer site (if different from company) Contact information (phone and fax numbers. 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? © 2007 MicroStrategy. be prepared to provide the following additional information: • case number: Please keep a record of the number assigned to each case logged with MicroStrategy Technical Support. Inc. Resources • • xxix . and steps taken to troubleshoot the case thus far • Business/system impact If this is the Support Liaison’s first call.

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. Feedback Please send any comments or suggestions about user documentation for MicroStrategy products to: xxx Feedback © 2007 MicroStrategy.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. 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. RAM. The Support Liaison may call MicroStrategy Technical Support at any time to inquire about the status of the issue. If the Technical Support representative is responsible for an action item. a database move. Inc. a major database load. disk space. not all items listed below may be necessary): computer hardware specifications (processor speed. 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. or a software upgrade)? If there was an error message. .

please include the name and version of the products you are currently using. © 2007 MicroStrategy.com Send suggestions for product enhancements to: support@microstrategy. Your feedback is important to us as we prepare for future releases.com When you provide feedback to us. Feedback xxxi .Project Design Guide Preface documentationfeedback@microstrategy. Inc.

. Inc.Preface Project Design Guide xxxii Feedback © 2007 MicroStrategy.

Business intelligence (BI) systems facilitate the analysis of volumes of complex data by providing the ability to view data from multiple perspectives. BI ARCHITECTURE AND THE MICROSTRATEGY PLATFORM Introduction Before planning and creating a project in MicroStrategy. An optimum business intelligence application: • • • 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 © 2007 MicroStrategy. specifically. how the MicroStrategy platform interacts with your business data to provide a wide range of functionality. it is important to understand how business intelligence systems work and. 1 . Inc.1 1.

as well as some of the components within the MicroStrategy platform that allow you to create and analyze your business intelligence. . SAP BW. MicroStrategy can also access data from text files. see Data warehouse for data storage and relational design. Inc. but other systems or files that capture or hold data of interest are also possible An extraction. Hyperion Essbase. and loading (ETL) process A data warehouse—typically an online analytical processing (OLAP) system A business intelligence platform such as MicroStrategy • • • The diagram above illustrates the common setup for standardizing data from source systems and transferring that data into MicroStrategy. transformation. page 5. For more information on how MicroStrategy can access your data sources. 2 Business intelligence architecture © 2007 MicroStrategy. Microsoft Analysis Services.1 BI Architecture and the MicroStrategy Platform Project Design Guide This chapter introduces you to the basic architecture of BI systems. Excel files. and other data sources. Business intelligence architecture A BI architecture has the following components: • A source system—typically an online transaction processing (OLTP) system.

and many others. Data formats are not necessarily uniform across systems. deposits. This is in contrast to data warehouses which are often designed for reading data for analysis with a minimum number of updates. Each of these business services has a different and specific workflow. • • • Recall the example of a bank that relies on several source systems to store data related to the many services the bank offers. A source system is usually the most significant site of online transaction processing (OLTP). An average bank offers several services such as account activity updates and loan disbursement. This processing is relied upon daily by nearly every industry.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. manufacturing. suppose one source system—a database file on the bank’s server—keeps track of deposits and withdrawals as they occur. Meanwhile. and order processing. e-commerce. inventory. 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. 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. Business intelligence architecture 3 . Data history is limited to recent or current data. insertions. For more information on data warehouse design. by business activities and workflow. website usage. as the system records huge volumes of data every day. including health care. © 2007 MicroStrategy. For example. telecommunications. see Data warehouse for data storage and relational design. Transactional processing involves the simple recording of transactions and other business data such as sales. a different source system—another file on the server—keeps track of each customer’s contact information. Inc. and therefore has many source systems to support these services. A bank is an example of a business with many source systems. that is. Data is aligned by application. or deletions. page 5.

you must enter the bank and perform the transaction with a bank teller. Inc. filling in incomplete data. This is because the operational systems supporting these two services are designed to perform specific tasks. and loading (ETL) process. The ETL process involves the following steps: 1 Data is gathered from various source systems. Transformation procedures can include converting data types and names. to get a money order.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. including the customer's ATM activity. transformation. correcting typographical errors. and loading process The extraction. Each of these different sets of data is likely gathered by different source systems. transformation. This process can be explained with the example of a bank that wants to consolidate a variety of information about a particular customer. and account balances. If a bank wants to see a unified view of a particular customer. loan status. 2 The data is transformed and prepared to be loaded into the data warehouse. such as a customer's ATM activity. the customer information stored in each of these different systems must be consolidated. loan status. and loading (ETL) process represents all the steps necessary to move data from different source systems to an integrated data warehouse. . account balances. and similar processes to standardize the format and structure of data. transformation. This consolidation is achieved using the extraction. eliminating unwanted data. Since 4 Business intelligence architecture © 2007 MicroStrategy. The ETL process consolidates data so it can be stored in a data warehouse. However. and money market account information. Extraction. and these two services require different operational systems. 3 The data is loaded into the data warehouse.

see Storing and analyzing data with alternative data sources. Excel files. Data is rarely inserted. You can integrate different types of data sources with MicroStrategy such as text files. and profit analysis. Analytical processing involves activities such as choosing to see sales data by month and selecting the applicable metric to calculate sales trends. Data warehouses are usually based on relational databases or some form of relational database management system (RDBMS) platform. The source systems described above. percent-to-total contributions. This is in contrast to most © 2007 MicroStrategy. updated. These relational databases can be queried directly with Structured Query Language (SQL). a language developed specifically to interact with RDBMS software.Project Design Guide BI Architecture and the MicroStrategy Platform 1 each source system can have its own naming conventions. trend reporting. whereas data warehouses are usually designed and optimized for analytical processing. growth patterns. the data warehouse also provides the foundation for a robust online analytical processing (OLAP) system. In this case. and OLAP cubes. MicroStrategy does not require that data be stored in a relational database. However. 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. transforms it until it is standardized and consistent. or deleted. Inc. For more information on accessing data stored in alternative data sources. In combination with MicroStrategy tools and products. the data that comes from one system may be inconsistent with the data that comes from another system. the ETL process extracts the data from the different banking source systems. and then loads the data into the data warehouse. page 6. Most data warehouses have the following characteristics: • Data access is typically read-only. such as OLTP systems. The most common action is the selection of data for analysis. are generally designed and optimized for transactional processing. Business intelligence architecture 5 . It enables its users to leverage the competitive advantage that the business intelligence provides.

and Hyperion Essbase. • • Data is aligned by business subjects. and loading process. • • Storing and analyzing data with alternative data sources Along with integrating with relational databases. which are a common type of data warehouse. Inc. as explained in Extraction. reporting. or storage location which stores data that is to be used in MicroStrategy for query. For more information on source systems. see Source systems for data collection. page 4). The structure of data in a data warehouse and how it relates to your MicroStrategy environment can be defined and understood through a logical data model and physical warehouse schema. Warehouse Structure for Your Logical Data Model. system. see Chapter 2. A data source is any file. Defining a project’s logical data model and physical warehouse schema are important steps in preparing your data for a MicroStrategy project. and loading process. Microsoft Analysis Services. page 3. The following are different data source alternatives which MicroStrategy can integrate with: • OLAP cube sources: In MicroStrategy you can integrate with sets of data from SAP BW. transformation. transformation. and refers specifically to using a database as your data source. and analysis. . A data warehouse can be thought of as one type of data source. For more information on the steps of the project design process. The Logical Data Model and Chapter 3. page 4. MicroStrategy can also integrate with a number of alternative data sources. which are referred to as 6 Business intelligence architecture © 2007 MicroStrategy. A data warehouse is populated with data from the existing operational systems using an ETL process.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. Data history extends long-term. Data formats are uniformly integrated using an ETL process (see Extraction. usually two to five years.

analyze. The MicroStrategy platform 7 . MicroStrategy can integrate with these data sources while simultaneously accessing a relational database effectively. For more information on using text files and Excel files with the Freeform SQL and Query Builder features. and maintenance of business intelligence applications.Project Design Guide BI Architecture and the MicroStrategy Platform 1 OLAP cube sources. support. Some of the main components of the MicroStrategy platform include: • MicroStrategy metadata. • Text files and Excel files: With MicroStrategy’s Freeform SQL and Query Builder features. Connecting to OLAP Cube Sources. The MicroStrategy platform A business intelligence platform offers a complete set of tools for the creation. Inc. page 13—a highly interactive user environment and a low-maintenance interface for reporting and analysis • • • © 2007 MicroStrategy. see the MicroStrategy Advanced Reporting Guide. page 11—an analytical server optimized for enterprise querying. and report on data stored in text files and Excel files. Windows-based environment providing a complete range of analytical functions designed to facilitate the deployment of reports MicroStrategy Web and Web Universal. see Appendix B. and OLAP analysis MicroStrategy Desktop. page 8—a repository that stores MicroStrategy object definitions and information about the data warehouse MicroStrategy Intelligence Server. As with OLAP cube sources described above. For more information on connecting to and integrating OLAP cube sources in MicroStrategy. you can query. MicroStrategy can report against these alternative data sources while concurrently accessing a relational database to integrate all of your data into one cohesive project. page 11—an advanced. reporting. deployment.

see the MicroStrategy System Administration Guide. The sections that follow provide a brief overview of each of these components. To learn how to administer and tune the MicroStrategy platform. For more detailed information about these and the other components that make up the MicroStrategy platform. The information is stored in a proprietary 8 The MicroStrategy platform © 2007 MicroStrategy.1 BI Architecture and the MicroStrategy Platform Project Design Guide • MicroStrategy project. refer to the MicroStrategy Installation and Configuration Guide. 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. MicroStrategy metadata MicroStrategy metadata is a repository that stores MicroStrategy object definitions and information about your data warehouse. . as shown in the following diagram. Inc.

The Building Blocks of Business Data: Facts. reports. which are analytical calculations that are displayed on a report. and project administration. The metadata also stores the definitions of all objects created with MicroStrategy Desktop and Web such as templates. see the MicroStrategy System Administration Guide. Schema objects—Objects that are created in the application to correspond to database objects. Inc. Facts are discussed in more detail in Chapter 5. user privileges. attributes. and columns. In general. hierarchies. such as tables. report creation in MicroStrategy is achieved through using various types of objects which represent your data as report building blocks. These schema objects are often created and managed by a MicroStrategy architect: Facts relate numeric data values from the data warehouse to the MicroStrategy reporting environment. The number of units sold is one example of a fact. are all created and stored in the metadata repository. views. facts. and other objects which are stored in the Schema Objects folder in MicroStrategy Desktop’s folder list. configuration objects are created and maintained with the managers in MicroStrategy Desktop within the Administration icon. but are created by a project architect or administrator to configure and govern the platform. Facts are used to create metrics. users. and hierarchies are three essential pieces to any business intelligence application. • © 2007 MicroStrategy. attributes. Examples include database instances. which are described below.Project Design Guide BI Architecture and the MicroStrategy Platform 1 format within a relational database. You can build and manipulate several fundamentally different kinds of objects in MicroStrategy. metrics. These objects are not used directly for reporting. For more information about creating and administering configuration objects. groups. Schema objects include facts. The MicroStrategy platform 9 . The metadata maps MicroStrategy objects—which are used to build reports and analyze data—to your data warehouse structures and data. and so on. Facts. these objects. and so on. As a general rule. • Configuration objects—Objects that provide important information or governing parameters for connectivity.

MicroStrategy Intelligence Server evaluates the most efficient data retrieval scenario to provide excellent query performance. and so on. The Context of Your Business Data: Attributes. One of the most common examples of a hierarchy is a time hierarchy which includes attributes such as Year. Inc.1 BI Architecture and the MicroStrategy Platform Project Design Guide Attributes represent the business context in which fact data is relevant. These groupings can help users make logical connections between attributes when reporting and analyzing data. • Application objects—Objects used to provide analysis of and insight into relevant data. Southeast represents the attribute or context of the sales data. . page 13. It converts user requests into SQL queries and 10 The MicroStrategy platform © 2007 MicroStrategy. see MicroStrategy Web and Web Universal. Attributes are used to define the level at which you want to view the numeric data on a report. documents. Creating Hierarchies to Organize and Browse Attributes. filters. Reports and documents can also be created and managed in MicroStrategy Web. The metadata enables the sharing of objects across MicroStrategy applications by providing a central repository for all object definitions. MicroStrategy metadata also facilitates the retrieval of data from the data warehouse when using MicroStrategy applications. Hierarchies are discussed in more detail in Chapter 7. templates. Information on creating application objects is in the MicroStrategy Basic Reporting Guide and MicroStrategy Advanced Reporting Guide. metrics. and prompts. Application objects include reports. All application objects can be created and maintained in MicroStrategy Desktop. Month. Hierarchies are groupings of attributes so that they can be displayed to reflect their relationships to other attributes. Attributes are discussed in more detail in Chapter 6. For more information about MicroStrategy Web. In the example of regional sales in the Southeast. custom groups. Quarter. Application objects are created using schema objects as building blocks.

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. You can also add and define your own functions. The MicroStrategy platform 11 . For a detailed description of MicroStrategy Intelligence Server functionality and tuning recommendations.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. and OLAP analysis. refer to the MicroStrategy System Administration Guide. refer to the MicroStrategy Installation and Configuration Guide. See the MicroStrategy Functions Reference for details about these functions. For information on how to install and configure MicroStrategy Intelligence Server. 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. MicroStrategy Desktop MicroStrategy Desktop is an advanced. © 2007 MicroStrategy. Windows-based environment providing a complete range of analytical functionality designed to facilitate the deployment of reports. reporting. Inc. MicroStrategy Intelligence Server MicroStrategy Intelligence Server is an analytical server optimized for enterprise querying.

• After reports have been created. Inc. and other schema objects are the building blocks for application objects such as reports and documents. MicroStrategy Web. thus providing access to your data. For example. Projects are discussed in Chapter 4. The change automatically takes effect in the application. including MicroStrategy Desktop.1 BI Architecture and the MicroStrategy Platform Project Design Guide Desktop enables you to model applications using an intuitive. which are in turn used to design reports. Tables in MicroStrategy are references to tables in your data warehouse. Schema objects allow application objects to interact with the data warehouse to access the data for analysis. However. schema objects must first exist. This modification is necessary if you have new requirements that require you to add or remove new levels of data in a hierarchy. facts are used to create metrics. Desktop is where you can manage application objects such as reports. before application objects are created. For information about the various components that comprise MicroStrategy Desktop. report designers and analysts can deploy them through different interfaces. refer to the MicroStrategy Installation and Configuration Guide. and metrics. hierarchies. attributes. without making any alterations to the database. Facts. Application objects such as reports are used to analyze and provide insight into the relevant data. 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. One of the other functions of MicroStrategy Desktop is to create projects. It provides a unified environment for creating and maintaining business intelligence projects. Desktop provides the ability to modify one aspect of the application without affecting the others. filters. You can change the structure of a business hierarchy by re-ordering it. and MicroStrategy Office. If you need to change how to view your business information or how the data is modeled. Creating and Configuring a Project. graphical interface. 12 The MicroStrategy platform © 2007 MicroStrategy. .

IBM WebSphere®. are discussed in Project connectivity components. and Apache Tomcat All web servers and browsers supported by MicroStrategy Web MicroStrategy Intelligence Server must be running for users to retrieve information from your data warehouse using MicroStrategy Web products. MicroStrategy Web provides ad-hoc querying. Inc. Using the Web interface. including many project-related terms. and rapid customization potential. © 2007 MicroStrategy. For information on advanced Desktop functionality. analyze. The MicroStrategy platform 13 . making it easy for users to make informed business decisions. Red Hat® Linux®. Additional MicroStrategy definitions. and HP-UX Application servers such as BEA WebLogic™. see the MicroStrategy Installation and Configuration Guide. see the MicroStrategy Advanced Reporting Guide. page 64. refer to the MicroStrategy Basic Reporting Guide. IBM AIX®.Project Design Guide BI Architecture and the MicroStrategy Platform 1 For more information about creating application objects such as reports in MicroStrategy Desktop. users can access. Sun ONE®. and share data through any web browser on many operating systems. MicroStrategy Web Universal is a version of MicroStrategy Web that provides the added benefits of also working with: • • • Operating systems such as Sun Solaris™. quick deployment. For more information about deploying MicroStrategy Web. industry-leading analysis. MicroStrategy Web and Web Universal MicroStrategy Web provides users with a highly interactive environment and a low-maintenance interface for reporting and analysis. Oracle®.

projects appear one level below project sources in the Folder List. Schema objects include facts. metrics. and user community. and so on. you may have a project source separated into four different projects with analysis areas such as human resources. Contains all reporting objects used to create reports and analyze the data. privileges. Security and other project-level administrative features are discussed in the MicroStrategy System Administration Guide. sales distribution. hierarchies. and 14 The MicroStrategy platform © 2007 MicroStrategy. Defines the security scheme for the user community that accesses these objects. Report objects are covered in the MicroStrategy Basic Reporting Guide and the MicroStrategy Advanced Reporting Guide. A project: • • Determines the set of data warehouse tables to be used. • • A project can contain any number of reports in addition to a number of other objects that support simple and advanced reporting requirements. A project can contain many types of objects. Contains all schema objects used to interpret the data in those tables. In MicroStrategy Desktop. and reports that you can create using schema objects such as attributes and facts. attributes. Conceptually. which together provide a flexible reporting environment. Inc. . and therefore the set of data available to be analyzed. reports. A project also represents the intersection of a data source. inventory. For example. access control.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. metadata repository. Security objects include security filters. filters. a project the environment in which all related reporting is done. prompts. Reporting objects include metrics. and so on. including application objects such as filters. security roles. and so on. Projects are often used to separate data from a data warehouse into smaller sections of related data that fit user requirements. Schema objects are discussed in later chapters in this guide.

Project Design Guide BI Architecture and the MicroStrategy Platform 1 customer satisfaction. The project design process When you create a project in MicroStrategy Desktop. Inc. one of the connections you create is between the project and your data warehouse. determined by the project source through which you create the project. Some key concepts to understand before you begin creating a project are as follows: • A project is created within a specified metadata repository. © 2007 MicroStrategy. The project design process 15 . you can then create schema objects based on the columns and tables in the warehouse. • The procedures associated with these concepts are explained in Creating the project. The project’s warehouse location is specified by associating it with the appropriate database instance. page 73. In the project. 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.

. and project creation. schema design and implementation. It is important to keep this in mind as you design your project and plan for the next phase of development. As projects are deployed and tested. linear process. Designing a project is very rarely a single. 16 The project design process © 2007 MicroStrategy.1 BI Architecture and the MicroStrategy Platform Project Design Guide The diagram below shows this high-level view of data modeling. new user requirements and project enhancements require modification to the initial project design. which are each covered in the following chapters: Notice that the project design process includes a feedback loop. Inc.

which arranges data for efficient database use.2 2. A logical data model is a logical arrangement of data as experienced by the general user or business analyst. Inc. providing a way of organizing data so it can be analyzed from different business perspectives. For example. You also need a plan that is visible and laid out correctly. You need to know where you are going and how to get there. 17 . how its various parts interact. a simple logical data model for a retail company can organize all necessary © 2007 MicroStrategy. and can also help you decide what you intend to learn from the data. A logical data model is similar in concept to using a map and an itinerary when going on a trip. This chapter describes one of the major components of data modeling: the logical data model. This is different from the physical data model or warehouse schema. The logical data model graphically depicts the flow and structure of data in a business environment. 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.

This is the key concept of the logical data model. 18 © 2007 MicroStrategy. and time. which are three common business perspectives typically associated with a retail business. As the MicroStrategy platform does not require you to define dimensions explicitly.2 The Logical Data Model Project Design Guide facts by store. Inc. the word logical is a more accurate term than multidimensional. What occurs under the logical data model can change with need or with technology. . and you do not need to start over completely. the more complex the logical data model becomes. logical data modeling is similar to multidimensional data modeling. 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. but the blueprint remains the same. The more sophisticated and complex the reporting requirements and source data. If you are familiar with multidimensional data modeling. The reason that a logical data model must be independent of technology is because technology is changing so rapidly. While a multidimensional data model must have at least one dimension. product. a logical data model may or may not have any explicitly defined dimensions. Logical data models are independent of a physical data storage device.

and relationships of data in a technical.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. conceptual. 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. or business environment. characteristics. Inc. 19 .

This is usually one of the first steps in designing a project.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. as shown in the following diagram: This chapter provides conceptual information about logical data models. and also general instructions and guidelines for creating these models. Inc. page 22 Hierarchies: Data relationship organization. A logical data model is a graphic representation of the following concepts: • • • Facts: Business data and measurements. . the elements that exist within them. page 21 Attributes: Context for your levels of data. page 25 20 © 2007 MicroStrategy.

For example.EMP_ID) WHERE a22. facts exist as columns within the fact tables. the ORDER_AMT column in the warehouse may correspond to the Order Amount fact in the MicroStrategy environment: SELECT sum(a21. in the following SQL statement. 9. you can think of facts as business measurements. To those familiar with SQL. such as SUM and AVG. while you capture stock and inventory data in another system and track it weekly. data.CALL_CTR_ID in (5.ORDER_AMT) EMP_NAME FROM ORDER_FACT a21 JOIN LU_EMPLOYEE a22 ON (a21.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. or variables that are typically numeric and suitable for aggregation. 12) © 2007 MicroStrategy. They can come from different source systems and they can have different levels of detail. Inc. Sales. In a data warehouse. you can capture sales data in one system and track it daily. For example. Facts are the building blocks used to create business measurements or metrics from which to derive insight into your data. and Account Balance are some examples of facts you can use as business measurements. In MicroStrategy. Facts: Business data and measurements 21 . facts are schema objects that relate data values (typically numeric data) from the data warehouse to the MicroStrategy reporting environment. Conceptually.EMP_ID = a22. Inventory. facts generally represent the numeric columns in database tables on which you perform SQL aggregations. The rest of data modeling consists mostly of providing context for the data that facts provide access to. 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.

ORDER_AMT) represents a metric. a Month attribute allows you to see the same sales data summarized at the month level. attributes generally represent the non-numeric and non-aggregatable columns in database tables. Fore a more complete discussion about facts.2 The Logical Data Model Project Design Guide In addition. The Building Blocks of Business Data: Facts. which are business calculations often built using facts. If you were informed that your company had sales of $10. consider the sales figures of your company. refer to Chapter 5. if your sales data is stored at the day level.000. such as national. sum(a21. Inc. For example. 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. . 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. you can gather little useful information. while ORDER_AMT is the fact. regional. Metrics are discussed in detail in the MicroStrategy Basic Reporting Guide. 22 Attributes: Context for your levels of data © 2007 MicroStrategy. the attributes must be identified. For example. To those familiar with SQL. local. To make the sales figure meaningful. Attributes: Context for your levels of data After the facts are determined. Attributes allow you to answer questions about a fact and provide a context for reporting and analyzing those facts. They are used to answer business questions about facts at varying levels of detail. These columns are used to qualify and group fact data.

For example. Inc.MONTH_DESC) MONTH_DESC. © 2007 MicroStrategy. sum(a11. The Context of Your Business Data: Attributes. refer to Chapter 6. For example. Attribute elements also allow you to qualify on data to retrieve specific results.MONTH_ID = a12. the MONTH_ID column in the warehouse maps to the Month attribute in the MicroStrategy environment: SELECT a11. Attributes: Context for your levels of data 23 . page 36.TOT_DOLLAR_SALES) DLRSALES FROM MNTH_CATEGORY_SLS a11 join LU_MONTH a12 on (a11. in the following SQL statement. 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. Attribute elements: Data level values Attribute elements are the unique values or contents of an attribute.MONTH_ID MONTH_ID. attributes are used to build the report and the attribute elements are displayed in rows or columns on the executed report.200202. max(a12.200203) GROUP BY al1. For a complete discussion about attributes.MONTH_ID) WHERE a11. On a report.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. 2005 and 2006 are elements of the Year attribute while New York and London are elements of the City attribute.Project Design Guide The Logical Data Model 2 For example.MONTH_ID in (200201.

and therefore no logical structure. you can better design your data model and project. A child must always have a parent and a parent can have multiple children. The relationships give meaning to the data by providing logical associations of attributes based on business rules. Inc. Attribute elements are discussed in more detail in Unique sets of attribute information: Attribute elements. Attribute relationships Building an effective project in MicroStrategy requires you. which are associations between attributes that specify how attributes are connected. page 140. as well as how each of them relates to the other attributes. as the project designer. By recognizing and understanding the elements of an attribute. Attribute relationships. they are necessary in understanding attribute relationships. Without relationships. are essential to the logical data model.2 The Logical Data Model Project Design Guide The following diagram shows some examples of attributes and attribute elements. Although attribute elements are not included in the logical data model. Every direct relationship between attributes has two parts—a parent and a child. to have a solid understanding of all the attributes in the project. . there is no interaction between data. The parent attribute is at a 24 Attributes: Context for your levels of data © 2007 MicroStrategy.

However. Attributes in one hierarchy are not directly related to attributes in another hierarchy. and hierarchies are related and form a complete logical data model is shown in the section Sample data model. you can group the attributes Year. Year and Quarter are attributes that are usually directly related to each other. Year and Customer are related through a fact. In a logical data model. Therefore. It is the existence of a fact that ties the Time hierarchy to the Customer hierarchy. if you want to create a report that shows information about customer purchases in a particular year. Usually the best design for a hierarchy is to organize or group attributes into logical business areas. They are identified by multiple attributes.Project Design Guide The Logical Data Model 2 higher logical level than the child is. Examples of related and unrelated attributes. are discussed in Attribute relationships. facts exist at the intersection of hierarchies. In this case. © 2007 MicroStrategy. Hierarchies: Data relationship organization 25 . there must be some way to determine how these two attributes are related. along with more detailed information about attribute relationships. For example. and Day to form the Time hierarchy. Attributes are either related or unrelated to each other. Year is the parent attribute and Quarter is the child. the fact is a customer purchase. hierarchies contain attributes that are directly related to each other. A graphical example of how facts. 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. One year has many quarters and both attributes are in the Time hierarchy. For example. page 26 below. in a relationship between Year and Quarter. For example. Year and Customer are attributes that are usually not in the same hierarchy and are not directly related to each other. Month. Inc. attributes. which represent the level at which a fact is stored.

Inc.2 The Logical Data Model Project Design Guide For a complete discussion about hierarchies. attributes. Sample data model When all of the components are placed in a single diagram—facts. refer to Chapter 7. relationships. Creating Hierarchies to Organize and Browse Attributes. 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 • • • User requirements Existing source systems Converting source data to analytical data 26 Sample data model © 2007 MicroStrategy. and hierarchies—a logical data model begins to take shape. .

Sometimes. page 28. These managers may want reports about their specific region or store over short-and long-terms. However. 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. additional user requirements can be encountered after deploying a project as users encounter areas for enhancement. © 2007 MicroStrategy. lack of data in the source systems can limit user requirements. In some cases. Your user community can consist of people with vastly different requirements. where additional questions and concerns arise with each draft of the logical data model. User requirements are an important part of the initial project design process. When creating the logical data model. as explained in Existing source systems. In some cases. you can derive additional data not found in the source systems.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. For example. Inc. 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. 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. Building a logical data model 27 . you must consider all the potential users and how to accommodate their varied requirements. to satisfy user requirements.

Although some data may not exist in a source system. For example. 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. State and region do not appear in the existing source data and so you need to extract them from another source. although data is stored at a daily level in the source system. User requirements should drive the decision on what to include and what to exclude. However. everything you find in the source data does not necessarily need to be included in the logical data model. . 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.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. users also want to see data at the monthly or yearly level. In this case. you can build the logical data model based heavily on current user requirements. and relationships. Inc. you may not find all the facts and attributes to meet your needs within the data itself. Conversely. Additionally. 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. Existing data is usually abundant. While a review of your data is initially helpful in identifying components of your logical data model. you can plan additional attributes to provide the levels at which you intend to analyze the facts in your data model. Converting source data to analytical data If there are no existing systems and you are just beginning your data warehousing initiative. this does not mean that it should not be included in the logical data model. 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. attributes. The existing data should suggest a number of facts.

determine the business level at which each fact is recorded. Remember that facts can be calculated and are usually numeric and aggregatable. For example. page 31 Step 4: Define hierarchies. Whether you start from nothing or have an existing source system to use. A logical data model is similar in concept to an ERD. sales and profit figures. A product inventory fact. or day level. item. page 30 Step 3: Determine attribute relationships. For example. An ERD provides a graphical representation of the physical structure of the data in the source system. for a particular item. The source data usually has some sort of documented physical structure. However. After you have all the facts listed. the steps to create a logical data model are as follows: • • • • Step 1: Identify the facts. in retail models.Project Design Guide The Logical Data Model 2 implemented. Step 1: Identify the facts Using your existing data. on a particular day. page 29 Step 2: Identify the attributes. page 32 The details in these steps are related to using an existing source system. Building a logical data model 29 . which lets you easily recognize tables and columns and the data stored in those columns. sales facts are often stored at the store. can be © 2007 MicroStrategy. for example. Inc. make a list of all data that can be represented as facts in MicroStrategy. 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. meaning that a sale takes place in a particular store. however. most OLTP systems have an entity relationship diagram (ERD).

or week level. your users are interested in analyzing data at more than just at the day level. 30 Building a logical data model © 2007 MicroStrategy. You can then design a Year attribute for your project. Inc. These business levels become the attributes in your logical data model (see Step 2: Identify the attributes. item. To improve performance and meet the requirements of the majority of your users. For example. They also want to view their data at the year. page 30). This analysis requires MicroStrategy to aggregate the sales data from the day level to the year level. 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). Start by looking at the levels at which each fact is recorded and build from there. However.2 The Logical Data Model Project Design Guide stored at the region. and week levels. month. in the existing data there may be fact data recorded only at the day level. Step 2: Identify the attributes Uncover attributes by considering the levels at which you would like to view the facts on your reports. 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. . 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.

Building a logical data model 31 . Primary Competitor. for a number of dates (in a © 2007 MicroStrategy. 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. you should determine the type of relationship. several dates exist. These attributes are all related to the Opportunity attribute because they all answer questions about opportunity information. Year has a one-to-many relationship to Month. Opportunity Open Date. From the reverse perspective the same relationship specifies that. and Month has a one-to-many relationship to Day. Additionally. you must then determine which attributes are related to each other. Logical data modeling is an iterative process. It is usually unnecessary to bring all data from the source system into the analytical environment. for every year. in the diagram below. Only include facts and attributes that can serve your user community. Step 3: Determine attribute relationships Once you have identified your data to be defined as attributes in MicroStrategy.Project Design Guide The Logical Data Model 2 Be careful not to include more facts and attributes than necessary. and so on. you can always add more attributes and facts later. Inc. and for every month. several months exist. For example. if necessary. This one-to-many relationship specifies that.

and so on) and not directly connected to a year (Dec 2005.2 The Logical Data Model Project Design Guide form such as 12/01/2005). Inc. If you have documentation for the existing data. You can 32 Building a logical data model © 2007 MicroStrategy. Jan. Consider the Year to Month attribute relationship type of one-to-many. only one year exists. you can organize all time-related attributes into the Time hierarchy. and for a number of months. Jan 2006. 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. Attribute relationships are discussed in detail in Attribute relationships. In the context of a logical data model. such as an ERD. This example may not accurately define how you store time information. think of hierarchies as logical arrangements of attributes into business areas. For example. If you define the attribute Month as simply the month name (Dec. it is likely that the documentation provides some additional details about the nature of the data and any inherent relationships. . and so on) then the relationship would become many-to-many. only one month exists (in a form such as Dec 2005).

Logical data modeling conventions 33 . Again. Inc. help with system maintenance. the requirements of your user community should help you determine what hierarchies are necessary. These include: • • • Unique identifiers Cardinalities and ratios Attribute forms These logical modeling conventions can provide cues for system optimization opportunities. Depending on the complexity of your data and the nature of your business.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. It is possible that all the data is directly related. in which case you may have one big hierarchy. Although the user community is the ultimate beneficiary of a © 2007 MicroStrategy. you may have very few hierarchies or you may have many. and make for a more robust logical data model. Logical data modeling conventions There are numerous logical data modeling conventions you can use to enhance your logical data model.

Unique identifiers An additional modeling convention is to add unique identifiers for each attribute and fact.2 The Logical Data Model Project Design Guide well-optimized and maintained system. when applicable. Each convention adds more information about the data to the logical data model. The following diagram shows a logical data model with unique identifiers added. This information can help define primary keys in the physical warehouse schema (see Uniquely identifying data in tables with key structures. and advanced report designers. This additional information can be particularly useful to a person learning about the system. these conventions are primarily intended for project designers. administrators. . Remember that facts are usually identified by multiple attributes and therefore will have multiple unique identifiers. Some attributes rely on more than 34 Logical data modeling conventions © 2007 MicroStrategy. Inc. page 42). Unique identifiers denote the key that maps an attribute to its source data in the source system.

note the Item attribute.Project Design Guide The Logical Data Model 2 one ID column to identify its elements. Ratios can be particularly helpful when trying to © 2007 MicroStrategy. Inc. 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. Creating Hierarchies to Organize and Browse Attributes. Logical data modeling conventions 35 . Cardinalities and ratios Another enhancement to the logical data model is the addition of cardinalities and ratios for each attribute. which are discussed in Chapter 7. Cardinality is the number of unique elements for an attribute and ratios are the ratios between the cardinalities of related attributes. For example. which requires both the Item_ID and Class_ID columns to uniquely identify its elements.

This additional information can be invaluable to database administrators and project designers. this is because this information varies and is unpredictable. Inc. Also note that the cardinality of some attributes such as Date of Birth are unknown. it is impossible to determine how many customers have different dates of birth in the warehouse.2 The Logical Data Model Project Design Guide decide where creating aggregate tables will be most effective. 36 Logical data modeling conventions © 2007 MicroStrategy. Note the cardinalities in the upper right corner of each attribute rectangle and the ratios next to some of the relationships between attributes. For example. 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. . The following diagram shows a logical data model which includes cardinalities and ratios.

you can model these additional © 2007 MicroStrategy. and in the data. When a one-to-one relationship exists between an attribute and one of its descriptions.Project Design Guide The Logical Data Model 2 Attribute forms contain additional descriptive information about a given attribute. Each element of the Customer attribute represents a different customer. In reality. and it is part of the Customer hierarchy. Inc. For example. each with a one-to-one relationship to the Customer attribute. 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. you create an attribute called Customer to represent customers in your system. though. these attributes simply provide additional information about the Customer attribute. Logical data modeling conventions 37 . they do not represent different levels within the Customer hierarchy.

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:

Attribute forms are discussed in terms of their role in MicroStrategy in Column data descriptions and identifiers: Attribute forms, page 143.

38 Logical data modeling conventions

© 2007 MicroStrategy, Inc.

3
3.

Physical Warehouse Schema

WAREHOUSE STRUCTURE FOR YOUR LOGICAL DATA MODEL

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. In contrast, the logical data model is a logical arrangement 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
39

© 2007 MicroStrategy, Inc.

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.

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. including Item_Mnth_Sls and City_Ctr_Sls. and Discount fact columns. the derived fact Tot_Dollar_Sales is created using the Qty_Sold. the derived fact exists in several tables. © 2007 MicroStrategy. Inc. Unit_Price.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. Tables: Physical groupings of related data 47 . 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. Also.

see the MicroStrategy Advanced Reporting Guide. the following image shows two facts with an Item/Day/Call Center level. page 97. which translates into simpler SQL and a speedier query at report run time. Inc. You can create the same type of data analysis in MicroStrategy with the use of metrics.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 disadvantage is that derived fact columns require more storage space and more time during the ETL process. For more information on the different types of facts in MicroStrategy and how they are defined. Metrics allow you to perform calculations and aggregations on fact data from one or more fact columns. 48 Tables: Physical groupings of related data © 2007 MicroStrategy. day. 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 more information on what metrics are and how to create them. and call center levels because those levels exist as ID columns in the fact table. The Sales and Inventory facts can be analyzed at the item. and Call_Ctr_id columns in the table above represent practical levels at which sales and inventory data can be analyzed on a report. Day_id. The advantage of storing derived fact columns in the warehouse is that the calculation of data is previously performed and stored separately. The Item_id. see How facts are defined. For example.

and in one source system regions are identified by column name Region_id and in the other the column name is Reg_id. notice that the table above does not include the Customer_id column. as shown in the diagram below. Fact tables should only include attribute ID columns that represent levels at which you intend to analyze the specific fact data. and when a reporting request involves still a different level. These naming inconsistencies occur because source systems use different naming conventions to name the data they collect. Homogeneous versus heterogeneous column naming Suppose the data warehouse has information from two source systems. This is called heterogeneous column naming. © 2007 MicroStrategy.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. You must be able to support fact reporting at the business levels which users require. they store the same data: information about regions. Though the Region_id and Reg_id columns have different names. 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. Tables: Physical groupings of related data 49 . this is because analyzing inventory data at the customer level does not result in a practical business calculation. Inc. For example.

This explains why the same information about regions is represented by two columns with different names.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. . Inc. the Region_ID column has the same name in both tables. heterogeneous columns must be mapped to their corresponding facts and attributes. In order for reports to retrieve accurate and complete results. it is a good idea for columns that contain the same data to have the same column name. In this case. consider the heterogeneous column names that may exist in your source systems. When you define facts and attributes in MicroStrategy Desktop. as shown in the following diagram: 50 Tables: Physical groupings of related data © 2007 MicroStrategy. 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. This is called homogeneous column naming. For example. if you create a Region attribute given the tables in the example above. For consistency.

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. How you choose to structure the warehouse depends on the nature of your data. 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. 51 . 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. A fact column may or may not have the same name in different tables. it is also possible for the same fact data to exist in different fact tables. Typically. the available storage space. one of the schema types. These schema types are: • • • 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 © 2007 MicroStrategy. and the requirements of your user community.

see Using summary tables to store data: Aggregate tables. lookup tables contain unique developer-designed attribute keys. • Highly normalized schema: Minimal storage space The following diagram is an example of a highly normalized schema. • Joins are SQL operations that are required to combine two tables together in order to retrieve data. such as Call_Ctr_id. Data redundancy also makes updating data a more intensive and difficult process because data resides in multiple places. The sections below are not meant to be an exhaustive list of all possible schema types. and Region_id. the number of joins required to build your queries affects the performance of those queries. Dist_Ctr_desc. 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. and 52 Schema types: Data retrieval performance versus redundant storage © 2007 MicroStrategy. but as with any operation performed on your data warehouse. data only has to be updated in a single place. . These operations are necessary. Fact table keys consist of attribute keys relevant to the level of data stored in the table. Dist_Ctr_id.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. page 241). 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. as shown in the figure below. When comparing the different schema types. They also contain attribute description columns. such as Call_Ctr_desc. Inc. The schema examples that follow show data at the Item/Call Center/Date level. However. With no data redundancy. In highly normalized schemas. you should keep in mind the following concepts: • Redundant data can cause a couple of drawbacks.

the lookup table for an attribute contains the ID column of the parent attribute. Also. Inc. Schema types: Data retrieval performance versus redundant storage 53 .Project Design Guide Warehouse Structure for Your Logical Data Model 3 Region_desc. © 2007 MicroStrategy. such as Dist_Ctr_id in the Lookup_Call_Ctr table.

However.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. therefore. This is because each table contains only a small amount of information about a given attribute. 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. there is a drawback to using only small tables in the data warehouse. . This schema type has the same basic structure as the highly normalized schema. numerous joins are required to retrieve information about the higher-level tables. Inc. When accessing higher-level lookup tables such as Lookup_Region in the example above. The difference 54 Schema types: Data retrieval performance versus redundant storage © 2007 MicroStrategy.

Region_id is included in the Lookup_Call_Ctr table.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. © 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 tables within this type of schema take up some redundant storage space in the warehouse. Because the ID columns of both the parents and grandparents of an attribute exist in multiple tables. since some tables contain the same ID columns (as shown above with the Region_ID column). However. Using a moderately normalized schema provides a balance between the pros and cons of normalized and denormalized schema types. The following diagram shows what the physical lookup tables look like in the warehouse. A highly denormalized schema has the same basic structure as the other two schema types. fewer joins are required when retrieving information about an attribute. Inc. Highly denormalized schema: Enhanced query performance The following diagram is an example of a highly denormalized schema. . With 56 Schema types: Data retrieval performance versus redundant storage © 2007 MicroStrategy.

this schema type requires the largest amount of storage space within the warehouse because of its large lookup tables. For example. High denormalized schemas also cause the highest level of data redundancy. Distribution Center. This is possible because Lookup_Call_CTR contains all information (including description data) for Call Center as well as for Distribution Center and Region. Using a highly denormalized schema further reduces the joins necessary to retrieve attribute descriptions. Region_desc is included in the Lookup_Call_Ctr table. Inc. However. Schema types: Data retrieval performance versus redundant storage 57 . not only are higher-level attribute ID columns present within all related tables. you can include the descriptions of Call Center.Project Design Guide Warehouse Structure for Your Logical Data Model 3 this type. and Region along with Sales Dollars in the same report while only having to join the Lookup_Call_CTR and Fact_Sales tables. © 2007 MicroStrategy. For example. but the description columns are present as well.

geography) consists of several lookup tables. the lookup tables are consolidated so that every attribute ID and description column for a given hierarchy exists in one table. as shown below. In a star schema. star schemas can often 58 Schema types: Data retrieval performance versus redundant storage © 2007 MicroStrategy. . the amount of join operations are reduced by using a star schema. However. Recall that in a highly denormalized schema. each hierarchy (for example.3 Warehouse Structure for Your Logical Data Model Project Design Guide Star schema: Consolidating lookup tables When using the highly denormalized schema. A star schema can also reduce the amount of storage space necessary in a highly denormalized schema. it is possible to eliminate most of the lookup tables and leave just a few. as shown below: As with any schema type model there are advantages and disadvantages to using a star schema. only one lookup table is used to contain all of the attribute IDs and description columns for a given hierarchy. In this type of schema. however. Arranging the warehouse schema this way produces a star schema. Inc. As with a highly denormalized schema type.

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. and greater maintenance for the database administrator. you will have to create an extensive data model and schema to support those requirements. However. slower query performance. Design trade-offs Constructing a logical data model and physical warehouse schema is an iterative process of compromises and trade-offs. You must decide which factors are most important in your particular environment and weigh them against the other factors. If you try to satisfy every single user requirement from the simplest to the most complex. 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. This results in an increased load on the warehouse. 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. For example. Design trade-offs 59 . The following diagram shows the three major requirements that must be balanced to create an effective system. Inc. Each of these categories affects the others.

One hierarchy can be highly normalized while another can be highly denormalized. In addition to the previous points. page 241. 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. which are discussed in Using summary tables to store data: Aggregate tables. For more comparisons between the different schema types described in this chapter. see the following section Schema type comparisons. You can even use different schema types within the same hierarchy. Schema Type Highly normalized schema Lookup Table Structure • Attribute ID • Attribute description column • ID column of parent • Attribute ID • Attribute description column • ID column of parent • ID column of grandparents Advantages Minimal storage space and minimal data redundancy which makes updating data less intensive than for the other schema types Greatly reduces the number of joins necessary to relate an attribute to its grandparents as compared to a highly normalized schema Disadvantages Requires numerous joins to retrieve information from higher-level lookup tables Moderately normalized schema Requires some redundant storage 60 Schema type comparisons © 2007 MicroStrategy. page 60. The table below compares the different schema types. Inc. .3 Warehouse Structure for Your Logical Data Model Project Design Guide expensive in terms of database resources and processing time. you may need higher level lookup tables to take advantage of aggregate tables. 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.

Project Design Guide Warehouse Structure for Your Logical Data Model 3 Schema Type Highly denormalized schema Lookup Table Structure • Attribute ID • Attribute description column • ID column of parent • description column of parent • ID column of grandparents • description column of grandparents • Consolidates an entire hierarchy into a single lookup table Advantages Further reduces joins necessary to retrieve attribute descriptions as compared to a moderately normalized schema Disadvantages Requires the most storage space and redundant data requires a more intensive process to update Star schema • 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 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. Schema type comparisons 61 . As facts and attributes are the cornerstones of the reports you intend to create using MicroStrategy. you can learn about these same schema objects in terms of how they exist in the MicroStrategy environment. it is essential to understand the structure of each of these schema objects before creating a project. © 2007 MicroStrategy. Inc.

. Inc.3 Warehouse Structure for Your Logical Data Model Project Design Guide 62 Schema type comparisons © 2007 MicroStrategy.

This chapter guides you through the first few major steps involved in creating a project in MicroStrategy.4 4. Inc. see Chapter 1. CREATING AND CONFIGURING A PROJECT Introduction Once you create a logical model of your business data and arrange the data within the data warehouse. For more information about the © 2007 MicroStrategy. BI Architecture and the MicroStrategy Platform. you are ready to create 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. access the MicroStrategy Tutorial provided with the MicroStrategy platform. To see a sample project. It is ready to be used and requires no additional configuration tasks. The Tutorial is a sample data warehouse and demonstration project you can use to learn about the various features of the MicroStrategy platform. 63 .

see Appendix A. refer to the MicroStrategy Basic Reporting Guide.4 Creating and Configuring a Project Project Design Guide Tutorial. Metadata is stored in a relational database with a predefined structure. configuration objects. To view the structure of the MicroStrategy Tutorial. Project connectivity components This section defines some of the basic terminology used in project creation in MicroStrategy Desktop. and project settings are stored in the MicroStrategy metadata. 64 Project connectivity components © 2007 MicroStrategy. . It is intended to familiarize you with some of the terms discussed in this guide. MicroStrategy metadata All schema objects. The RDBMS for the metadata and warehouse do not need to be the same. application objects. MicroStrategy Tutorial. Inc.

You create the metadata shell with the MicroStrategy Configuration Wizard. You should not connect directly to the metadata unless you are implementing a prototype environment. To view the readme from the Start menu select Programs. Inc. then MicroStrategy. which creates the blank tables and populates some of the tables with basic initialization data. Project connectivity components 65 . It is highly recommended that you never use direct mode connection in a production environment. page 71. In MicroStrategy Desktop. and password to a metadata repository. login. the necessary tables to hold the data must be present. the project source appears in the Folder List with an icon that varies depending on the type of connection it represents. © 2007 MicroStrategy. MicroStrategy strongly suggests you always connect to the metadata through Intelligence Server because of the security and scalability it provides. The metadata shell is the set of blank tables that are created when you initially implement a MicroStrategy business intelligence environment. and then select ReadMe.Project Design Guide Creating and Configuring a Project 4 You can find the list of supported RDBMS platforms in the readme file that is installed with MicroStrategy products. This first step in the project creation process is outlined in Creating the metadata repository. Metadata shell Before you can populate the metadata repository with data. 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. Project source The project source is a configuration object which represents a connection to a metadata repository.

A four-tier connection is a Server (three-tier) connection in conjunction with MicroStrategy Web deployed on a web server. which in turn governs and validates the connection to the metadata. For these reasons. the same metadata repository can be accessed by multiple project sources. schema objects. MicroStrategy Desktop is the second tier. A project source connects to a single metadata repository. 66 Project connectivity components © 2007 MicroStrategy. Intelligence Server manages all connections to databases. and configuration objects from any number of projects defined within this project source (see MicroStrategy metadata. and ensures metadata integrity. The project metadata is the first tier. and Intelligence Server is the third tier. every object definition you create within this project source is stored in this metadata. A project source may contain any number of projects. This is the type of connection used to create a production-ready project in MicroStrategy. enforces security.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. page 8 for definitions of these object types). Inc. However. This includes application objects. After the connection to the metadata is established. and MicroStrategy Desktop. Intelligence Server is a necessary part of any production project. . Intelligence Server. The following diagram illustrates Server connectivity between a MicroStrategy metadata repository.

When you define a project.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. © 2007 MicroStrategy. Inc. For information on database instances. Connecting to a data source through a database instance is explained in detail in Connecting to a data source. For more information on what a project is in MicroStrategy. and user community. Project connectivity components 67 . page 72. see MicroStrategy project. you specify the data source location by creating and selecting a database instance with the appropriate connection parameters. metadata repository. 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. see the MicroStrategy Installation and Configuration Guide. A project also represents the intersection of a data source. page 14.

Creating a project The following procedure describes the main steps to create a MicroStrategy project. database instances. . These steps provide you with a high-level view of the project creation process. project sources. 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. and projects. 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.4 Creating and Configuring a Project Project Design Guide Summary of project connectivity With a firm understanding of the MicroStrategy metadata. Bear this process in mind as you proceed through the rest of this guide.

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. You can use Query Builder or Freeform SQL to 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. The steps listed above relate to the process of creating 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. Before proceeding to the next section, make sure your 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. For instructions on creating a metadata repository in a 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

MicroStrategy also allows you to connect to your SAP 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 Intended audience Project type Complexity Project Creation Assistant Advanced users Production-ready or other large projects Extensive features require more project design knowledge Project Builder Newer users Test or basic projects 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 Advanced; can create the following objects and more: • multiple tables, attributes, and facts at once • attributes with many-to-many and joint child relationships A variety of databases and other data sources

Project Builder Limited; cannot be used to create multiple schema objects at once, but can be used to create basic hierarchies and metrics

Functionality

Metadata repository type Metric and report creation

Microsoft Access

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

Creating and Configuring a Project

4

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. You can use Project Mover to move a demonstration 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. You can learn about creating and designing reports in 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. It is assumed you intend to implement Intelligence Server 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: • 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.

76 Creating the project

© 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. You should complete all the steps in the Project 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. Inc. . 2 From the Schema menu. 78 Creating the project © 2007 MicroStrategy. description. select Create New Project. such as the Warehouse Catalog. For more details on how to setup HTML documents for a project. see the Configuring and Connecting Intelligence Server chapter of the MicroStrategy Installation and Configuration Guide. The Project Creation Assistant opens. 4 Enter the name. To create a project source which connects to your data through Intelligence Server. as shown below: 3 Click Create project. or Attribute Creation Assistant. and default document directory location for the project. Fact Creation Assistant. To create a new project using the Project Creation Assistant 1 Log in to a project source in MicroStrategy Desktop. see the MicroStrategy Installation and Configuration Guide. The New Project page opens. The default document directory for a project is the directory location to store all HTML documents.

select Enable the guest user account for this project. The Project Creation Assistant creates an empty project in the metadata repository. You use the Warehouse Catalog to add warehouse tables to your project.Project Design Guide Creating and Configuring a Project 4 5 To support anonymous authentication mode for guest users for this project. you cannot proceed to the next step. you select the lookup. When you create a new project. If you are not authorized by your database or system administrator to create projects in the data source you have selected. Adding tables using the Warehouse Catalog The warehouse tables for a project determines the set of data available to be analyzed in the project. 7 Click OK. and the Project locale property match. select the project source in which you created the database instance to connect to your metadata repository. the language of the local machine (the LOCAL_MACHINE registry key). Inc. Proceed to the next section to determine the tables to be used in your project. The Warehouse Catalog queries the data source and lists the tables and columns that exist in it. fact. and relationship tables to use in your new © 2007 MicroStrategy. it can lead to inconsistencies in the language display. 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. 8 Enter a valid login ID and password and click OK. From this list. When these properties do not match. The Login dialog box opens. a language check ensures that the language settings of the user profile of the local machine (the CURRENT_USER registry key). Creating the project 79 . 6 From the Project Source drop-down list. The language check prevents these inconsistencies and ensures that the language display is consistent across the project.

The database login you use must have read privileges so you are able to view the tables in the selected warehouse. Inc. Once tables are selected from the data source and added to your project. 2 Select a database instance from the drop-down list and click OK. Logical Tables. You should also include all other tables needed to complete your project. Database instances and database logins are MicroStrategy objects that determine the warehouse to which a project connects. To learn more about these objects. MicroStrategy schema objects such as attributes. and partition mapping tables. Logical tables are representations of the tables that are available in the data warehouse. they become schema objects known as logical tables in MicroStrategy. facts. To add and remove tables to the project using the Warehouse Catalog 1 In the Project Creation Assistant. You can edit your database instance by clicking Edit. and tables are abstractions built on top of the tables and columns in the data source. 80 Creating the project © 2007 MicroStrategy. refer to the MicroStrategy Installation and Configuration Guide. The database instance selected in this dialog box determines which data source is accessed. The Warehouse Database Instance dialog box opens. aggregate tables. including transformation tables. select Select tables from the Warehouse Catalog. . The Warehouse Catalog opens. and are discussed in detail in Appendix C.4 Creating and Configuring a Project Project Design Guide project.

copy a table. For example you can view rows in a table. © 2007 MicroStrategy. specify a table prefix. Creating the project 81 . For more information on these abilities and how to use them. Warehouse Catalog options 6 Right-clicking any table provides you with additional Warehouse Catalog functionality. and click > to add the selected tables. select the tables you want to add to the Warehouse Catalog. see Managing warehouse and project tables. page 221. if any: 4 From the left side. or specify a database instance for a table. The list on the right shows all the tables currently being used in the project. 5 To remove tables from your project.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. Click << to remove all the tables from your project. Click >> to add all the listed tables. Inc. select them from the right side and click < to remove them.

The Building Blocks of Business Data: Facts and Chapter 6. 8 In the toolbar. 82 Creating facts and attributes © 2007 MicroStrategy. you can change the database instance. click Save and Close to save your changes to the Warehouse Catalog. The Context of Your Business Data: Attributes. For example. 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. This process can take some time to complete. it is important to understand what facts and attributes are and the defining characteristics of each. page 220. see Adding and removing tables for a project.4 Creating and Configuring a Project Project Design Guide 7 To set advanced options you can click Options on the Warehouse Catalog toolbar. page 226. For more information on these abilities and how to use them. Follow the instructions outlined in Creating facts and attributes. This information is covered in Chapter 5. . Inc. customize how tables and columns are read from the database system catalog. The table definitions are written to the metadata. you can still access the Warehouse Catalog to add additional tables. page 82 and Configuring additional schema-level settings. The next step in the Project Creation Wizard involves creating schema objects: facts and attributes. see Modifying data warehouse connection and operation defaults. For steps to access the Warehouse Catalog to add tables to a project. and decide whether schema objects are mapped automatically or manually. page 83 to learn how to create these schema objects and configure additional schema-level settings for those objects. however. display extra table and row information. After exiting the Project Creation Assistant. Before you create facts and attributes.

Project Design Guide Creating and Configuring a Project 4 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. • • • © 2007 MicroStrategy. and configure facts. User hierarchies: The Hierarchy Editor allows you to create user hierarchies. and the Warehouse Partition Mapping Editor. which facilitate access to attribute and element browsing and drilling. The tools used to create aggregate tables and partitions are the Warehouse Catalog. proceed to the chapters referenced above to complete the next steps in the project creation process. Creating Transformations to Define Time-Based and Other Comparisons. This is covered in Adding and modifying attributes. page 134. Attribute definitions: The Attribute Editor allows you to create and edit attributes. This is covered in Chapter 7. and attribute form expressions. edit. which are schema objects used for time-series analysis. These settings include: • Fact definitions: The Fact Editor allows you to create. Configuring additional schema-level settings 83 . attribute forms. aggregate tables. Creating Hierarchies to Organize and Browse Attributes. Transformations are covered in Chapter 9. Inc. page 91. This information is covered in Chapter 8. and partitioning and partition mappings: The Transformation Editor allows you to create transformations. Advanced configurations: These objects include transformations. Now that you have completed most of the key steps in creating a new project. This is covered in Creating and modifying simple and advanced facts. Optimizing and Maintaining Your Project. the Metadata Partition Mapping Editor.

Facts are used to create metrics. Note the following: • MicroStrategy allows you to connect to your SAP BW. see the Creating Freeform SQL reports chapter in the MicroStrategy Advanced Reporting Guide. custom groups. Proceed to the chapters listed above to add analytical depth and more functionality to your project. that if you completed only the steps in this chapter. For information on how to use your own customized SQL statements to create reports. reports. Connecting to OLAP Cube Sources. see the MicroStrategy Web online help. For a complete discussion of metrics. Microsoft Analysis Services. refer to the Deploying your Project with MicroStrategy Web chapter of the MicroStrategy Installation and Configuration Guide. and metrics and attributes are essential components of reports. and other report objects. • 84 Deploying your project and creating reports © 2007 MicroStrategy. however.4 Creating and Configuring a Project Project Design Guide Deploying your project and creating reports After you create a project. filters. you can deploy it to your user community using MicroStrategy Web. Inc. To learn more about how to deploy your project using MicroStrategy Web. and other report objects such as filters. You can also begin creating reports in MicroStrategy Desktop and MicroStrategy Web. . refer to the MicroStrategy Basic Reporting Guide and the MicroStrategy Advanced Reporting Guide. Facts and attributes provide the backbone of the reports and documents created by report designers. for creating reports in MicroStrategy Web. refer to the MicroStrategy Basic Reporting Guide. For information about connecting to OLAP cube sources. and prompts. see Appendix B. For information about creating reports in MicroStrategy Desktop. the project you deploy will contain only basic facts and attributes. are beyond the scope of this guide. and Hyperion Essbase data sources. Metrics. Keep in mind.

As the project designer. 85 . In the MicroStrategy environment. the amount of sales represents the fact. Facts form the basis for metrics. and the store and month represent attributes. facts are schema objects created by and shared between MicroStrategy users. Facts and attributes are necessary to define projects. In this case. Inc.5 5. In a MicroStrategy project. you want to analyze the amount of sales at a certain store during January. THE BUILDING BLOCKS OF BUSINESS DATA: FACTS Introduction Facts are one of the essential elements within the business data model. Facts generally represent the answers to the business questions on which users want to report. © 2007 MicroStrategy. facts are numeric data and attributes are contextual data for the facts. The facts you create in MicroStrategy allow users to access data stored in the data warehouse. which are used in the majority of analyses and reports that users can create with MicroStrategy. They relate numeric data values from the data warehouse to the MicroStrategy reporting environment. For example.

These fact tables are composed of different columns. . Inc. Users can then use these facts and attributes as building blocks for metrics and reports. 86 © 2007 MicroStrategy. This data is used to create a metric (such as profit) which is a business measure.5 The Building Blocks of Business Data: Facts Project Design Guide you must create projects that contain facts and attributes. that column is accessed to retrieve the necessary data. Facts are stored in the data warehouse in fact tables. Each cell in the columns represents a specific piece of information. When fact information is requested for a report in MicroStrategy. as shown below. Facts are based on physical columns within tables in the data warehouse.

Creating and modifying simple and advanced facts.Project Design Guide The Building Blocks of Business Data: Facts 5 Like other schema objects such as attributes. Facts are the actual data values stored at a specific fact level. page 87) of this chapter. facts are logical MicroStrategy objects that correspond to physical columns and tables. page 91 covers steps to add and modify both simple and advanced facts for an existing project. using different techniques and MicroStrategy interfaces: • Simultaneously creating multiple. simple facts as part of the initial project design effort or later in a project’s life cycle. The later sections discuss conceptual information on facts. as well as highlight some advanced fact design techniques and procedures. profit. facts such as Tenure and Compensation Cost could exist in a data warehouse that contains human resources data. For example. 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. facts do not describe data. it can often be necessary to modify and create facts throughout the life cycle of a project. units sold. Creating facts A fact has two common characteristics: it is numeric and it is aggregatable. Creating facts • © 2007 MicroStrategy. Unlike attributes. Facts such as Quantity and Item Cost could exist in a warehouse containing sales and distribution data. page 88 covers steps to create multiple. Inc. simple facts. The procedures to perform these tasks are discussed in the first section (Creating facts. Examples of facts include sales dollars. and cost. While creating facts is a major step in the initial creation of a project. A fact entry level is the lowest set of attributes at which a fact is stored. Data warehouses contain different types of facts depending on the purpose of the data. It is important to understand how to define facts because facts are the basis for almost all metrics. 87 .

Inc. 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. 88 Creating facts © 2007 MicroStrategy. is used to add advanced features to facts that already exist or to create new simple or advanced facts as your project evolves. You can also access the Fact Creation Wizard in MicroStrategy Desktop from the Schema menu. you can create multiple simple facts using the Project Creation Assistant and the Fact Creation Wizard. which is discussed in Creating and modifying simple and advanced facts. It allows you to create multiple facts in a single creation process. page 91. simple facts During your initial project design effort. • The Fact Editor.5 The Building Blocks of Business Data: Facts Project Design Guide Simultaneously creating multiple. 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. However. . The Project Creation Assistant utilizes the Fact Creation Wizard to help you create the facts for your initial project creation effort.

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. Unlike most attributes which can access multiple columns of description information. 3 The Column data type area allows you to select the column data types that are available as possible fact ID columns. If the naming conventions in your warehouse do not conform to the defaults in the Fact Creation Rules page. 89 © 2007 MicroStrategy. Creating facts . Rules help automate and govern the fact creation process. if you select Character and Numeric and leave the remaining check boxes cleared. you may need to change these rules. a fact does not have description information.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 Rules page opens. For example. The Fact Creation Wizard opens. Therefore. as shown below: 2 Click Define Rules to set some basic fact creation rules. you can only select data types for the ID columns of your facts. Select the check boxes for the data types to be included when the wizard searches the data warehouse for available fact columns. Inc.

. – The Fact Creation Wizard cannot handle columns that hold the same information but have different column names (that is. 10 Review the summary information in the Finish page and click Finish to create the facts. page 129. Select the appropriate check boxes to create the desired default fact names. heterogeneous columns). 7 From the Available columns pane. with columns that are not currently being used in the project listed in the Available columns pane. page 102. select them from the Facts pane and click < to move them to the left side. Note the following: – You can rename any fact to make its name more user-friendly by right-clicking the fact and selecting Rename. see Facts with different column names: Heterogeneous column names. For more information about mapping facts to heterogeneous columns. The selected fact definitions are stored in the metadata. Fact column selection 6 Click Next. 9 Click Next. 8 To remove fact columns from your project. Inc. that is. whether to replace underscores in the fact name with spaces and whether the first letter is capitalized. 90 Creating facts © 2007 MicroStrategy. see Simultaneously creating multiple attributes. The Column Selection page opens. 5 Click OK to accept your rule changes and return to the Fact Creation Wizard. Click >> to add all the listed columns. To continue creating a project with the Project Creation Assistant. Click << to remove all the columns in your project. select the fact columns to use for your facts and click > to add them to your project.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. The Finish page opens.

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. To create facts with the Fact Creation Wizard 1 In MicroStrategy Desktop. Inc. However. You can use the Fact Editor to edit existing facts and create fact expressions. you only use the Fact Creation Wizard as part of the initial project creation. log in to the project source that contains your project and expand your project. it limits you to creating simple facts and does not allow you to edit existing facts. © 2007 MicroStrategy. 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. for creating most of the facts for the project. Typically. column aliases. you can use it to create one or more simple facts at the same time. Creating facts 91 .Project Design Guide The Building Blocks of Business Data: Facts 5 Creating and modifying simple and advanced facts After you have created a project. and configure other settings. map multiple or heterogeneous columns. level extensions.

see Permissions and Privileges of the MicroStrategy System Administration Guide. see Permissions and Privileges of the MicroStrategy System Administration Guide. For more information about privileges. 2 From the Folder List in MicroStrategy Desktop. select the project to which to add additional facts. . To use the Fact Creation Wizard to add facts. follow the procedures outlined in To create facts with the Fact Creation Wizard. 3 From the Schema menu. 2 From the Folder List in MicroStrategy Desktop. The Fact Creation Wizard opens.5 The Building Blocks of Business Data: Facts Project Design Guide You must use a login that has Architect privileges. Creating simple and advanced facts with the Fact Editor As your project evolves. select Fact Creation Wizard. you can create additional facts and modify existing facts with the Fact Editor. For more information about privileges. You can also use the Fact Editor to add extensions to those facts and configure additional settings within them to support various analytical requirements. Inc. select the project to which to add additional facts. 92 Creating facts © 2007 MicroStrategy. To create a simple fact with the Fact Editor 1 In MicroStrategy Desktop. You must use a login that has Architect privileges. The following procedure describes how to use the Fact Editor to create a simple fact based on a single fact column in a table. page 89. log in to the project source that contains your project and expand your project.

– These mapping methods are different from the automatic mapping methods for the Warehouse Catalog. select Automatic or Manual. • © 2007 MicroStrategy. Inc. Creating facts 93 . 6 In the Mapping area. – 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. The source table is the table or logical view that contains the fact column on which you want to base a new fact. select the source table for the fact. You then select which of those tables are used as source tables for the fact. 5 From the Available columns pane. with the Create New Fact Expression dialog box displayed on top of it. 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. 4 From the Source table drop-down list. You can then remove any tables mapped automatically or select other tables. The Fact Editor opens. and then Fact. select New. drag and drop a fact column into the Fact expression pane. • 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.Project Design Guide The Building Blocks of Business Data: Facts 5 3 From the File menu. manually select the appropriate source tables for each fact. – If the same column name does not contain the same data across different 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. page 231) determine whether attributes or facts are automatically mapped to new tables when they are added after an attribute or fact is created.

page 105. page 107. Fact extensions are discussed in Modifying the levels at which facts are reported: Level extensions. the MicroStrategy SQL Engine may use the incorrect column for the facts. although the column name is the same in both tables (i. In the Fact_Sales table. suppose you have a column named Sales. in the Fact_Discount table. 8 Use the tabs of the Fact Editor to define fact expressions. For detailed information about the options on each tab within the Fact Editor. . Extensions: This tab allows you to create fact level extensions. If you use the Automatic mapping method in both cases.e. • • 9 When your changes are complete. page 97. you must select the Manual mapping method so you can select the Fact_Discount table as a source table for the Discount fact. However. create column aliases. refer to the MicroStrategy Desktop online help. Sales). you must select the Manual mapping method so you can select the Fact_Sales table as a source table for the Revenue fact. 7 Click OK to close the Create New Fact Expression dialog box. Column aliases are discussed in Fact column names and data types: Column aliases. 94 Creating facts © 2007 MicroStrategy. Column Alias: This tab allows you to create a column alias for the fact. the Sales column contains revenue data. Inc. and create extensions. When creating the Discount fact. which exists in both the Fact_Sales table and the Fact_Discount table. When creating the Revenue fact. Fact definitions are discussed in How facts are defined. as described below. the columns contain different fact data in each table. the Sales column contains discount data. • Definition: This tab allows you to define fact expressions.5 The Building Blocks of Business Data: Facts Project Design Guide For example. In other words. click Save and Close.

open the folder that contains the fact to modify. 11 From the Schema menu.Project Design Guide The Building Blocks of Business Data: Facts 5 10 In the Save As dialog box. Enter a name for the fact and click Save. select Update Schema to update the project schema. Creating facts 95 . 2 Double-click the fact to open the Fact Editor and edit the fact. Inc. navigate to the location in which to save the fact. Modifying simple and advanced facts To modify an existing fact 1 In MicroStrategy Desktop. The fact is saved and the Fact Editor closes. © 2007 MicroStrategy. You can learn how to create more advanced facts in the various sections below.

Extensions can also prevent a fact from being reported at a certain level. Fact definitions are discussed in detail in How facts are defined. Inc. Level extensions are discussed in detail in Modifying the levels at which facts are reported: Level extensions. Every fact must have a column alias. . Fact level extensions allow facts stored in the data warehouse at one level to be reported at an unrelated level. The column alias stores the column name MicroStrategy uses to generate SQL statements when creating temporary tables related to the fact. MicroStrategy selects a default column alias depending on the type of fact. unless you create a new column alias. • • 96 The structure of facts © 2007 MicroStrategy. facts are made up of the following components: • The fact definition is composed of one or more fact expressions. page 97. even though it is stored at that level. page 105.5 The Building Blocks of Business Data: Facts Project Design Guide The structure of facts As shown in the diagram below. Level extensions are very effective for advanced data modeling scenarios. Column aliases are discussed in detail in Fact column names and data types: Column aliases. page 107. Every fact must have at least one expression.

The following table provides an example of a fact definition. How facts are defined A fact definition contains properties that define a fact and its components. and source tables.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. The fact expression contained in the definition represents how the fact is calculated by MicroStrategy. the fact expression is simply the name of the column which holds the fact data. multiple expressions can exist within a fact definition. the fact expression maps the fact to the All_Sales columns in the LU_ITEM and ORDER_DETAIL tables in the warehouse. including the fact name. Facts can be found in multiple tables in a warehouse schema. During project creation with the Fact Creation Wizard. The fact definition is composed of at least one fact expression and basic information about the fact. expression. both the fact definition and column alias are automatically defined. In this case. see Creating facts. While the Unit Price fact only has one expression. © 2007 MicroStrategy. which includes the fact’s name. However. some facts use more advanced expressions to perform calculations on multiple columns of data to return a single fact. Inc. Fact Name Unit Price Expression All_Sales Source Tables LU_ITEM ORDER_DETAIL In the example. and the source tables it uses. expression. page 87. For a discussion of the tools used to created facts and procedures on how to use them. when you select the numeric column used to represent the fact. How facts are defined 97 . and often must be calculated differently from one table to the next. Level extensions are optional.

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. Inc. A fact definition must have one or more fact expressions. The mathematical operators that can be used in a fact expression are: • • • • Addition (+) Subtraction (-) Multiplication (*) Division (/) 98 How facts are defined © 2007 MicroStrategy. fact expressions define how the fact is calculated.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. a fact expression represents a mapping to specific fact information in the warehouse. 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.

where you can sum the column holding the constant to create a COUNT. some facts do not exist at all in the warehouse and are defined in other ways. In other words. if you want to build a metric defined as Sum(1). You may also find it helpful to use implicit facts when building metrics. For example. • Most facts represent physical columns in the data warehouse. These temporary columns allow you to keep track of how many rows are returned for a certain attribute. For example. For detailed information about metrics. These steps are covered in Creating and modifying simple and advanced facts. adding another column’s values. or setting the expression to be an absolute value. However. Implicit facts and implicit fact expressions Implicit facts are virtual or constant facts that do not physically exist in the database. see the MicroStrategy Advanced Reporting Guide. Inc. creates a derived fact. you can use implicit fact expressions to create “temporary columns” in the database with a value of “1” for every row. although nothing is saved in a table column. An implicit fact indicates a fact table from which to retrieve data. as explained in the following sections. you can define a fact equal to the constant “1”. The implicit fact can have its expression defined as a constant value. 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.Project Design Guide The Building Blocks of Business Data: Facts 5 Note the following: • You can use the Fact Editor to create fact expressions. Apply functions are discussed in the Pass-Through Expressions appendix in the MicroStrategy Advanced Reporting Guide. Any operation on a column such as adding a constant. How facts are defined 99 . you are creating a fact © 2007 MicroStrategy. page 91. A fact can also be defined using an ApplySimple function.

For more information on what metrics are and how to create them. 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. see the MicroStrategy Advanced Reporting Guide. Inc. Sales. Example: creating derived facts The Cost fact in the MicroStrategy Tutorial contains the derived fact expression Qty_Sold * Unit_Cost. 100 How facts are defined © 2007 MicroStrategy. you can create such analysis in MicroStrategy with the use of metrics. Using a single fact saves storage space and limits the number of SQL passes used in queries. the columns are used to answer the business question. In this case. a table in your data warehouse contains the following elements: Fact Table 1 Item Quarter Quantity_Sold Price You can create a new fact.5 The Building Blocks of Business Data: Facts Project Design Guide from information that is available in the data warehouse. For a more generalized procedure to create derived facts. 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. Metrics allow you to perform calculations and aggregations on your fact data. “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. refer to the MicroStrategy Desktop online help. For example. . Rather than creating a derived fact.

9 Click Validate to check whether the syntax of the expression is correct. 2 Navigate to the My Personal Objects folder. How facts are defined 101 . 7 From the Available columns list.Project Design Guide The Building Blocks of Business Data: Facts 5 To create a derived fact 1 In MicroStrategy Desktop. click * (multiplication operator) to add it to the expression. point to New. 8 Under Mapping method. The Fact Editor opens. 4 From the Source table drop-down list. double-click the UNIT_PRICE column to add it to end of the fact expression. and then select Fact. 5 From the Available columns pane. select the ORDER_DETAIL table. The derived fact expression appears in the Fact expression pane in the Fact Editor. with the Create New Fact Expression dialog box displayed on top of it. and open the My Objects folder. log in to the MicroStrategy Tutorial project. 6 With the cursor in the Fact expression pane. 3 From the File menu. © 2007 MicroStrategy. The expression should appear as shown below: 10 Click OK. double-click the QTY_SOLD column to add it to the Fact expression pane on the right. select Automatic. Inc.

5 The Building Blocks of Business Data: Facts Project Design Guide 11 From the File menu. both fact columns are used in the SQL. With heterogeneous column names. . When you call for the information in a report through the use of a metric. However. resulting in an accurate representation of the fact in the report. it is not necessary to update the schema. In the example below. Table 2 includes a fact called Dollar_Sls. two fact tables in a warehouse each contain columns for dollar sales. 102 How facts are defined © 2007 MicroStrategy. 12 Enter a name for the derived fact and click Save. The Save menu opens. select Save As. Inc. the same fact can access columns with different column names. at this point. you must update the project schema. Facts with different column names: Heterogeneous column names In your warehouse. In the example above. Table 1 contains a fact called Dollar_Sales. Table 1 Year Dollar_Sales Table 2 Month Dollar_Sls MicroStrategy allows you to identify heterogeneous fact column names for each fact. 13 When you create a fact for your project. you can refer the same fact to multiple columns with different column names and from different tables that identify the same quantitative value. since this is only an example. These two items represent the same information. creating a heterogeneous fact column name for dollar sales informs the system that the Dollar_Sales and Dollar_Sls columns represent the same fact.

Qty_Sold and Tot_Unit_Sales. they represent the same data and are therefore both mapped to the Unit Sold fact. select the ORDER_FACT table. 2 Navigate to the My Personal Objects folder. point to New. The Fact Editor opens. To create heterogeneous fact columns 1 In MicroStrategy Desktop.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. you create the Units Sold fact and map its corresponding heterogeneous fact columns to it. 7 Click OK. refer to the MicroStrategy Desktop online help. double-click the QTY_SOLD column to add it to the Fact expression pane on the right. The Fact Editor opens and the fact expression you just created appears in the Fact expression pane. log in to the MicroStrategy Tutorial project. 5 From the Available columns pane. select Automatic. with the Create New Fact Expression dialog box displayed on top of it. In the procedure. 6 In the Mapping method area. This is one of the tables in which a heterogeneous fact column for the Units Sold fact exists. and open the My Objects folder. 3 From the File menu. How facts are defined 103 . You must map heterogeneous fact columns to their corresponding facts to ensure that accurate and complete data is displayed on reports. © 2007 MicroStrategy. For a more generalized procedure to map heterogeneous fact columns. Inc. The following procedure describes how to create the Units Sold fact that already exists in MicroStrategy Tutorial. 4 From the Source table drop-down list. and then select Fact. Although these fact columns have different names and exist in different fact tables.

The Create New Fact Expression dialog box opens. 14 Enter a name for the new fact and click Save. 15 When you create a fact for your project. 8 Click New. at this point. since this is only an example. Now the Units Sold fact you are creating maps correctly to its heterogeneous fact columns. 9 From the Source table drop-down list. However. select Save As. select Automatic. it is not necessary to update the schema. select the CITY_CTR_SALES table. . Inc. The Fact Editor opens and the fact expression you just created appears in the Fact expression pane. This is the other table in which a heterogeneous fact column for the Units Sold fact exists. 11 In the Mapping method area. 13 From the File menu. 12 Click OK. double-click the TOT_UNIT_SALES column to add it to the Fact expression pane on the right. The Save menu opens. 10 From the Available columns pane. 104 How facts are defined © 2007 MicroStrategy. you must update the project schema.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.

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. [Start_Date_Id]. 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.#0. Fact column names and data types: Column aliases 105 . The SQL you create may be different. For example. This syntax is specific to Microsoft SQL Server. © 2007 MicroStrategy. there are cases where you may need to change this. By default.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. #1)". Inc. [End_Date_Id]) The expression syntax is specific to your database type. However. You could create this fact using the following expression: ApplySimple("DateDiff(day.

This is used when a temporary SQL table needs to be created for the calculation. is an integer. . The Column Editor . The Fact Editor opens. If you did not change the data type of the column alias. log in to the project source that contains the fact to create a new column alias for. You can use the Fact Editor to create column aliases. 1 In MicroStrategy Desktop. To avoid the possibility of an error due to conflicting data types. the difference between the two dates. Data Types. click Modify. For a description of the different data types supported by MicroStrategy. 5 Select New to create a new column alias. 3 Select the Column Alias tab. The Column Editor . 4 In the Column alias area.Column Selection dialog box opens. Data type: The data type for the fact. This can cause an error for some database platforms. you should modify the column alias for the fact to change the default Date data type to an Integer data type.Definition dialog box opens.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. 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. 2 Right-click the fact and select Edit. then the system uses a Date data type and tries to insert integer data into this column. the result of the calculation. • 106 Fact column names and data types: Column aliases © 2007 MicroStrategy. Inc. that is. However. see Appendix D. To create a column alias for a fact This procedure assumes you have already created a fact with a valid fact expression for which to create a new column alias.

Project Design Guide The Building Blocks of Business Data: Facts 5 • Depending on the data type selected. including Item and Quarter. see the MicroStrategy Desktop online help. Every fact is tied to a set of attributes that may or may not © 2007 MicroStrategy. 8 Click OK to save your changes and return to the Fact Editor. you can specify the byte length. bit length. For example. the fact table shown below contains several attribute IDs. 9 Select Save and Close to save your changes. For a detailed description on each of these properties. 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.Column Selection dialog box. or time scale for your column alias. Modifying the levels at which facts are reported: Level extensions Facts are stored at a particular business level in the warehouse. 7 Click OK to save your changes and return to the Column Editor . Inc. scale. These attribute IDs imply that the fact is reported at the item and quarter levels by default. precision. Modifying the levels at which facts are reported: Level extensions 107 . The level of a fact is defined by the attribute IDs present in the table.

Inc. . you have to extend the level of the Discount fact to the Call Center level. However. A fact extension is needed when a fact does not relate directly or indirectly to an attribute included on a report. you record a Discount fact at the Item/Date level. page 118). For example if you have a cost fact at the level of a date attribute in a time hierarchy. 108 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy. 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. To see if some call centers are selling significantly more items at a discount than other call centers. For example. If the entry level of a fact is at the lowest level of a hierarchy. That is.5 The Building Blocks of Business Data: Facts Project Design Guide satisfy all users’ reporting requirements. discounts apply to particular items on particular days. 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. all attributes at a higher logical level in the hierarchy are available for use as well. which is an attribute from a different hierarchy. without the use of level extensions. You can use level extensions to change a fact level and extend a fact level to a level in a completely different hierarchy.

Project Design Guide The Building Blocks of Business Data: Facts 5 Level extensions define how facts can be extended. You can create fact level extensions by using any of the following methods: • • • • • Defining a join on fact tables using table relations. This is because if a fact is stored at a level unrelated to an attribute on a report. page 118 Disallowing the reporting of a fact at a certain level. By creating a level extension. page 116 Lowering the level of fact data: Fact degradations. and they tend to be used only in specific cases. you are allowing facts or attributes that have been captured at one level to be extended to other levels to meet reporting requirements. 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. there is no way to make a connection between the fact data and the attribute. Level extensions are not required like the fact definition and column alias. © 2007 MicroStrategy. lowered. Inc. Otherwise. Modifying the levels at which facts are reported: Level extensions 109 . a level extension must be defined for the fact. Before a metric containing a fact can be used with an attribute that is not in or related to the attribute’s entry level. page 114 Forcing facts to relate to attributes: Using cross product joins. You can use the Fact Editor to create level extensions. a level extension must exist to relate the fact data to the attribute. or disallowed to other attributes across the schema. page 110 Defining a join on fact tables using fact relations.

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. you are creating a table relation to extend a fact. the Freight fact cannot be reported at the Item level. Inc. In this example. This metric has a table relation fact extension to the Item attribute. . 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. Since the ORDER_FACT table that defines Freight does not include the identity column for the Item attribute. The procedure also describes general principles of creating fact extensions which you can use to create fact extensions for the facts in your project. 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. 2 The Freight fact cannot simply be joined with a table containing Item information to return a meaningful freight value for each item. The following procedure steps through how to create the fact extension that has been created for the Freight fact of the Tutorial project. A fact extension is required to view freight values for each item included in an order. and ORDER_DETAIL contains the Item attribute’s identity column to extend the fact to Item. 110 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy.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. the MicroStrategy Tutorial project includes a Freight metric. For example. When you specify a table to join with a fact. These two columns are used to allocate the fact expression in the procedure below.

log in to the MicroStrategy Tutorial project. page 118) Extend the fact entry level: define a fact extension on a table relation. The Level Extension Wizard opens. The General Information page opens. 3 Click the Extensions tab. 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. To create a new fact extension you would click New. To lower. © 2007 MicroStrategy. However. Modifying the levels at which facts are reported: Level extensions 111 . The Extended Attributes page opens. so select Extend the fact entry level. and click Next. Inc. this example steps through how the Freight fact extension Extension to Item was created. 4 Select Extension to Item and click Modify. 5 Read the Welcome statement and click Next. dynamic fact relation. extend. 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 122) • • For this example you are creating a fact extension on a table relation. 2 Browse to the Facts folder and double-click the Freight fact to edit it.Project Design Guide The Building Blocks of Business Data: Facts 5 To define a fact extension with a table relation 1 In Desktop. or disallow the fact entry level 6 Enter a name and a description for your fact extension (already provided). The Fact Editor opens.

The Extension Type page opens. join attributes. 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. To select the table. choose the lowest level attribute in that hierarchy. the ORDER_DETAIL table is already selected. Inc. and define the allocation expression 9 Select the table used to extend the fact to the new level. The Join Type page opens. 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. 112 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy. allowing the fact to be reported at the new level.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. Click Next. For this example Item is already selected. 10 Select whether to allow Intelligence Server to dynamically select what attribute(s) to perform the join. select Order and click Next. page 116) . To extend the fact so that it can be reported at any level in a hierarchy. For this example. • For this example select Specify the relationship table used to extend the fact. page 114). The Table Selection page opens. Click Next. . Select the relationship table dynamically: select a fact and join attributes. 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. The Join Attributes Direction page opens. 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. and click Next to continue defining your fact extension on a table relation.

[LU_ITEM] a13 where a11. When the engine processes a report containing Order. and Freight (metric mapped to the Freight fact) is: select a11.[ORDER_ID] AS ORDER_ID. Item. For this example.[ITEM_ID] AS ITEM_ID.[ITEM_ID] The SQL statement above is for an Access database. The Allocation page opens. In this case Order has no children. The SQL generated for the report containing Order. Notice that the expression returns an average freight amount per item of an order.[ITEM_ID] = a13.[QTY_SOLD])) AS WJXBFS1 from [ORDER_FACT] a11. Promotion level. not an exact calculation. max(a13.[ORDER_DATE]) AS ORDER_DATE. the extension of Freight provides an estimate of the freight for each item of an order. © 2007 MicroStrategy. A more detailed description of why this occurs follows this procedure.[ITEM_NAME]) AS ITEM_NAME. Day. the allocation expression is already provided. [ORDER_DETAIL] a12. ((Freight * [Item-level Units Sold]) / [Order-level Units Sold]). Click Next. 12 Enter an allocation expression that calculates the fact at the new level. 13 Click Finish to create the fact extension.[ITEM_ID] group by a11. Inc. Order.Project Design Guide The Building Blocks of Business Data: Facts 5 11 You can choose to join using the attribute. Employee. a12. Therefore.[FREIGHT] * a12.[QTY_SOLD]) / a11. Take a moment to review the allocation expression. so you do not have to click the Join against arrow to change the default.[ORDER_ID] = a12. Modifying the levels at which facts are reported: Level extensions 113 .[ORDER_ID]. max(a11. a12. and Freight. it joins ORDER_FACT and ORDER_DETAIL and considers the resulting table as one logical fact table at the Item. The SQL for your reports may vary depending on the type of DBMS you use.[ORDER_ID] and a12. Item. sum(((a11. or join using the attribute and its children.

This illustrates how fact extensions often provide an estimation of values at a different level rather than an exact calculation.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. This allows more flexibility in defining the relations. Defining a join on fact tables using fact relations Fact extensions can be defined by a fact relation instead of a table relation. If you want to provide exact values of data at a certain level. With a fact relation. Notice that the Freight metric averages the amount of freight per item in an order. . since the MicroStrategy Engine is responsible for choosing the appropriate table to join. review the values of the first order with an extra metric that calculates the number of each item type in an order shown below. you most likely need to capture such data and store it in your data source. The larger freight values occur because more than one of the item type was included in the order. Inc. rather than you having to select tables manually. 114 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy. the table join is possible on any table that contains the 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.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. © 2007 MicroStrategy. you can create a fact relation using the Order Unit Sales fact. This option is set in the step immediately after To select the type of fact extension. Inc. 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. Modifying the levels at which facts are reported: Level extensions 115 . Open the Order Unit Sales fact and extend it to 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. page 110 after two summary tables are added to it. select the Select the relationship table dynamically option and specify the tables to use for the extension. To extend the entry level of the Freight fact to Customer. depending on the join attributes specified: • • • • Table 1 and Table 2 on Distribution Center. Next.

you are creating a Cartesian product of the lookup attribute. sum(a1. The SQL for your reports may vary depending on the type of DBMS you use.DIST_CENTER.CUSTOMER The SQL statement above is for an Access database.DIST_CENTER group by a1. a2. The SQL generated for a report containing Distribution Center. select a1. The cross product join is an extension that allows a single fact value to relate to all elements of an unrelated attribute.CUSTOMER.5 The Building Blocks of Business Data: Facts Project Design Guide page 112 in the procedure above. This method can produce incorrect data because data can be repeated and counted twice in some cases. As with table relations. 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. Inc.DIST_CENTER = a2.DIST_CENTER. the set of join attributes must contain the entire key of the left-hand-side fact table (Table 3 in the example SQL above). Since this method can be inefficient. and Freight is shown below. if the only join attribute is Distribution Center. as explained above.Freight) from TABLE3 a1. . a2. MicroStrategy does not recommend using the cross product join. The tables and attributes you specify in the wizard determine the different types of joins that are created. Customer. TABLE4 a2 where a1. In a best fit join. When you specify a cross product join to relate a fact to an attribute. Cross products should only be used when no other way to extend the fact exists. 116 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy. you can specify the best fit as the join strategy so that the engine calculates the joins.

and Dollar Sales is: select a1. You can define this cross product join in the Level Extension Wizard in the Fact Editor. TABLE2 a2 group by a1. a cross product join must be used.DIST_CENTER. The SQL generated for a report containing Customer. select the Perform the extension through a cross product option. you do not need to specify an allocation expression. The SQL for your reports may vary depending on the type of DBMS you use. Modifying the levels at which facts are reported: Level extensions 117 . Inc. in the following schema. a2. Next.DOLLAR_SALES) from TABLE1 a1. page 112 of the procedure above. For this example. Distribution Center. Open the Dollar Sales fact and extend it to the Distribution Center attribute. This option is set in the step immediately after To select the type of fact extension.DIST_CENTER The SQL statement above is for an Access database.CUSTOMER. Distribution Center does not relate to Dollar Sales: Table 1 Table 2 Order Customer Dollar Sales Distribution Center To report Dollar Sales by Distribution Center. The MicroStrategy Engine always cross-joins the lookup tables of the attributes in the extension. sum(a2. © 2007 MicroStrategy. Notice that no join attributes are specified.Project Design Guide The Building Blocks of Business Data: Facts 5 For example.

Inc. . which lowers a fact level. For example. and has a fact degradation to the Employee level (the attributes. The fact extension does not use an allocation expression to degrade Planned Compensation to the Employee level. However.5 The Building Blocks of Business Data: Facts Project Design Guide Lowering the level of fact data: Fact degradations Degradation. you must support those users who wish to view and analyze the same fact data at a lower logical level. facts. To view fact data at a lower logical level than the fact is stored at. is the logical opposite of aggregation. However. This causes every employee to be listed with the same planned compensation value as the employee’s department. the Human Resources Analysis Module of the MicroStrategy BIDK includes a Planned Compensation fact that is stored at the Department 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. as shown below: The analytical value of this fact degradation is not immediately recognizable. This scenario may occur because you stored a fact at a level that is used most commonly in reports. and metrics used in this example can all be found in this Analytics Module). you must degrade the fact to a lower level. now that Planned Compensation is available at the Employee level.

For example. The metric definition is ([Compensation Cost]/[Planned Compensation]). the Compensation Cost fact is stored at the Employee level. Modifying the levels at which facts are reported: Level extensions 119 . You can now view what percentage of your planned compensation per department has been spent per employee. Inc. which performs a division of metrics defined from the Compensation Cost and Planned Compensation facts. The procedure also describes general principles of creating fact degradations which you can use to create fact degradations for the facts in your project.Project Design Guide The Building Blocks of Business Data: Facts 5 stored at the Employee level. 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. © 2007 MicroStrategy. as shown below: Without using a degradation of Planned Compensation to Employee. respectively. The Fact Editor opens. 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 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. you could not include Department and Employee on a report with these metrics and return accurate values.

The Level Extension Wizard opens. 8 Select what attribute(s) to perform the join. 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. Click Next. The Extended Attributes page opens. Click Next. Inc. . 120 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy. the Department attribute is already selected. For this example. To create a new fact degradation you would click New. However. To extend the fact so that it can be reported at any level in a hierarchy. The Join Attributes Direction page opens. choose the lowest level attribute in that hierarchy. allowing the fact to be reported at the new level. 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. 5 Read the Welcome statement and click Next. 7 Select the attributes you want to degrade the fact to. For this example Employee is already selected. and click Next. dynamic fact relation.5 The Building Blocks of Business Data: Facts Project Design Guide 3 Click the Extensions tab. 4 Select Degradation to Employee and click Modify. page 122) • For this example you are creating a fact degradation so select Lower the fact entry level. or a cross product join (see Defining a join on fact tables using table relations. The Join Type page opens. this example steps through how the Planned Compensation fact degradation Degradation to Employee was created. 6 Enter a name and a description for your fact extension (already provided). The General Information page opens.

Fact degradations often produce data estimates rather than exact values for the fact data at lower logical levels. Ordinarily. the join is performed on the Department attribute and its children.Project Design Guide The Building Blocks of Business Data: Facts 5 9 You can choose to join using the attribute. you do not need to include an allocation expression. you must add an allocation expression. Fact degradations with allocation expressions Not all fact degradations can simply be lowered to a new level. Click Next. By creating allocation expressions. 11 Click Finish to create the fact degradation. For this example. if your fact is stored at the yearly level and you want to report the data at the monthly level. page 121 for an example of using an allocation expression for a fact degradation. you can create a degradation on the fact to relate it to the monthly level. For example. Allocation expressions are defined by operations you set on attributes and facts in the Level Extension Wizard in the Fact Editor. consider the allocation expression fact/12 for a degradation from Year to Month. This is similar in concept to choosing an aggregation function (Sum. See Fact degradations with allocation expressions. or join using the attribute and its children. Modifying the levels at which facts are reported: Level extensions . You select Month to be the attribute to which to degrade. The Allocation page opens. For this example. you define how higher-level facts are degraded to lower-level attributes. Avg. which allows the distribution of values according to a calculation you specify. For example. Using such an allocation expression would spread a year’s fact data evenly over the 12 months of that year. this is often an unlikely scenario. and so on) when aggregating data to higher levels. 10 Enter an allocation expression that calculates the fact at the new level. Inc. You then specify that the allocation expression is fact/12. to change the definition of the fact in a level extension. Such fact degradations should be used 121 © 2007 MicroStrategy. While it is possible that the fact data would be the same for every month of the year.

When you create a report containing the Month attribute and the Sales metric. If a fact is stored at a level that is counterproductive to a query. if you have three years’ worth of data. the report fails because the disallow setting now prevents the cross-joins between the lookup tables and fact tables. or disallow the fact entry level. page 111 of the procedure to create a fact extension above. does not affect normal joins. 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. Consider a schema containing three dimensions: Geography. such as data that is stored at the Minute or Second level. and Product. if you create a report and attempt to include the fact at the Minute or Second level. To explicitly disallow an extension of the Sales fact to the Time dimension. The following examples describe instances in which disallowing a fact entry level can prove useful. querying at the Minute or Second level consumes too many resources and returns extensive data. an error is returned. you can disallow the lower levels. however. The setting prevents unnecessary joins to lookup tables. This option is set in the step immediately after To lower. Time. extend. For example.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. . 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. 122 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy. Inc. After updating the schema and re-executing the report. indicating that the report cannot be run at that level. 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. the Analytical Engine does a dynamic cross-join and evaluates the report. 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. This setting. With a disallow in place.

For example. You now disallow an extension on the Revenue fact for the Item attribute and update the schema. In this case. This implies that the fact extension has not been disallowed. If you execute the report containing the Year attribute and Sales metric. you create a report that contains the attributes Subcategory and Item and the Revenue metric. the report runs successfully. assume you specify an extension to the Month attribute and also disallow extension to Year which is a parent of the extended attribute. Modifying the levels at which facts are reported: Level extensions 123 . This is not an expected design condition. So you encounter only normal joins and no extensions. The Disallow the fact entry level setting applies only to attributes that can be considered as extended attributes. disallowing the Revenue fact at the level it is stored at in the data warehouse does not make logical sense. Month. In this case. you can still see Revenue by Item. © 2007 MicroStrategy. Inc. although the engine returns a valid SQL. It is advisable to avoid fact definitions that contain contradictory extension definitions. There must be a valid reason to disallow reporting a fact at a certain level. the engine sorts the extension conditions specified in some order and calculates the report based on the sorted order of extensions. which is defined as sum of the Revenue fact. If you re-execute the report.Project Design Guide The Building Blocks of Business Data: Facts 5 In the previous example. This is because Revenue exists at the same level as Item in the MicroStrategy Tutorial project. for the Sales fact.

Inc. .5 The Building Blocks of Business Data: Facts Project Design Guide 124 Modifying the levels at which facts are reported: Level extensions © 2007 MicroStrategy.

you have a report with the Month. When executed. month. Because of the attributes on the report. © 2007 MicroStrategy. While knowing your company’s total sales is useful. If you remove the attributes from the report. Year. and Region attributes on the template. the report displays your company’s revenue at the region. and year levels. a substantial amount of information is available. Inc. which take the form of attributes in MicroStrategy. knowing where and when the sales took place provides the kind of analytical depth users require on a daily basis. 125 .6 6. including which regions produced the least revenue and which years saw the highest growth in revenue. For example. 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. Attributes provide the business model with a context in which to report on and analyze facts. as well as a Revenue metric based on the Revenue fact. you can only find out how much revenue the company generated in total.

Inc. Date 126 © 2007 MicroStrategy. using this report definition. consider the following: Select Store_ID. Intelligence Server. attributes are identified by the column headers of the reports. A report designer creates a report in part by determining these report column headers. instructs the engine how to build the SQL for that report. . Date. New user and application requirements make attribute creation and modification an important part of the entire project life cycle. For example. In MicroStrategy reports. attributes are normally identified by a unique ID column in a lookup table.6 The Context of Your Business Data: Attributes Project Design Guide Creating attributes is an important step in the initial project design effort. The expressions of attributes and facts in the report define the SELECT clause of the SQL command. sum(Sales) From Store_Fact Group By Store_ID. In the data warehouse. which comes after creating facts when using the Project Creation Assistant.

page 143. Because of this process. • • © 2007 MicroStrategy. See Attribute form expressions. Attribute expression: maps a MicroStrategy attribute form to one or more columns in the warehouse. Customer First Name. it is just not aggregated. A discussion about metrics. For example. A high-level report. Attributes can have multiple attribute forms. report analyzers do not have to know SQL to extract information from a data warehouse. filters. 127 . Customer Email. page 147. for the Customer attribute. Attribute relationship: allows interaction of data at different conceptual levels and shows how data is related within a project. such as a report at the Year level. Inc. includes the Year attribute but lacks the detail of a similar report which includes the lower level attributes Month and Week. such as Day. and reports is beyond the scope of this guide and is covered in the MicroStrategy Advanced Reporting Guide. is the lowest level of detail reported. and Customer Last Name are examples of attribute forms. 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.Project Design Guide The Context of Your Business Data: Attributes 6 In the SQL above. Attributes are defined by these properties: • Attribute form: contains an identifier or descriptor of an attribute. sales information will be retrieved by store and date. See Column data descriptions and identifiers: Attribute forms. It is important to understand the data is still the same. page 159. The lowest level attribute you include in a report. See Attribute relationships.

. it is often necessary to modify and create attributes throughout the life cycle of a project. Inc. The later sections discuss conceptual information on attributes. as well as highlight some advanced attribute design techniques and procedures. 128 © 2007 MicroStrategy.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. page 129) of this chapter. The procedures to perform these tasks are discussed in the first section (Creating attributes.

For steps to access the Project Creation Wizard. Inc. page 134—steps to add and modify attributes for an existing project. This section provides steps to create attributes at different phases of the project design process. © 2007 MicroStrategy. you can create multiple attributes using the Attribute Creation Wizard. 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. Creating attributes 129 . see To create a new project using the Project Creation Assistant. To create attributes using the Attribute Creation Wizard This procedure is part of an initial project creation effort using the Project Creation Assistant. creating attributes is a major step in any project design effort.Project Design Guide The Context of Your Business Data: Attributes 6 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. Adding and modifying attributes. using different techniques and MicroStrategy interfaces: • Simultaneously creating multiple attributes. therefore. which launches the Attribute Creation Wizard to complete the attribute creation tasks. page 129—steps to create multiple attributes as part of the initial project design effort or later in a project’s life cycle.

6 The Context of Your Business Data: Attributes Project Design Guide page 78. click Create attributes. 1 In the Project Creation Assistant. 2 Review the introduction page that is displayed. 3 Click Define Rules to set some basic attribute creation rules. Define attribute creation rules These rules can make the process of choosing attribute columns and naming your attributes considerably easier. The Attribute Creation Rules page opens. The Attribute Creation Wizard uses these rules below to help automate the attribute creation process. You can also access the Attribute Creation Wizard at any time in the development of a project from the Schema menu in MicroStrategy Desktop. 4 The Column data type area allows you to select the column data types to be available as possible attribute ID columns. The Attribute Creation Wizard opens. Inc. . as shown below. Select the check boxes for the data types that should be included when the wizard searches the data warehouse for available attribute ID columns. Change these rules if the naming or data type conventions in your warehouse do not conform to these defaults. 130 Creating attributes © 2007 MicroStrategy. especially if you use consistent naming conventions and data types in your data warehouse.

The defaults are ID for identifier columns. and LOOKUP for lookup tables. DESC for description columns. ID column selection An ID column is a column or group of columns that uniquely identifies each element of an attribute. You should never use a column that has NULL or repeated values as the ID column for an attribute. Inc. 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. make sure that all values in the column are unique and that it does not contain NULL values. Only those columns with data types that match those chosen in the rules you defined above appear on the ID Selection page.Project Design Guide The Context of Your Business Data: Attributes 6 5 The Attribute name area allows you to determine how to create default attribute names. The columns that match the identifier naming convention that you set in the warehouse search rule above are automatically highlighted. The ID Column Selection page opens. Creating attributes 131 . Doing so results in unexpected behavior and errors. 7 Click OK to accept your rule changes and return to the Attribute Creation Wizard. © 2007 MicroStrategy. 8 Click Next. When choosing the ID column for an attribute.

select the attribute IDs in the Attributes pane and click < to move them to the Available columns pane.6 The Context of Your Business Data: Attributes Project Design Guide 9 From the Available columns pane. Create compound attributes A compound attribute is defined as an attribute with more than one column specified as the ID column. Type a name for the attribute. Note the following: – You can rename any attribute name to make it more user-friendly by right-clicking the attribute and selecting Rename. 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. Click >> to add all the listed columns. . Description column selection Description columns provide the data which gives context and meaning to your attributes. heterogeneous columns). You are returned to the Attribute Creation Wizard. – To remove attribute ID columns from your project. page 183). For more information about mapping attributes to heterogeneous columns. Inc. page 153. 10 To create a compound attribute. Select the columns that are required to uniquely identify the compound attribute and click OK. 132 Creating attributes © 2007 MicroStrategy. see Joining dissimilar column names: Heterogeneous mappings. The New Compound Attribute dialog box opens. complete the following steps: • • • Click Compound Attributes and then click Add. – The Attribute Creation Wizard cannot handle columns that hold the same information but have different column names (that is. select the columns to use for your attribute IDs and click > to add them to your project.

for more information about attribute forms. The Lookup Table Selection page opens. Specify the lookup table and description column for the compound attributes and click Next. 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.Project Design Guide The Context of Your Business Data: Attributes 6 11 After adding all your attribute ID columns. however. such as Year. In some cases. The column that meets the description naming convention that you set in the warehouse search rule is automatically selected. The Relationship Definition page opens. 13 Click Next when you are finished selecting description columns for attributes. If you have not created a compound attribute. the Compound Attribute Definition page opens. Creating attributes 133 . 12 Select whether to use the ID or a different column for the description of the attribute. 15 Click Next: • If you have created compound attributes. the Relationship Definition page opens. page 136. Inc. click Next. • © 2007 MicroStrategy. The Description Column Selection page opens. – Other attribute forms need to be created through the Attribute Editor after you complete steps in the Project Creation Assistant. you should use the default description column for each attribute. they provide the information for an attribute through data stored in their ID and description columns. In general. Lookup table selection Lookup tables are the physical representation of attributes. Note the following: – In general. it may make sense to use the ID column as the description column. you should choose the default lookup table for each attribute. Refer to Adding attributes with the Attribute Editor.

click Next. The Select Children Attributes dialog box opens. Related attributes such as City. The Finish page opens. select the relationship type for the attribute to its child attribute. when attributes are in the same hierarchy they must be related to each other. After you have completed the steps of the Attribute Creation Wizard. When you design a logical data model for your project (see Chapter 2. you specify the children and the type of relationship: one-to-one. whereas attributes in different hierarchies cannot be related. you can also create and add attributes as they become necessary. 16 For each attribute.6 The Context of Your Business Data: Attributes Project Design Guide Relationship definition For each attribute. Inc. Adding and modifying attributes Just as you can add more facts to your project once you have created it. • 17 When you have defined children for all the attributes that need them. so does its 134 Creating attributes © 2007 MicroStrategy. As a company evolves. one-to-many. the attributes are created. The Logical Data Model). like Location. For more information on the different attribute relationship types. select an attribute and click Add. see Attribute relationships. the relationships between attributes should become apparent. In a logical data model. You are returned to the Attribute Creation Wizard. In the Children of: attribute name pane. State. This completes the initial creation of a project with the Project Creation Assistant. or many-to-many. . page 159. or Region are often grouped in a common hierarchy. Select the child attributes from the list of available child attributes and click OK. define child attributes: • • In the Attributes pane. 18 Review the summary information in the Finish page and click Finish to create the attributes.

these requirements can lead to changes to the data warehouse as well as to the schema within its MicroStrategy projects. and attribute form expressions. a health care company. configure additional settings. map heterogeneous column names. Creating attributes 135 . it must add lookup tables that contain data about its new offices to its warehouse.Project Design Guide The Context of Your Business Data: Attributes 6 reporting requirements. decides to extend its operations into Europe and Asia. which you use to create the first attributes for your project. You can use the Attribute Editor to edit existing attributes and create additional attribute forms. attribute forms. • 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. and create the appropriate attributes so report users can analyze business data for their appropriate country. or the Attribute Editor. and so on. In general. You can create attributes with either the Attribute Creation Wizard. It must then add these tables to its MicroStrategy project. define advanced expressions. which allows you to define attributes. For example. when the company opens its offices in Europe and Asia. © 2007 MicroStrategy. Inc. However. Before the shift overseas. for creating most of the attributes for the project. with offices only in the United States. the company does not include lookup tables with information about different countries in its data warehouse. you only use the Attribute Creation Wizard as part of the initial project creation.

Adding attributes with the Attribute Editor The Attribute Editor is used to add advanced features such as attribute forms to attributes that already exist. choose Attribute Creation Wizard. follow the steps outlined in Simultaneously creating multiple attributes. Inc. To create simple attributes in bulk using the Attribute Creation Wizard 1 In MicroStrategy Desktop. 3 From the Schema menu. you may still find it useful if you need to create multiple attributes from remaining lookup columns in your warehouse. log in to the project source that contains your project and expand your project. 2 From the Folder List. The Attribute Creation Wizard opens. Follow the steps below to use the Attribute Creation Wizard to create simple attributes in bulk. 136 Creating attributes © 2007 MicroStrategy. You can also use it to add new attributes to your project.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. See the Permissions and Privileges appendix of the MicroStrategy System Administration Guide for more information. page 129. . select the project to which to add new attributes. You must use a login that has Architect privileges. 4 To create attributes with the Attribute Creation Wizard.

functions. The Attribute Editor opens. 2 From the File menu. log in to the project source that contains your project and expand your project. © 2007 MicroStrategy. 3 From the Source table drop-down list. Click f(x) in the Form expression toolbar to create a function using the Insert Function Wizard. page 147). select a table which contains the columns of data for the attribute. you are only required to select an available column and move it to the Form expression pane. Creating attributes 137 . 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 attribute form expression as possible source tables for the attribute form. 4 To create a simple attribute form expression (Attribute form expressions. Its columns are listed in the Available Columns pane. 6 Under Mapping Method. You do not have to include any operators.Project Design Guide The Context of Your Business Data: Attributes 6 To create an attribute using the Attribute Editor 1 In MicroStrategy Desktop. use a combination of any of the following techniques: • • • Enter constants in double quotes. drag a column name from the Available columns pane to the Form expression pane. or parentheses. and then Attribute. To create a more advanced attribute form expression. Click any operator in the Form expression toolbar to insert it into the expression. Inc. with the Create New Form Expression dialog box displayed on top of it. When you create an expression for an attribute form. select New. 5 Click Validate to make sure your expression is valid. or select other tables. You can then clear any tables mapped automatically.

7 Click OK. 9 In the Form general information area. – A constant expression cannot use the automatic mapping method. A lookup table holds the information for an attribute. The Warehouse Catalog mapping methods (discussed in Mapping schema objects and calculating logical sizes for tables. type a name and description in the associated fields for the attribute form. 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 default is Manual. Using automatic mapping in the Attribute Editor helps you decide which tables to map your attribute to when creating an attribute.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. 138 Creating attributes © 2007 MicroStrategy. If you chose manual mapping. from which you can create attribute forms for the attribute (Column data descriptions and identifiers: Attribute forms. select the check boxes of the tables to map to the attribute form. – These mapping methods are NOT the same as the automatic mapping methods for the Warehouse Catalog. page 143). The Create New Attribute Form dialog box opens. For subsequent attributes. The system maps the expression to each of the source tables. . 8 From the Source tables pane. page 231) determine whether attributes or facts are automatically mapped to new tables when they are added after an attribute or fact is created. Inc. select a table and click Set as Lookup to set the lookup table for the attribute.

For a description of form categories. Click Save. select Save As. • Modifying attributes After creating an attribute. you can modify the attribute at any time using the Attribute Editor. Enter a name for the derived fact. 14 Navigate to the folder in which to save the attribute.Project Design Guide The Context of Your Business Data: Attributes 6 10 In the Category used drop-down list. Therefore. For more information on custom groups. if you select a column with a non-numeric data type and set it as an ID column. refer to the MicroStrategy Advanced Reporting Guide. 12 Click OK. © 2007 MicroStrategy. see Attribute form properties. select Update Schema to update the project schema. Inc. 11 In the Form format area. Creating attributes 139 . do one of the following: • Select a form category from the drop-down list. Click Modify to create a new form category. This ensures that your project is updated to recognize the new attribute definition. You cannot use the Attribute Creation Wizard to modify attributes. Custom groups are sorted by the Default sort of the form that appears first in the Report display forms. select a display type and a default sorting option from the associated drop-down lists. 13 From the File menu. page 146. The Attribute Editor opens. a warning message appears by default when you click OK in the Create New Attribute Form dialog box. Using a column with a non-numeric data type as an ID column of an attribute can result in SQL generation issues. The Save dialog box opens. 15 From the Schema menu.

You can then modify all the options available when creating and attribute in the Attribute Editor.6 The Context of Your Business Data: Attributes Project Design Guide To modify an existing attribute 1 In MicroStrategy Desktop. Baltimore BA. For example. and Boston BN are elements of the attribute City: 140 Unique sets of attribute information: Attribute elements © 2007 MicroStrategy. Inc. 2 Double-click the attribute to edit. which is described in the previous procedure To create an attribute using the Attribute Editor. Unique sets of attribute information: Attribute elements Attribute elements are the unique sets of information or values of an attribute. Customer is the attribute and New York NY. in the following diagram. . open the folder that contains the attribute to modify. page 137. You can learn how to create more advanced attributes in the various sections below. The Attribute Editor opens.

With the Customer attribute.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. page 143). which should be forms that provide a general description of the attribute element. As shown above. as shown below: The Customer attribute is a good example to understand the components of an attribute and the concept of an attribute element. each attribute element is an individual customer. and so on which are defined by the attribute forms (see Column data descriptions and identifiers: Attribute forms. For example. Each customer (attribute element) has its own set of information such as last name. first name. Each attribute element is a row in an attribute lookup table in your data warehouse. in the image above. the First Name and Last Name forms are used to identify the 141 © 2007 MicroStrategy. an attribute element is a unique set of information defined by the attribute forms of an attribute. Unique sets of attribute information: Attribute elements . Inc. Attribute elements are identified by their browse forms. email address.

6 The Context of Your Business Data: Attributes Project Design Guide attribute elements. the report below (created from the Sales 142 Unique sets of attribute information: Attribute elements © 2007 MicroStrategy. such as Men’s Clothing. For example. Shoes. . see Using attributes to browse and report on data. For more information on selecting the attribute forms used to identify attribute elements. Attribute elements can be identified in logical data models. Just as you would not refer to a customer by his or her street address. page 189. and Sporting Goods: In MicroStrategy reports. the attribute Division has multiple attribute elements. Inc. attribute elements are displayed depending on the location of the attribute they are associated with. you would not want to use the Address form to identify the Customer attribute elements. As shown below.

The display of attributes and their attribute elements is also affected by the location of the metrics on the report. Inc. Sales Organization is on the rows of the report along with its attribute elements such as USA Central.Project Design Guide The Context of Your Business Data: Attributes 6 and Distribute Analysis Module of the MicroStrategy BIDK) has two attributes. Column data descriptions and identifiers: Attribute forms Attribute forms are identifiers or descriptors of an attribute. 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. and most have at least two: © 2007 MicroStrategy. page 33. Column data descriptions and identifiers: Attribute forms 143 . Every attribute must have at least one form. Year is on the columns of the report along with its attribute elements such as 2005. as explained in Logical data modeling conventions. Sales Organization and Year.

These types of forms give context and information about the Customer attribute. including the Customer Name and the Address forms. Email is included as an additional descriptive form. each customer must have a different value for their identity column. To differentiate between two customers such as John Smith and Fred Black. which is a column of unique numeric values to identify each customer. ID forms serve to uniquely identify each attribute element from other elements for the same attribute. The Customer attribute in the MicroStrategy Tutorial has various forms. Attributes also have description forms. For the Customer attribute. For example. 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. . Some attributes can have additional descriptive forms that do not serve as the primary description form.6 The Context of Your Business Data: Attributes Project Design Guide • • The ID form (required) A description form Every attribute must have an ID form (identity form). the Customer attribute’s ID form is Customer_ID. Inc. as shown in the following diagram: 144 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy.

one with the forms Customer_ID. The second lookup table contains Customer _ID and Email. Name. The attribute will have the Customer_ID. the ID forms are used to join tables. Inc. which uniquely identifies the attribute. and SSN. The forms you create must have a reference to a lookup table and can include multiple expressions. you can choose a lookup table in the Attribute Editor from a list of tables existing in the project. Column data descriptions and identifiers: Attribute forms 145 . two columns with different names can represent the same information about an attribute. SSN. © 2007 MicroStrategy. a lookup table with three columns holds the following separate forms. and Email forms and the tables will join together through the ID columns because that is the column they have in common. Heterogeneous column names are discussed in Joining dissimilar column names: Heterogeneous mappings. the LU_CUSTOMER table records all of the attribute form data for the Customer attribute. described below: • • • Customer_ID: a unique. Attributes must contain at least one ID form. Name. When creating an attribute form. 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. you must map the appropriate columns to the same attribute to retrieve accurate and complete results when using an attribute on a report. For example. In the warehouse. Each table must have an ID form.Project Design Guide The Context of Your Business Data: Attributes 6 In the data warehouse. page 153. In such cases. two tables exist.

specifying a format type of Big Decimal allows users to preserve precision when qualifying on a form with more than 15 digits. While there is no difference in how a Desc attribute form and None attribute form are used in MicroStrategy. Big Decimal is discussed in detail in Appendix D. For example. 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.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. You can create new form categories in the Attribute Editor. If you define multiple attribute forms of an attribute with ascending or descending sort orders. These properties affect the display of the forms and include the following: • Categories help group the types of forms. Inc. you can define the default sort order for each attribute form. Each attribute can have only one Desc form. When you have attributes that require multiple description forms. You can choose from Ascending. Data Types. Default sort governs how the form is sorted by default when included in a report. . see Default sorting of multiple attribute forms. Descending. For information on how attribute forms are sorted when multiple attribute forms of a single attribute define a default sort order. • Default sorting of multiple attribute forms When creating attribute forms. it is a good practice to map the most commonly used or most important description form to the Desc form of the attribute. • Format types control how the form is displayed and how filters are built. or None. There is no way to distinguish a Desc attribute form from a None attribute form on a MicroStrategy report. Desc. the first attribute form with a default sort order is 146 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy. below. the other description forms must be mapped to None forms. The standard category options are ID. and None.

Attribute form expressions Attributes act like holders of information and provide context for fact data. Inc.Project Design Guide The Context of Your Business Data: Attributes 6 used to sort the attribute on the report. customers are sorted by their address in descending order. and other report objects are sorted. It is important to note that you can change how attribute forms are sorted from within a report. refer to the MicroStrategy Advanced Reporting Guide. the Customer attribute in the MicroStrategy Tutorial project has the five attribute forms shown below: Of these five attribute forms. An attribute form expression defines what columns in the warehouse are used to represent the attribute form in SQL. If you include Customer on a report with both Last Name and Address. Each attribute form must have at least one expression. Column data descriptions and identifiers: Attribute forms . 147 © 2007 MicroStrategy. then the second attribute form with a default sort order is used for sorting. These information units are called attribute forms. Modify the Address form so that it has a descending default sort order. In a report you can use advanced sorting to define how attribute forms. only Last Name has a default sort order set. If you remove the Last Name form from the report. Sorting defined for a report takes precedence over default sorting defined for attribute forms. metrics. and so on. customers are sorted by their Last Name in ascending order. For more information on advanced sorting. This is because Last Name was created first and therefore is considered for sorting before the Address form. the Customer attribute holds information about the customer such as Name and Address. For example. If the first attribute form with a default sort order is not included on a report. For example. This is the default functionality for how attributes are sorted by their attribute forms on reports.

Derived expressions. for example. the CUST_FIRST_NAME and CUST_LAST_NAME columns in the warehouse provide information about first and last names respectively. page 150: Derived form expressions perform some type of mathematical calculation on columns in the data warehouse to create an attribute form. The definition of the simple expression includes the tables in which the column is found. constants. a form cannot have two different expressions in the same source table. . The types of attribute form expressions are: • • Simple expressions. The form expression for the Customer Last Name attribute form is CUST_LAST_NAME. 148 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy. You can create expressions using attribute columns. since they only use the constants you declare. • • Simple expressions A simple expression is based on a single warehouse column. You can also create a form expression using Apply functions. Although you can have multiple expressions in different tables. Inc. page 153: Heterogeneous mappings allow you to use columns with different names in the data warehouse as the same attribute form. *. Only implicit attributes do not include a column in the expression. the form expression for the Customer First Name attribute form is CUST_FIRST_NAME. In this instance. Implicit expressions. /. These form expressions create virtual data by combining or using columns to generate the data. These functions are discussed in the Pass-through Expressions appendix in the MicroStrategy Advanced Reporting Guide. page 148: Simple form expressions access data through columns in the data warehouse. Joining dissimilar column names: Heterogeneous mappings. page 155: Implicit form expressions do not relate directly to data stored in the data warehouse. -. and/or mathematical operators.6 The Context of Your Business Data: Attributes Project Design Guide For example. +.

At this point. The expression for the ID form is the CATEGORY_ID column and the expression for the description form is the CATEGORY_DESC column. Once gathered. log in to the project source that contains the MicroStrategy Tutorial project and then log in to MicroStrategy Tutorial. including their dates of birth. © 2007 MicroStrategy. This will enable report designers to display each customer’s date of birth alongside each customer’s name on reports. The retailer’s customers provide a variety of information on the surveys. 2 Navigate to the Schema Objects folder. It has two forms. Inc. 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.Project Design Guide The Context of Your Business Data: Attributes 6 For example. 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 Attribute Editor opens. Follow the procedure below to create Customer Birth Date as an attribute form in the Customer attribute. both of which are defined by simple expressions. Category is an attribute in the MicroStrategy Tutorial. and then the Customers folder. Column data descriptions and identifiers: Attribute forms 149 . Both of these columns reside in the table LU_CATEGORY. To create an attribute form with a simple expression 1 In MicroStrategy Desktop. ID and Description. The retailer intends to analyze the data gathered from the surveys to better market their products in the future. open the Attributes folder. 3 Double-click the Customer attribute. the project designer must add the column containing the customer dates of birth as an additional attribute form of the Customer attribute.

mathematical operators. While simple expressions have their value determined by just one column in a warehouse table. 7 Click OK. you can create a derived attribute to calculate age or anniversaries. For example. 5 From the Source table drop-down list. Inc. type Customer Birth Date. The Create New Attribute Form dialog box opens. The new Customer Birth Date attribute form is added to the Attribute form pane in the Attribute Editor. 10 Click OK. you can create an attribute to hold the age of a customer or an employee that has been derived from the two columns. 6 Double-click the CUST_BIRTHDATE column to add it to the Form expression pane on the right. select the LU_CUSTOMER table. functions. The mapping method is selected as Automatic by default. By creating an attribute to calculate age in this manner. 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. in the Name field. By calculating the difference between the columns Date of Birth and Current Date. 11 Because this is only an example. The Create New Attribute Form dialog box opens. adding another column. This is the table that contains customers’ dates of birth. 8 In the Form general information area. or setting the expression to be an absolute value) creates a derived expression. the attribute’s value 150 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy. close the Attribute Editor without saving your changes. Derived expressions Derived expressions are created using a combination of warehouse columns. . select DATE since Customer Birth Date is neither the ID form of Customer nor the primary description form.6 The Context of Your Business Data: Attributes Project Design Guide 4 Click New. and constants. 9 From the Category used drop-down list.

log in to the project source that contains the MicroStrategy Tutorial project and then log in to MicroStrategy Tutorial. the SQL query and resulting report can fail. As another example. and then the Customers folder. CUST_FIRST_NAME and CUST_LAST_NAME. the syntax of the derived expression for Name reads: CUST_FIRST_NAME + “ “ + CUST_LAST_NAME On a report. If you created an attribute for age in which you included a constant number. you could create a derived expression for Name in the format of Last Name. open the Attributes folder. you want reports to display a customer’s first name and last name together as a single entry on a report. this information is displayed as Mary Jones under the Name column. Column data descriptions and identifiers: Attribute forms 151 . but you must make sure you use expressions that meet the requirements of your database-specific SQL syntax. the information is displayed as Jones. © 2007 MicroStrategy. Example: creating an attribute form with a derived expression In your database. Calculations and functions used in a derived expression can assist in deriving data from the database. the attribute would need to be updated every time a customer or an employee has a birthday. However. you store Customer names in two different columns. which consists of the two strings.Project Design Guide The Context of Your Business Data: Attributes 6 is automatically updated as the age changes. If you use syntax that is not supported by your database or other data source. Mary under the Name column. To create an attribute form with a derived expression 1 In MicroStrategy Desktop. Using the Customer attribute. You can achieve this using a derived form expression Name. 2 Navigate to the Schema Objects folder. First Name using the following syntax: CUST_LAST_NAME + “. Inc. “ + CUST_FIRST_NAME Using this expression.

10 Click OK. in the Name field. type Last Name. select the LU_CUSTOMER table. First Name is neither the ID form of Customer nor the primary description form.6 The Context of Your Business Data: Attributes Project Design Guide 3 Double-click the Customer attribute. The Create New Attribute Form dialog box opens. This is the table that contains customers’ first and last names. 13 Click OK. 5 From the Source table drop-down list. 6 Double-click the CUST_LAST_NAME column to add it to the Form expression pane on the right. select None since Last Name. “ +. 9 Select Automatic as the mapping method. The new attribute form is added to the Attribute form pane in the Attribute Editor. Your expression should be defined as shown below. Inc. . 7 In the Form expression pane. First Name. 12 From the Category used drop-down list. 11 In the Form general information area. The Attribute Editor opens. The Create New Attribute Form dialog box opens. 152 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy. place the cursor to the right of [CUST_LAST_NAME] and type + “. close the Attribute Editor without saving your changes. 14 Because this is only an example. 8 Double-click the CUST_FIRST_NAME column to add it to the Form expression pane on the right. 4 Click New.

Because different source systems may store information in various contexts. For example. depending on your database platform. 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. Of all the tables in which the columns exist. Each expression is linked to a set of source tables that contain the columns used in the expression. Inc. you might be able to join columns with data types of Number and Integer. The Day_Date column occurs in the LU_DATE table and the Order_Date column occurs in the ORDER_DETAIL and ORDER_FACT tables. most databases cannot join a data type of Text to a data type of Number. Column data descriptions and identifiers: Attribute forms 153 . your company may have multiple columns in different tables that all represent the same business concept. in the MicroStrategy Tutorial. you can select as many or as few as you want to be used as part of the attribute’s definition. For example. © 2007 MicroStrategy. heterogeneous mapping automatically occurs when tables and column names require it. However. the ID form of the attribute Day contains two expressions. you can view the chosen tables in the source Tables area to the right of the Form Expressions area. 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. In the Attribute Editor. If you define more than one expression for a given form.Project Design Guide The Context of Your Business Data: Attributes 6 Joining dissimilar column names: Heterogeneous mappings Heterogeneous mapping allows Intelligence Server to perform joins on dissimilar column names. The data types of columns used in a heterogeneous mapping for a given attribute must be identical or similar enough for your particular RDBMS to join them properly. In the above example.

The Create New Form Expression dialog box opens. 11 Click OK. select the LU_DAY table. The mapping method is selected as Automatic by default. 8 Click New. The Create New Attribute Form dialog box opens. 10 Double-click the ORDER_DATE column to add it to the Form expression pane on the right. . 7 Click OK. Inc. and then the Time folder. 6 Double-click the DAY_DATE column to add it to the Form expression pane on the right. both of which use different tables as the source of their information. 3 Double-click the Day attribute. open the Attributes folder. 2 Navigate to the Schema Objects folder. 154 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy. 4 Click New. The mapping method is selected as Automatic by default. 9 From the Source table drop-down list. You could continue this process to add as many heterogeneous columns as part of one attribute form as necessary. The Create New Attribute Form dialog box opens. 5 From the Source table drop-down list. Notice that there are now two expressions for the attribute form definition. The Attribute Editor opens. log in to the project source that contains the MicroStrategy Tutorial project and then log in to MicroStrategy Tutorial.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. The Create New Form Expression dialog box opens. select the ORDER_DETAIL table.

the Rush Order attribute in MicroStrategy Tutorial is an example of an implicit attribute. close the Attribute Editor without saving your changes. RushOrder=‘Yes’. Inc. 15 Because this is only an example.Project Design Guide The Context of Your Business Data: Attributes 6 12 In the Form general information area. although nothing is saved in an actual column. in the Name field. Implicit expressions are not defined by column names. rather than being defined in terms of columns. 13 From the Category used drop-down list. for each order that is a rush order. Implicit attributes are not commonly used. Some attribute definitions can be implied by the existence of a row in a certain table. but are useful in special cases such as the scenario described above. The new Date Example attribute form is added to the Attribute form pane in the Attribute Editor. © 2007 MicroStrategy. On a report with the Order and Rush Order attributes on the template. type Date Example. they are defined by constants you specify. an implicit attribute is a virtual or constant attribute that does not physically exist in the warehouse. An implicit attribute such as Rush Order is useful for this purpose. Implicit expressions While most attributes map directly to one or more physical columns in the warehouse. Such an attribute has an implicit expression. which is a constant value. for example. a “Y” is displayed in the Rush Order column. For example.” This implicit expression is used to keep track of which orders are rush orders. which stands for “Yes. 14 Click OK. Implicit attributes are useful in analyzing and retrieving relevant information. Any constant is acceptable. Suppose you want a report to display which orders are rush orders so you can better keep track of your shipments. The Rush Order attribute is defined by two expressions: the Rush_Order column in the Order_Fact table and the implicit expression “Y”. select None since this is simply an example scenario. Column data descriptions and identifiers: Attribute forms 155 .

depending on your database or data source type. They can also help you take more advantage of the data in your data warehouse. By doing so. you must modify the column alias for the attribute form and map it to a special data type. For example. the precision can be preserved when performing filtering. This inheritance is governed by MicroStrategy. 0).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. there are cases where you may need to change the data type. the data type for an attribute form is inherited from the data type of the column on which the form is defined. Data Types for more information on how MicroStrategy selects a matching data type). However. In such a case. Because this column stores high-precision values. The following are some examples of such cases. you can create a Year attribute using the following form expression: ApplySimple("Year(#0)". 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. SQL Server has a Year function that extracts just the year from a date. 156 Column data descriptions and identifiers: Attribute forms © 2007 MicroStrategy. Many database platforms have functions that can extract parts of a date from a Date data type.[Date_Id]) The ApplySimple expression above is syntactically correct for SQL Server. For attributes. drilling. . or page-by on the Account attribute. 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. Big Decimal. a column alias performs the same function as it does for facts. Column aliases allow you to specify a more appropriate data type that can help avoid errors in your SQL. you may need to use a different syntax. 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. By default. Inc. However.

you can change the column alias name to be more meaningful. The above example is a simple one. the system uses a Date data type and tries to insert integer data into this column.Date_Id) CustCol_1. the column alias also lets you specify the column alias name to be used in the SQL generated by MicroStrategy. sum(a11.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. where the column alias name is used: SELECT Year(a12. To create a column alias for an attribute This procedure assumes you have already created an attribute with a valid attribute expression for which to create a new column alias. log in to the project source that contains the attribute to create a new column alias for. the column alias for the attribute form defaults to CustCol (or CustCol_1. some databases will return an error. such as 2002. the result of the calculation is a year. When you create a form expression using a custom expression or multiple columns (as discussed in Attribute form expressions. in bold. You can use the Attribute Editor to create column aliases. While this does not create a problem in all database platforms. 1 In MicroStrategy Desktop.Date_Id) While the column alias name does not affect the actual results or your report. Inc. and so on). © 2007 MicroStrategy. but this can be useful for troubleshooting the SQL for a particularly complex report. The following piece of SQL shows. if you do not change the data type of the column alias. CustCol_2. and it is an integer. modify the column alias for the attribute form and change the default Date data type to an Integer data type. Column data descriptions and identifiers: Attribute forms 157 . page 147). In addition to specifying the data type to be used for an attribute form. However. To avoid the possibility of an error due to conflicting data types.Tot_Dollar_Sales) WJXBFS1 FROM YR_CATEGORY_SLS a11 cross join TRANS_DATE_LW_LY a12 GROUP BY Year(a12. When a temporary SQL table is created. This is because Date_ID is a Date data type.

• • 8 Click OK to save your changes and return to the Column Editor . The Attribute Editor opens. Data type: The data type for the fact. The Column Editor . 5 In the Column alias area.Column Selection dialog box. scale. Inc. precision. bit length. The Column Editor .Definition dialog box opens. Attribute forms versus separate attributes Attribute forms can be considered as additional descriptions for an attribute. 3 Select an attribute form and click Modify. 4 Select the Column Alias tab. see the MicroStrategy Desktop online help. see Appendix D. 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 Types. The Modify Attribute Form dialog box opens. For a description of the different data types supported by MicroStrategy. 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.6 The Context of Your Business Data: Attributes Project Design Guide 2 Right-click the attribute and select Edit.Column Selection dialog box opens. 6 Select New to create a new column alias. click Modify. For a detailed description on each of these properties. you can specify the byte length. 9 Click OK to save your changes and return to the Attribute Editor. or time scale for your column alias. Depending on the data type selected. . 10 Select Save and Close to save your changes.

see Attribute forms. The implications of whether attributes are related become clear when you begin building reports. or cross join. 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. In general. In other words. The data that you map to attributes can be represented as separate attributes or as an attribute form of an attribute. for example—without any problems. as explained in Attribute relationships.Project Design Guide The Context of Your Business Data: Attributes 6 other attributes. The parent-child relationships you create determine the system hierarchy within the project. which is generally undesirable. Attribute relationships You link directly related attributes to each other by defining parent-child relationships. or else a Cartesian join occurs. 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. dictate the relationships that you define between attributes. however. You can run a report with two attributes that are related—Country and City. these relationships define how the engine generates SQL. You do not group by the data. is very database intensive as every row in one table is joined to every row in the other table. A Cartesian join. © 2007 MicroStrategy. how tables and columns are joined and used. Attribute relationships 159 . A report with two unrelated attributes. page 24. and which tables are related to other tables. For more information on whether to model data as an attribute form or as a separate attribute. page 36. or the actual data values for an attribute. must include a metric based on a fact that is on or below the level of the two attributes. Attribute elements. Inc.

and these relationships are defined by the attribute elements that exist in the related attributes. Q1 2007. Inc. Attributes can also be related to other attributes through a chain of attribute relationships.6 The Context of Your Business Data: Attributes Project Design Guide In MicroStrategy Desktop. In banking. Three types of direct relationships can exist between related attributes. after a project has already been created. page 161. you can define relationships for the attributes in your project. This assumes that quarters are defined with an accompanying year such as Q4 2006. Attributes can be either related or unrelated to one another: • Related: A parent-child relationship is defined between two or more attributes. For example. One-to-one: Each element in the parent attribute has one and only one corresponding element in the child attribute. One year has many quarters. as part of the initial project design effort and in Viewing and editing the parents and children of attributes. Year has a one-to-many relationship to quarter. page 129. but a specific quarter can be in one year only. 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. consider the Geography hierarchy of the Customer Analysis Analytics 160 Attribute relationships © 2007 MicroStrategy. One customer may have many accounts. Attributes of this type are often in the same hierarchy. The relationship is defined through the attribute’s lookup table or a relationship table. A common example of a one-to-one relationship is citizen and Taxpayer ID. and each account may be associated with many customers. These are the most common types of attribute relationships. One-to-many: Each element in the parent attribute corresponds to one or more elements in the child attribute. customers and accounts are an example of a many-to-many relationship. such as in the case of a joint checking account. . A citizen can have only one Taxpayer ID and a Taxpayer ID can be assigned to only one citizen. This step is covered in Simultaneously creating multiple attributes.

How attributes relate to one another and the types of relationships they share define the system hierarchy which is used to generate SQL. For example.Project Design Guide The Context of Your Business Data: Attributes 6 Module of the MicroStrategy BIDK. Inc. Attribute relationships 161 . however. Customer Region and Customer State are directly related to each other and Customer State and Customer City also have a direct relationship. Don Addison. these attributes are relatively straightforward to deal with from a project design perspective. Customer State. In general. No relationship is present in the lookup tables or relationship tables for these attributes. Unrelated attributes can exist together in fact tables. In this case. 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. A particular customer and a particular day only make sense together if a fact is associated with that combination. This SQL.500 on January 5. a certain customer. • Unrelated: No parent-child relationship has been defined and the attributes are not related through a chain of attribute relationships. spent $2. and Customer City: In this scenario. determines the output of a report. For example. 2003 on behalf of the health care company in which he works. giving context to the fact. which contains the attributes Customer Region. in turn. © 2007 MicroStrategy. While Customer City is not directly related to Customer Region. the Customer and Day attributes have no relationship to one another. 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. care must be taken when using unrelated attributes on a single report.

For a general procedure to view and edit the parents and children of an attribute. when a report generates inaccurate SQL and results. The Attribute Editor opens. Inc. page 193. refer to the MicroStrategy Desktop online help. A one-to-one relationship exists between Distribution Center and Call Center. Follow the procedure below to view and edit the parents and children of the Distribution Center attribute. and the relationship table in which the relationship exists. Country. you can continue to make changes to the relationships between attributes even after creating your project. and then the Geography folder. . 4 Click the Children tab. log in to the project source that contains the MicroStrategy Tutorial project and then log in to MicroStrategy Tutorial. along with the relationship type it shares with Distribution Center. For example. However. 2 Navigate to the Schema Objects folder. is the parent of Distribution Center and multiple distribution centers exist in each country. 162 Attribute relationships © 2007 MicroStrategy. Also. open the Attributes folder. To view and edit the parents and children of an attribute 1 In MicroStrategy Desktop. So these two attributes have a one-to-many relationship. as discussed in Creating Hierarchies to Organize and Browse Attributes. in turn. This means that only one call center exists in each distribution center. The Call Center attribute is listed.6 The Context of Your Business Data: Attributes Project Design Guide Parent-child relationships were designated when attributes were selected for the new project. 3 Double-click the Distribution Center attribute. viewing and changing parent-child relationships may be a necessary troubleshooting method. the Distribution Center attribute is the parent of the Call Center attribute. Assigning parent-child relationships to attributes allows you to connect attributes to one another in user hierarchies.

Logical data models and physical warehouse schemas are discussed in Chapter 2. close the Distribution Center attribute without saving your changes. Before reading this section. The Logical Data Model and Chapter 3. Attribute relationships 163 . The following sections discuss the considerations you must make to ensure an effective warehouse design in light of the unique nature of these relationships. © 2007 MicroStrategy. in this case. While the topics are largely related to logical model design. select the LU_Employee table from the Relationship table drop-down list.Project Design Guide The Context of Your Business Data: Attributes 6 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. you must change the relationship type between Call Center and Distribution Center. Inc. select One to Many from the Relationship type drop-down list. 7 Because this is only an example. Warehouse Structure for Your Logical Data Model respectively. you should know what logical data models and physical warehouse schemas are. a working knowledge of physical schemas is helpful when dealing with the challenges involved with these topics. To change the relationship table. can introduce additional complexity to the schema and warehouse design process. These chapters discuss how to plan and create a conceptual framework for your business intelligence data. many-to-many relationships and joint child relationships. 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. Supporting many-to-many and joint child relationships Two forms of attribute relationships. and how to read and interpret them. 5 To change the relationship type.

Likewise. 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.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. there are many colors for a single type of car. Inc. many models of cars are produced. 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. red shoes. you must make additional considerations to effectively plan your design. With the presence of many-to-many relationships. green hats—and one color can be associated with many items—red dress. red socks. each salesperson can work in more than one calling center. • 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. Potential problems with many-to-many relationships usually come in the following forms. red hat. One item can come in many colors—red hats. 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 calling center has many salespeople. and many types of cars can be associated with the same color. blue hats. That is. and each comes in several colors. In a car manufacturing plant. .

but in addition it shows a simple fact table containing sales data keyed by item. a distinct relationship table needs to be present in your warehouse. In many-to-many relationships this is not feasible. The following diagram shows the same scenario as before. Recall that one-to-many relationships are usually in the child’s lookup table. Rather. Attribute relationships 165 . 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.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. and date. © 2007 MicroStrategy. Inc. color.

Multiple counting occurs when all of the following takes place: • You attempt to aggregate data to the level of one of the attributes in the many-to-many relationship. In summary. Inc. All of the attributes in the many-to-many relationship are not in the fact table. Multiple counting When dealing with many-to-many relationships. . Only item/color combinations that were actually sold—and therefore have sales recorded—can be retrieved from this table. 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 You can implement the above points in several different ways. If you have item/color combinations that are available but that have never been sold. The relationship exists in a distinct relationship table. which are discussed in Working with many-to-many relationships.6 The Context of Your Business Data: Attributes Project Design Guide The fact table in the above diagram alone is not sufficient to answer the first question. page 168. to prevent any loss of analytical flexibility when dealing with a many-to-many attribute relationship. loss of analytical capability is only one challenge. • • 166 Attribute relationships © 2007 MicroStrategy. or a higher level than one of the attributes in the many-to-many relationship. this fact table cannot provide a complete list of item/color combinations to answer question one. Another equally significant issue is multiple counting.

effectively aggregating to the item attribute level in the many-to-many relationship. 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. and green—with the exception of socks. 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. and socks—and that they come in three colors—red. Assume that there are three items—hats. blue. but make the following change: remove color from the fact table. which come in only green and blue. dresses. © 2007 MicroStrategy. Attribute relationships 167 . Inc.Project Design Guide The Context of Your Business Data: Attributes 6 Recall the example from above.

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. however. seemingly simple questions can require you to take a number of steps to answer them when many-to-many relationships are involved. using the given data. • What are the total sales for red dresses? Again. • What are the total sales for red items? You cannot determine an accurate answer. 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. For example. instead of calculating the sales of red items. since socks do not come in red. Working with many-to-many relationships As you can see. The sum includes all hats and all dresses. which is the total for all hats and dresses. you cannot confirm this since color is not recorded in the fact table. you cannot determine an accurate answer. The answer you get is $85. If all the dresses sold are indeed green.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. Inc. which can be calculated directly from the fact table. the correct answer is $0. For example. the following questions cannot all be answered accurately: • What are the total sales for hats? The answer is $35. the query aggregates sales for all items that come in red according to the relationship table. This obviously leads to numbers that are higher than the true sales for red items. . It is entirely possible that all the dresses sold are green. There is no way to directly relate the sales of an item in the fact table to the color of that particular item. including blue ones and green ones. The three techniques all have differing levels of 168 Attribute relationships © 2007 MicroStrategy.

Project Design Guide The Context of Your Business Data: Attributes 6 flexibility. Rel_Color_Item) and add both attribute IDs to the fact table as shown in the following diagram. All of the following methods require additional data in the fact table. When a metric is included. Attribute relationships 169 . For example. the SQL Engine uses the related table when no metric is included on the report. Inc. If this additional data was never captured in the source system. you need to have data in the source system as to what the color is of each item sold. and flexibility is always a trade-off with complexity. 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 MicroStrategy builds the rules that MicroStrategy SQL Engine uses to generate SQL when a report request is made. In all cases. Method 1 This method is the most straightforward way to effectively manage many-to-many relationships. you cannot fully resolve the many-to-many relationship to calculate the amount of sales for items of a certain color. This means that you must capture the additional data in the source system. If you make both of the above physical implementations. © 2007 MicroStrategy. the fact table is used to answer the query. Method 1 requires you to create a separate relationship table (in this case.

Here the many-to-many relationship is converted into a compound attribute relationship. in this case Item_ID and Color_ID. lower in level than either Color or Item.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. Also. which gives it a 170 Attribute relationships © 2007 MicroStrategy. While this method eliminates the need for a separate relationship table. you lose the ability to view items independent of color. to the fact table as shown in the following diagram. rather than two Here you must create a new attribute. you add both attribute IDs. 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. or vice versa. This attribute is essentially a concatenation of Color and Item. . Inc. You treat one attribute as a child of the other and have a compound key for the lower level attribute.

as shown in the following diagram. These relationships can be modeled and conceptualized like traditional attributes but. Attribute relationships 171 . Such attributes are called joint children. text facts. Joint child relationships Some attributes exist at the intersection of other indirectly related attributes. like facts. The major difference is that the distinct relationship table from Method 1 has an additional column. They do not fit neatly into the modeling schemes you have learned about thus far. Consequently. Joint child relationships connect special attributes that are sometimes called cross-dimensional attributes.Project Design Guide The Context of Your Business Data: Attributes 6 one-to-many relationship between itself and each of its parent attributes. Finally. particularly common in retail data models or situations. as well as possibly adding complexity to the ETL process. This is the SKU attribute. or qualities. they exist at the intersection of multiple attribute levels. you only need to include this new child attribute SKU. © 2007 MicroStrategy. The major disadvantage of Method 3 lies in creating the new attribute if your business model does not already use a similar structure. This method is actually quite similar to Method 1. rather than including Color and Item in the fact table. SKU. Inc. you can use this single value in the fact table. which extends the relationship of each item/color combination into a single value.

. consider the relationship between three attributes: Promotion. Therefore. Promotion has a many-to-many relationship to both Item and Quarter. In this case. An example of a promotion might be a “Red Sale” where all red items are on sale. as shown in the following diagram. if flags are referenced in your source system documentation. 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. you might create 172 Attribute relationships © 2007 MicroStrategy.6 The Context of Your Business Data: Attributes Project Design Guide Many source systems refer to these special attributes as flags. and Quarter. 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. In this case. Inc. For example. these are likely candidates for joint child relationships. Item. A business might run this promotion around Valentine's Day and again at Christmas time.

Attribute relationships 173 . one to relate Promotion and Item. distinct relationship table. Defining the relationship directly in the lookup table for the parent of the joint child—in this case. Alternatively. These two tables are sufficient to answer questions such as: • • What items have been in what promotions? What quarters have had what promotions? However. The second relates Promotion and Quarter as shown in the following diagram. you must combine the two relationship tables.Project Design Guide The Context of Your Business Data: Attributes 6 two relationship tables. creating one table to relate all three attributes. Inc. it does not necessarily have to be in its own. 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. The relationship in the distinct relationship table must exist for a joint child relationship to be properly defined. However. Promotion—would be fine. you can build the relationship directly into the fact table. © 2007 MicroStrategy.

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.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. as opposed to it being related to Item and Quarter separately. to see sales by promotion—the join will always use both joint children rather than just one or the other. Inc. The issues with many-to-many relationships—loss of analytical capability and multiple counting—also apply to many-to-many joint child relationships. . Notice that a joint child relationship can be one-to-many or many-to-many. If you have a joint child relationship in your data. The Promotion attribute is related to a particular Item-Quarter pair. 174 Attribute relationships © 2007 MicroStrategy. This is the essence of a joint child relationship and is shown in the following diagram. This ensures that when you need to join the fact table to the parent attribute of a joint child relationship—for example.

For example. When multiple attributes are defined using the same lookup table and column. Inc. in the following image. Attributes that use the same lookup table: Attribute roles 175 . AIRPORT_ID. notice that the attributes Origin Airport and Destination Airport are defined using the same lookup table. LU_AIRPORT. © 2007 MicroStrategy. it is understood that destination airport data differs from origin airport data. and column. Suppose you define two attributes that have the same data definition but play different roles in your business model. You need to support the logical concepts of an origin airport and a destination airport.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. and thus take up more storage space and be harder to maintain. How an attribute plays multiple roles depends on the specific attribute. Creating two separate lookup tables would create redundancy. the attributes are essentially playing different attribute roles. Although it makes sense to see JFK as either an origin or destination airport on a report. but you do not want to create two separate lookup tables with identical data.

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"). In one case. you must create an attribute in the logical model for each of the roles. 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. it refers to the 176 Attributes that use the same lookup table: Attribute roles © 2007 MicroStrategy. the fact columns are ORIGIN_AIRPORT_ID and DESTINATION_AIRPORT_ID. as explained in Specifying attribute roles. or various aspects about them. such as description. In the following diagram. as shown below. an empty result set is returned.6 The Context of Your Business Data: Attributes Project Design Guide The Origin Airport and Destination Airport attributes share the same attribute forms. This ensures that a report with attributes playing multiple roles returns correct data. State is another example of an attribute that can have two roles since it relates to both the Vendor and Store attributes. however. Inc. page 177. location. If you identify that one of your attributes needs to play multiple roles. . a separate column exists for each of their roles. and so on. In the fact table.

The State attribute is therefore said to be playing two roles. they must have different attribute names. Attributes that use the same lookup table: Attribute roles 177 . as shown in the above diagram. To create unique attributes. generating the empty result set. Specifying attribute roles To see both roles on the same report. you have the following options: • Automatic attribute role recognition. Automatic recognition is enabled by the VLDB © 2007 MicroStrategy. The SQL statement tries to obtain the description of a state that is both Arkansas and New York simultaneously. Inc. In an OLTP system. it refers to the location of a store. you must treat them as different attributes. That is. roles are most often implemented as a single table. a query involving both Vendor State and Store State needs to use the State table twice in the same query. In the other. a report is created to display vendors from Arkansas who sold to New York stores. where you create multiple attributes that have the same lookup table and allow MicroStrategy to automatically detect the multiple roles. In the data warehouse. For example. The results may be blank if the data warehouse structure was set up incorrectly.Project Design Guide The Context of Your Business Data: Attributes 6 location of a vendor.

as Ship Month and Order Month. is enabled). if you identify that any one of your attributes needs to play multiple roles. it may be the better alternative. for example. For more information. If you create more than this number of attributes. you encounter an error. Engine Attribute Role Options. 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. In this example.6 The Context of Your Business Data: Attributes Project Design Guide property Engine Attribute Role Options at the database instance level. In summary. in the State example provided above. refer to the MicroStrategy System Administration Guide. • Explicit table aliasing. You can use either automatic attribute role recognition or explicit table aliasing to create the attribute roles. Month is the attribute that has multiple roles. the two State attributes do not have a common child attribute. the attribute has multiple roles. however. In a MicroStrategy project in which automatic attribute role recognition is enabled (meaning that the database instance-level VLDB property. an attribute must be created in the logical model for each of the roles. 178 Attributes that use the same lookup table: Attribute roles © 2007 MicroStrategy. Inc. If you are upgrading or have a very complex schema. meaning that a child attribute is shared. . you can have a maximum of 99 attributes defined on the same column of the same lookup table. For example. Table aliasing provides advanced users with more control. Automatic recognition does not work if the attributes are in the same hierarchy. MicroStrategy recommends that you take advantage of automatic role recognition if you do not know the details of the modeling logic or the database. it is easier to use automatic attribute role recognition. If you are new to MicroStrategy. and are unable to update the project schema or restart Intelligence Server. Remember this rule to help you identify attribute roles: If you want to see the same attribute multiple times on one report.

” The same lookup table. using different attribute names for the same expression. LU_State. Automatic recognition allows these two attributes. Store State and Vendor State. a query involving both Vendor State and Store State needs to use the State table twice in the same query to get correct results. both of which use the same lookup table. You can set up two attributes. Vendor State and Store State. Attributes that use the same lookup table: Attribute roles 179 . the logical model must reflect that. The resulting SQL code contains a self-join with the LU_State table. can be used for both © 2007 MicroStrategy. “Show me total sales by Store State for all my vendors in Arkansas (Store State ID = 15). which in most cases simply represents a column or columns in a lookup 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. to access the same lookup table. Inc. Consider the following sample desired report: Vendor_State_ID=15 (Arkansas) Metrics Vendor State Vendor Store Store State Dollar Sales In this case. the request is. Automatic role recognition works only when the attributes use exactly the same expression.Project Design Guide The Context of Your Business Data: Attributes 6 Using automatic attribute role recognition In the data warehouse.

See the MicroStrategy Desktop online help or the MicroStrategy System Administration Guide for steps to set this VLDB property. Store State and Vendor State. found in the database instance-level VLDB Properties under Query Optimization. When you use explicit table aliasing to designate attributes that have multiple roles. To use automatic attribute role recognition. if attribute roles are used. 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. 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. 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. it can represent the Vendor State or the Store State. Explicitly aliasing tables to specify attribute roles Explicit table aliasing provides more robust functionality than automatic recognition. you must select the Engine Attribute Role Options. both roles for the State attribute are included in the logical model so that State can be considered from two different perspectives. . In this case. Inc.6 The Context of Your Business Data: Attributes Project Design Guide attributes. The two attributes refer to the same columns of that table.

for both state names. one table (LU_State_Store) contains the attribute Store State while the other (LU_State_Vendor) contains Vendor State. you create separate lookup tables in the schema. but point them each to the same physical table. 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 Store State Dollar Sales When explicit table aliasing is used. Since they are just different names for the same physical table. If you use explicit table aliasing for the Store attribute. the report accesses the same physical table. as shown in the following diagram. Inc. the two lookup tables LU_State_Store and LU_State_Vendor are used.State_Desc as State_Desc FROM LU_State a12 LU_State a13 © 2007 MicroStrategy.State_Desc as State_Desc SELECT a13.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. LU_State. Attributes that use the same lookup table: Attribute roles 181 . as shown by this sample SQL: SELECT a12.

the selected table is copied. In the case above. 3 Right-click the LU_State table and select Create Table Alias. select Rename. refer to Appendix C. When you create a table alias. log in to the project source that contains the MicroStrategy Tutorial project and then log into MicroStrategy Tutorial. When you are ready to create new attributes—as in the example discussed above—you can map the appropriate table to each attribute. 5 Right-click the LU_State table and select Create Table Alias. Create the attributes 7 Select the Attributes folder. . For information about logical tables. 6 Right-click LU_State(1). You can use the same high-level procedure and concepts as guidelines to create attribute roles in your project setup. 4 Right-click LU_State(1). allowing you to rename a copy of the same table. Table aliases are one kind of logical table. and rename the table as LU_State_Vendor. and then select the Tables folder. select Rename. 182 Attributes that use the same lookup table: Attribute roles © 2007 MicroStrategy. An LU_State(1) table is created. 2 Navigate to the Schema Objects folder. To create attribute roles with explicit table aliasing This procedure provides steps to re-create the example of explicit table aliasing described in this section. Inc.6 The Context of Your Business Data: Attributes Project Design Guide You create table aliases in the Schema Objects/Tables folder in MicroStrategy Desktop. and rename the table as LU_State_Store. An LU_State(1) table is created. Logical Tables. 1 In MicroStrategy Desktop. you would select the LU_State_Store table for the Store State attribute and LU_State_Vendor for Vendor State.

Do NOT select the LU_State_Vendor table as a source table. Inc. 9 From the Source table drop-down list. otherwise the attributes cannot have separate roles. select LU_State_Store. The Create New Attribute Form dialog box opens. 12 In the Source tables pane. 14 Click New to map any other columns to attribute forms for the State Store attribute. This implies that more than one ID column is needed to uniquely identify the elements of that attribute. 13 Click OK. 11 Select Manual mapping and click OK. select New. Attributes with more than one ID column: Compound attributes 183 . 16 Create a Vendor State attribute with the same sub-procedure (Create the attributes. 10 In the Available columns pane. The Attribute Editor opens. 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. and then Attribute. 15 Save the State Store attribute once you are finished mapping attribute forms to columns of the LU_State_Store table. You must make sure to map any State Store attribute forms to columns from the LU_State_Store table.Project Design Guide The Context of Your Business Data: Attributes 6 8 From the File menu. Generally. page 182) used to create State Store above. except you must use the LU_State_Vendor table instead of the LU_State_Store table. The Create New Form Expression dialog box opens. select the LU_State_Store table. you build a compound © 2007 MicroStrategy. double-click STATE_ID.

women’s. Item_ID and Class_ID must be grouped together. For example. depending on the class—men’s. However. regardless of country. The same Distribution Center identification numbers can exist for different distribution centers. To uniquely identify a distribution center. Distribution Center. 184 Attributes with more than one ID column: Compound attributes © 2007 MicroStrategy. page 186. They should also use the same lookup table. to uniquely identify a man’s shirt. . a retail project has two attributes. there are different shirts. each distribution center has a unique identification number. but in the same country. one must know two details about the distribution center: the ID of the distribution center and the country in which it exists. The values in the Item_ID column do not uniquely identify an item. Class is the parent of Item and has a one-to-many relationship with it. This creates a unique identifier for each distribution center. 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. Inc. It is an attribute that requires that two different columns are specified as the ID column. All of the ID forms of the compound attribute should be grouped together using form groups. This data is represented by the Dist_Ctr_ID and Country_ID columns respectively. and children’s. In the relational database. For information about form groups. creating a compound attribute. You can create a compound attribute. ID and Description. When defining the ID form. select the source table columns for Country ID and Distribution Center ID. a compound key is a primary key that consists of more than one database column. Therefore. with two attribute forms. The item shirt has an Item_ID of 1. Example: Creating compound attributes Distribution Center is an example of a compound attribute in the MicroStrategy Tutorial. see Collections of attribute forms: Form groups.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. Therefore. Class and Item.

and click OK. and then Attribute. 2 Navigate to the My Personal Objects folder. © 2007 MicroStrategy. 4 From the Source table drop-down list. 3 From the File menu. This attribute form maps to the distribution center ID column necessary to complete the definition of the Distribution Center attribute. with the Create New Form Expression dialog box displayed on top of it. type Country ID. The Create New Attribute Form dialog box opens. To create the Distribution Center compound attribute 1 In MicroStrategy Desktop. 11 Select Automatic mapping and click OK. 6 Select Automatic mapping and click OK. 9 In the Attribute Editor. in the Name field. 7 In the Form general information area. Inc. select New. 8 Keep all other defaults.Project Design Guide The Context of Your Business Data: Attributes 6 Follow the procedure below to create the Distribution Center compound attribute. The Create New Attribute Form dialog box opens. 5 Double-click the COUNTRY_ID column to add it to the Form expression pane on the right. This is the table in which the two ID columns of Distribution Center reside. and open the My Objects folder. log in to the project source that contains the MicroStrategy Tutorial project and then log into MicroStrategy Tutorial. For a general procedure to create compound attributes. 10 Double-click the DIST_CTR_ID column to add it to the Form expression pane on the right. Attributes with more than one ID column: Compound attributes 185 . select the LU_DIST_CTR table. refer to the MicroStrategy Desktop online help. click New to create the other attribute ID form. The Attribute Editor opens.

in the Name field. select ID from the Category drop-down list. type Distribution Center and click OK. You must create a form group to create a compound key. Create a form group 14 A dialog box notifies you that another form (in this case. This is necessary when creating compound attributes. with the form group you created in the Attribute forms pane. close the Distribution Center attribute without saving your changes. 13 In the Form category section. you create form groups to create compound attributes. Click Yes. In general. The Create New Attribute Form dialog box opens. . page 186.6 The Context of Your Business Data: Attributes Project Design Guide 12 In the Form general information area. 186 Collections of attribute forms: Form groups © 2007 MicroStrategy. refer to Collections of attribute forms: Form groups. You must designate this attribute form as an ID column so that it can be combined with the Country_ID form to create one unique identifier ID for the Distribution Center attribute. Inc. 16 Because this is only an example. 15 In the Name field. type Distribution Center ID Number. COUNTRY_ID) is already using the ID form category and that you must create a form group to combine the two ID columns. For basic information and examples about form groups. which identifies that an attribute form requires more than one ID column to uniquely identify its elements. 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. You can also use form groups to link similar forms together so that they are displayed together on a report. Click OK. which are attributes with more than one column specified as the ID column. The Attribute Editor opens.

For example. © 2007 MicroStrategy. When you create a form group. page 185. Distribution Center is an example of a compound attribute. choose the same form category for both forms—you are then prompted to name your new form group. For an example of creating a form group (form group creation is a subtask of the complete procedure). In the MicroStrategy Tutorial. you can design a uniquely defined form that groups two or more forms under an attribute. a compound attribute is created by using a form group to group together two forms to create the attribute’s ID. Therefore. see the procedure To create the Distribution Center compound attribute. you have a distribution center in London. To uniquely identify a distribution center. France which has a Dist_Ctr_ID=1 as well. England which has Dist_Ctr_ID=1. the included forms are joined together and act as one form. In the Attribute Editor. and you also have a distribution center in Paris. To uniquely identify the two distribution centers you must include the Country_ID as part of the attribute ID.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. the Distribution Center attribute is identified using a form group that combines these two forms. By grouping forms. one needs information from both the Country_ID and Dist_Ctr_ID tables. When you create a form group. Collections of attribute forms: Form groups 187 . Inc. This is because all countries identify distribution centers with numbers starting at 1.

You can also group two or more attribute forms as a form group after creating all of the attribute forms. 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. 188 Collections of attribute forms: Form groups © 2007 MicroStrategy. log in to the project source that contains the MicroStrategy Tutorial project and then log into MicroStrategy Tutorial. For example.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. To group attribute forms as a form group 1 In MicroStrategy Desktop. . page 185. as described in the procedure below. Inc. 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.

5 Double-click the ITEM_NAME column to add it to the Form expression pane on the right. they are used in two primary ways—browsing and reporting. The Create New Attribute Form dialog box opens. in the Name field.Project Design Guide The Context of Your Business Data: Attributes 6 2 Navigate to the Schema Objects folder. A form group which includes an item’s name and foreign name is created for the Item attribute. Using attributes to browse and report on data 189 . 4 Select New. and then the Item folder. 6 Select Automatic mapping and click OK. type Item and Foreign Name and click OK. 8 In the Form category area. Using attributes to browse and report on data Once attributes are built. The Create New Form Expression dialog box opens. 10 Select the Item Name 2 and Foreign Name attribute forms. open the Attributes folder. The Attribute Editor opens. Since this is only an example of how to create a form group. type Item Name2. Each © 2007 MicroStrategy. select None. 7 In the Form general information area. in the Category used drop-down list. Users browse through attributes to locate an attribute to use on a report. The Attribute Editor opens. 11 In the Name field. The Create New Attribute Form dialog box opens. 9 Click OK. and then right-click the selected attribute forms and select Group. Inc. do not save the changes to the Item attribute. The Attribute Editor opens. 3 Double-click the Item attribute. and users place an attribute on a report to display details about the particular attribute and how it relates to fact data.

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. you select a different set of values for display. 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. If a report lists the cities in which you have stores. default for each attribute. Therefore. then you might choose to display the Long Description form. such as Chicago. In Grid view.chicago. 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. If ID is selected as the attribute form. This separation allows for greater attribute display flexibility depending on the application. the display could be a number such as four.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. www. You can also select which attribute forms are retrieved with the report results but not displayed on the grid. Inc. a report includes Region as an attribute. instead of the URL attribute form. These browse forms are found in the Report Objects pane. such as Northwest. You can do this on a report-by-report basis. By selecting different forms for the attribute. Report display forms are the attribute forms that appear as columns in a completed report. you can add the attribute forms in Report Objects to the report without re-executing the report. You must choose a default attribute display for browsing and another for reporting. all forms are included as report display forms and browse forms by default. browse forms identify attribute elements. . The only exception is if you create multiple attribute forms. If Description is selected as the attribute form. that is. When creating attributes.com. or project-wide. For example. 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. the display could be a name. but you still must specify the global.

© 2007 MicroStrategy. The ID form group is made up of two separate ID columns.” You can use the Attribute Editor to determine how the attribute forms are displayed on a report. The Description form of Distribution Center. however. You can also determine which attribute forms are displayed when browsing a project with the Data Explorer. For a general procedure to set how attribute forms are displayed by default. Country_ID and Dist_Ctr_ID. the Dist_Ctr_ID form shows the identification numbers of specific distribution centers in the data warehouse. displays the actual name of the Distribution Center such as “San Diego. selecting Attribute Display to open the Attribute Display dialog box For steps to display attribute forms on a report or template. In the case of the Distribution Center attribute. Setting how attribute forms are displayed by default You can generally display attribute forms in a number of ways. refer to the MicroStrategy Desktop online help. or both are displayed. Inc. Using attributes to browse and report on data 191 . the distribution center names. see the online help and the section below. Displayed on a report. For example. you can specify whether the identification number of each distribution center.Project Design Guide The Context of Your Business Data: Attributes 6 • From the Data menu. 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. the Distribution Center attribute in the MicroStrategy Tutorial consists of an ID form group and a Description form.

The Attribute Editor opens. . the actual names of the distribution centers are displayed. 5 Because this is only an example. 2 Double-click the Distribution Center attribute. The Data Explorer makes hierarchies available for users to facilitate placing objects on reports. • 192 Using attributes to browse and report on data © 2007 MicroStrategy. 3 Click the Display tab. the description form of the Distribution Center is set as the only display form. and then the Geography folder.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. close the Attribute Editor without saving your changes. On the right. in the Report display forms pane. The ID 2 form in the Available forms pane represents the distribution centers’ identification numbers. You can also determine how attributes are displayed while users are editing and viewing reports. page 209. when the Distribution Center attribute is used on a report. 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. open the Attributes folder. The Data Explorer is discussed in Enabling hierarchy browsing in reports: Data Explorer. Inc. navigate to the Schema Objects folder. This means that. 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. See the MicroStrategy Basic Reporting Guide for details.

to reflect the relationships that exist between the attributes in a project. Inc. CREATING HIERARCHIES TO ORGANIZE AND BROWSE ATTRIBUTES Introduction Hierarchies are groupings of attributes that can be displayed.7 7. This chapter discusses hierarchies as they exist in the MicroStrategy environment and provides information on the two different types of hierarchies in MicroStrategy. either ordered or unordered. The Logical Data Model. The system hierarchy is automatically created when you create a project and is maintained by the © 2007 MicroStrategy. and Year attributes. you can include a Time hierarchy in your model that consists of Day. you learned how to use hierarchies to group related attributes in practical business areas. For example. 193 . Week. In Chapter 2. These types of hierarchies include the system hierarchy and the user hierarchy. Month.

For information on user hierarchies and system hierarchies. This chapter explores how to create and configure user hierarchies in MicroStrategy and provides additional information about hierarchy functionality in MicroStrategy Desktop. 194 Creating user hierarchies © 2007 MicroStrategy. page 196. see Types of hierarchies. Inc. The user hierarchy is a hierarchy which you create specifically for your report designers. .7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide relationships that exist among the project’s schema objects. Creating user hierarchies In MicroStrategy Desktop. Follow the procedure below to learn how to create a user hierarchy. you create user hierarchies using the Hierarchy Editor.

This procedure is covered in Viewing and editing the parents and children of attributes. select New. log into the project source that contains your project and open the project. and then Hierarchy. Creating user hierarchies 195 . 4 From the File menu. 5 In the Select Attributes dialog box. in the Available objects window. an entry point. If arrows do not appear between attributes you know are related. If the Use as a drill hierarchy check box at the bottom of the Hierarchy Editor is selected. 6 In the Hierarchy Editor. you must edit the attribute(s) in the Attribute Editor. and update the schema. Type a name for the hierarchy. or filtered. page 161. Once you save and re-open the hierarchy. © 2007 MicroStrategy. To do so. page 209. Inc. 2 In the Folder List.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 To create a new user hierarchy 1 In MicroStrategy Desktop. a dialog box opens notifying you that the hierarchy you are about to save is drillable in reports. select the attributes to use in the hierarchy and click the arrow to add them to the Selected objects window. navigate to and open the Schema Objects folder. select Show Details. Click OK to close the Select Attributes dialog box. you can view the details of each attribute in the hierarchy. assign the appropriate parent or child relationship to the attributes. Drill hierarchies are discussed in Drilling using hierarchies. 7 Click Save and Close. The arrows that connect certain attributes denote the presence of a relationship between the connected attributes. The Hierarchy Editor opens. and then the Data Explorer folder. followed immediately by the Select Objects dialog box. The attributes you selected appear in the Hierarchy Viewer. arrows appear between related attributes. from the View menu. 3 Open the Hierarchies folder. These details include whether or not the attribute is locked.

You do not need to create the system hierarchy. it is automatically created in Desktop when you create a project. User hierarchy: User hierarchies are named sets of attributes and their relationships to each other. As the structure of your business intelligence evolves. to make the user hierarchy available for element browsing in the Data Explorer. Steps to create user hierarchies are discussed in Creating user hierarchies. . Although the system hierarchy specifies an ordered set of all attributes in the project. The ordering and grouping of attributes. 9 Update the project schema by selecting Update Schema from the Schema menu. you must place it in the Data Explorer sub-folder within the Hierarchies folder. They are user-defined and do not need to follow the logical data model. Types of hierarchies The two types of hierarchies that exist in MicroStrategy include: • System hierarchy: The system hierarchy is created according to the relationships defined between the attributes in your project. This type of hierarchy is created to provide flexibility in element browsing and report drilling. Inc. page 194. • 196 Types of hierarchies © 2007 MicroStrategy. you can easily change the design of a user hierarchy to include additional attributes or limit user access to certain attributes. navigate to the location in which you want to save the hierarchy. is defined in user hierarchies. However. You can save user hierarchies in any folder. arranged in specific ways that make sense to a business organization.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide 8 In the Save As dialog box. among other configurations. it does not define ordering or grouping among attributes.

page 211. and so on. Month. you can double-click Year to get to Quarter and double-click Quarter to get to Month. You create user hierarchies to define the browse and drill relationships between attributes. When you browse the attributes in the Data Explorer. the only hierarchy it contains is the system hierarchy. The system hierarchy cannot be edited but is updated every time you add or remove attribute children or parents in the Attribute Editor. The Hierarchy Viewer is discussed in detail in Using the Hierarchy Viewer. Any attributes that are not assigned to a user hierarchy remain available to the system as report objects. you can create a Time hierarchy that contains the Year. arranged in specific sequences for a logical business organization. User hierarchies: Logical business relationships User hierarchies are sets of attributes and their relationships. Inc. Types of hierarchies 197 . or when you define attribute children in the Project Creation Assistant. It contains all of the attributes in the project and is actually part of the schema definition. For example. Attributes from the system hierarchy do not need to be part of an explicitly-defined user hierarchy.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. You can view the system hierarchy in the Data Explorer or in the Hierarchy Viewer. and Day attributes. When you first create a project. but not the Hierarchy Editor. These report objects are discussed in detail in the MicroStrategy Advanced Reporting Guide. © 2007 MicroStrategy. You can access the Hierarchy Viewer from Graphical View in the Schema menu. The system hierarchy is useful in determining relationships between all objects in the project. The system hierarchy holds information on the relationships between attributes in the project. Quarter. filter conditions. and components of consolidations.

Within the Location hierarchy. up to Year. . Inc. or across to an attribute within another hierarchy. This allows users to more easily locate attributes in a project and navigate from one attribute to another. For example. and you can create any number of user hierarchies for each project. in drilling the user actually chooses to move to higher or lower levels on a report or move across to levels within different hierarchies. 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. you can place related attributes into hierarchies by their level. The Customer hierarchy also groups together the attributes Company. and Store are organized according to their relationships to each other. Contact. A user hierarchy is the only type of hierarchy you can define. he or she can drill down to Month. 198 Hierarchy organization © 2007 MicroStrategy. State. You can create user hierarchies in the Hierarchy Editor using one or more attributes from the system hierarchy. For example. City. The example below demonstrates the Location and Customer hierarchies. and Customer.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide Whereas browsing occurs through the Data Explorer. if the user drills on the Quarter attribute in a report.

Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 When creating user hierarchies. if you only include Store in the Region hierarchy. This hierarchy allows you to create drilling and browsing options to the lower levels to view Region. However. When you group attributes together into user hierarchies. as in the second example. The rest of this chapter discusses user hierarchies and how to create and configure them in your project. only the user hierarchy allows you to logically define and order groups of attributes. © 2007 MicroStrategy. One hierarchy demonstrates Region having multiple States and the States having multiple Stores. then the only options for drilling or browsing are the Region and Store levels. and Store on a report. you are developing a working design of the display and browse functions of the attributes. State. In the example below. Hierarchy structure While both a system hierarchy and user hierarchy allow you to navigate attributes in your project. Hierarchy organization 199 . Inc. 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. there are two instances of the Region hierarchy.

In user hierarchies. page 203). Attribute Filters: Specifies whether the data retrieved and displayed should be complete or filtered by any specific criteria. Browse Attributes: Shows the attributes to which users can browse from a given attribute. page 201). The element display may be locked. unlocked. A filter on a hierarchy acts like a filter in a report. 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. In the system hierarchy. as shown in the following procedures: • Element Display: Determines the elements a user can see. page 205). Entry Point/Not an Entry Point: Specifies whether the user can begin browsing in this hierarchy using this attribute (see Entry point. the connections between the attributes represent the parent-child relationships. or limited (see Controlling the display of attribute elements. The Aerial perspective provides an overview of hierarchies. You can use the Hierarchy Editor to configure each of these properties. its decreased scale allows you to navigate through the entire project. Inc. page 206). the connections show the browse paths between the attributes. Only data satisfying the filter criteria is displayed (see Filtering attributes in a hierarchy. • • • 200 Configuring hierarchy display options © 2007 MicroStrategy. The Hierarchy Viewer is discussed in further detail in Using the Hierarchy Viewer. Represented by lines that connect one attribute to others (see Hierarchy browsing. The Hierarchy Viewer is accessed from the Graphical View option in the Schema menu. .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.

The Order attribute may be locked in order to prevent unauthorized users from accessing sensitive information about customer orders. © 2007 MicroStrategy. When you set the element display to locked. he or she cannot view information about each customer’s order. the attribute Order is locked in the Data Explorer sample shown below. For example. While the user can view the attribute elements of Customer Region and Customer City. you can prevent the expansion of long attribute element lists that can consume system resources. a padlock icon appears next to the attribute name. 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.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 The following sections explain these properties and how to use the Hierarchy Editor to configure each. By restricting the view of attribute elements and lower level attributes in the Data Explorer. Anything higher in the hierarchy is still visible. Inc. Configuring hierarchy display options 201 . 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.

3 To lock an attribute. no elements for Year display in the Data Explorer when Year is expanded. 5 In the Hierarchy Editor. select Element display. 202 Configuring hierarchy display options © 2007 MicroStrategy. . You can also lock and unlock attributes when you edit them in the Display tab of the Attribute Editor. if the attribute Year is locked in the Attribute Editor. 6 Update the project schema by selecting Update Schema from the Schema menu. 4 To unlock a locked attribute. A padlock icon appears next to the locked attribute. you can set the limit to five or ten at a time. from the right-click menu. However. Instead of loading all attribute elements at once. 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. 2 Right-click the attribute to lock or unlock. and users can now view the elements of this attribute. this locks and unlocks the attributes within the system hierarchy. and then Locked. The user can then click the arrows to see the next set of elements for that attribute. The padlock icon is removed from the attribute. For example. Also. select Element display. not any user hierarchies that contain the attributes. from the right-click menu. The Hierarchy Editor opens. and users can no longer view elements of this attribute.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. This method is useful when there are extensive attribute elements in a hierarchy. and then Unlocked. click Save and Close. retrieving a large number of elements at once can negatively impact system performance. Inc.

The following graphic displays this view in the Data Explorer. refer to the Filters chapter in the MicroStrategy Advanced Reporting Guide to understand what filters are and how to create them in MicroStrategy. With a filter you can choose exactly which attribute elements to display in a hierarchy. You can add filters to a hierarchy to control how data is retrieved and displayed. the Chocolate subcategory. Configuring hierarchy display options 203 . select Element display. Rather than displaying all of them at once and overwhelming the user. 2 From the right-click menu. and then Limit. shown below.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 For example. type the number of elements you want to see at one time and click OK. Filtering attributes in a hierarchy Before reading this section. contains many items. For example. 3 In the Limit dialog box. you can filter a hierarchy so that data for only one © 2007 MicroStrategy. 5 Update the project schema by selecting Update Schema from the Schema menu. right-click the attribute to limit. To limit the display of attributes in a hierarchy 1 In the Hierarchy Editor. 4 In the Hierarchy Editor. Inc. click Save and Close. a limit of five items has been set.

you want to view only those customers who are younger than 30 years old. When filtering attributes in a hierarchy. and the user is unable to see additional data in the hierarchy. Filters increase efficiency when retrieving data because you can limit user access to parts of a hierarchy when you apply filters to attributes. Creating a limited hierarchy reduces the number of elements displayed at one time.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide quarter is displayed. Only those customers younger than 30 years old are displayed. you need to make sure that each filter is relevant to the attribute’s information. limit the elements a user is allowed to see and therefore. however. Filters make data retrieval faster by only allowing specific data to be displayed. create a filter on Customer Age less than 30. In the Hierarchy Editor. you are limiting the elements of the data returned when you browse the Data Explorer. You cannot use a prompt-based filter to filter a hierarchy. To apply a filter to an attribute in a hierarchy 1 Create a filter in MicroStrategy Desktop. right-click the attribute to filter and select Define Attribute Filters. add the filter to the Customer attribute. See the MicroStrategy Desktop online help for more details. Each attribute in the hierarchy can have multiple filters applied to it. For example. perform a type of security. Update the project schema. MicroStrategy does not validate that the associated filter makes sense on that attribute. 2 In the Hierarchy Editor. The filters allow the Data Explorer to display only the criteria you select. and view the Customer hierarchy in the Data Explorer. . click OK. Inc. 204 Configuring hierarchy display options © 2007 MicroStrategy. When adding filters to an attribute in a hierarchy. 3 If a tip about filtering opens. or data for only a few days of one quarter. Filters. First.

such as Q1. Q2. in the Available objects list. a typical hierarchy is Time. When you set an attribute to be an entry point. When you click on 2006. the hierarchy. You can see the locked attribute. click Save and Close. the attributes. it appears in its normal position within the hierarchy structure. and 2005. This is especially useful when accessing frequently-used attributes. you need to open several levels of attributes to reach the correct data level. Configuring hierarchy display options 205 . an element for each Quarter. and Q4. the attribute Week appears in the Data Explorer at the same level as Year. 2006. you are creating a shorter route to access that attribute. The attribute to which you applied the filter appears in the hierarchy with a filter icon. If you set the attribute Week as an entry point. and their elements appear in the Data Explorer. which is Week. © 2007 MicroStrategy. If an attribute is not set to be an entry point. right-click the attribute to set as an entry point. If you set a locked attribute as an entry point. 5 Click OK to close the Select Filters dialog box. 6 In the Hierarchy Editor. it still appears in the hierarchy but with a padlock icon. but are unable to access elements or attributes below that level. To create entry points in a hierarchy 1 In the Hierarchy Editor. select the filters to apply and click > to add them to the Selected objects list. opens. 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. When you create a user hierarchy. Inc. For example. open. Entry point An entry point is a shortcut to an attribute in the Data Explorer. When you click on Time. Q3.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 4 In the Select Filters dialog box. elements for each Year. If you are seeking Week 24. such as 2007.

Some of the attributes in the Hierarchy Viewer may already be set as entry points. Subcategory. Inc. if Catalog. the hierarchy resembles the example below. For example. These relationships determine how users can browse the attributes from the Hierarchies folder. you can define the relationships between them. showing the parent/child relationships between the attributes. in the hierarchy below. . Hierarchy browsing Once you choose which attributes to place in a hierarchy. To remove an entry point from an attribute. Category. For example. 3 In the Hierarchy Editor. 206 Configuring hierarchy display options © 2007 MicroStrategy. Category is a parent attribute of Category and Category is the child attribute of Category.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide 2 From the right-click menu. attributes set as entry points are denoted by a green check. 4 Update the project schema by selecting Update Schema from the Schema menu. and Item are the attributes that comprise the user hierarchy Catalog Items. select Set as entry point. select Remove Entry Point from the right-click menu. click Save and Close.

see Enabling hierarchy browsing in reports: Data Explorer. When you apply browse attributes to attributes in a hierarchy. It can simply be a collection of attributes. Specifically: Hierarchy Attribute Catalog Category Subcategory Item Browse Attribute(s) Category. Subcategory Subcategory Catalog.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 A user hierarchy does not need to have these direct relationships defined. For each attribute in a hierarchy. some of these attributes have been assigned a browse attribute. Using the example above. Inc. you are specifying what levels of detail are visible when browsing the Data Explorer. Attributes in a hierarchy can have both browsing and drilling relationships between them. page 209. Configuring hierarchy display options 207 . without having to first browse down through the Category © 2007 MicroStrategy. Including hierarchies in the Data Explorer makes the hierarchies available for reports and to users in the project. Item The addition of these browse attributes allows users to see the Subcategory elements directly from the Catalog attribute. you can assign one or more browse attributes to it. Browse attributes are attributes you specify a user can directly browse to from a given attribute in the user hierarchy. For more information on including hierarchies in the Data Explorer.

In the Data Explorer. Inc. The ability to browse more directly through the hierarchy can be represented as shown below. the hierarchy described above resembles the example below.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide attributes to get to Subcategory. 208 Configuring hierarchy display options © 2007 MicroStrategy. Users can now view the subcategories in the catalog without first having to browse through the categories. .

at a project level. which contains the two attributes. You can make user hierarchies available for drilling. Configuring hierarchy display options 209 . For example. When you create a new project. Drilling using hierarchies Drilling is a function in MicroStrategy reports that allows users to browse different levels of attributes along specified paths. up. drilling is enabled in the Time hierarchy. the system hierarchy for that project is automatically placed in the Data Explorer. This allows a user to drill down from Year to Month and. 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. if they need to. The Data Explorer is a tool in the Object Browser that holds the system hierarchy and the user hierarchies. Depending on the level of the attributes included in the drilling specification. © 2007 MicroStrategy. Inc. When a user selects a drilling path in a report. the attributes to which users can drill from other attributes. the user can drill down on the Year attribute to a lower level attribute such as the Month attribute. Revenue data is reported at the Month level. and across to different levels of detail. on the new report. In the example of the Year and Month attributes. You can save user hierarchies in any folder. A new report is automatically executed. drill back up from Month to Year. Moving hierarchies to and from this folder also allows you to keep some hierarchies visible to users while hiding others. reports can allow users to drill down. which is located in the Schema Objects folder. on a report with the Year attribute and Revenue metric.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 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. This option enables you to determine. the report refreshes to display the selected level of detail.

Therefore. page 206 for more details about browsing attributes. you must enable the user hierarchy to be used as a drill hierarchy in the Hierarchy Editor. If you enable drilling in this hierarchy. See Hierarchy browsing. . you can drill from Catalog down to Subcategory—and any other browse attributes of Catalog—on a report. click Save and Close. 210 Configuring hierarchy display options © 2007 MicroStrategy. If a user hierarchy is not enabled. select the Use as a drill hierarchy check box. To enable drilling in a user hierarchy 1 Open the hierarchy in which to enable drilling. the default drill path is defined by the System Hierarchy. 4 Update the project schema by selecting Update Schema from the Schema menu.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide To enable a user hierarchy as a drill path. 2 At the bottom of the Hierarchy Editor. in the following hierarchy. which means that you can access the elements of Subcategory without having to necessarily access the elements of Catalog in Data Explorer. you can think of browsing paths in a user hierarchy as potential drilling paths. 3 In the Hierarchy Editor. Subcategory is a browse attribute of Catalog. For example. Inc.

or you may select only one at a time. as defined by the system when the project was created. • The Hierarchy Viewer gives you flexibility over how much of a given hierarchy you choose to view at once. Using the Hierarchy Viewer and Table Viewer 211 . you do not see true attribute relationships. to facilitate user browsing and report development. When a user right-clicks on Year and selects Drill Down. the attribute Week appears in the drill-down list. Inc. Using the Hierarchy Viewer and Table Viewer Through the Hierarchy Viewer. • When you view the system hierarchy. you can see the actual relationships between attributes. You can see all of the entry points into a hierarchy at once. the hierarchy contributes to the drilling path of any attributes in it. For details on entry points. and also allows you direct access to the attributes that comprise it. When you view a user hierarchy. assume Week is a browsing attribute assigned to Year. You can use the Hierarchy Viewer to view either the system hierarchy or any of your user hierarchies. Using the Hierarchy Viewer The Hierarchy Viewer allows you to select the hierarchy you want to examine. but rather the structure of the user hierarchy as defined by a project designer. For instance. Additional information on drilling is available in the MicroStrategy Advanced Reporting Guide. It is used to view all of the tables in your project graphically. page 205.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 After a user hierarchy is enabled for drilling. 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. see Entry point. © 2007 MicroStrategy.

select Aerial perspective. 212 Using the Hierarchy Viewer and Table Viewer © 2007 MicroStrategy. page 205 for more details on creating entry points. select the hierarchy to view. Inc. from the Schema menu. .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. To access Aerial perspective mode in the Hierarchy Viewer 1 In the Hierarchy Viewer. Its decreased scale allows you to navigate through the entire project. you can define them as entry points. from the View menu. See Entry point. To view the system hierarchy in the Hierarchy Viewer 1 In MicroStrategy Desktop. When you access a hierarchy’s attributes directly. 2 Select Hierarchies. An aerial view of the hierarchy you are currently viewing is displayed. 2 Select Edit. page 205 for more details on creating entry points. from the Hierarchy menu. the Aerial perspective provides an overview of the hierarchies in your project. 2 Attributes that have a green check mark next to them are entry points. To view a user hierarchy in the Hierarchy Viewer 1 In the Hierarchy Viewer. select Graphical View. See Entry point. To edit an attribute from the Hierarchy Viewer 1 In the Hierarchy Viewer. The green squares indicate attributes that are entry points. In the Hierarchy Viewer. right-click the attribute to edit.

Inc. page 249 for information on updating logical table structures. To view more or less information about each table in the project 1 Open the Table Viewer. select Graphical View.Project Design Guide Creating Hierarchies to Organize and Browse Attributes 7 2 The hierarchy in the Hierarchy Viewer shifts according to where you navigate in the aerial view. from the Schema menu. select Options. 2 In the Table Viewer. See The size of tables in a project: Logical table size. They represent and indicate how Architect sees the tables that were brought into the project when it was created. 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. To view your project’s tables in the Table Viewer 1 In MicroStrategy Desktop. as described above. © 2007 MicroStrategy. you will need to update the logical table structure. If you make changes to the actual tables in the data warehouse. Using the Hierarchy Viewer and Table Viewer 213 . Click a section of the aerial view display to shift your view of a hierarchy to that particular section. The tables that are displayed here are logical tables. 2 Select Tables.

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. select or clear the options for any of the following. Inc.7 Creating Hierarchies to Organize and Browse Attributes Project Design Guide 3 From the Options menu. .

page 216—As you continue to enhance the design and functionality of your project. © 2007 MicroStrategy. 215 . you will need to make various schema changes. you are ready to start thinking about ways to better maintain the project and optimize it for both the short and long term. and explains how to use these methods to enhance your project. OPTIMIZING AND MAINTAINING YOUR PROJECT Introduction Once your MicroStrategy project is set up and populated with schema objects. and using partition mapping.8 8. To see any enhancements and changes to your project schema. This chapter introduces you to maintenance and optimization concepts such as tuning the interaction between your data warehouse and your project. you must update your project schema. Inc. You can find this information in the sections listed below: • Updating your MicroStrategy project schema. creating aggregate tables.

reduce input/output and other resource requirements. 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. Using summary tables to store data: Aggregate tables. attributes. page 218—As your data warehouse changes to meet new data logging requirements. Rather. table sizes. the project schema is not the same as the physical warehouse schema. transformations. hierarchies. Dividing tables to increase performance: Partition mapping. 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. You can do any of the following to update your project schema: 216 Updating your MicroStrategy project schema © 2007 MicroStrategy. your project must reflect these changes. 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. page 241—Aggregate tables store data at higher levels than the data was originally collected in the data warehouse. and so on—in your project come together to form your project’s schema. page 250—Partition mapping involves the division of large logical tables into smaller physical tables. and minimize the amount of data that must be aggregated and sorted at run time. Although the concepts are related. • • Updating your MicroStrategy project schema All of the schema objects—facts. the project schema refers to an internal map that MicroStrategy uses to keep track of attribute relationships.8 Optimizing and Maintaining Your Project Project Design Guide • Data warehouse and project interaction: Warehouse Catalog. fact levels. and so on within the project. Inc. This can include adding new tables to your project or removing tables that are no longer used. . These summary tables provide quicker access to frequently-used data.

or deleted a schema object. To manually update the schema 1 In MicroStrategy Desktop. © 2007 MicroStrategy. Updating your MicroStrategy project schema 217 . select Update Schema. if in server-connected (3-tier) mode. select or clear the following check boxes: • • Update schema logical information: Use this option if you added. • 3 Click Update. Inc. if in direct (2-tier) mode. 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. modified. Manually update the schema. Disconnect and reconnect to the project or the project source. Manually updating the schema allows you to determine which specific elements of the schema are updated. from the Schema menu.Project Design Guide Optimizing and Maintaining Your Project 8 • • • Stop and restart MicroStrategy Intelligence Server. 2 In the Schema Update dialog box. You can also update the schema with the last saved settings by clicking the Update Schema icon in the toolbar. Logical table sizes are a significant part of how the MicroStrategy SQL Engine determines the tables to use in a query. 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 project client object cache size: Use this option to update the object cache size for the project.

the structure of the SQL catalogs. This section also discusses customizing catalog SQL statements. page 219 Adding and removing tables for a project. and the default SQL statements used for each database. page 220 Managing warehouse and project tables. page 239 218 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. From this list. . page 233 Troubleshooting table and column messages. This section covers the following topics: • • • • • • • What should I know before I use the Warehouse Catalog?. page 219 Accessing the Warehouse Catalog. You can add warehouse tables to your project with the Warehouse Catalog or MicroStrategy Project Builder. adding tables in the project through Project Builder can become a cumbersome process. as later. you can select the tables to add to your project. The Warehouse Catalog is better for maintaining the warehouse tables used for an existing project. Inc. Adding tables through Project Builder is useful only when you are creating a project for the first time.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. Every project can have a unique set of warehouse tables. The Warehouse Catalog queries the data warehouse and lists the tables and columns that exist in it. page 226 Customizing catalog SQL statements. page 221 Modifying data warehouse connection and operation defaults.

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. Inc. point to Programs. For more information about privileges see the Permissions and Privileges appendix of the MicroStrategy System Administration Guide. You must use a login that has Architect privileges. refer to Appendix B. For more information on Query Builder. and Microsoft Analysis Services instead of a relational database. You can connect to OLAP cube sources such as SAP BW. then Desktop. In this case. and then select Desktop. the OLAP Cube Catalog handles tasks similar to the Warehouse Catalog. you need to be familiar with: • • Your schema. Data warehouse and project interaction: Warehouse Catalog 219 . • What should I know before I use the Warehouse Catalog? Before you begin using the Warehouse Catalog. © 2007 MicroStrategy. and expand your project. Hyperion Essbase. 2 Log in to the project source that contains your project in MicroStrategy Desktop. For more information. see the MicroStrategy Advanced Reporting Guide. Connecting to OLAP Cube Sources.Project Design Guide Optimizing and Maintaining Your Project 8 Note the following: • You can also add tables to a project using MicroStrategy Query Builder. then to MicroStrategy.

Log in to the project source that contains your project in MicroStrategy Desktop. as your project matures. Click >> to add all the listed tables. . 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. select the tables you want to add to the Warehouse Catalog. and click > to add the selected tables. and click > to add the selected tables. Inc. • 220 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. and expand your project. To remove tables—From the left side. select Warehouse Catalog. select the tables you want to add to the Warehouse Catalog. it may become necessary to add additional tables from the data warehouse to your project. Click >> to add all the listed tables. 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. you may need to remove tables from your project that are no longer used and are taking up space in the metadata. page 219. Adding and removing tables for a project As you become aware of the additional needs of report designers and users. Also. The Warehouse Catalog opens after it retrieves the table information from the warehouse database.8 Optimizing and Maintaining Your Project Project Design Guide 3 Select a project and then from the Schema menu. 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.

Tables being used in the project: Displays tables that have been selected to be part of the project. Data warehouse and project interaction: Warehouse Catalog 221 . Menu File • Save Saves the current settings and status of the Warehouse Catalog. The Warehouse Catalog has the following sections: • Tables available in the warehouse: Displays tables that are located in the warehouse. You can add tables to the project by double-clicking the tables or by selecting the tables and then clicking >. see Accessing the Warehouse Catalog. but have not been included in the project. You can remove tables from the project by double-clicking the tables or by selecting the tables and then clicking <. This process can take some time to complete. You can update it by selecting Read the Warehouse Catalog from the Actions menu. by selecting Update Schema. You can add or remove all the tables from one section to the other by clicking << and >> buttons. To access the Warehouse Catalog for a project. 4 Update the project schema from the Schema menu. click Save and Close to save your changes to the Warehouse Catalog. as well as those tables that are available in the warehouse but have not been included in the project. Warehouse Catalog has the following menu options. page 219. Inc. you need to periodically load the updates into the Warehouse Catalog. The table definitions are written to the metadata. Description • © 2007 MicroStrategy.Project Design Guide Optimizing and Maintaining Your Project 8 3 In the toolbar. Managing warehouse and project tables The Warehouse Catalog allows you to view tables that have been included in the project. As you make changes to the tables in the warehouse.

Calculates the number of rows in the selected tables. For more information. and so on. changing or assigning default table prefixes and structures. Displays MicroStrategy help options Some of these options are also available through toolbar buttons and through right-click menus for quick access. see Data warehouse connection and read operations. automatic mapping. page 227 of this appendix. Displays the list of tables referred to by the selected partition mapping table in the Table Partitions dialog box. Allows you to assign or update a database instance for the project. 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.8 Optimizing and Maintaining Your Project Project Design Guide Menu • Exit Tools • View Partitions Description Exits the Warehouse Catalog. Allows you to import the prefixes from the warehouse table name space. Displays the structure of a table selected in the Warehouse Catalog. . Viewing table structure To view the table structure of a table. • Table Structure • Calculate Table Row Count • Table Prefix • Table Database Instances • Import Prefix • Options Actions • Read the Warehouse Catalog Help Allows you to update and reflect the changes done to tables in the warehouse. Allows you to specify various settings for the Warehouse Catalog such as changing the database instance. Inc. This option is enabled when a partition mapping table is selected. Allows you to add or remove a table prefix for the selected table. row calculation.

The table structure of the selected table is displayed in the dialog box. You can also select Table Structure from the Tools menu. You can also click Update Structure to reflect any recent changes done to that table (see Updating table structure. Some examples of these type of changes are when you add. delete. When the data type of one or more columns is modified. To update the structure of a table 1 Access the Warehouse Catalog for your project (see Accessing the Warehouse Catalog. The warning message appears only if you have selected the Display a warning if the columns data types are modified when updating the table structure option in the Warehouse Catalog Options dialog box. Data warehouse and project interaction: Warehouse Catalog 223 . This option is selected by default. or rename a column in a table associated with a project. © 2007 MicroStrategy. Click Cancel to undo all data type changes. you get a warning message of this change. 2 In the Tables being used in the project list. Inc. 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. page 219). The Warehouse Catalog opens.Project Design Guide Optimizing and Maintaining Your Project 8 shortcut menu. right-click the table that has changed and select Update Structure. This action results in no changes being applied to any tables or columns. page 223). which provides the following options: • • Click OK to apply the change to this column in all the tables it appears. The dialog box displays the columns available in the selected table and the data type of each column.

If any of the object definitions have changed. you receive a message warning of this change. if you rename a column in a table. • 224 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. the warehouse structure gets updated completely with the Update Structure command. the table structure is only partially updated with the Update Structure command. – From the Schema menu. For example. • If no object definitions have changed. you have to manually update the facts that use this column. .8 Optimizing and Maintaining Your Project Project Design Guide If the data type of one or more columns is modified. – Select the fact expression and click Modify. you have to manually update the schema objects that depend on the outdated structure. – Click Save and Close to save the changes and close the Fact Editor. Inc. The procedure for manually updating the fact is as follows: – Right-click the fact and select Edit. Then. The Modify Fact Expression dialog box opens. The Fact Editor opens. – From the list of source tables select the source table from which the fact has been created. For example. this would apply if you rename a column in the table and the column is not being used in any fact expression. Edit the fact expression and click OK. 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. – Click Update. – Repeat the first to steps of this procedure to open the Warehouse Catalog and update the table structure. select Update Schema. The Schema Update dialog box opens. 3 Click Save and Close to close the Warehouse Catalog dialog box. You are returned to the Fact Editor.

you need to define two database instances. For example. In the Warehouse Catalog. This way. Viewing sample data To view sample data from a table. One of them is the primary database and the other is the secondary database. The default database instance for the project is set to be the primary database. click Reload table values. in your environment you might have a gateway between two databases such as an Oracle database and a DB2 database. You can also select Show Sample Data from the Tools menu. The primary database receives all SQL requests and passes them to the correct database. page 219) and choose Show Sample Data from the shortcut menu. right-click a table in the Warehouse Catalog (see Accessing the Warehouse Catalog. 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. © 2007 MicroStrategy. To refresh the table data. From the perspective of MicroStrategy products in this environment.Project Design Guide Optimizing and Maintaining Your Project 8 – Click Save and Close to save the changes and close the Warehouse Catalog dialog box. one for the primary database and another for the secondary database. MicroStrategy products know how to generate SQL for each table. you must set the secondary database instance for any tables that are found in the secondary database. Inc. Data warehouse and project interaction: Warehouse Catalog 225 . The first 100 rows of the table are returned as sample data in the Values dialog box.

. 5 Click OK to accept your changes and return to the Warehouse Catalog. row counts. Modifying data warehouse connection and operation defaults You can specify various settings for data warehouse connection and operation defaults using the Warehouse Catalog. row calculation. (in the pane on the right side) and select Table Database Instances. by choosing Options from the Tools menu (see Accessing the Warehouse Catalog. and so on. You cannot select the primary database instance as a secondary database instance. 4 Select one or more Secondary Database Instances. 3 In the Primary Database Instance drop-down list. The Warehouse Catalog Options dialog box opens. 6 From the toolbar. automatic mapping. 2 Right-click a table being used in the project. page 219 for steps to access the Warehouse Catalog). which allows you to perform the following tasks: • • • Data warehouse connection and read operations Displaying table prefixes. The settings are available from the Warehouse Catalog. and name spaces Mapping schema objects and calculating logical sizes for tables 226 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. select Save and Close to save your changes and close the Warehouse Catalog. Example settings include changing the database instance.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. The Available Database Instances dialog box opens. changing or assigning default table prefixes and structures. select the primary database instance for the table. page 219). The Warehouse Catalog opens. Inc.

Database Instance: You can select the database instance for the Warehouse Catalog from the drop-down list. 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. or if it does but needs to be modified. by © 2007 MicroStrategy. you can select from the following: – Click Edit to modify the selected database instance. You can make these type of modification from the Catalog category. – Click New to create a new database instance. • Read Settings: You can customize the SQL that reads the Warehouse Catalog for every platform except Microsoft Access. You could restrict the information returned. The General tab of the Database Instances dialog box opens. The default catalog SQL retrieves a DISTINCT list of tables and columns from all users.Project Design Guide Optimizing and Maintaining Your Project 8 Data warehouse connection and read operations You can modify the database instance and database login used to connect the data warehouse to a project. see the online help. If the desired database instance does not appear in the Database Instance box. Inc. The Database Instance Wizard opens. as well as change how the database catalog tables are read. Data warehouse and project interaction: Warehouse Catalog 227 . for example. When connected to a Microsoft Access data source. Custom Database Login: You can either select the database login or clear the login to use no database login. Refer to the MicroStrategy System Administration Guide for more information on either of these dialog boxes. the Settings option is disabled. For more information on the database login. 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.

For more information. The check for the data type change is only performed when updating a table’s structure. it may redefine the data type for a column included in the project. By default this option is selected when you open the Warehouse Catalog for the first time. . see Ignoring table name spaces when migrating tables. page 232 of this appendix. 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. This option is helpful when you want to identify fact tables and aggregation tables. do not select this option as it will have a negative effect on performance. Column Merging Options: When you add a new table to your data warehouse.8 Optimizing and Maintaining Your Project Project Design Guide specifying certain conditions and table owners (see Customizing catalog SQL statements. page 233). your project includes a table named Table1 that has 228 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. 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. Inc. 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. If performance is more important than obtaining the row count. For example. By default this option is selected. 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. 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.

the data type with the largest precision or scale is used. Data warehouse and project interaction: Warehouse Catalog 229 . – Use maximum denominator data type: This option updates the column data type to use the data type with the largest precision or scale. For example. the column data types are modified to maintain a consistent schema in one of three ways. a warning is displayed and you are asked if you want to use the new data type. Inc. depending on the option you select. In the example above. If the data type has been changed to a different compatible data type. the column data type for C1 would be changed to char(4) since Table2 was added after Table1. Then a new table named Table2 is added to the project. This is because char(4) has a higher precision than char(1) defined in Table1. © 2007 MicroStrategy. as defined in Table2. This example is used to illustrate the options described below. – Use most recent data type: This option updates the column data type to use the most recent column definition.Project Design Guide Optimizing and Maintaining Your Project 8 column C1 of data type char(1). When you update the table structure. The options below do not handle the merge if the data type has changed to an incompatible data type. the column data type for C1 would be changed to char(4). In the example above. If the data type has changed to an incompatible data type. but it has column C1 set to data type char(4). as illustrated in the image below. a column is changed from data type char to data type integer.

From the example above.8 Optimizing and Maintaining Your Project Project Design Guide – Do not merge: This option renames the column in the newly added table. by using the View category. 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. including new tables added to the project. column C1 uses the char(1) data type for Table1. Displaying table prefixes. You have the following options: Display table prefixes in the main dialog: Select this option to display all prefixes in table names. Column C1 in Table2 is defined as a separate copy of C1 and uses the char(4) data type. 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. • Read Mode: The Warehouse Catalog can be automatically read upon opening the Warehouse Catalog. 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. row counts. and name spaces You can choose to show or hide table prefixes. This option can cause unwanted schema changes and should be used only when necessary. and name spaces. By default this option is selected. the Warehouse Catalog reads the 230 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. row counts. Inc. which allows the columns to have different data types. .

– Modify prefix list: You can create a new tables prefix or delete an existing prefix by selecting this option. see the online help. this option is selected and table name spaces are shown. Data warehouse and project interaction: Warehouse Catalog 231 .Project Design Guide Optimizing and Maintaining Your Project 8 name space for each table being added. • Table Name Spaces: You can show or hide the name space for each table. you can determine whether existing schema objects in the project are mapped to these new tables automatically. creates a prefix having the same text as the name space. 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. this option is selected and the number of rows are shown. The Table Prefixes dialog box opens. Inc. 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. 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. using the following options: © 2007 MicroStrategy. By default. By default. 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. For more information on modifying the prefix list. Mapping schema objects and calculating logical sizes for tables The Schema category is divided into the following subcategories: • Automatic Mapping: When you add new tables to the Warehouse Catalog. • Table Row Counts: You can show or hide the number of rows per table. This option is only active when the database supports prefixes.

the Warehouse Catalog automatic mapping settings do not determine whether the attribute and table are automatically mapped. Do not map schema objects to the new tables: Objects in the schema are not automatically mapped to tables you add to the project. you change the project to point to the primary warehouse. Automatically mapping tables to schema objects when adding attributes or facts to a project is controlled by the Attribute Editor and Fact Editor. For example. With the Map schema objects to new tables automatically option selected. If the table was added to the Warehouse Catalog first and then the attribute was created. . Before going into production.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. These automatic mapping methods are only applied to existing schema objects when tables are added to the Warehouse Catalog. the Year attribute is automatically mapped when the new table is added. 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. Then a new table which includes a YEAR_ID column is added to the Warehouse Catalog. Do not calculate table logical sizes: Logical sizes are not calculated for the tables you add to the project. Inc. 232 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. the attribute Year with an attribute form mapped to YEAR_ID is included in a project. • 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. respectively.

Inc. select the Ignore current table name space when reading from the database catalog and update using new table name space check box. the Warehouse Catalog recognizes the two tables as the same table and saves the new table name space information. the Warehouse Catalog defaults to identifying the table by both table name space and table name. 233 © 2007 MicroStrategy.LU_STORE. you can have LU_STORE in a table name space called dbo and another table LU_STORE in another table name space called admin.Project Design Guide Optimizing and Maintaining Your Project 8 Most database management systems (Oracle. This setting allows you to migrate much more easily between warehouses. This method allows you to repeat the same table name in different table name spaces. Thus. Customizing catalog SQL statements In all supported warehouse platforms other than Microsoft Access. If the check box is cleared. For instance. the Warehouse Catalog saves information to the appropriate table name space. If you select this option. Data warehouse and project interaction: Warehouse Catalog . which is a way of organizing database tables into different storage spaces. 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. and the table is actually stored as admin. To solve this problem.LU_STORE in the new production warehouse. and their data types.Read Settings options subcategory. When you add tables to a project. The table name space provides an extra piece of information that uniquely identifies the table. the Warehouse Catalog ignores the current table name space when it reads the catalog information.LU_STORE. MicroStrategy uses SQL statements to query the relational database management system (RDBMS) catalog tables to obtain warehouse catalog information. columns. You now have two tables dbo. This information includes catalog tables. and others) support the concept of a table name space. The Warehouse Catalog interprets the table as already in the project and not found in the new warehouse.LU_STORE and admin. This is because the Warehouse Catalog is looking for a table named dbo. You can find this option in the Warehouse Catalog Options dialog box under the Catalog . DB2.

which increases processing speed. In the following sections. the first SQL used in a two-pass catalog retrieval. This is the recommended option for interactive warehouse catalog building because no unnecessary catalog information is read from the database. . a similar ODBC call is used for the Generic DBMS database type. 234 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy. One-pass SQL mode. The name Full Catalog SQL refers to the SQL used to read all the tables and columns in one pass. so an ODBC call must be used to retrieve information about tables and columns in Access. By default. Microsoft Access does not have catalog tables. The structure of individual tables is read only when the table is selected. but you can choose to use custom catalog SQL for the generic type if you wish. This option is recommended only if the catalog SQL is well customized to limit the amount of data returned by it. that is. on the other hand. In two-pass SQL mode. reads all the tables and columns in one SQL statement. the name Catalog Table SQL refers to the catalog SQL to retrieve the tables in the warehouse. The MicroStrategy Warehouse Catalog can be configured to read the catalog information in one. Inc.or two-pass SQL mode. but both can be customized in the Warehouse Catalog Options dialog box.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. The two retrieval options use different catalog SQL. it first reads only the tables from the database.

Depending on the type of RDBMS. Data warehouse and project interaction: Warehouse Catalog 235 . a name space gives each table a unique name. page 235 SQL placeholder strings and incomplete catalog SQL. the owner of the table. page 236 Modifying catalog SQL. page 238 The table name space In a typical RDBMS platform. page 237 Default catalog SQL. These placeholders are: • #LOGIN_NAME#—This placeholder is automatically replaced at run time with the login name used to connect to the database.Project Design Guide Optimizing and Maintaining Your Project 8 To customize a catalog SQL. In both the Catalog Table SQL and Full Catalog SQL. this name space can be the name of the database. A table name space is a partition of the database installation in which table names are unique. a table name does not uniquely identify it in a particular database installation. page 236 Structure of Full Catalog SQL. you must understand several important concepts and procedures: • • • • • • The table name space. or a combination of both database and owner. You can leave this template in the customized SQL if you want the catalog SQL to yield © 2007 MicroStrategy. A customized catalog SQL can omit the name space if duplicate table names do not present a problem in the warehouse database. This helps you to avoid confusing tables that share the same table name. The table name space is optional. 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. page 235 Structure of Catalog Table SQL. Inc.

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. used with Teradata.0: SELECT DISTINCT OWNER NAME_SPACE. The column that identifies the table name space uses the SQL column alias NAME_SPACE. If a name space is not provided. • #?Database_Name?#. one identifying the name space of the table and the other the name of the table. used with DB2 AS/400. #?Schema_Name?#—This catalog SQL placeholder is an incomplete SQL string that must be completed by the user before it can be executed. Each row of the SQL result must uniquely identify a table. Structure of Catalog Table SQL Catalog Table SQL is expected to return two columns. 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.8 Optimizing and Maintaining Your Project Project Design Guide different results depending on the warehouse login used. The command #?Database_Name?#. The string starts with #? and ends with ?#. . #?Schema_Name?#. Otherwise. only the table name column is required. this template is replaced with the name of the database user who owns the warehouse tables of interest. must be replaced with the name of the schema in which the database tables reside. Duplicates are not allowed. Inc. must be replaced with the name of the database containing the database tables. The column that identifies the table name has the alias TAB_NAME. The following example is the default Catalog Table SQL for Oracle 8. depending on the RDBMS platform and the customization.

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. Inc.name TAB_NAME. and then by TAB_NAME. C. C.prec DATA_PREC. C.uid ORDER BY 1. The catalog SQL can be modified in the Warehouse Catalog options for your project. if available. T.id = C.name NAME_SPACE.type DATA_TYPE. C.id and T. 'V') AND T.name COL_NAME. © 2007 MicroStrategy. syscolumns C.type in ('U'.length DATA_LEN. Data warehouse and project interaction: Warehouse Catalog 237 . The Warehouse Catalog opens.scale DATA_SCALE FROM sysobjects T. C. sysusers WHERE T. page 219).uid = U. To modify the catalog SQL for your project 1 Access the Warehouse Catalog for your project (see Accessing the Warehouse Catalog. 2 Modifying catalog SQL You can customize and modify the catalog SQL that is run against your database for each project.0: SELECT U. The following example is the default Full Catalog SQL for Microsoft SQL Server 7.

3 Expand the Catalog Category. 4 Click the Settings button. The Catalog . Default catalog SQL When customizing the catalog SQL that is executed on your database. the catalog SQL options are displayed as shown below.8 Optimizing and Maintaining Your Project Project Design Guide 2 From the Tools menu. The Warehouse Catalog Options dialog box opens. select Options. Inc. and select Read Settings. .Read Settings options are displayed. The catalog SQL settings are unavailable if your 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. 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.

which retrieves column information for the selected tables.Project Design Guide Optimizing and Maintaining Your Project 8 platforms. To generate and view the default Full Catalog SQL for your database platform. page 237). To generate and view the default catalog SQL 1 Access the catalog SQL options for your project (see Modifying catalog SQL. click the upper-most Use Default button. You can generate the default catalog SQL in MicroStrategy for the database platform your project connects to. which retrieves a list of available tables in the Warehouse Catalog. This allows you to save any modifications you have made previously to the catalog SQL statements. • The top pane controls the Catalog Table SQL. click the bottom-most Use Default button. Inc. Before performing the next step. and then compare them to the default statements you are about to generate. Troubleshooting table and column messages You may encounter the following messages while using the Warehouse Catalog: © 2007 MicroStrategy. The bottom pane controls the Full Catalog SQL. 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. cut and paste the SQL statements in the two panes into any text editor. Data warehouse and project interaction: Warehouse Catalog 239 . 2 Generate and view the default catalog SQL for your database platform. • • You can use the default catalog SQL statements or compare and combine them with your own customized catalog SQL statements. A dialog box for the catalog SQL options is displayed.

no changes occur and the original table structure remains intact. In this case. Remove the table from the project. 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. 240 Data warehouse and project interaction: Warehouse Catalog © 2007 MicroStrategy.8 Optimizing and Maintaining Your Project Project Design Guide • • • Tables missing Columns data type changed Columns missing Tables missing This happens when one or more tables already in the project are removed from the data warehouse. you get a warning message showing the table name. However the definition in the project may be inconsistent with the real physical structure in the warehouse. • When the Warehouse Catalog tries to update the structure of a table that is missing in the 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. and you have the option to proceed or cancel the operation. . they are presented to you. the Warehouse Catalog does not check for any dependencies until you save the changes. If there are any dependencies. Columns data type changed When the table structure is updated for one or more tables in which the column data types have been changed. This can result in SQL errors when running reports that need data from a “missing” table. Inc. column name. 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.

which are mapped to the missing column and the update structure operation is canceled. then a message is displayed that gives details on objects. This section describes how and why aggregate tables are used. Using summary tables to store data: Aggregate tables 241 . while retaining the traditional power of ROLAP to directly query the database to answer any questions. To understand aggregate tables. You are asked to remove the mapping before continuing with the update structure and original table structure is restored.Project Design Guide Optimizing and Maintaining Your Project 8 original data type. then no error message is shown. and Chapter 5. MicroStrategy creates aggregates only on fact tables since lookup tables and relationship tables are usually significantly smaller. 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. the Warehouse Catalog checks for the following: • • Column is not mapped to any schema object: If this is the case. © 2007 MicroStrategy. The Building Blocks of Business Data: Facts. Inc. Chapter 3. Aggregate tables provide quicker access to frequently requested information. If this happens. see Chapter 2. Warehouse Structure for Your Logical Data Model. The Logical Data Model. Columns missing Missing columns are detected when Update Structure is performed. This results in no changes being applied to the tables and columns. For more information on these topics. you should be familiar with fact tables in the context of data modeling and data warehousing. and new data type. You can click Cancel at any time to undo all data type changes. Column is mapped to a schema object: If this is the case.

. 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. CPU. RAM. Multidimensional OLAP (MOLAP) is sometimes considered by some to be the answer to this problem. 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. in combination with aggregate tables and caching. The disadvantage to this relational OLAP (ROLAP) methodology is that accessing huge fact tables can be potentially time-consuming. the MicroStrategy SQL Engine. However. 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. Aggregate tables are advantageous because they • • • • • Reduce input/output. Inc.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. can produce results at about the same speed as MOLAP. 242 Using summary tables to store data: Aggregate tables © 2007 MicroStrategy. This combined solution allows questions to be answered on the fly and is also scalable for large databases.

the rolling up of data. an aggregate table with the sales data rolled up to the month level is useful. Inc. The daily values from the fact table are selected. as shown below. sorted. If sales data is frequently requested at the month level. aggregation. and added to produce the monthly totals. Using summary tables to store data: Aggregate tables 243 . must occur. that is. Aggregation can also be completed before reports are executed. For example. © 2007 MicroStrategy. You can build these pre-aggregated—or aggregate—tables as part of the ETL process. sales data is stored by day in a fact table. By default.Project Design Guide Optimizing and Maintaining Your Project 8 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 occurs dynamically with a SQL statement at report run-time. A report requesting month-level data is executed. the results of the aggregation are stored in an aggregate table. as in the previous example. This process is called pre-aggregation.

This ensures that all possible 244 Using summary tables to store data: Aggregate tables © 2007 MicroStrategy. Inc. That is. and calculation of data from many database rows in a large. sorting. as shown in the following example. . it requires a completely aggregated schema to answer most questions. every possible combination of aggregate associations must be generated when the multidimensional cube is built. 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. an aggregate table is any fact table whose data is derived by aggregating data from an existing base table. lower-level fact table at run time.8 Optimizing and Maintaining Your Project Project Design Guide Pre-aggregation eliminates the reading. Degree of aggregation While MOLAP can provide fast performance when it answers a question. In these terms.

This scenario becomes very difficult to maintain as the number of attributes and the amount of data increase.Project Design Guide Optimizing and Maintaining Your Project 8 questions can be answered. 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. In a ROLAP environment. ROLAP. its presence provides a response as fast as a MOLAP system can provide. and therefore is not very scalable. A densely aggregated warehouse has a large number of aggregate tables while a sparsely aggregated warehouse has fewer. page 247 • © 2007 MicroStrategy. Sparse aggregation refers to the fact that a given project only requires as many aggregate fact tables as is useful to its users. if a certain aggregate combination is rarely or never used. However. page 246 The compression ratio—Compression ratio. Not every attribute level or hierarchy intersection is suitable for pre-aggregation. Build aggregate tables only if they can benefit users. Inc. Also. Only the aggregate combinations that you determine are beneficial must be created. That is. do not waste database space for tables that will not be used. page 246 The relationship between the parent and child—Considering any related parent-child relationships. since the creation and maintenance of aggregate tables requires additional work by the database administrator. provides much greater flexibility than MOLAP. Consider the following factors when deciding whether to create aggregate tables: • • The frequency of queries at that level—Determining the frequency of queries at a specific level. therefore. if the aggregate table is useful in answering frequently-asked queries. Using summary tables to store data: Aggregate tables 245 . the degree of aggregation can be as dense or as sparse as is appropriate for your users.

all 246 Using summary tables to store data: Aggregate tables © 2007 MicroStrategy. as well as the database backup routines. the query must use item-level data and summarize the department data dynamically. trace the usage of any aggregate tables to determine how frequently they are used in a day-to-day business environment. and loading process. translation. . eliminate it from the warehouse. when the parent-child relationship is altered. if users frequently want to exclude inactive items. based on the key combinations in a relationship table. Considering any related parent-child relationships When an aggregate table is created. usefulness is not always easy to quantify. Therefore. they consume disk space and impose unnecessary burdens on the extraction. However. If any table is not used. However.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. MicroStrategy Enterprise Manager allows you to easily track table usage. For more information on Enterprise Manager. see the MicroStrategy System Administration Guide. Inc. the department aggregate tables would not be used in this situation. Once your warehouse is in production. If aggregate tables are never accessed. In any hierarchical relationship. For example. the child records are usually summarized into the parent record. consider the following hierarchy: A summary of data at the department level seems to be a good candidate for an aggregate table.

Using summary tables to store data: Aggregate tables 247 . Compression ratio The process of data aggregation applies an aggregate function. a store can decide to reclassify the department to which items belong. In these cases. and the impact on the batch process. If the tables are large. Inc. to a set of child records to produce a single parent record. a table contains one value for the sum of all stores. and then balance the disadvantages against the advantages of having an aggregate table. The average number of child records combined to calculate one parent record is called the © 2007 MicroStrategy. such as sum or average. and complicate the batch process. rolling up an entire hierarchy can avoid many problems with relationship changes. For example. For example. or the addition. they are a part of static relationships. time hierarchies are seldom dynamic—days do not migrate into different weeks.Project Design Guide Optimizing and Maintaining Your Project 8 tables that hold that relationship or data relevant to it must be updated. or discontinuation of items or services. reclassification. Also. Static relationships When elements rarely or never change relationships. and fiscal weeks do not move into different months. Aggregate tables that contain dynamic relationships must be recalculated every time a change is made. this process can take time. Consider the frequency of the changes. the relationship is called dynamic. For example. Frequent changes can mean aggregate tables are not optimal for this situation. consume resources. Dynamic relationships When the relationship between parent and child elements change. These changes often occur because of organizational restructuring. the table size. Whether these relationships are dynamic or static change how they are aggregated into tables. It is not affected by a reorganization within the geography hierarchy. maintaining aggregate tables is very easy. geographical realignment.

the compression ratio suggests that an aggregate table can provide more efficient queries. 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.8 Optimizing and Maintaining Your Project Project Design Guide compression ratio. the aggregate table reduces the number of records by 3/4 and uses only 1/4 of the storage space. if the compression ratio is 3:2. pre-aggregating data is effective only if the compression ratio is significant. since it represents the decrease in records that must be read to respond to a query at that level. page 35. Creating aggregate tables You can integrate aggregate tables in your project using the Warehouse Catalog in MicroStrategy Desktop. . One measure of effectiveness of an aggregate table can be estimated from this number. Inc. For example. For more information on ratios. refer to Cardinalities and ratios. Also. if the compression ratio is 4:1. the resource demands placed on the database server by dynamic aggregations decrease and therefore so does the effectiveness of pre-aggregation. 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. you must balance the importance of speed of query response time and the availability of disk space and resources to maintain the schema. for smaller base tables. 248 Using summary tables to store data: Aggregate tables © 2007 MicroStrategy. To determine when pre-aggregation is worthwhile for your system. as outlined in the following procedure. In contrast. Therefore. When the number of elements differs significantly between two attributes in the same hierarchy.

Because Desktop uses the conceptual or logical attribute definitions when assigning sizes. Using summary tables to store data: Aggregate tables 249 .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. this measurement is known as the logical table size. that contains enough data to answer the query. Because the attribute levels are lower in the base fact © 2007 MicroStrategy. Inc. In other words. When you run a report. Suppose the base fact table contains millions of rows of transaction-level detail. Architect is aggregate-aware. The other tables. when either could provide the answer to a query? The answer is logical table size. These size assignments are stored in the metadata and are calculated based on the table columns and their corresponding attributes. see Adding and removing tables for a project. Architect automatically adds it to the definitions of your existing attributes and facts. For steps to add tables using the Warehouse Catalog. the Analytical Engine chooses the smallest of all tables. If your aggregate table structure is consistent with your base fact table structure. 2 Use the new table in the desired fact expressions and attribute form expressions. How does Architect know to use the aggregate table rather than the base fact table. based on logical table size. however. have only higher-level or summary data. 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. 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. page 220.

Dividing tables to increase performance: Partition mapping Partition mapping involves the division of large logical tables into smaller physical tables. By distributing usage across multiple tables. partitions improve the speed and efficiency of database queries. Logical tables are discussed in detail in Appendix C. Partitioning by time limits growth of the database tables and increases stability. the Logical Table Editor allows you to alter the logical table sizes based on their true relative sizes. Either way. such as month or department. Of course. the table as a whole is assigned a higher value for the logical table size than are the summary tables with higher-level attributes. 250 Dividing tables to increase performance: Partition mapping © 2007 MicroStrategy. Inc. not where the tables are split. The terms “application” and “server” refer to what manages the partitioned tables. Server versus application partitioning Partitioning can be managed by either the database server or the MicroStrategy application. Logically.8 Optimizing and Maintaining Your Project Project Design Guide table. a table with a higher-level attribute should be smaller in size. For steps to use the Logical Table Editor. . this is not always true in a real warehouse. tables are partitioned at the database level. Time is the most common category for partitioning databases. Logical Tables. see the MicroStrategy Desktop online help. Therefore. 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. this division is based on a definable data level.

Application-level partitioning In application-level partitioning the application. manages the partition tables. Inc. This approach makes it easier for you to specify a flexible partitioning schema. such as time or geography. rather than the RDBMS server. Instead. The original fact table is not physically broken into smaller tables. In contrast. page 251—stores the mapping information in the project metadata Warehouse partition mapping. manages the partitioned tables in RDBMS server-level partitioning. the partitioning is transparent to MicroStrategy. MicroStrategy. in application-level partitioning the relational database is unaware of the partitioned tables. Partition tables are usually divided along logical lines. rather than MicroStrategy. Dividing tables to increase performance: Partition mapping . MicroStrategy supports two types of partitioning: • • Metadata partition mapping. Since only the logical table is displayed to the end user. 251 © 2007 MicroStrategy. the database server logically partitions the table according to parameters specified by the database administrator. Refer to your database documentation for details on server partitioning for your particular platform. 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.Project Design Guide Optimizing and Maintaining Your Project 8 Server-level partitioning The database server. in this case. MicroStrategy manages the mapping between the logical table and the physical tables. You do not need to take any action in MicroStrategy to support the partitioning. A partition base table (PBT) is a warehouse table that contains one part of a larger set of data.

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

Optimizing and Maintaining Your Project

8

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. When using warehouse partition mapping, it is usually 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

Creating Transformations to Define Time-Based and Other Comparisons

9

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. A table-based transformation is required when a many-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.

Creating the transformation metric and the report are discussed in the Transformation metrics section in the Metrics chapter of the MicroStrategy Advanced Reporting Guide.

260 Creating transformations

© 2007 MicroStrategy, Inc.

For example. Creating transformations 261 . 5 Double-click the PREV_YEAR_ID column to place it in the expression box. 2004. 2 From the File menu. which maps this year to last year. The Year_ID is in the format YYYY. Name the transformation Last Year (Table). 4 Select the LU_Year table from the Table drop-down list. A report designer can now use the transformation in a revenue metric to calculate last year’s revenue. The Transformation Editor opens with the Select a Member Attribute dialog box displayed. Notice that this table contains a previous year column. one subtracted from the year 2005 results in the previous year.Project Design Guide Creating Transformations to Define Time-Based and Other Comparisons 9 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.Define a new member attribute expression dialog box opens. point to New. The table's columns appear in the Available columns list. The Year . then create a report using that transformation metric to obtain last year’s revenue. 3 Double-click Time to open the folder. 7 Click Save and Close on the toolbar. 6 Click OK. © 2007 MicroStrategy. and select Transformation. then double-click Year. Inc. You have now created the transformation. so the previous year is simply Year_ID minus one. Building an expression-based transformation This example shows how to create a last year transformation using an expression rather than a table.

Define a new member attribute expression dialog box opens. The Year . Again. and select Transformation. To create a last year transformation based on an expression 1 In MicroStrategy Desktop. Inc. 262 Creating transformations © 2007 MicroStrategy. then double-click Year. 3 Select the LU_Year table from the Table drop-down list. 4 Double-click the YEAR_ID column to place it in the expression box. The transformation will subtract 1 from the Year ID to calculate last year’s ID. . point to New. The Transformation Editor opens with the Select a Member Attribute dialog box displayed.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. 2 Double-click Time to open the folder. 5 Type -1 in the expression box. creating the transformation metric and the report are discussed in the Transformation metrics section in the Metrics chapter of the MicroStrategy Advanced Reporting Guide. The table's columns appear in the Available columns list. The resulting report is displayed below. from the File menu.

7 Click OK. in the Last Year transformation. For a table-based transformation. Quarter. each member expression is based on a specific table. this is the transformation table defining the relationship. and Day. For example. • Member expressions: Each member attribute has a corresponding expression.Project Design Guide Creating Transformations to Define Time-Based and Other Comparisons 9 6 Click Validate. • Member tables: These tables store the data for the member attributes. the member tables are LU_YEAR. Transformation components 263 . respectively. Name the transformation Last Year (Expression). Quarter. then add it to the report created in the previous example. For an expression-based transformation. You have now created the last year transformation. the different levels to which the rule applies. in the Last Year transformation in the MicroStrategy Tutorial. for the member attributes Year. and Day. and LU_DAY. The message “Valid expression” appears with a green check mark. © 2007 MicroStrategy. Month. Transformation components All transformations have the following components: • Member attributes: This component contains the attributes to which the transformation applies. that is. For example. LU_QUARTER. the member attributes are Year. A report designer can now use the transformation in a revenue metric to calculate last year’s revenue. Inc. generally the lookup table corresponding to the attribute being transformed. LU_MONTH. Month. 8 Click Save and Close on the toolbar.

mathematical functions.” One day or month this year maps exactly to one day or month from last year. However. consider YearToDate defined as a many-to-many transformation and Revenue (YTD) as a transformation metric. this is simply a column from a specific warehouse table specifically populated with data supporting the transformation. In fact. For one date. For a table-based transformation. if you store Month as 200001 (January 2000). in the case of a many-to-many transformation. Many-to-many transformations can lead to double-counting scenarios. many other dates are included in the year-to-date calculation. and columns from the warehouse. For instance. many cases can exist where the data is not conducive to such calculation. • Mapping type: This component determines how the transformation is created based on the nature of the data. LY_MONTH_ID. For example. These are all columns from the lookup tables set in the Member tables field. For example. the member expressions are LY_DAY_DATE. LY_QUARTER_ID. typically the attribute ID column. Suppose this metric is used on 264 Transformation components © 2007 MicroStrategy. Many-to-many: A typical many-to-many relationship is year-to-date. and PREV_YEAR_ID. . this is a mathematical expression. It is particularly effective when no straightforward formula can express the rule. a separate table is required. The rule is then not encapsulated in an expression but directly in the data of the column. you cannot subtract one and receive December 1999 as the result. this approach provides considerable flexibility in the transformation definition. in the Last Year transformation.9 Creating Transformations to Define Time-Based and Other Comparisons Project Design Guide For an expression-based transformation. In the most generic case. The mapping can be one of the following: One-to-one: A typical one-to-one relationship is “last year to this year. Since the data defines the rule. For example. this expression uses constants. arithmetic operators. you can create a Last Year transformation using Year_ID-1 as the expression. Inc.

page 171 before proceeding in this section. as shown below: When a joint child attribute—an attribute that exists at the intersection of other indirectly related attributes—is added. a range of dates is specified in the filter. Each quarter is displayed. page 171. which is the member attribute on the template. The joint child attribute cannot be transformed because not all of its joint children—Quarter and Item—are time-related. For more information about joint child attributes. In this instance. For example. with the previous year’s revenue. Inc. Transformation metrics and joint child attributes 265 . For example. see Joint child relationships. the Revenue (YTD) metric will double count. the © 2007 MicroStrategy. In the report. the joint child attribute Promotion is added to the previous report. the values for the transformation. a report contains Quarter and the transformation metric Last Year’s Revenue. In a report. Transformation metrics and joint child attributes Review the discussion of joint child attributes and relationships in Joint child relationships. that is.Project Design Guide Creating Transformations to Define Time-Based and Other Comparisons 9 a report that does not include the Day attribute. a transformation metric displays the current attribute with transformed data. The report displays the quarter. a conflict arises.

and the revenue data from the date-promotion combination. again. not the attributes. the Valentine’s Day-Q1 2002 combination cannot be displayed on the report.9 Creating Transformations to Define Time-Based and Other Comparisons Project Design Guide promotion associated with a given quarter. . That is. 266 Transformation metrics and joint child attributes © 2007 MicroStrategy. it is not intuitive how the transformation should be performed. displaying transformed data. Notice that the Valentine’s Day promotion existed in 2003 but not in 2002. the Valentine’s Day promotion is not listed for Q1 2002 despite the existence of the last year transformation. In summary. While you may want to see it listed for 2002. remember that only the metric values are transformed. However. but not attributes such as Promotion. This is the case because. since the Valentine’s Day promotion was not run in 2002. Inc. A sample report is shown below: The displayed attributes should still be current. since the joint child attribute Promotion essentially exists in both the time dimension and a non-time dimension. transformations “transform” metric values such as Revenue. minus one year.

and user community. What is the MicroStrategy Tutorial? 267 . and a set of demonstration applications designed to illustrate the features of the MicroStrategy platform. Inc. the project is the environment in which all related reporting is done. which includes a metadata and warehouse. You create projects that users access to run reports.A A. A project is the highest-level of intersection of a data warehouse. filters. MICROSTRATEGY TUTORIAL Introduction This appendix provides information on the MicroStrategy Tutorial. What is the MicroStrategy Tutorial? The MicroStrategy Tutorial is a MicroStrategy project. metadata repository. including the data model and physical warehouse schema. © 2007 MicroStrategy. A typical project contains reports. and functions. metrics. Conceptually.

Human Resources Analysis. • Enterprise Reporting Documents: This folder contains various examples of different types of standard enterprise reporting documents. For instance. Each hierarchy can be viewed graphically through MicroStrategy Desktop and MicroStrategy Web. Reporting areas: Customer Analysis. production and operational reports. Category Managers. Regional Sales Managers. invoices and statements. Options to create reports from MicroStrategy Desktop and MicroStrategy Web focusing on a particular analysis area. Brand Managers. Inc. such as scorecards and dashboards. Numerous customers and purchased items. and business reports. and Suppliers. or Call Center. Each subfolder contains reports that would be of interest to the type of business user for which the subfolder is named. and Time. managed metrics reports. The Supplier folder contains a Supplier Sales report. © 2007 MicroStrategy. the Billing Managers folder contains an Invoice report and a customer-level transaction detail report. They are a sampling of the types of reporting documents that can be built using MicroStrategy Report Services. Inventory and Supply Chain Analysis. Inventory. Enterprise Performance Management. Products. 268 What is the MicroStrategy Tutorial? . Category. • • • 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. Promotions. Sales and Profitability Analysis. Operations Managers. such as Customer. Time. Products. including Billing Managers. Geography. Company Executives. The key features include the following: • Hierarchies—Customer. and the Brand Managers subfolder contains a report called Brand Performance by Region.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. Employee. District Sales Managers. books. and Supplier Analysis. movies and music.

Project Design Guide

MicroStrategy Tutorial

A

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.

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

© 2007 MicroStrategy, Inc.

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

MicroStrategy Tutorial

A

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 entry point Definition 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. 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.

one-to-many relationship

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

MicroStrategy Tutorial

A

The Geography hierarchy contains the following attributes.
Attribute Country Region Call Center Distribution Center Manager Employee Experience Hire Date Salary Employee Age Employee Birth Date Employee Description Countries where the company does or hopes to do business in the future. Also refers to countries where employees work. Each country is split into regions. Where product phone-in orders are taken. Each call center is located in a different city. The location where product orders are sent out to customers. Currently, each is located in the same city as the call center it services. Person responsible for a specific call center. The number of years an employee has worked for the organization. The date on which a particular employee was hired. The amount of money an employee makes per year. The age of each employee. The date each employee was born. The lowest level in the Geography hierarchy, representing the individual responsible for each order placed. Example USA, Spain, France. Central, Northeast, Southwest. Atlanta, Boston, Charleston. Miami, New Orleans, Fargo. Peter Rose, Alice Cooper. 3, 5, 6. 2/16/97, 3/15/99. 24,000, 35,000. 29, 36, 52. 5/6/66, 1/1/77. 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 Category Subcategory Description Products are organized into categories at the highest level. Used to further differentiate a subset of products within a category. Example Electronics, Music. Business, Cameras, Drama.

274 MicroStrategy Tutorial data model

© 2007 MicroStrategy, Inc.

Project Design Guide

MicroStrategy Tutorial

A

Attribute Warranty Brand Catalog Supplier Discontinued Code Item

Description The time period in months during which a manufacturer repairs a broken item (specific to Narrowcast Server). The manufacturer or artist for a particular product. The medium used to sell products. The distributor for a set of brands. 0 = discontinued product, 1 = non-discontinued product. The individual product sold.

Example 3, 5. Ayn Rand, 3Com, Sony. Spring 2002, Fall 2003. McGraw Hill, Disney Studios. 0, 1 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 Customer Country Customer Region Customer State Customer City Customer Age Customer Birth Date Income Bracket Zip Code Customer Shipper Rush Order Description The highest level of differentiation for where Customers live The highest level of differentiation for where customers live. Each Customer Region is divided into multiple States. Each Customer State is broken down into cities. The age of a particular customer at a current point in time. The date on which the Customer was born. The salary range reported by the customer. The lowest level of differentiation for where customers live. The name of the individual customer. The vendor used to send products to the customer. (Currently not implemented in the project.) Indicates whether a customer chose to expedite delivery of an order. The way a customer pays for an order. The date on which an order is shipped from the distribution center. The tracking number associated with a particular group of items purchased. Amex, Check. 9/15/02, 3/26/03. 167, 2635. Example USA, Spain, France Northeast, South, France. Maine, North Dakota. Albany, Chicago, Memphis. 26, 38, 59. 8/4/50, 4/30/72. $31,000 - 40,000, $61,000 70,000. 07026, 36303. Selene Allen, Chad Laurie. Pronto Packages, MailFast.

Payment Method Ship Date Order

276 MicroStrategy Tutorial data model

© 2007 MicroStrategy, Inc.

Project Design Guide

MicroStrategy Tutorial

A

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

12/26/03. Q2 02. Attribute Year Quarter Month of Year Month Day Description Calendar year of purchase. Refer to the following image to see how all these attributes are organized into the MicroStrategy Tutorial Time hierarchy. Calendar month of purchase. Calendar quarter of purchase. . Jul 02. 2003. January. 278 MicroStrategy Tutorial data model © 2007 MicroStrategy. Month of purchase. 5/14/02. Aug 03. Inc.A MicroStrategy Tutorial Project Design Guide The Time hierarchy contains the following attributes. November. This hierarchy is useful for recording whether a sale was a promotional purchase. Example 2002. Q3 03. Calendar date of purchase. Promotions hierarchy The Promotions hierarchy contains Promotion and Promotion Type.

Example Mother’s Day. Viewing the MicroStrategy Tutorial data model Although the MicroStrategy Tutorial data model is displayed in the previous pages. © 2007 MicroStrategy. You must log on as an Administrator. you can also view it directly in the product. 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. Labor Day. 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.) Type of discount period offered (Sale type). 9/1/02 .Project Design Guide MicroStrategy Tutorial A The Promotions hierarchy contains the following attributes. Attribute Promotion Type Promotion Description (Currently not implemented in the project.) Date range for a particular discount period under which an item is purchased (Sales Date). Specify the user name as Administrator and provide a blank password to complete these steps. MicroStrategy Tutorial data model 279 .9/4/02. (Currently not implemented in the project. Inc.

and relationships of data in a business. After the data model is created. point to Graphical View. or conceptual environment. the next step is to create the schema. Inc. 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. but allows you to view the hierarchy in a way meaningful to you. 5 To view the entire hierarchy in the window. MicroStrategy Tutorial schema A schema is a logical and physical definition of warehouse data elements. click Auto arrange in the toolbar. 280 MicroStrategy Tutorial schema © 2007 MicroStrategy. select it from the Entry Point drop-down list in the toolbar. 3 To view a different hierarchy. the HierarchiesMicroStrategy Tutorial dialog box opens. and then choose Hierarchies. select it from the Hierarchy drop-down list on the toolbar. 8 To save the layout view of the hierarchy. characteristics. technical. 4 To focus on a different entry point. It is a graphic-intensive technique that results in a data model representing the definition. 7 To return to the default view. Once loaded. this saved view is displayed.A MicroStrategy Tutorial Project Design Guide 2 From the Schema menu. 6 You can rearrange the attributes by dragging and dropping them. and interrelationships. click Fit in window from the toolbar. click Save in the toolbar. physical characteristics. The next time you open the Hierarchy Viewer. This does not affect the browse order. .

MicroStrategy Tutorial schema 281 . This appendix shows the physical warehouse schema. The physical warehouse schema describes how your data is stored in the data warehouse. While the logical data model tells you what facts and attributes to create. Item. Several physical warehouse schemas can be derived from the same logical data model. the physical warehouse schema tells you where the underlying data for those objects is stored. 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. © 2007 MicroStrategy.Project Design Guide MicroStrategy Tutorial A The physical warehouse schema is based on the logical data model. refer to earlier chapters in this guide. the set of columns required to uniquely identify a record in a table. They typically consist of descriptions of dimensions. including data types. or Account. such as Day. Symbol LU_ Indicates Definition a lookup table A database table used to uniquely identify attribute elements. Store. For more detailed information on the physical schema. a primary key In a relational database. Inc. 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.

The amount of money charged by the company to the customer per individual item sold. The basic facts from which all metrics in the MicroStrategy Tutorial were created from are listed below. The number of individual items bought by customers.unit cost. The schema also contains fact tables. The excess of the selling price of goods over their cost.A MicroStrategy Tutorial Project Design Guide Symbol REL_ Indicates a relationship table Definition While lookup tables store information about one or more attributes. thus defining associations between them. The total income produced by a given source accounting for all product sales deducting discounts. A fact table is a database table containing numeric data that may be aggregated along one or more dimensions. Begin on hand The number of individual items available at the beginning of each month. A monetary reduction made from a regular price. PMT_ a partition A warehouse table that contains information used to identify the mapping table partitioned base tables as part of a logical whole. Fact Cost Discount End on hand Description The total amount charged by the supplier to the company. Unit price . . relate tables store information about the relationship between two attributes. The number of individual items acquired from a supplier. The number of individual items remaining at the close of each month. Freight Profit Revenue Rush Charge Unit Cost Unit Price Unit Profit Units Received Units Sold The compensation paid for the transportation of goods. The amount of money charged to expedite delivery service. 282 MicroStrategy Tutorial schema © 2007 MicroStrategy. Also referred to as a PMT. Inc. Fact tables may contain atomic or summarized data. The amount of money charged by the supplier to the company per individual item purchased. Relate tables contain the ID columns of two or more attributes.

Inc.Project Design Guide MicroStrategy Tutorial A Geography schema © 2007 MicroStrategy. MicroStrategy Tutorial schema 283 .

Inc. .A MicroStrategy Tutorial Project Design Guide Products schema 284 MicroStrategy Tutorial schema © 2007 MicroStrategy.

Inc. MicroStrategy Tutorial schema 285 .Project Design Guide MicroStrategy Tutorial A Customers schema © 2007 MicroStrategy.

A MicroStrategy Tutorial Project Design Guide Time schema 286 MicroStrategy Tutorial schema © 2007 MicroStrategy. Inc. .

Inc.Project Design Guide MicroStrategy Tutorial A Promotions schema Sales fact tables © 2007 MicroStrategy. MicroStrategy Tutorial schema 287 .

A MicroStrategy Tutorial Project Design Guide Inventory fact tables Miscellaneous fact tables 288 MicroStrategy Tutorial schema © 2007 MicroStrategy. Inc. .

2 From the Schema menu. and then choose Tables. © 2007 MicroStrategy. To view the MicroStrategy Tutorial schema 1 If you are not already using the Tutorial. 4 To change display preferences for the physical view. MicroStrategy Tutorial schema 289 . You must login as an Administrator to complete these steps.Project Design Guide MicroStrategy Tutorial A Viewing the MicroStrategy Tutorial schema Although the MicroStrategy Tutorial physical schema is displayed in the previous pages. Use circular joins: Select whether to use circular joins. the TablesMicroStrategy Tutorial dialog box opens with the physical view displayed. you can also view it or the logical schema directly in the product. Inc. use the following options from the Options menu: • • Show joins: Select whether to connect the tables to represent the joins between the table columns. 5 To change display preferences for the logical view. log in to the project source containing the MicroStrategy Tutorial and expand the MicroStrategy Tutorial project. then Logical View. point to Graphical View. Use circular joins: Select whether to use circular joins. 3 To switch to the logical view. Show table prefixes: Select whether to display the table prefix as part of the table name. Once loaded. Show column data types: Select whether to show the data type and size for each column. use the following options from the Options menu: • • • • Show joins: Select whether to connect the tables to represent the joins between the warehouse tables. select View.

select Copy as Metafile from the File menu. and many-to-many relationships. The next time you open the Table Viewer. then Physical View. This does not affect the relationships or joins. 9 To return to the default view. . 290 MicroStrategy Tutorial schema © 2007 MicroStrategy. select View. as a link between the logical and physical views. 8 You can rearrange the tables by dragging and dropping them. click Auto arrange in the toolbar. 11 To copy the layout view. one-to-many. Inc. Show relationship types: Choose whether to differentiate between one-to-one. 7 To view the entire schema in the window. but allows you to view the tables in a way meaningful to you. Show columns: Select whether to display the warehouse columns that define each attribute.A MicroStrategy Tutorial Project Design Guide • • Show relationships: Choose whether to map the relationships between the tables. 10 To save the layout view of the tables. many-to-one. this saved view is displayed. click Save in the toolbar. • 6 To switch back to the physical view. click the Fit in window button on the toolbar.

such as MicroStrategy. Microsoft Analysis Services (Analysis Services). This system setup requires an integrated business intelligence (BI) solution. 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). Specifically. Hyperion Essbase. Inc. or Hyperion Essbase (Essbase). Integration with Analysis Services 2000. 291 .B CONNECTING TO OLAP CUBE SOURCES B. This appendix describes how MicroStrategy Intelligence Server integrates with these products using MultiDimensional Expressions (MDX). Analysis Services 2005. SAP BW. this appendix discusses the following topics: • • MicroStrategy integration with OLAP cube sources. The integration with SAP BW uses SAP’s OLAP Business Application Programming Interface (BAPI). that can concurrently access OLAP cube sources and the data warehouse effectively. page 292 Understanding the SAP BW terminology. and Essbase uses XML for Analysis (XMLA). page 298 © 2007 MicroStrategy.

1 and 3. • • • Microsoft Analysis Services 2000 Microsoft Analysis Services 2005 Hyperion Essbase 7. .0. page 302 Relating objects from Essbase to MicroStrategy. MicroStrategy refers to SAP BW/SAP BI OLAP cube sources as SAP BW. SAP has renamed SAP BW to SAP BI. Using the MicroStrategy standard interface. page 334 Connecting to Analysis Services 2000 servers. page 317 Relating objects from Analysis Services 2005 to MicroStrategy. page 337 Connecting to Analysis Services 2005 servers. page 311 Relating objects from Analysis Services 2000 to MicroStrategy.B Connecting to OLAP Cube Sources Project Design Guide • • • • • • • • • Relating objects from SAP BW to MicroStrategy. page 327 Connecting to Essbase servers. in addition to relational databases. Inc. Intelligence Server can join data from different OLAP cube sources. all of which can be exposed via a unified Web interface. These additional OLAP cube sources include the following: • SAP BW 3. page 340 Integrating OLAP cubes into MicroStrategy. page 322 Connecting to SAP BW servers. 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.0 With version 7.5 and SAP BI 7.1 292 MicroStrategy integration with OLAP cube sources © 2007 MicroStrategy. and bring the data into one single MicroStrategy project.

An MDX expression returns a multidimensional result set (dataset) that consists of axis data. the OLAP BAPI provides an open interface through which Intelligence Server can access the SAP BW data.5. For more information on MDX syntax. Analysis Services and Essbase store data in cubes obtained from various sources. integration allows MicroStrategy to gain additional data sources for analysis. It is important to understand that the MicroStrategy integration with OLAP cube sources does not change the overall structure of the MicroStrategy product. Defined by Microsoft.3. With the SAP BW OLAP BAPI Certification on MicroStrategy 8. and properties data.com/ and search for MDX. MicroStrategy Web Universal is certified to run on SAP Web Application Server.microsoft. or another SAP data source system. including the following: © 2007 MicroStrategy. SAP BW obtains data from R/3.1 of the specification is available at www.0. Rather. CRM.org and is the basis for the MicroStrategy implementation. cell data. Inc. To access the data. refer to http://msdn. Version 1. If you use OLAP cube sources and MicroStrategy as your combined BI solution. In other words.xmla. each of these products is simply another data warehouse that holds data for report generation. SEM. see the MicroStrategy readme. and MicroStrategy Web and SDK are certified to run with SAP Enterprise Portal through iView Packages. MicroStrategy has chosen to use the OLAP BAPI approach because it is the most native interface that SAP provides. MDX is similar to SQL but is used to query cubes. Likewise. The XMLA integration provides a Web Service interface for OLAP and data mining functions. This data is stored in cubes or other SAP objects.Project Design Guide Connecting to OLAP Cube Sources B For MicroStrategy’s support status with the OLAP cube sources listed above. you can get the best out of both products. the Intelligence Server generates MDX. MicroStrategy integration with OLAP cube sources 293 . As SAP’s proprietary API for accessing SAP BW data and functionality. With the Powered by Net Weaver Certification on MicroStrategy 7i -7. MicroStrategy Intelligence Server is certified to connect and execute reports against SAP BW cubes.

all of which can be accessed through MicroStrategy Web. and Query Builder provides additional mechanisms for pulling data into the MicroStrategy platform for analysis. refer to the MicroStrategy Advanced Reporting Guide. Support for SAP BW. Understanding MicroStrategy architecture The MicroStrategy platform offers OLAP Services. and Narrowcast Server functionality. . it is treated in the same 294 MicroStrategy integration with OLAP cube sources © 2007 MicroStrategy. Freeform SQL. Inc. Analysis Services. as illustrated in the following diagram. For information on Freeform SQL and Query Builder reporting.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 For troubleshooting and diagnostics logging routines related to OLAP cube sources. Essbase. Data is pulled from multiple OLAP cube sources using MDX and operational systems using Freeform SQL or Query Builder. Report Services. Once the data is retrieved. see the Troubleshooting the System chapter of the MicroStrategy System Administration Guide.

MicroStrategy integration with OLAP cube sources 295 . you could have multiple MicroStrategy projects. Each project contained one project schema that held the logical model for that project. which was represented by the database instance. One database instance could be referenced by multiple projects in a configuration. © 2007 MicroStrategy. each pointing to a data warehouse. shown below. 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. To understand the current MicroStrategy architecture better. This means that core MicroStrategy capabilities are available no matter what the original data source is.Project Design Guide Connecting to OLAP Cube Sources B manner as data pulled from the relational data warehouse. Inc.

note that instead of pointing to the project schema. but the only source is the data warehouse. each of which can represent a distinct OLAP cube source. a Report Services document can contain multiple datasets. which is a logical placeholder for a physical cube that exists in an OLAP cube source. and a single MicroStrategy project can reference multiple database instances. In addition. Each report can only reference one specific cube. the SQL Engine would implicitly reference the schema to determine which table(s) should be queried.B Connecting to OLAP Cube Sources Project Design Guide When a report was executed. each OLAP cube report points directly to one cube in MicroStrategy. due to the structure in OLAP cube sources where queries can only be run against one cube at a time. Inc. You can create multiple reports to run against one cube. 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. . 296 MicroStrategy integration with OLAP cube sources © 2007 MicroStrategy. However.

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. Freeform SQL reports. MicroStrategy integration with OLAP cube sources 297 .Project Design Guide Connecting to OLAP Cube Sources B The model also shows how you can include any number of standard reports. By bringing these different types of reports together inside a document. and OLAP cube reports in one Report Services document. refer to the MicroStrategy Document Creation Guide. Authentication Most of the standard MicroStrategy platform authentication features also apply to OLAP cube sources and OLAP cube reports. refer to the MicroStrategy Advanced Reporting Guide. described as follows: © 2007 MicroStrategy. For information on Freeform SQL and Query Builder reports. Inc. Query Builder reports.

If multiple sources are configured for warehouse pass-through execution. page 302. Warehouse pass-through authentication: is supported in the same way as for relational data providers. Connection mapping: is supported the same way as for standard MicroStrategy reports. To enforce OLAP cube source security in MicroStrategy. for example. you need to be familiar with the terms that are used to describe the SAP BW objects. . but not to the cube sources. relational databases or OLAP cube sources. it is recommended that you use connection mapping or pass-through authentication. Further information is provided later in this appendix on how the SAP BW objects are related to those in the MicroStrategy environment. then the same login information must be applicable to all sources. This is explained in Relating objects from SAP BW to MicroStrategy. Some of these terms are provided in the following section. refer to the MicroStrategy System Administration Guide. NT authentication: used for database logins are not supported with OLAP cube sources.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. 298 Understanding the SAP BW terminology © 2007 MicroStrategy. specific connection mappings may be designated for each database instance and user or group combination. In addition. • • • For information on authentication in general. Inc. NT Authentication can be used to authenticate the user to the Intelligence Server. refer to your SAP documentation. For a comprehensive and detailed explanation on SAP BW objects. Understanding the SAP BW terminology Before looking in depth into how MicroStrategy integrates with SAP BW.

which is described below. Understanding the SAP BW terminology 299 . 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. for example. To release a query for analysis in MicroStrategy. InfoCubes define a specific domain of analysis in special areas. Query cubes also provide MicroStrategy users access to additional InfoProviders including ODS objects. Query cube (or query): defines a subset of data from an InfoCube or another InfoProvider. Data is organized by dimension and stored physically in a star schema. finance or sales. Any existing query can be released for analysis within MicroStrategy. 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. three InfoCubes or two ODS objects. which are roughly equivalent to attributes and facts in a MicroStrategy project. and MultiProviders. ODS objects are flat relational tables and are similar to MicroStrategy fact tables. InfoSets. for example. ODS object: is an operational data store object. Query cubes generally offer better performance than InfoCubes because they are smaller and can be scheduled and cached within SAP BW. MultiProvider: is a logical union of two or more InfoProviders that are used to combine data from two different subject areas. 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. • • InfoCube: is the primary object that SAP BW uses to store data for analysis. They include objects such as characteristics and key figures. The fact table at the center of an InfoCube contains the data available for analysis. A query cube includes characteristics (dimensions/attributes) and key figures (metrics) from its source provider.Project Design Guide Connecting to OLAP Cube Sources B • InfoObject: are the building blocks for individual cubes.

However. • Key figure: describes numeric data. SAP BW characteristics are similar to MicroStrategy attributes. Central. © 2007 MicroStrategy. customer group. You can also create calculated key figures and restricted key figures in the query definition in the Business Explorer. and number of call centers. date. a Sales Region characteristic can have North. it is treated as a separate dimension for analysis. When the query is executed. In addition. product. Subcategory. these variables are filled with values by the system or by the user. ODS objects. profit. and period. quantities. These hierarchies are also available when you work with a cube in MicroStrategy. hierarchy nodes. • • 300 Understanding the SAP BW terminology . such as sales region. Defined in the Query Designer. numbers. hierarchies. hierarchies can be associated with a specific characteristic within SAP BW. the Item characteristic might have a hierarchy that includes Category. • Characteristic: provides classification possibilities for a dataset. and South specifications. Inc. For example. designers can quickly access existing query cubes and business content when working in MicroStrategy. However. Variable: is used as a parameter of a query in SAP BW. fiscal year. and master data attributes. SAP BW also has an object called an attribute. This is a different paradigm from MicroStrategy’s model where each attribute defines its own level. such as revenue. This is similar to creating derived metrics and conditional metrics within the MicroStrategy environment. when the levels of a hierarchy are viewed in MicroStrategy. texts. There are five types of key figures: amount. and formulas. For example. they are presented with the traditional attribute-based parent-child relationships. all of which can be used in InfoCubes.B Connecting to OLAP Cube Sources Project Design Guide interface. when each characteristic is translated into a cube. as noted later. variables can be of such types as characteristic values. With this option enabled. and finally Item. and time. but it is equivalent to an attribute form in MicroStrategy. Hierarchy: is a way of defining the relationships among elements within a characteristic.

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.Project Design Guide Connecting to OLAP Cube Sources B When an OLAP cube is imported into a MicroStrategy project. When working in MicroStrategy. For more information. © 2007 MicroStrategy. refer to the MicroStrategy Desktop online help. see Supporting SAP BW variables. standard prompts can also be created for this report. rows. Besides the above-mentioned terminology. refer to documentation provided by SAP BW. When the OLAP cube is used to create a MicroStrategy report. Understanding the SAP BW terminology 301 . For more information on variables. In addition. you will find a list of available cubes for reporting. you also need to have a basic understanding of the SAP Query Designer. For step-by-step instructions on how to create MicroStrategy reports from the data in SAP BW cubes. and MultiProviders. including all of the published query cubes. and free characteristics. all the variables in this cube are represented as prompts. where you define queries. the report inherits all those prompts. page 308. Inc. columns. InfoCubes.

when thinking about SAP objects. but not identical. ODBO defines an object model that is used in conjunction with MDX to query cubes. However. 302 Relating objects from SAP BW to MicroStrategy © 2007 MicroStrategy. keep in mind how those objects appear in ODBO. if you are a report designer. Thus. you can treat SAP BW reports as if they were standard MicroStrategy reports. 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. .B Connecting to OLAP Cube Sources Project Design Guide Relating objects from SAP BW to MicroStrategy As a Web or Desktop Analyst. ODBO stands for OLE database for OLAP and is a protocol defined by Microsoft. The ODBO model is similar to SAP’s standard model. it is helpful to understand how SAP’s metadata model is translated into MicroStrategy’s metadata model. Inc.

Query cubes are accessed through their respective InfoCube catalogs. The following image demonstrates how SAP BW objects are exposed in ODBO and then how they are related to objects in the MicroStrategy environment. they are then translated into the MicroStrategy metadata model. SAP BW ---> InfoCube ODBO ---> catalog MicroStrategy (catalog) • SAP BW: InfoCube Each InfoCube that has queries associated with it is exposed as a catalog in ODBO.Project Design Guide Connecting to OLAP Cube Sources B 2 From ODBO to MicroStrategy: After SAP objects are translated into the ODBO model. © 2007 MicroStrategy. Relating objects from SAP BW to MicroStrategy 303 . Inc. The following sub-sections—each starting with a table—describe each level of comparison from top to bottom as shown in the above illustration. You can then interact with SAP content while working within the paradigm that is consistent with the rest of MicroStrategy’s products.

The cube can be used to represent InfoCubes. Therefore. SAP BW ---> N/A ODBO ---> schema MicroStrategy N/A • • SAP BW: not supported ODBO: schema Schema in ODBO provides another grouping mechanism. • MicroStrategy: not supported SAP BW ---> InfoCube/ query cube ODBO ---> cube MicroStrategy 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. and query cubes. Cubes are treated in a manner very similar to tables in the MicroStrategy metadata. if any. . MultiProviders. • MicroStrategy: (Catalog) Each catalog includes one InfoCube and associated query cubes. ODBO catalogs are exposed in a few editors when selecting and managing cubes.B Connecting to OLAP Cube Sources Project Design Guide • ODBO: Catalog Catalogs are used to group cubes. Inc. In the same way that a regular table maps the physical columns of a relational table to attributes and metrics. Catalogs in MicroStrategy are represented in a folder. a MicroStrategy cube maps the physical columns of an SAP BW cube to attributes and metrics. 304 Relating objects from SAP BW to MicroStrategy © 2007 MicroStrategy.

you can build a Time hierarchy that is attached to the Month characteristic. For example. Each characteristic (dimension) has at least one hierarchy with two levels: the first level is an aggregate of all the data. Relating objects from SAP BW to MicroStrategy 305 . Inc. For more information. However. or they could be other characteristics that are used to define the levels of this one hierarchy. • ODBO: dimension A dimension in ODBO defines a logical category of analysis. see the following sub-section. They can only be seen inside the SAP BEx Query Designer when you build a query cube. and Month. This hierarchy defines a number of levels including Year. Quarter. all dimensions in cubes coming from SAP BW are shared. Shared dimensions allow a designer to use only one definition for a dimension across multiple cubes. © 2007 MicroStrategy. Each characteristic in SAP is modeled as a dimension in ODBO and is shared across cubes. For example. each with an arbitrary number of levels. Dimensions in SAP BW are used to group characteristics and are not exposed through the ODBO interface. The SAP BW characteristic hierarchies appear as hierarchies to MicroStrategy users. For example. an InfoCube might include the Month characteristic. A characteristic appears as a dimension for MicroStrategy users. these same levels could either be specifically defined as part of the hierarchy. A characteristic can have any number of additional hierarchies. Time and Geography are dimensions along which you can slice data. which represents months just like it does in MicroStrategy. Therefore.Project Design Guide Connecting to OLAP Cube Sources B SAP BW ---> characteristic ODBO ---> dimension MicroStrategy dimension • SAP BW: characteristic Characteristics in SAP BW are similar to attributes in MicroStrategy. and the second level is the detailed data.

In this way.B Connecting to OLAP Cube Sources Project Design Guide Measures (metrics) are stored in a special measure dimension. SAP BW ---> hierarchy ODBO ---> hierarchy MicroStrategy hierarchy • • • SAP BW: hierarchy ODBO: hierarchy MicroStrategy: hierarchy Hierarchies are used to group attributes (levels) together and define the relationships between these attributes. • MicroStrategy: dimension A dimension object in MicroStrategy is very similar to an ODBO dimension. In MicroStrategy. which are very similar to metrics in MicroStrategy. and so on. Inc. It is used to group attributes and define parent-child relationships. 306 Relating objects from SAP BW to MicroStrategy © 2007 MicroStrategy. The inclusion of the term “Level” is an SAP BW convention. MicroStrategy reuses the hierarchy objects to represent both dimensions and hierarchies from ODBO. measures are simply one more dimension of a cube. Measures in ODBO are called key figures in SAP BW. SAP BW ---> virtual level ODBO ---> level MicroStrategy attribute • SAP BW: virtual level Levels are generated automatically based on either the definition of the characteristic or the hierarchies associated with a characteristic. SAP BW levels have names such as Region Level 01. and they are represented as physical columns. Region Level 02. . architects have the option to rename the levels of a cube with a more readable convention.

However. For example. each ODBO level generates two physical columns and forms in MicroStrategy—ID and DESC. In SAP BW. Relating objects from SAP BW to MicroStrategy 307 . For example. the Customer attribute may have the forms First Name and Last Name. SAP BW also supports navigational attributes. SAP BW ---> characteristic attribute ODBO ---> property MicroStrategy attribute form • • • SAP BW: characteristic attribute ODBO: property MicroStrategy: attribute form Attribute forms provide additional information about a given attribute. This concept also applies to ODBO and SAP BW. Inc.Project Design Guide Connecting to OLAP Cube Sources B • • ODBO: level MicroStrategy: attribute (ID/DESC) MicroStrategy attributes map to ODBO levels. SAP BW ---> characteristic value ODBO ---> member MicroStrategy (attribute element) • • • SAP BW: characteristic value ODBO: member MicroStrategy: (attribute element) Element values come from either the database or a cube. 2003 and 2004 are elements of the Year attribute. © 2007 MicroStrategy. These attributes are presented as distinct dimensions when working in MicroStrategy. forms are sometimes referred to directly as attributes.

and formula elements. the report inherits the prompts included in the OLAP cube. When the query is being executed. these variables are filled with values. Otherwise. refer to your SAP documentation. an error occurs when you attempt to import the SAP BW cube. 308 Relating objects from SAP BW to MicroStrategy © 2007 MicroStrategy. Only variables with the Manual Entry/Default processing type are presented to users for resolution. variables are automatically turned into prompts in the MicroStrategy OLAP cube. On top of the “inherited” variable prompts. see the Prompts section of the Creating OLAP Cube Reports chapter of the MicroStrategy Advanced Reporting Guide. SAP BW variables of type Replacement Path cannot be imported into MicroStrategy. Originally created in an SAP query cube. additional standard MicroStrategy prompts can also be created for the report. including characteristic values. you must remove them before importing the cube into MicroStrategy. variables are represented as prompts in the MicroStrategy environment. There are several types of variables. For more information. If your SAP BW cube included variables of type Replacement Path.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. . The conversion process involves the following general steps: 1 When an SAP query cube is imported into a MicroStrategy project. Inc. texts. For detailed information on variables. hierarchy nodes. hierarchies. 2 When a MicroStrategy report is created using a MicroStrategy OLAP cube. Variable types with the Customer Exit/SAP Exit and Authorization processing types are automatically resolved by the SAP BW system.

Default Low. and Variable Ordinal. © 2007 MicroStrategy. Entry Type. and measures/key figures. Rename the prompt.Project Design Guide Connecting to OLAP Cube Sources B Mapping between variables and prompts can be viewed in the OLAP Cube Catalog. Relating objects from SAP BW to MicroStrategy 309 . Variable Type. The OLAP Cube Catalog lists all the prompts that were converted from variables. Default Low Description. Selection Type. Details about this variable in SAP BW are displayed on the Variable tab. In addition. in addition to cube names. as shown in the following image. or Map the variable to a prompt in an existing MicroStrategy project. including Variable Name. Inc. you can view any variable’s properties by right-clicking its name and then selecting Properties. In the OLAP Cube Catalog. dimensions. using the right-mouse click you can Edit the prompt in the Prompt Generation Wizard.

If you use any SAP BW key date variables in your query.B Connecting to OLAP Cube Sources Project Design Guide One prompt can be mapped to more than one variable across cubes. No major changes. The following table contains information on how the different types of SAP BW variables are mapped to MicroStrategy prompts. Hierarchy Node variable Hierarchy element list prompt Text variable Formula variable N/A Value prompt: all types Characteristic value variables offer an “Including/Excluding” option. so it is distinguished from a simple characteristic variable on date. . 310 Relating objects from SAP BW to MicroStrategy © 2007 MicroStrategy. you need to manually set the variable’s property in the OLAP Cube Catalog. This is especially useful if you want to get a summary of the variable elements that are used in answering the variable prompts. Not available from SAP BW. For more information about prompts in OLAP cube reports. a prompt is displayed only once. see the Prompts section of the Creating OLAP Cube Reports chapter of the MicroStrategy Advanced Reporting Guide. Inc. the MicroStrategy interface qualifies on the key value of each element by default. SAP Variable Type ---> Characteristic Value variable Hierarchy variable MicroStrategy Prompt Element list prompt or attribute qualification prompt N/A Notes See the note below for more information. you can view the prompt details in the Report Details pane in the Report Editor. When executing a Report Services document with multiple datasets using these cubes. Qualifications in the Including section cause the data to be brought into the query. Not supported. while those in the Excluding section restrict the data from being displayed in the query. Both single and multiple selection are supported. This allows the same prompt answer to be used to resolve multiple variables during document execution. To be consistent with the SAP functionality. After an OLAP cube report is executed.

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. it is helpful to understand how Essbase’s metadata model is translated into MicroStrategy’s metadata model. Relating objects from Essbase to MicroStrategy 311 . However. © 2007 MicroStrategy. 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). select the Set Key Date check box. and then click OK. you cannot drill down into the elements of characteristic structures. In addition to key figure structures. if you are a report designer. Relating objects from Essbase to MicroStrategy As a Web or Desktop Analyst.Project Design Guide Connecting to OLAP Cube Sources B Set the properties for key date variables 1 Right-click the variable name and select Properties. Each element of a key figure structure is represented as a unique metric in the MicroStrategy environment. The Properties [variable name] dialog box is displayed. a query could also have characteristic structures. Inc. you can treat OLAP cube reports from an Essbase OLAP cube as if they were standard MicroStrategy reports. In a MicroStrategy report. 2 On the Variable tab.

. When thinking about Essbase objects. You can then interact with Essbase content while working within the paradigm that is consistent with the rest of MicroStrategy’s products.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. they are then translated into the MicroStrategy metadata model. The Essbase model predates XMLA so there are some differences. 312 Relating objects from Essbase to MicroStrategy © 2007 MicroStrategy. 2 From XMLA to MicroStrategy: After Essbase objects are translated into the XMLA model. Inc. The following image demonstrates how Essbase objects are exposed in XMLA and then how they are related to objects in the MicroStrategy environment. XMLA defines an object model that is used in conjunction with MDX to query cubes. keep in mind how those objects appear in XMLA.

Relating objects from Essbase to MicroStrategy 313 . • MicroStrategy: not supported Essbase ---> database XMLA ---> cube MicroStrategy cube • • Essbase: database XMLA: cube © 2007 MicroStrategy. Essbase ---> N/A XMLA ---> schema MicroStrategy N/A • • Essbase: not supported XMLA: schema Schema in XMLA provides another grouping mechanism. Catalogs in MicroStrategy are represented as a folder. if any.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. Databases are accessed through their respective catalogs. Therefore. XMLA catalogs are exposed in editors when selecting and managing cubes. • MicroStrategy: (catalog) Each catalog includes one application and associated databases. • XMLA: catalog Catalogs are used to group cubes. Essbase ---> Application XMLA ---> catalog MicroStrategy (catalog) • Essbase: Application Each Application is exposed as a catalog in XMLA. Inc.

measures are simply one more dimension of a cube. . Time and Geography are dimensions along which you can slice data. • XMLA: dimension A dimension in XMLA defines a logical category of analysis. The cube represents an Essbase database. Each dimension has a single hierarchy with the number of levels determined by the greatest depth in the outline. Inc. These can be raw data or formulas with associated calculation or aggregation rules. For example. Essbase ---> dimension XMLA ---> dimension MicroStrategy dimension • Essbase: dimension In Essbase. a dimension represents the highest consolidation level in the database outline. An Essbase dimension appears as a dimension for MicroStrategy users. Each dimension has a single root node or member and is a child of the outline root node which is the database. Measures in ODBO are the members of the dimension of type=Accounts in Essbase. The dimension therefore is both the highest level member in the dimension and the dimension itself. • MicroStrategy: dimension 314 Relating objects from Essbase to MicroStrategy © 2007 MicroStrategy. Cubes are treated in a manner very similar to tables in the MicroStrategy metadata. Measures (metrics) are stored in a special measure dimension. 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. In this way.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.

Levels(0). As a result. architects have the option to rename the levels of a cube with a more readable convention. Inc. The outline is a hierarchical structure of database members with a parent containing its children. In MicroStrategy.Project Design Guide Connecting to OLAP Cube Sources B A dimension object in MicroStrategy is very similar to an XMLA dimension. MicroStrategy reuses the hierarchy objects to represent both dimensions and hierarchies from XMLA. • • XMLA: hierarchy MicroStrategy: hierarchy Hierarchies are used to group attributes (levels) together and define the relationships between these attributes. Essbase ---> level XMLA ---> level MicroStrategy attribute • Essbase: level Levels group together members in an Essbase database outline. It is used to group attributes and define parent-child relationships. • • XMLA: level MicroStrategy: attribute (ID/DESC) © 2007 MicroStrategy. Essbase ---> dimension XMLA ---> hierarchy MicroStrategy hierarchy • Essbase: dimension An Essbase dimension is defined as part of the database outline. Therefore the dimension is the same as the hierarchy in Essbase. Relating objects from Essbase to MicroStrategy 315 . the outline defines a single hierarchy. Essbase levels may have default names such as Time.

each XMLA level generates the two physical columns and forms ID and DESC in MicroStrategy. 2003 and 2004 are elements of the Year attribute.1. However. properties can be defined for a database as user defined attributes or attribute dimensions and used in an MDX statement. However. For example. . Essbase ---> member XMLA ---> member MicroStrategy attribute element • • • Essbase: member XMLA: member MicroStrategy: attribute element Element values come from either the database or a cube. Until they are returned as rows in the property schema rowset they are not available as attribute forms in MicroStrategy. Essbase ---> N/A XMLA ---> property MicroStrategy attribute form • Essbase: N/A Essbase as of version 7. 316 Relating objects from Essbase to MicroStrategy © 2007 MicroStrategy. For example. Inc. • • XMLA: property MicroStrategy: attribute form Attribute forms provide additional information about a given attribute.B Connecting to OLAP Cube Sources Project Design Guide MicroStrategy attributes map to XMLA levels. the Customer attribute may have the forms First Name and Last Name.3 does not return any properties in the XMLA property schema rowset.

If you are a report designer. 2 From XMLA to MicroStrategy: After Analysis Services 2000 objects are translated into the XMLA model. Inc. they are then translated into the MicroStrategy metadata model. 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.Project Design Guide Connecting to OLAP Cube Sources B Relating objects from Analysis Services 2000 to MicroStrategy Microsoft Analysis Services 2000 (Analysis Services 2000) cubes are exposed directly for XMLA access. XMLA defines an object model that is used in conjunction with MDX to query cubes. 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. Relating objects from Analysis Services 2000 to MicroStrategy 317 .

Analysis Services 2000 ---> XMLA ---> database catalog MicroStrategy (catalog) • Analysis Services 2000: database Each database is exposed as a catalog in XMLA. The following sub-sections—each starting with a table—describe each level of comparison from top to bottom as shown in the above illustration. Cubes are accessed through their respective catalogs. • XMLA: catalog Catalogs are used to group cubes. • MicroStrategy: (catalog) 318 Relating objects from Analysis Services 2000 to MicroStrategy © 2007 MicroStrategy. XMLA catalogs are exposed in editors when selecting and managing cubes.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. Therefore. . Inc.

Analysis Services 2000 ---> XMLA ---> N/A schema MicroStrategy N/A • • Analysis Services 2000: not supported XMLA: schema Schema in XMLA provides another grouping mechanism. if any. The cube represents an Analysis Services 2000 cube. Analysis Services 2000 ---> XMLA ---> dimension dimension MicroStrategy dimension • Analysis Services 2000: dimension © 2007 MicroStrategy. In the same way that a regular table maps the physical columns of a relational table to attributes and metrics. Catalogs in MicroStrategy are represented as a folder.Project Design Guide Connecting to OLAP Cube Sources B Each catalog includes one database and associated cubes. Cubes are treated in a manner very similar to tables in the MicroStrategy metadata. a MicroStrategy cube maps the physical columns of an Analysis Services 2000 cube to attributes and metrics. • MicroStrategy: not supported Analysis Services 2000 ---> XMLA ---> cube cube MicroStrategy 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. Relating objects from Analysis Services 2000 to MicroStrategy 319 . Inc.

Time and Geography are dimensions along which you can slice data. MicroStrategy reuses the hierarchy objects to represent both dimensions and hierarchies from XMLA. related dimensions can be grouped together so that they represent hierarchies of the same dimension from an XMLA perspective. For example. It is used to group attributes and define parent-child relationships. Measures (metrics) are stored in a special measure dimension. • XMLA: dimension A dimension in XMLA defines a logical category of analysis. 320 Relating objects from Analysis Services 2000 to MicroStrategy © 2007 MicroStrategy. a dimension is defined from one or more tables of data. Measures in XMLA are the members of the Measures dimension in Analysis Services 2000. Each dimension can have one or more hierarchies. . Inc. An Analysis Services 2000 dimension appears as a dimension for MicroStrategy users. measures are simply one more dimension of a cube. • • XMLA: hierarchy MicroStrategy: hierarchy Hierarchies are used to group attributes (levels) together and define the relationships between these attributes. In this way.B Connecting to OLAP Cube Sources Project Design Guide In Analysis Services 2000. • MicroStrategy: dimension A dimension object in MicroStrategy is very similar to an XMLA dimension. These can be columns in the table or calculated members represented by formulas with associated aggregation rules. Analysis Services 2000 ---> XMLA ---> dimension hierarchy MicroStrategy hierarchy • Analysis Services 2000: dimension Using a structured naming approach.

Member properties are returned in the XMLA property schema rowset. For example. Analysis Services 2000 ---> XMLA ---> member property property MicroStrategy attribute form • Analysis Services 2000: member property A member property is a descriptive piece of information associated with the element of a level. • • XMLA: level MicroStrategy: attribute (ID/DESC) MicroStrategy attributes map to XMLA levels. Inc.Project Design Guide Connecting to OLAP Cube Sources B Analysis Services 2000 ---> XMLA ---> level level MicroStrategy attribute • Analysis Services 2000: level Levels are mapped to columns in a table and are organized into hierarchies and dimensions. However. 2003 and 2004 are elements of the Year attribute. XMLA: property MicroStrategy: attribute form Relating objects from Analysis Services 2000 to MicroStrategy 321 . Analysis Services 2000 ---> XMLA ---> member member MicroStrategy attribute element • • • Analysis Services 2000: member XMLA: member MicroStrategy: attribute element Element values come from a cube. each XMLA level generates two physical columns and forms in MicroStrategy—ID and DESC. • • © 2007 MicroStrategy.

the Customer attribute may have the forms First Name and Last Name.B Connecting to OLAP Cube Sources Project Design Guide Attribute forms provide additional information about a given attribute. Relating objects from Analysis Services 2005 to MicroStrategy Microsoft Analysis Services 2005 (Analysis Services 2005) has a unique modeling approach for building cubes. 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. . 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. This section is limited to information on the basic cube object and how it relates to the XMLA model. 322 Relating objects from Analysis Services 2005 to MicroStrategy © 2007 MicroStrategy. Inc. For example. You can then interact with Analysis Services 2005 content while working within the paradigm that is consistent with the rest of MicroStrategy’s products. they are then translated into the MicroStrategy metadata model.

• XMLA: catalog Catalogs are used to group cubes. XMLA catalogs are exposed in editors when selecting and managing cubes. The following sub-sections—each starting with a table—describe each level of comparison from top to bottom as shown in the above illustration. Relating objects from Analysis Services 2005 to MicroStrategy 323 . • MicroStrategy: (catalog) © 2007 MicroStrategy. Analysis Services 2005 ---> XMLA ---> database catalog MicroStrategy (catalog) • Analysis Services 2005: database Each database is exposed as a catalog in XMLA. Inc. Therefore. Cubes are accessed through their respective catalogs.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.

In the same way that a regular table maps the physical columns of a relational table to attributes and metrics. Cubes are treated in a manner very similar to tables in the MicroStrategy metadata. Analysis Services 2005 ---> XMLA ---> N/A schema MicroStrategy N/A • • Analysis Services 2005: not supported XMLA: schema Schema in XMLA provides another grouping mechanism. if any. Catalogs in MicroStrategy are represented as a folder. Inc. • MicroStrategy: not supported Analysis Services 2005 ---> XMLA ---> perspective cube MicroStrategy 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.B Connecting to OLAP Cube Sources Project Design Guide Each catalog includes one database and associated cubes. • • 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. The cube represents an Analysis Services 2005 cube. 324 Relating objects from Analysis Services 2005 to MicroStrategy © 2007 MicroStrategy. . a MicroStrategy cube maps the physical columns of an Analysis Services 2005 cube to attributes and metrics.

For example. All columns in the tables are eligible to become attributes of the dimension. Measures (metrics) are stored in a special measure dimension. Unlike Analysis Services 2000. It is used to group attributes and define parent-child relationships. • MicroStrategy: dimension A dimension object in MicroStrategy is very similar to an XMLA dimension. • XMLA: dimension A dimension in XMLA defines a logical category of analysis. measures are simply one more dimension of a cube. Each dimension can have one or more hierarchies. Relating objects from Analysis Services 2005 to MicroStrategy 325 . Time and Geography are dimensions along which you can slice data.Project Design Guide Connecting to OLAP Cube Sources B Analysis Services 2005 ---> XMLA ---> dimension dimension MicroStrategy dimension • Analysis Services 2005: dimension In Analysis Services 2005. Measures in XMLA are the members of the Measures dimension in Analysis Services 2005. In this way. These can be columns in the data source table or calculated members represented by formulas with associated aggregation rules. a data source does not always map directly to the tables in a relational database. Inc. An Analysis Services 2005 dimension appears as a dimension for MicroStrategy users. Each attribute is used to define a hierarchy within the dimension and multi-level hierarchies can be defined as well. a dimension is defined from one or more data source tables. Analysis Services 2005 ---> XMLA ---> hierarchy hierarchy MicroStrategy hierarchy © 2007 MicroStrategy.

MicroStrategy reuses the hierarchy objects to represent both dimensions and hierarchies from XMLA. . Analysis Services 2005 ---> XMLA ---> level level MicroStrategy attribute • Analysis Services 2005: level Each attribute in a hierarchy becomes a level. 326 Relating objects from Analysis Services 2005 to MicroStrategy © 2007 MicroStrategy. For example. • • XMLA: hierarchy MicroStrategy: hierarchy Hierarchies are used to group attributes (levels) together and define the relationships between these attributes. However. Inc. 2003 and 2004 are elements of the Year attribute. each XMLA level generates two physical columns and forms in MicroStrategy—ID and DESC. Analysis Services 2005 ---> XMLA ---> member member MicroStrategy attribute element • • • Analysis Services 2005: member XMLA: member MicroStrategy: attribute element Element values come from a cube. • • XMLA: level MicroStrategy: attribute (ID/DESC) MicroStrategy attributes map to XMLA levels.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.

Connecting to SAP BW servers In addition to relational databases. For example. see the MicroStrategy readme.Project Design Guide Connecting to OLAP Cube Sources B Analysis Services 2005 ---> XMLA ---> member property property MicroStrategy attribute form • Analysis Services 2005: member property Attributes can be related as member properties when defining the levels of a dimension. 3. MicroStrategy certifies connecting to SAP BW 3.1. Connecting to SAP BW servers 327 . and 7. Member properties are returned in the XMLA property schema rowset. For any late-breaking changes to the certification status of connecting to various SAP BW versions. you need to establish a connection to the SAP BW system. • • XMLA: property MicroStrategy: attribute form Attribute forms provide additional information about a given attribute. 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. Inc.5. This section discusses how to connect to SAP BW servers in the following environments: • • Connecting to SAP BW servers on Windows Connecting to SAP BW servers on UNIX and Linux © 2007 MicroStrategy. refer to the MicroStrategy Desktop online help. For more information on establishing a connection to SAP BW. the Customer attribute may have the forms First Name and Last Name.0.

3 and also supports more recent versions. you are required to install the new Visual Studio .11.dll Locate the Path environment variable from your machine’s System Properties dialog (right-click on My Computer and select Properties).B Connecting to OLAP Cube Sources Project Design Guide Connecting to SAP BW servers on Windows Important note from SAP: “Starting with JCo 2. you may have to perform some extra configuration and troubleshooting steps to connect to SAP BW servers. You can use the following URL to download the Java Connector: https://service. To connect to SAP BW servers on Windows 1 Open the SAP Service Marketplace and download the SAP Java Connector. 2 Install the SAP Java Connector. Take the following steps to connect to SAP BW servers in Windows. . 3 Place the following SAP Java Connector files in any directory that is referenced in the Path environment variable: • • Librfc32. refer to the Tech Note TN5800-800-0559.NET C/C++ run-time libraries on Windows platforms. In 328 Connecting to SAP BW servers © 2007 MicroStrategy. Inc.” Depending on your system and SAP BW setup. select Environment Variables. For more information.0. See SAP Note 684106 for details on how to install them.dll Sapjcorfc.sap.com/~form/sapnet?_SHOR TKEY=01100035870000463649 MicroStrategy certifies version 2.1.1.4 and JCo 2. on the Advanced tab.

To specify database connection parameters 9 For the database instance. as shown below. open a project source and expand Administration from the folder list. System Number from the SAP BW system. SAP Router String if you use an SAP Router. For example. 4 Place the Sapjco. select a database connection or create a new database connection that provides the following information as required: • • • • Application Server is the name of the SAP BW Server or IP address. Connecting to SAP BW servers 329 . 8 Create a database instance with SAP BW as the database connection type. The Database Instance editor opens. C:\Program files\Common files\MicroStrategy. To create a database instance for your SAP BW connection 5 In Desktop. 7 Select New.Project Design Guide Connecting to OLAP Cube Sources B the list of System Variables. select Database Instance Manager. Client Number from the SAP BW system. Verify that the directory is included in the value for the Path variable. and then Database Instance from the File menu. locate Path.jar in the Common Files MicroStrategy folder. 6 From the folder list. © 2007 MicroStrategy. Inc.

. refer to the MicroStrategy Tech Note TN5300-802-0734. refer to the MicroStrategy online help.B Connecting to OLAP Cube Sources Project Design Guide • Language is the language code provided by your SAP administrator. For example. Connecting to SAP BW servers on UNIX and Linux Take the following steps to connect to SAP BW servers in UNIX. You can use either the Database Instances Editor or the Database Instance Wizard to create a database instance for SAP BW. Depending on your system and SAP BW setup. EN is the language code for English. Note the following: • • You can get the above information from your SAP Logon. you may have to perform some extra configuration and troubleshooting steps to connect to SAP BW servers. You can use the following URL to download the Java Connector: https://service. For more detailed steps on creating a database instance and related components to connect to SAP BW.sap. 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. For more information. Inc.com/~form/sapnet?_SHOR TKEY=01100035870000463649 330 Connecting to SAP BW servers © 2007 MicroStrategy. To connect to SAP BW servers on UNIX/Linux 1 Open the SAP Service Marketplace and download the SAP Java Connector.

You can type the command “chmod+wx SAP. /opt/var/MicroStrategy/SAP.so libsapjcorfc.1. use the command gunzip [file name] or gzip [file name].so sapjco. Open the SAP. The default is Read Only.sh by doing the following: • Add the Write and Execute privileges to this file.so sapjco. For example.o libsapjcorfc. copy them onto your machine.Project Design Guide Connecting to OLAP Cube Sources B • MicroStrategy certifies version 2.jar 4 Edit the SAP.sh file and enter the information for XXXX_SAP_LIBRARY_PATH=’’.jar SUN librfccm. for AIX: # # set up the environment for SAP # XXXX_SAP_LIBRARY_PATH='/opt/var/MicroStr ategy/SAP' if [ -n "${XXXX_SAP_LIBRARY_PATH}" ]. and create a new directory for them. then xxxx_append_path LD_LIBRARY_PATH "${XXXX_SAP_LIBRARY_PATH:?}" export LD_LIBRARY_PATH fi • © 2007 MicroStrategy. For example.jar Linux librfccm. Inc.so sapjco. 2 Select the zip file for the platform you want to use and unzip it. Connecting to SAP BW servers 331 .3 and also supports more recent versions. For example.sh file in the MicroStrategy installation directory [INSTALL_PATH]/env/SAP.sh” in the UNIX/Linux console.so libsapjcorfc. AIX librfccm. 3 Search for the files listed in the following table. This information indicates where the server needs to point to use the downloaded files.

open a project source and expand Administration from the folder list. 9 Select New. then xxxx_append_path LIBPATH "${XXXX_SAP_LIBRARY_PATH:?}" export LIBPATH fi • Save the file. 332 Connecting to SAP BW servers © 2007 MicroStrategy.B Connecting to OLAP Cube Sources Project Design Guide For example. and then Database Instance from the File menu. Make sure you have Write privilege to this directory. /install/jar. 6 Restart the server to get the latest updates. 5 Add sapjco. for Solaris: # # set up the environment for SAP # XXXX_SAP_LIBRARY_PATH='/opt/var/MicroStr ategy/SAP’ if [ -n "${XXXX_SAP_LIBRARY_PATH}" ]. select Database Instance Manager. . 8 From the folder list. The Database Instance editor opens.jar to the installation directory. To create a database instance for your SAP BW connection 7 In Desktop (available only in Windows). Inc.

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. Connecting to SAP BW servers 333 . For more information. You can use either the Database Instances Editor or the Database Instance Wizard to create a database instance for SAP BW.Project Design Guide Connecting to OLAP Cube Sources B 10 Create a database instance with SAP BW as the database connection type. EN for English Note the following: • • You can get the above information from your SAP Logon. You can also refer to Tech Note TN5300-802-0734 for more information on setting up SAP BW with Intelligence Server Universal. refer to the MicroStrategy Desktop online help. 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. as shown below. © 2007 MicroStrategy. Inc. for example. To specify database connection parameters 11 For the database instance.

This section discusses how to connect to Essbase servers in the Windows or UNIX/Linux environment. Configuring the XMLA Provider The material in this section assumes familiarity with the XMLA 1. you need to establish a connection to the Essbase servers. and the configuration of the XMLA provider for each of these products. 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. refer to MicroStrategy Tech Note TN1100-000-0635. 334 Connecting to Essbase servers © 2007 MicroStrategy. A Discover request supports queries to metadata and the results are packaged in a DiscoverResponse message.xmla. Inc. MicroStrategy can also use Essbase as a data source to conduct enterprise reporting and analysis.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.org. For more detailed steps on creating a database instance and related components to connect to SAP BW. You can think of XMLA as a Web Service that supports metadata and data queries against an OLAP Cube source. For information on how to use the XMLA Connectivity Test Tool. The Execute request queries cube data and results are returned in an ExecuteResponse message. refer to the MicroStrategy online help. Connecting to Essbase servers In addition to relational databases. Before creating any reports using the Essbase data. .1 specification found at www.

1 provider is correctly deployed and security settings are configured correctly. The web application server may be installed on a different machine from the Essbase server. refer to your 3rd-party documentation. The Hyperion XMLA provider supports BEA WebLogic 6. Inc.1 on the application server machine to verify that access is available to the Essbase server via the Service Console.Project Design Guide Connecting to OLAP Cube Sources B Make sure the XMLA 1. Information for correctly installing the XMLA provider can be found in the 3rd-party documentation for Hyperion’s Enterprise Deployment Services product. You should receive a confirmation from the provider that includes a display of currently configured properties. Consult your 3rd-party documentation for further details on system requirements and the latest updates. © 2007 MicroStrategy. You can verify it is working by connecting to the provider URL from your browser. Install Hyperion Enterprise Deployment Services 7. • • • • Creating a database instance Perform the following steps to connect to Hyperion Essbase servers. The Hyperion XMLA Provider must be installed and configured on a compatible web application server. Note the following: • For the latest information on the 3rd-party connection prerequisites given below. see MicroStrategy Tech Note TN5300-802-0794. Connecting to Essbase servers 335 .1 and Apache Tomcat. For information on installation procedures. The application server that hosts the Hyperion XMLA provider must enable anonymous access to the XMLA application.

4 Create a database instance with Hyperion Essbase as the database connection type. The Database Instance editor opens. Inc. http://fully-qualified-machinename:8080/ xmla/EssbaseXmlForAnalysis.domain.B Connecting to OLAP Cube Sources Project Design Guide To create a database instance for Essbase 1 From the Desktop Folder List. You can also use the IP address as the fully-qualified-machinename.com. 2 Expand Administration from the Folder List and select Database Instance Manager. select New. 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.company. For Essbase the URL is most likely case sensitive. To specify database connection parameters 5 For the database instance. • DSI: The DataSourceInfo (DSI) value is of the form: 336 Connecting to Essbase servers © 2007 MicroStrategy. For example. . 3 From the File menu. as shown below. and then Database Instance. The fully-qualified-machinename is usually of the form machine. connect to a project source.

Project Design Guide Connecting to OLAP Cube Sources B Provider=Essbase. Connecting to Analysis Services 2000 servers In addition to relational databases. Before creating any reports using the Analysis Services 2000 data. you should check that you meet all of the requirements listed in the tech note TN5200-802-0540. 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. Note the following: • Before connecting to your Analysis Services 2000 servers. you need to establish a connection to the Analysis Services 2000 servers. refer to the MicroStrategy online help. Connecting to Analysis Services 2000 servers . Use the Essbase Administration Console to view the applications and databases available on the server. You can perform a test of the XMLA connection to your OLAP cube servers completely separate of any MicroStrategy dependencies with the XMLA 337 • © 2007 MicroStrategy. This section discusses how to connect to Analysis Services 2000 servers in the Windows or UNIX/Linux environment. Inc. • Catalog: The Essbase Catalog value is the Essbase Application containing the database you want to work with in MicroStrategy. A cube in XMLA is a database in Essbase. For more detailed steps on creating a database instance and related components to connect to Analysis Services.Data source=<machine name> The value is split between the DSI setting and an additional connection string parameters setting. MicroStrategy can also use Analysis Services 2000 as a data source to conduct enterprise reporting and analysis.

Creating a database instance Perform the following steps to connect to Microsoft Analysis Services 2000 servers. and the configuration of the XMLA provider for each of these products. 338 Connecting to Analysis Services 2000 servers © 2007 MicroStrategy. You can think of XMLA as a Web service that supports metadata and data queries against an OLAP Cube source. Make sure the XMLA 1. select Database Instance Manager. Inc.1 provider is correctly deployed and security settings are configured correctly. Information for correctly installing the XMLA provider can be found in your Microsoft documentation. Creating a database instance for Analysis Services 2000 1 In Desktop. . refer to MicroStrategy Tech Note TN1100-000-0635. A Discover request supports queries to metadata and the results are packaged in a DiscoverResponse message.B Connecting to OLAP Cube Sources Project Design Guide Connectivity Test Tool provided with your MicroStrategy installation. The Execute request queries cube data and results are returned in an ExecuteResponse message.xmla.org.1 specification found at www. You can verify Analysis Services 2000 is working by connecting to the provider URL from your browser. Configuring the XMLA Provider The material in this section assumes familiarity with the XMLA 1. open a project source and expand Administration from the folder list. 2 From the folder list. For information on how to use the XMLA Connectivity Test Tool. You should receive an XML response indicating that the site is available as an XMLA provider.

The Database Instance Editor opens. Connecting to Analysis Services 2000 servers 339 . http://fully-qualified-machinename/xmla/ msxisapi. • 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. For Analysis Services XMLA running on IIS. The database that contains the cube becomes the catalog for XMLA. Catalog: Use Microsoft’s Analysis Manager to view the Analysis Server containing the cubes you want to work with in MicroStrategy. as shown below. Inc. You can also use the IP address as the fully-qualified-machinename. To specify database connection parameters 5 For the database instance.dll The fully-qualified-machinename is usually of the form machine.company.com. and then Database Instance. the URL is not case-sensitive. select New.Project Design Guide Connecting to OLAP Cube Sources B 3 From the File menu. 4 Create a database instance with Microsoft Analysis Services as the database connection type. For example. 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.domain. • © 2007 MicroStrategy.

Inc. refer to the tech note TN5300-802-0755. MicroStrategy can also use Analysis Services 2005 as a data source to conduct enterprise reporting and analysis. This section discusses how to connect to Analysis Services 2005 servers in the Windows or UNIX/Linux environment.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. Before creating any reports using the Analysis Services 2005 data. you should check that you meet all of the requirements listed in the tech note TN5200-802-0542. . For information on setting up authentication for Intelligence Server with Analysis Services. • 340 Connecting to Analysis Services 2005 servers © 2007 MicroStrategy. 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. Connecting to Analysis Services 2005 servers In addition to relational databases. you need to establish a connection to the Analysis Services 2005 servers. refer to the MicroStrategy online help. For information on how to use the XMLA Connectivity Test Tool. Note the following: • Before connecting to your Analysis Services 2005 servers. refer to MicroStrategy Tech Note TN1100-000-0635. For more detailed steps on creating a database instance and related components to connect to Analysis Services.

only the TCP/IP transport is configured. The Execute request queries cube data and results are returned in an ExecuteResponse message. Creating a database instance for Analysis Services 2005 1 In Desktop. open a project source and expand Administration from the folder list. Creating a database instance Perform the following steps to connect to Microsoft Analysis Services 2005 servers. and then Database Instance. 3 From the File menu.1 specification found at www. select Database Instance Manager.org. which includes configuring security settings. Information for correctly installing the XMLA provider can be found in your Microsoft documentation. The Database Instance Editor opens. XMLA is the native access method for Analysis Services 2005. 2 From the folder list. by default. Connecting to Analysis Services 2005 servers 341 . A Discover request supports queries to metadata and the results are packaged in a DiscoverResponse message.xmla. and the configuration of the XMLA provider for each of these products. Follow Microsoft documentation to make sure that the XMLA provider is correctly configured for HTTP access. Inc. select New.Project Design Guide Connecting to OLAP Cube Sources B Configuring the XMLA Provider The material in this section assumes familiarity with the XMLA 1. You can think of XMLA as a Web Service that supports metadata and data queries against an OLAP Cube source. However. © 2007 MicroStrategy.

• To specify a database login 6 Create a database login with the user and password to use to connect to Analysis Services.domain. • DSI: For Analysis Services 2005. To specify database connection parameters 5 For the database instance. the URL is not case sensitive. each URL will be configured to support only one data source. For example.com. Catalog: Use Microsoft’s SQL Server Management Studio to view the Analysis Server which contains the cubes to work with in MicroStrategy. 342 Connecting to Analysis Services 2005 servers © 2007 MicroStrategy. 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 Analysis Services 2005 XMLA running on IIS. http://fully-qualified-machinename/xmla/ msmdpump. as shown below.company. .dll The fully-qualified-machinename is usually of the form machine. The database that contains the cube becomes the catalog for XMLA. You can also use the IP address as the fully-qualified-machinename. Inc. Unlike Analysis Services 2000. the DSI entry can be left blank.B Connecting to OLAP Cube Sources Project Design Guide 4 Create a database instance with Microsoft Analysis Services as the database connection type.

To learn how to create a database instance for an OLAP cube source. For more detailed steps on creating a database instance and related components to connect to Analysis Services. see Mapping OLAP cubes. the OLAP Cube Catalog can be accessed from the Schema menu on Desktop. refer to Chapter 5. page 327 – Connecting to Analysis Services 2000 servers. page 349 and Creating metrics from OLAP cube data with MDX and compound metric techniques. For information on setting OLAP cube schema loading options for an OLAP cube source database instance. where you can import OLAP cubes and remap the OLAP cubes before you create any OLAP cube reports. Integrating OLAP cubes into MicroStrategy 343 . Note the following: • Once an OLAP cube is imported.Project Design Guide Connecting to OLAP Cube Sources B For information on setting up authentication for Intelligence Server with Analysis Services. Configuring and Connecting to Intelligence Server of the MicroStrategy Installation and Configuration Guide. see one of the following sections: • – Connecting to SAP BW servers. Like the Warehouse Catalog. Inc. The best place to start is with the OLAP Cube Catalog. 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. page 359. For more information. The OLAP Cube Catalog is available only after an OLAP cube source database instance has been created. refer to the MicroStrategy online help. refer to the tech note TN5300-802-0755. you can start working with the OLAP cube data in MicroStrategy. you can remap an OLAP cube to MicroStrategy objects and create metrics within an OLAP cube with the OLAP Cube Editor. page 337 © 2007 MicroStrategy.

For details on how to use the OLAP Cube Catalog. under their respective catalog names in the Available Cubes pane. page 340 – Connecting to Essbase servers. 344 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. OLAP cubes can be imported into a MicroStrategy project only by an architect with the “Import OLAP cube” privilege. Inc. Importing OLAP cubes OLAP cube importing is performed on the Cube Selection tab. you can expand or hide the cubes contained in this catalog.B Connecting to OLAP Cube Sources Project Design Guide – Connecting to Analysis Services 2005 servers. refer to the MicroStrategy Desktop online help (search for “OLAP Cube Catalog”). Configuring and Connecting to Intelligence Server of the MicroStrategy Installation and Configuration Guide. When you open the OLAP Cube Catalog. 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. . by default. all the OLAP cubes are displayed. For information on setting OLAP cube schema loading options for an OLAP cube source database instance. as shown in the image below. You can choose to load the schema for imported OLAP cubes when Intelligence Server starts or during OLAP cube report execution. Using the plus (+) or minus (-) sign next to a catalog name. refer to Chapter 5. SAP BW is used as the OLAP cube source but the procedure is similar for Analysis Services and Essbase.

To import OLAP cubes 1 In Desktop. an InfoCube is marked with a cube icon in blue. see MicroStrategy Tech Note TN4100-802-1879. Inc. log in to a project that is connected to an OLAP cube source. If you create new cubes in Analysis Services and the cubes are not being displayed in the OLAP Cube Catalog. 2 From the Schema menu.Project Design Guide Connecting to OLAP Cube Sources B A catalog is marked with an icon showing a folder containing a cube. you may have to modify some permissions in Analysis Services. Integrating OLAP cubes into MicroStrategy 345 . © 2007 MicroStrategy. select OLAP Cube Catalog. For details on how to make Analysis Services cubes available for import in the OLAP Cube Catalog. and a query cube is marked with a cube icon in green.

You can also select All to display the OLAP cubes for all catalogs. click the single arrow (>). and select an OLAP cube source database instance to connect to. To import all OLAP cubes. 346 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. a Database Instance dialog box opens. 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. the imported OLAP cubes are displayed in the Selected Cubes pane on the right. • 3 Select the Cube Selection tab. page 349. click OK. If you have multiple OLAP cube source database instances created for the project. create. and the OLAP Cube Catalog opens. the OLAP Cube Catalog opens. 4 From the Catalog drop-down list. using this dialog box. Once you select a valid OLAP cube source database instance. . The catalog contains all the OLAP cubes associated with it. select the OLAP cube to import. 7 Once imported. Inc. After importing OLAP cubes. you can build reports that access the imported OLAP cubes. you can use the OLAP Cube Catalog to map the OLAP cube data to MicroStrategy objects (see Mapping OLAP cubes. 8 Click Save to save your progress.) Once the data is mapped to MicroStrategy objects. click the double arrows (>>).B Connecting to OLAP Cube Sources Project Design Guide • If you have a single OLAP cube source database instance created for the project. 6 Use one of the following methods to import the OLAP cubes: • • To import the selected OLAP cubes. You can edit.

For example. Once the first OLAP cube for an OLAP cube source is imported into MicroStrategy. Integrating OLAP cubes into MicroStrategy 347 . you can right-click any OLAP cube in the Selected Cubes pane. Using the right-mouse click. a Data Explorer for that OLAP cube source is added to the MicroStrategy project.Project Design Guide Connecting to OLAP Cube Sources B To remove an OLAP cube. 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. You can find the Data Explorer in the Folder List of Desktop. Inc. you can also select the Update Structure option to synchronize with the updated definition of cube structures in the OLAP cube source. Importing OLAP cubes during report creation When you create an OLAP cube report. under the associated MicroStrategy project. and select Remove [cube name]. 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.

and so on) are created to describe the OLAP cube. For details. However. where you can search for a specific cube for your report by the cube’s name. columns. and then select the Display Managed Objects option so that managed objects are displayed in the 348 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy.B Connecting to OLAP Cube Sources Project Design Guide instance has been defined. tables. You can click Find at the bottom of this dialog box to open the Find dialog box. metrics. For detailed information. In the Search for Objects dialog box. 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. managed objects (attributes. one way to access managed objects is by using the Search for Objects function from the Tools menu on Desktop. from the Tools menu select Options. . Managed objects When an OLAP cube is imported into a project. see the related sections above on connecting to the different OLAP cube sources. refer to the MicroStrategy Desktop online help. Inc.

you can rename or edit any of them by right-clicking its name. By default. A managed object can be removed once it is no longer referenced by another object in the project. Inc. right-click an OLAP cube in Desktop and select Edit. are new and are part of the project. Once the logical entities are identified. In the context of OLAP cube sources. Mapping OLAP cubes When an architect defines a project. page 344. metrics. When you. as the architect. Once the managed objects are listed in the search result. This model is referenced by the SQL Engine to generate SQL at run time. see the Managing Your Applications chapter of the MicroStrategy System Administration Guide. For example. an architect might identify that the key for the Customer attribute exists in the table LU_CUSTOMER. Intelligence Server creates new attributes. such as SAP BW. and hierarchies that reflect the data and levels of the imported OLAP cube. For more information on removing a database instance and its related managed objects. contains all the metadata information necessary to define a logical model and physical model. referred to as managed objects. as described in Importing OLAP cubes. a MicroStrategy OLAP cube is created that maps to the definition of the source cube in the OLAP cube source. they © 2007 MicroStrategy. you can simply select a cube by using the OLAP Cube Catalog or Select Cube dialog box.Project Design Guide Connecting to OLAP Cube Sources B search result. need to add an OLAP cube to a project in MicroStrategy. Integrating OLAP cubes into MicroStrategy 349 . Although these objects. the architect can then define a logical and physical model in the MicroStrategy metadata. To do this. such as attributes and facts. The removal of unused managed objects is usually performed by an administrator. much of the process centers on identifying logical entities. When an OLAP cube is imported into MicroStrategy. After you have imported an OLAP cube. that exist in physical tables. you can 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. an OLAP cube. instead of a single table.

you can remove the OLAP cube source database instance and all of its associated managed objects. 350 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. which ensures that a consistent logical model is maintained. For more information on the benefits of remapping OLAP cube data to project attributes. This allows data to be joined across sources in Report Services documents. Inc. it can be used to build reports and documents in MicroStrategy. For more information on managed objects in OLAP cube reports. In addition. see the Reporting on External Data Sources: OLAP Cube Reports chapter of the MicroStrategy Advanced Reporting Guide. Remapping OLAP cube data to existing attributes can also facilitate the use of MicroStrategy features such as security filters. you can remap OLAP cube data to existing attributes in a MicroStrategy project rather than new managed objects. A new schema is created for each OLAP cube source database instance used in a MicroStrategy project. Once an OLAP cube is mapped. .) For example. page 356. see the Managing Your Applications chapter of the MicroStrategy System Administration Guide. see Why do you need to remap OLAP cubes?.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 steps on how to perform these schema cleanup tasks. If you decide to discontinue the use of OLAP cube reports. a new managed object named Year has no relation to the Year attribute in the Tutorial project connected to the data warehouse.

you can map attribute forms for each attribute contained in the imported cube. only the ID and DESC forms are automatically mapped for each attribute.Project Design Guide Connecting to OLAP Cube Sources B Using the Cube Mapping feature in the OLAP Cube Catalog shown below. © 2007 MicroStrategy. Inc. As shown in the image above: • The Physical View in the left-hand column represents the cube structure in the OLAP Cube Source. with the same symbols for hierarchies and attributes as in standard reports. you can use the plus (+) sign next to the attribute levels to display the attribute forms. 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. Integrating OLAP cubes into MicroStrategy 351 . By default. 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. For SAP BW. • In the Physical View column.

and Description in SAP BW. Technical Name. you can view the information on its Name. 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. However. the columns are often returned as a string of characters. the Prompt Generation Wizard is displayed. you can perform the following manipulations by right-clicking the name in the Logical view column: • Edit the attribute or metric. In the case of OLAP cube data that is mapped to attributes. An ID form must be mapped for each attribute.B Connecting to OLAP Cube Sources Project Design Guide By default. The Show Technical Names option applies to SAP BW OLAP cubes only. . refer to Supporting SAP BW variables. page 308. In the Properties dialog box. only the ID and DESC forms are displayed. Map the characteristic or key figure to an existing attribute or metric in the MicroStrategy project. 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. note that when you select Edit. For MicroStrategy attributes and metrics. you can also perform the above-mentioned manipulations. Check the Properties of the characteristic or key figure. Manually setting column data types for OLAP cube data When OLAP cube data is mapped to MicroStrategy objects. • • • For variables. Inc. For more information. This option opens the Attribute Editor to edit attributes and the Metric Editor to edit metrics. This is because variables in SAP BW are represented as prompts in MicroStrategy. MicroStrategy retrieves the column data type through MDX. 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. This can be the case even with ID columns of data that are of a 352 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy.

Inc. you have OLAP cube data that is mapped to a Product attribute in MicroStrategy. You can access the OLAP Cube Editor by right-clicking an imported OLAP cube and selecting Edit.0 you can manually select the column data type that is applied to a column of OLAP cube data mapped to an attribute. 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. 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. Integrating OLAP cubes into MicroStrategy 353 . The ID attribute form for Product is returned as a string.1. 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. you can then include the two OLAP cube reports as datasets of a Report Services document and group the two Product attributes. starting with the step to expand data in the Physical view column. © 2007 MicroStrategy. For example. or as a later modification with the OLAP Cube Editor. but you know that its associated OLAP cube column is of type integer. but the same steps apply for the OLAP Cube Editor. By setting the Product ID attribute form to read the OLAP cube data as an integer. OLAP cube data that is mapped to MicroStrategy metrics is automatically converted to a numeric data type and thus does not need its column data type to be manually set. The following procedure uses the OLAP Cube Catalog. You can do this same mapping for another OLAP cube and create reports including the Product attribute.Project Design Guide Connecting to OLAP Cube Sources B numeric type such as integer. Starting in MicroStrategy 8.

354 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. 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. expand the OLAP cube data until you find the OLAP cube column data for which to manually set the data type. 8 Clear the Use default from source check box. select OLAP Cube Catalog. 4 Select the Cube Mapping tab. page 340 2 From the Schema menu. see one of the following sections depending on your OLAP cube source: • • • • Connecting to SAP BW servers. • • If the project connects to only one OLAP cube source. For information on connecting to an OLAP cube source. From the Select the Database Instance drop-down list. Inc.B Connecting to OLAP Cube Sources Project Design Guide 1 Log in to a project that is connected to an OLAP cube source. The Column Editor — Definition dialog box opens. The OLAP Cube Catalog: Cube Selection tab opens. page 337 Connecting to Analysis Services 2005 servers. 6 In the Physical view column. select the OLAP cube source database instance you want to connect to and click OK. page 334 Connecting to Analysis Services 2000 servers. select the OLAP cube you want to map to MicroStrategy objects. page 327 Connecting to Essbase servers. The OLAP cube data is displayed in the pane below. . 5 From the Catalog\Cube drop-down list. The Cube Mapping tab opens. If the project connects to more than one OLAP cube source the Database Instance dialog box opens. 7 Right-click the OLAP cube column data and select Data Type.

When Category. and Item are displayed on the report there is an empty cell for the Subcategory of Item number 22. precision. in a Product hierarchy that includes Category. • • • © 2007 MicroStrategy. • Balanced hierarchies have an equal number of levels in each branch of the hierarchy. select which data type to map the OLAP cube data as. specify the byte length. all hierarchies of an OLAP cube are treated as balanced hierarchies. 11 Click OK to save your changes and return to the OLAP Cube Catalog. Subcategory. and Month one branch might only have data down to the Quarter level. Subcategory. However. Quarter. 12 Click Save and Close to save your changes to the OLAP cube and exit the OLAP Cube Catalog. a Product hierarchy may contain the levels Category. For example. if you know that the structure of a hierarchy is unbalanced or ragged you must set the hierarchy’s properties to reflect its structure. 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. 10 Depending on the data type selected.Project Design Guide Connecting to OLAP Cube Sources B 9 From the Data type drop-down list. in a Time hierarchy that includes Year. and Item each branch would descend to a particular item. The terms balanced. unbalanced. Unbalanced hierarchies have at least one branch that does not descend to the lowest level. Unbalanced and ragged hierarchies By default. For example. and ragged are used to describe the different set of characteristics of hierarchical sets of data. Integrating OLAP cubes into MicroStrategy 355 . Inc. For example. Subcategory. Ragged hierarchies have at least one branch that includes a member whose logical parent is not the level above that member. and scale for the data type. and Item but Item number 22 does not have a Subcategory associated with it.

Set a hierarchy as unbalanced or ragged 1 In the OLAP Cube Catalog. 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. Why do you need to remap OLAP cubes? Although you can use the automatically generated managed object attributes. 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.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. 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. please refer to MicroStrategy Tech Note TN1100-000-0636. For detailed steps on mapping and remapping objects from OLAP cube sources to MicroStrategy objects. This modification also allows you to perform date qualifications on the mapped MDX property data. 2 On the Hierarchies tab. refer to the MicroStrategy Desktop online help (search for the “Mapping OLAP cubes” topic). A hierarchy in the Physical View column is represented with a green stacked boxes symbol. The Properties dialog box is displayed. metrics. right-click the hierarchy name in the Physical View column and select Properties. For information on how to support these date forms and qualifications.

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. MicroStrategy security filters can be applied to attributes in OLAP cube reports. the security filter on Year is applied. 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. they can be remapped to project attributes that participate in the ROLAP schema. However.Project Design Guide Connecting to OLAP Cube Sources B • 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. For example. This also prevents maintenance issues because reports need to be modified if an OLAP cube is remapped after the report is created. 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. then Year can be used to group the data within a document. For example. Inc. 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. three OLAP cubes can share the same managed object metric named Revenue. • • • You can remap the levels of an OLAP cube. Data can be joined across sources within a Report Services document. In the case of attributes. For example. Integrating OLAP cubes into MicroStrategy 357 . if an OLAP cube report and a standard report both use the Year attribute. metrics and hierarchies can only be remapped to other managed object metrics and hierarchies that are mapped to OLAP cube source data. it is recommended that you do the remapping initially so that subsequent users can take advantage of the mapping. © 2007 MicroStrategy.

The drawback with this setup is that you cannot create a relation between your OLAP cube data and your project data. also shows two logical models. you can map the attributes within the OLAP cube to existing project attributes. The one on the left exists in a specific OLAP cube. Example 2. The diagram below shows two logical models. Quarter. shown in the diagram below. and Month. Since this relation is not created. and the one on the right exists in a MicroStrategy project. Although both models have a Time hierarchy. you can create a Report Services document that contains Year. you cannot join data from these different sources in a Report Services document and you cannot support project security filters in OLAP cube reports. This feature allows you to quickly start creating reports for your OLAP cube data. none of the individual attributes are shared. With this technique. Inc. Quarter. . and Month information for both your 358 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. 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 R e g io n Ye a r C u b e Ye a r Q u a r te r M onth of Ye a 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 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.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. The difference between the two examples is that the OLAP cube has been partially remapped so that it shares the attributes Year.

For information on creating calculated expressions. Quarter. and Month are applied to OLAP cube reports that include these mapped attributes. Creating metrics from OLAP cube data with MDX and compound metric techniques When you map your OLAP cube data into MicroStrategy. Therefore.Project Design Guide Connecting to OLAP Cube Sources B data warehouse and OLAP cube sources. Metrics created with MDX combine the robust set of MDX functions and expressions with MicroStrategy analytical tools such as prompts. see the Designing Documents chapter of the MicroStrategy Report Services Document Creation Guide. any security filters for Year. In addition. changes to the Time dimension apply to OLAP cubes in the project that contain this dimension. Therefore. © 2007 MicroStrategy. except by using calculated expressions in Report Services documents. that change applies to all the OLAP cubes that share that dimension. Metrics created to map to your OLAP cube data are related only to their associated OLAP cube. You can also use basic arithmetic expressions to create these advanced metrics from OLAP cube data. these metrics cannot be directly integrated with data from a separate relational data source. 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 M o nt h o f Ye a r C usto m e r S ta te Q ua rte r C a ll C e nte 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. In this case. you can take advantage of MDX (MultiDimensional eXpressions) to create advanced metrics. when a level is remapped. Inc. Integrating OLAP cubes into MicroStrategy 359 .

-. These metrics can also reference multiple MicroStrategy metrics within the OLAP cube with an expression such as Revenue . you can create your own custom MDX to return data for a metric. and so on). page 366). For examples of smart metrics. 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.*. page 363. see the MicroStrategy Basic Reporting Guide. To use MDX to create your calculated measures you must enclose MDX in double quotes (“”). such as Discount * 1. to build a Profit metric. For general information on smart metrics. see How to build analysis into metrics with custom MDX. 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. where Discount is a metric mapped to data in the OLAP cube. 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. 360 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy.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./. This technique allows you to use MDX functions and flexibility to query and report on your OLAP cube data.Total Expenses. see the MicroStrategy Advanced Reporting Guide. If you do not make the metric a smart metric you can only use basic operators (+. The MDX you create is passed to your OLAP cube source to be executed and to return the data. • MDX customization: Rather than relying only on MicroStrategy to create MDX to return data from your OLAP cube source. . You can also use prompts in these compound and custom MDX metrics (see Using prompts within OLAP cube metrics. The expression can be as simple as a metric multiplied by a constant value. 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. For tips and insights on how to build analysis with MDX in MicroStrategy. where Revenue and Total Expenses are both metrics. Inc.5.

select OLAP Cube Catalog. 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. page 340 2 From the Schema menu. From the Select the Database Instance drop-down list. • • If the project connects to only one OLAP cube source. 3 Move all the OLAP cubes to import from the Available Cubes pane to the Selected Cubes pane by using the > button. The OLAP Cube Catalog: Cube Selection tab opens. page 327 Connecting to Essbase servers. starting with the step to access the Edit menu. the steps below apply for the OLAP Cube Editor. 4 Select the Cube Mapping tab. see one of the following sections. page 337 Connecting to Analysis Services 2005 servers. the OLAP Cube Catalog: Cube Selection tab opens. After right-clicking an OLAP cube and selecting Edit to access the OLAP Cube Editor. © 2007 MicroStrategy. Inc. page 334 Connecting to Analysis Services 2000 servers.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. The following procedure uses the OLAP Cube Catalog. select the OLAP cube source database instance to connect to and click OK. depending on your OLAP cube source: • • • • Connecting to SAP BW servers. These metrics can also be created as a later modification to an OLAP cube with the OLAP Cube Editor. If the project connects to more than one OLAP cube source the Database Instance dialog box opens. Integrating OLAP cubes into MicroStrategy 361 .

362 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy.B Connecting to OLAP Cube Sources Project Design Guide 5 From the Catalog\Cube drop-down list. enter your custom MDX in the Definition pane of the Metric Editor. 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. Validating MDX verifies that the entire expression is enclosed in double quotes. 6 From the Edit menu. The Save As dialog box opens. see Using prompts within OLAP cube metrics. 9 In the Object name text field.[Discount Amount] * 1.5” You cannot validate MDX in the Metric Editor as you can for a standard expression that is not enclosed by double quotes. 7 Create the expression for your metric: • If you are creating a compound metric. enter a name for your metric. arithmetic operators. The OLAP cube data is displayed in the pane below.Cost to create a Profit metric. you can simply drag and drop metrics from the OLAP cube’s Metrics folder. Inc. For example. For example. if you have Revenue and Cost metrics in your OLAP cube you can create the expression Revenue . For an example of creating a metric that includes a prompt. page 366. Make sure to enclose the entire expression in double quotes. 8 Click Save and Close. you can enter the following: “[Measures]. The Metric Editor opens. select Add New Compound Metric. while also including any required constants. . it does not validate the syntax of the expression. select the OLAP cube to map to MicroStrategy objects. and MicroStrategy analytical and aggregation functions. • If you are creating a metric using custom MDX. 10 Click Save to save your metric.

Project Design Guide Connecting to OLAP Cube Sources B 11 Click Save and Close to save your changes to the OLAP cube.1.1. Inc. refer to the following MicroStrategy Tech Notes: • • TN5200-81x-2345—How to create customized metric expressions for OLAP cube sources in MicroStrategy 8.1. 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. For additional best practices and examples. This allows you to further combine the analysis capabilities of MDX and MicroStrategy. TN5200-81x-2342—How to write a custom metric formula in MDX to ignore grouping on a cube dimension in MicroStrategy 8.1. Integrating OLAP cubes into MicroStrategy 363 .x TN5200-81x-2344—How to write a custom metric formula in MDX to implement a transformation in MicroStrategy 8. only basic principles of analysis with the use of MDX and MicroStrategy is provided.x TN5200-81x-2343—How to write a custom metric formula in MDX to filter on an attribute in MicroStrategy 8. To use MDX to create your metrics you must enclose MDX in double quotes (“”).x Creating such analysis requires appropriate knowledge of both MDX and MicroStrategy. This section provides some tips and best practices on how to build analysis into metrics with custom MDX. Be aware that MicroStrategy does not validate any custom MDX created by users to build metrics for OLAP cubes. • • Basics Creating your own custom MDX allows you to draw further analysis from your OLAP cube source into MicroStrategy.x. “[Measures]. For example. MDX syntax and functionality is not described in depth in this section. © 2007 MicroStrategy.[Total Sales]” is valid syntax for a metric defined with MDX.

You can also perform basic arithmetic in your MDX. Report designers can include these metrics on reports to view multiple perspectives of data on the same report. In 364 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. For example. A conditional metric allows you to apply a filter to only one metric on a report while not affecting the other metrics. as shown below: “sum(YTD([Quarter]. For example. Inc. the function is passed to the OLAP cube source and processed as a pass-through function. as shown in the report below.CurrentMember). you can also utilize MDX functions to create more advanced analysis. you can also display revenue for a certain category such as electronics. Conditional metrics Using MDX. .06” Along with these simple expressions. [Measures].[Total Sales] * .[Profit])” This expression returns year-to-date values by quarter for profit data.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. For example. the following expression applies a multiplier to the Total Sales data: “[Measures]. When you include an MDX function in your custom MDX. you can create conditional metrics in MicroStrategy from your OLAP cube data. you can use the MDX year-to-date (YTD) function to create transformation-style analysis on your OLAP cube data. along with viewing your total revenue on a report.

The values that identify data depend on how you have defined data in your OLAP cube source.[Revenue]. The report shown below uses this metric to compare total revenue with electronics revenue. © 2007 MicroStrategy.[Year]. Using the ApplySimple function. Inc. meaning they will produce the same MDX every time.Project Design Guide Connecting to OLAP Cube Sources B the example expression below. you can include prompts in your MDX to provide dynamic analysis on your OLAP cube data. you can create the same metric to return electronics revenue for only the year 2006. bold highlights the part of the expression (including the comma) that applies the condition to the revenue data: “([Measures]. 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. a second condition on the year is included by adding another comma and conditional expression: “([Measures]. 2 identifies the electronics category. [2006])” Prompts All of the MDX examples in the sections above are static expressions.[2].[Revenue]. You can include more than one condition for each metric. In the example expression below.[2])” In the example above. For example. Integrating OLAP cubes into MicroStrategy 365 .[Category].[Category].

?valueprompt) In the example syntax above. page 364.[Revenue]. This adds flexibility to your queries.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.#0)”.. you must use the ApplySimple function to 366 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. For example. For metrics created with compound metric techniques without any custom MDX. .. you can allow users to choose what category to view revenue for. You can also use this technique with the conditional metrics techniques described in Conditional metrics. For metrics created using MDX expressions. When the metrics are included on a report and the report is run. ?elementlistprompt) For more information on and a procedure for creating metrics in OLAP cubes with prompts. The syntax for including a prompt as an object to replace a placeholder is ?promptname. Using prompts within OLAP cube metrics If you are creating new metrics in your OLAP cube. #0 is a placeholder in the MDX expression for the value prompt. Inc. the prompts are displayed to the user for completion. ApplySimple(“([Measures].object0..[Total Sales] / #0)” . ApplySimple(“([Measures]. allowing users to determine the data to see on the report. you can also include MicroStrategy prompts with the metrics. rather than always returning the revenue data for electronics. you can simply include a prompt in the metric definition.. see the Using prompts within OLAP cube metrics section below. you can include an element list prompt on the Category attribute of the OLAP cube as shown below.object1. To provide this analysis to users.B Connecting to OLAP Cube Sources Project Design Guide ApplySimple(“MDX expression with placeholders for objects”.

• ApplySimple(“([Measures]. Users can then choose to view revenue data for different categories such as Books or Music. ?CategoryElementPrompt) This expression creates a Revenue metric. entered by the user running the report. you can enter expressions similar to the following: • ([Discount Amount] * ?constantprompt) This expression applies a special discount amount. 3 Click Save and Close. Integrating OLAP cubes into MicroStrategy 367 . 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. 2 Enter your expression in the Definition pane of the Metric Editor.#0)”. which is conditional on an element list prompt answered by the user running the report. page 361) until the step to create an expression for the metric. © 2007 MicroStrategy. 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. For example. Make sure to enclose the entire expression in double quotes. The Save As dialog box opens. 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.[Revenue]. Inc.Project Design Guide Connecting to OLAP Cube Sources B include prompts in the metric definition.

. a list of metrics that are dependent on the metric you are removing is returned. You can remove the compound metric from the report rather than deleting the report. you must first remove the Profit Margin metric.B Connecting to OLAP Cube Sources Project Design Guide 4 In the Object name text field. you import an OLAP cube. 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. enter a name for your metric. You must remove all of the metrics and reports which depend on the metric you are trying to remove. and its data is automatically mapped to MicroStrategy metrics. 6 Click Save and Close to save your changes to the OLAP cube and exit the OLAP Cube Catalog. you create a Profit Margin metric that uses the Profit metric you just created. This removes the dependency between the metric and the report. If the Profit metric is included on any reports. If a compound metric of an OLAP cube has been added to any reports. a search for dependent objects is automatically triggered. 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. This makes the Profit Margin metric dependent on the Profit metric. 368 Integrating OLAP cubes into MicroStrategy © 2007 MicroStrategy. a list of reports that depend on the metric is also returned. and the Profit Margin metric is returned. Removing compound metrics from OLAP cubes When you remove metrics based on multiple metrics of an OLAP cube. Then you can remove the metric. When you try to remove a metric with dependent metrics. Once this metric is created in your OLAP cube. dependencies may need to be resolved before you can remove the metric. If you try to remove the Profit metric. and you can then remove the metric from the OLAP cube. For example. To remove the Profit metric. 5 Click Save to save your metric and return to the OLAP Cube Catalog. Inc.

table aliases. with a focus on how you can use the logical view feature to take advantage of the enhanced schema support in MicroStrategy. This chapter introduces you to the different types of logical tables. 369 . which point to physical tables in the data warehouse. Inc. and logical views. logical views are defined using SQL queries against the data warehouse. logical views are created using the Table Editor. LOGICAL TABLES Introduction Logical tables represent tables in the data warehouse.C C. © 2007 MicroStrategy. There are three types of logical tables in the MicroStrategy environment: logical tables. Different from the logical tables. While logical tables are set up in a project by using the Warehouse Catalog.

Using the Logical Table Editor. In the MicroStrategy Tutorial. Logical views are created using the Table Editor. These physical tables are referenced in the SQL that is generated for the report. Table aliasing is used to create attribute roles (see Attributes that use the same lookup table: Attribute roles.C Logical Tables Project Design Guide Logical tables Logical tables are MicroStrategy objects that form the foundation of a schema. A table alias can have a different name from the physical table. A logical table is created for each physical table that is imported into a project. based on which attributes. the logical view can be used in the same way as the Type 1 logical table. While physical tables in a data warehouse consist of columns. and other schema objects can be defined. One physical table can have more than one table aliases. page 175). facts. These attributes and facts are part of the report definition that the MicroStrategy Engine refers to when a report is executed. logical tables and all the other schema objects are stored in the Schema Objects folder. A table alias is created outside of the Warehouse Catalog. It does not point directly to a physical table and is defined using a SQL query against the warehouse. The logical view is also referenced in the SQL that is generated for the report. Once created. 2 Table alias: is an additional logical table that points directly to an existing physical table. Inc. This type of logical table maps directly to physical tables in the data warehouse. logical tables in the MicroStrategy schema consist of attributes and facts. the whole SQL query is displayed in the place of physical tables as for Type 1 logical tables. 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. using the Warehouse Catalog. There are three types of logical tables: 1 Logical table: is a logical representation of a table that the Engine uses to generate SQL. . 370 Logical tables © 2007 MicroStrategy. 3 Logical view: is a logical table that points to a SQL statement instead of directly to a physical table.

How should I use logical tables? 371 . then define the new attributes using the appropriate tables. you need to create an attribute in the logical model for each of the roles.Project Design Guide Logical Tables C 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. Inc. Logical views are a little different from the above-mentioned logical tables and table aliases for the following reasons: • • • Logical views do not map directly to physical tables in the data warehouse. For example. please refer to Attributes that use the same lookup table: Attribute roles. 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 more information on how to use the Warehouse Catalog. First. To create a table alias. instead of being imported from a data warehouse or duplicated from existing logical tables. Logical views are created from scratch. if the Customer table is used to represent both Ship to Customer and Bill to Customer. right-click the logical table name and select Create Table Alias. Based on these tables. Basically. One way to do this is to create explicit table aliases. create a table alias by copying an existing logical table and giving it a new or different name. For detailed information on attribute roles. page 175. which is accessed from the Schema menu. please refer to the MicroStrategy online help (search for “Step-by-step instructions to create a table alias”). For step-by-step instructions. © 2007 MicroStrategy. you can create MicroStrategy schema objects. When an attribute plays more than one role. Logical views are defined using SQL queries. please refer to the MicroStrategy online help (search for “Warehouse Catalog”). you can create a table alias to resolve the double usage case. such as attributes and facts.

please refer to Logical view examples. 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. Whenever you create or add logical tables. once logical views are created. 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. such as the following: • • • • Slowly-changing dimensions Attribute form expressions from multiple tables Consolidated dimension tables Recursive hierarchies For common usage examples. .C Logical Tables Project Design Guide However. you need to update the schema. There are many common modeling scenarios that are easier to manage with the use of logical views. page 376. The Update Schema option can be accessed from the Schema menu. table aliases. they can be used in the same way as the regular logical tables (brought into the project using the Warehouse Catalog). Inc. 372 How should I use logical tables? © 2007 MicroStrategy. or logical views to the project.

on the other hand. while the Mapping panel is where you map for the columns returned by the SQL query. Object Browser lists all tables and columns that have been imported into the project. are created in MicroStrategy Desktop using the Table Editor. Logical views. Creating logical tables 373 . © 2007 MicroStrategy. As illustrated in the following image. For detailed instructions. and table aliases are created by duplicating existing logical tables.Project Design Guide Logical Tables C Creating logical tables Most logical tables are brought into the project by using the Warehouse Catalog. Inc. 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. 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). please refer to the online help (search for “Creating logical views”). One way to access the Table Editor is to select New from the File menu and choose Logical Table. Detailed instructions on how to create them are provided in the online help (search for “Tables”).

you can also drag and drop columns from the Object Browser to the Column Object cell. Please check your database for best usage. these expressions cannot be nested in the SQL because this would result in invalid SQL syntax. you map an existing column to the logical view. . The Table Editor is displayed with the Physical View tab selected by default. the change will affect all the tables with that column. It is recommended that you use derived tables to define logical views because the logical view SQL syntax becomes nested inside SQL statements generated by the Engine. type in your SQL statement. The names of the columns must match exactly the column aliases defined in the SQL statement. By doing this. However.C Logical Tables Project Design Guide To create a logical table in the Table Editor 1 From the File menu. you inherited the data type of that column. 2 In the SQL Statement panel. 374 Creating logical tables © 2007 MicroStrategy. This creates a new column. the order of the columns does not have to match the order in which the column aliases appear in the SQL statement. 4 Type in the column name under Column Object. 5 Select a Data Type for the column by using the drop-down list. Inc. select New and then Logical Table. 3 Click Add to map columns returned by the SQL statement. Alternatively. Keep in mind that if you change the data type. If you used an existing column in the mapping in Step 5. Although common table expressions (CTEs) are also supported for some databases. You can drag and drop columns from the Object Browser to insert into the statement).

make sure that your RDBMS is optimized to answer the query that you create. select Update Schema to ensure that the new logical table is loaded into the project. the statistics log does not contain any information about the actual physical tables accessed. are not nested in the SQL because this would result in invalid SQL syntax. The Engine generates derived table syntax to represent the logical view. In addition. The same holds true if you use a view in the database. It is recommended that you use derived tables to define logical views. CTEs. For a logical view—which maps to a SQL statement—the Engine inserts the SQL syntax in the FROM clause. © 2007 MicroStrategy. It is your responsibility to ensure the accuracy and validity of your SQL statements. 8 From the Schema menu. 7 Save and close the logical table. logical views are generated as either a derived table or a common table expression (CTE) depending on the type of database that you use. if applicable. in which case table objects accessed would are not logged either. you should also understand that the SQL query entered for logical views is not modified in any way by MicroStrategy. Creating logical tables 375 .Project Design Guide Logical Tables C 6 Modify the Precision and Scale of the column. Derived tables are advantageous because they are nested in the SQL generated by the Engine. In the SQL generated for a report. please check your database. the logical view is logged instead. Using SQL for logical views Since SQL queries are the key to creating logical views. however. you should be experienced with using SQL before you use the logical view feature. it inserts the name of the table into the FROM clause. Therefore. For best usage. although CTEs are also supported by some databases. When the Engine needs to use a logical table that maps directly to a physical database table. Because the MicroStrategy Engine does not parse through the SQL syntax. Inc.

you may double count if you have to join to a table where that attribute is part of the key. the logical view simply appears as additional syntax in the report SQL generated by MicroStrategy. for example. Logical view examples The following business cases are intended to help you understand how you can use the logical view feature in your applications. thus affecting element browsing requests that display a list of attribute elements. Market. Usually. Inc. and Region. often two problems arise: • The model cannot support fact tables at the level of attributes that are not keys. The following is an example lookup table for Store. While it is possible to model a schema with such a dimension table. If there is no distinct list of attribute elements. the MicroStrategy Engine joins the fact table with one lookup table and does the aggregation. in one-SQL-pass reports.C Logical Tables Project Design Guide The results of logical views are not cached. when populating pick lists for prompts. Lookup_store Store_ID Store_Name Market_ID Market_Name Region_ID Region_Name Level 376 Logical view examples © 2007 MicroStrategy. • Too many rows in the dimension table may slow down the SELECT DISTINCT query. 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). . This restriction applies to summary tables as well as to intermediate results that may be generated by the SQL Engine.

Inc. a direct join between the fact table and the above lookup table may result in double-counting.Sales) From (select Market_ID. if the requested fact table is at the Market or Region level. 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. a11. Usually.Project Design Guide Logical Tables C In this table. the following report SQL is generated: Select 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.Market_ID.Region_ID From Lookup_store Where level=1 Then use this table as the lookup table for Market.Market_ID = a12. When it is joined with a Market-level fact table (Market_Sales).Region_ID from Lookup_Store where level=1) a11. you can use the Logical View feature to define another logical table Lookup_Market as follows: Select Market_ID.Market_Desc. Market and Region are not the keys. Logical view examples 377 .Market_ID Group by a11.a11. Market_Name.Market_ID. To avoid that. Therefore. For example. Market_Sales a12 Where a11. Market_Name. the case is on Date columns. SUM(a12. F_Table1 Ship_Date Order_ID Fact1 © 2007 MicroStrategy.

F_table2 Where F_table1.Order_ID=F_table2. it may be better to model separate dimensions.C Logical Tables Project Design Guide F_Table2 Order_Date Order_ID Fact2 Using the Logical View feature. 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.Fact2 From F_table1.Order_ID The new logical table (logical view) looks like the following table. “Slowly” typically means after several months or even years. 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. For example. F_table1. . if dimensional relationships change more frequently. and a new attribute can be defined on the Cycle_Time column. a Type I SCD 378 Logical view examples © 2007 MicroStrategy. a company may annually reorganize their sales organization or recast their product hierarchy for each retail season. for instance). Indeed.Order_ID. Kimball has further coined different distinctions among ways to handle SCDs in a dimensional model. For example. Ralph Kimball has been particularly influential in describing dimensional modeling techniques for SCDs (see The Data Warehouse Toolkit. Fact1. Inc. dimensional hierarchies are presented as independent of time. SCDs are well documented in the data warehousing literature. Usually.

page 43. The discussion below is based on an example sales organization that changes slowly in time as the territories are reorganized. a Type II SCD preserves the history of a dimensional relationship. For information on compound keys. show me sales by District according to the way Districts are organized today. and Kelly moved from District 38 to 39 on 7/1/2004. For example. Inc. As-is vs. sales representatives switch districts in time. For example. Logical view examples 379 . “As-was” analysis presents a historical view of the slowly changing relationships. In the example below. Sales Rep Jones moved from District 37 to District 39 on 1/1/2004. They also provide you an easy way to specify which type of analysis you would like to perform. please refer to Lookup tables: Attribute storage. © 2007 MicroStrategy. for example. • The techniques described here provide the flexibility to perform either type of analysis. and so forth.Project Design Guide Logical Tables C presents only the current view of a dimensional relationship. 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. show me sales by District according to the way Districts were organized at the time the sales transactions occurred. 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.

. FACT_TABLE Sales_Rep_ID 1 2 3 1 2 3 2 3 4 Trans_Dt 9/1/2003 9/10/2003 9/15/2003 3/1/2004 3/10/2004 3/15/2004 9/5/2004 9/15/2004 9/20/2004 Sales 100 200 150 200 250 300 125 275 150 To specify the MicroStrategy schema 1 Create a logical view to represent just the current District-Sales Rep relationships. Inc. such as a transaction date.C Logical Tables Project Design Guide LU_SALES_REP Sales_Rep_ID 1 2 3 4 1 3 Sales_Rep_Name Jones Smith Kelly Madison Jones Kelly District_ID 37 37 38 38 39 39 Eff_Dt 1/1/1900 1/1/1900 1/1/1900 1/1/1900 1/1/2004 7/1/2004 End_Dt 12/31/2003 12/31/2099 6/30/2004 12/31/2099 12/31/2099 12/31/2099 When using this type of dimensional lookup table. LVW_CURRENT_ORG 380 Logical view examples © 2007 MicroStrategy. the fact table must include a date field.

Trans_Dt between L. 4 Define the following attributes: • Sales Rep: – @ID = sales_rep_id.Sales_Rep_ID) where F. sum(sales) sales from LU_SALES_REP L join FACT_TABLE F on(L. which captures the Sales Rep-District relationships that existed at the time the transactions occurred.End_Dt group by District_ID. Inc. @Desc = sales_rep_name – Tables: LU_SALES_REP (lookup). LVW_CURRENT_ORG – Child: Sales Rep • Historical District: – @ID = district_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. LVW_HIST_DISTRICT_SALES select District_ID. LVW_CURRENT_ORG. @Desc = district_name © 2007 MicroStrategy. FACT_TABLE • Current District: – @ID = district_id. Trans_Dt.Project Design Guide Logical Tables C select Sales_Rep_ID. @Desc = district_name – Tables: LU_CURRENT_DISTRICT (lookup). Trans_Dt 3 Create a table alias LU_CURRENT_DISTRICT for LU_DISTRICT. The resulting view is an “as-was” or historical view.Sales_Rep_ID = F. Logical view examples 381 . resulting in a fact view at the District level.Eff_Dt and L.

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 Current District Sales Rep Historical District Sales Rep Date Sales LU_TIME Date LVW_HISTORICAL_ DISTRICT_SALES Month Historical District Date Sales 382 Logical view examples © 2007 MicroStrategy.C Logical Tables Project Design Guide – Tables: LU_DISTRICT (lookup). LVW_HIST_DISTRICT_SALES – Child: Sales Rep • Date: – @ID = date_id. trans_dt – Tables: LU_TIME (lookup) . Inc. LU_SALES_REP. LVW_HIST_DISTRICT_SALES • Month: – @ID = MONTH_ID – Tables: LU_TIME (lookup) 5 Define the Sales fact: • • Expression: sales Tables: FACT_TABLE. . FACT_TABLE.

Date_ID) join LU_DISTRICT a13 on (a11.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. Sales Resulting SQL Logical view examples 383 .District_Name) District_Name. a12.District_ID District_ID.Sales_rep_ID = F.sum(sales) sales from LU_SALES_REP L join FACT_TABLE F on (L. Month.District_ID =a13.Sales_rep_ID) where F. Sales Resulting SQL Select a11.EFF_DT and L.SALES) WJXBFS1 From (select District_ID.Month_ID Month_ID.District_ID) group by a11.Distrcit_ID.Trans_dt = a12.END_DT group by District_ID. sum(a11. Report definition: Current District. a12. Trans_dt.Month_ID • Report results As-is analysis Specify the “as-is” analysis by using the Current District attribute on reports: • • © 2007 MicroStrategy.trans_dt between L. max(a13. Inc. Trans_dt) a11 join LU_TIME a12 on (a11. Month.

Trans_dt = a13. An example set of records is shown below.District_ID) group by a12.District_Name) District_Name. sum(a11.Month_ID Month_ID. District_ID from LU_SALES_REP where END_DT = '12/31/2099')a12 on (a11. Another common characteristic is to include an indicator field that identifies the current relationship records.C Logical Tables Project Design Guide select a12.District_ID = a14.Sales_Rep_ID) join LU_TIME a13 on (a11.Sales_Rep_ID = a12. a13.Date_ID) join LU_DISTRICT a14 on (a12.District_ID. LU_SALES_REP Sales_Rep_CD 1 2 3 Sales_Rep_ID 1 2 3 Sales_Rep_Name Jones Smith Kelly District_ID 37 37 38 Current_Flag 0 1 0 384 Logical view examples © 2007 MicroStrategy.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. . Inc.SALES) WJXBFS1 from FACT_TABLE a11 join (select Sales_rep_ID. a13.District_ID District_ID. max (a14.

A transaction date field may or may not exist. District_ID from LU_SALES_REP where Current_flag = 1 2 Create a table alias LU_CURRENT_DISTRICT for LU_DISTRICT. Inc. © 2007 MicroStrategy. FACT_TABLE Sale-Rep_CD 1 2 3 5 2 3 2 6 4 Sale 100 200 150 200 250 300 125 275 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. Logical view examples 385 . the fact table must also include the surrogate key.Project Design Guide Logical Tables C Sales_Rep_CD 4 5 6 Sales_Rep_ID 4 1 3 Sales_Rep_Name Madison Jones Kelly District_ID 38 39 39 Current_Flag 1 1 1 When using this type of dimensional lookup table.

LVW_CURRENT_ORG – Child: Sales Rep • Historical District: – @ID = district_id. FACT_TABLE • Sales Rep: – @ID = sales_rep_id. . Inc. LVW_CURRENT_ORG – Child: Sales Rep Surrogate • Current 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). @Desc = district_name – Tables: LU_CURRENT_DISTRICT (lookup). FACT_TABLE • Month: – @ID = MONTH_ID – Tables: LU_TIME (lookup) – Child: Date 4 Define the Sales fact: • Expression: sales 386 Logical view examples © 2007 MicroStrategy.C Logical Tables Project Design Guide 3 Define the following attributes: • Sales Rep Surrogate: – @ID = sales_rep_cd – Tables: LU_SALES_REP (lookup). @Desc = sales_rep_name – Tables: LU_SALES_REP (lookup).

Sales_Rep_CD) join LU_TIME a13 on (a11.SALES) WJXBFS1 from FACT_TABLE a11 join LU_SALES_REP a12 on (a11. Month.Sales_Rep_CD = a12. Inc. 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 Current District Sales Rep Surrogate Sale rep Historical District Sales Rep Surrogate Date Sales Date Month 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. Sales Resulting SQL select a12.Date_ID) join LU_DISTRICT a14 on (a12. max(a14.Distrcit_Name) Distrcit_Name. Logical view examples 387 .District_ID = © 2007 MicroStrategy. a13.Trans_dt = a13.Month_ID Month_ID.Project Design Guide Logical Tables C • Tables: FACT_TABLE. sum(a11.District_ID District_ID.

Sales Resulting SQL: select a13.Sales_Rep_CD = a12.Month_ID • Report results As-is analysis Specify the “as-is” analysis by using the Current District attribute on reports: • • Report definition: Current District.Trans_dt = a14.District_ID District_ID.SALES) WJXBFS1 from FACT_TABLE a11 join LU_SALES_REP a12 on (a11.Distrcit_Name) District_Name.C Logical Tables Project Design Guide a14. .Sales_Rep_ID) join LU_TIME a14 on (a11. sum(a11. Month.District_ID. a13.District_ID = a15.District_ID) group by a12. max(a15. a14.Sales_Rep_CD) join (select Sales_rep_ID.District_ID. Inc. a14.Month_ID 388 Logical view examples © 2007 MicroStrategy.Date_ID) join LU_DISTRICT a15 on (a13.District_ID) group by a13. District_ID from LU_SALES_REP where current_flag = 1) a13 on (a12.Month_ID Month_ID.Sales_Rep_ID = a13.

day_date)= MONTH(B. you need to define transformations. Select day_date day_date. The SQL below can be used to define a logical MTD_DATE table. B.day_date) = YEAR(B. one-to-many transformations require tables in the database that map each date to all the previous dates that make up “month-to-date”.day_date >= B. 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.day_date >= B. such as month-to-date and year-to-date calculations. Logical view examples 389 . such as Last Month.day_date ytd_date From lu_day A. can be defined in terms of an expression. Inc.day_date) © 2007 MicroStrategy. lu_day B Where A. Select A. Although one-to-one transformations.day_date) The same technique can be used to define a year-t0-date transformation. The MTD transformation can then be defined using the MTD_DATE column. lu_day B Where A.day_date And MONTH(A.day_date And YEAR(A.day_date mtd_date From lu_day A. 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.day_date day_date.Project Design Guide Logical Tables C • Report result Business case 4: One-to-many transformation tables In order to support time-series analysis. which contains the Day attribute. B.

For example. George . Emergency Contact Phone Number NULLS are displayed for employees who do not have emergency contacts. Abraham Walker. no metrics). . consider the tables below. 390 Logical view examples © 2007 MicroStrategy. EMPLOYEE EMP_ID FIRST_NAME LAST_NAME HIRE_DATE DEPT_ID EMERGENCY CONTACT EMP_ID CONTACT_FIRST_NAME CONTACT_LAST_NAME CONTACT_PHONE_NUMBER DEPARTMENT DEPT_ID DEPT_NAME BUS_UNIT_ID Given this structure. Martha . Inc. which means not all employees have contacts on record. James Dawson... the relationship between Employees and Emergency Contacts is such that each employee may have up to one contact.. Jane Taylor... Mary Walker.. Dawson. you could model an attribute hierarchy as follows: • • • Business Unit -< Department -< Employee Hire Date -< Employee Emergency Contact -< Employee In addition. Department Marketing Finance R&D Finance . John Larkins..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. One of the reports you probably would like to create may look like the following: Employee Gonzalez. 555-1212 555-3456 555-9876 ..

@[First Name] = FIRST_NAME. Inc. and only those employees who have emergency contacts would appear in the final result. © 2007 MicroStrategy. @[Last Name] = LAST_NAME Tables: EMPLOYEE (lookup). @[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. @[First Name] = CONTACT_FIRST_NAME. Logical view examples 391 . if you model the attributes as described below.Project Design Guide Logical Tables C However. you would not get the desired output: • Employee: @ID = EMP_ID. you can perform an outer join using a logical view. In order to see all employees. 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. described as follows.

LAST_NAME. @[Last Name] = LAST_NAME Tables: EMPLOYEE (lookup). Inc.HIRE_DATE. EMPLOYEE). E.CONTACT_LAST_NAME.CONTACT_FIRST_NAME.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. you can use the following SQL and the list of columns to map to the view: select E.DEPT_ID.CONTACT_PHONE_NUMBER from EMPLOYEE E left outer join EMERGENCY_CONTACT C on (E. E. C. C.EMP_ID = C.FIRST_NAME. LVW_EMERGENCY_CONTACT 392 Logical view examples © 2007 MicroStrategy. @[First Name] = FIRST_NAME.EMP_ID. . E. C. The new logical table LVW_EMERGENCY_CONTACT can then be used to define attributes as follows: • Employee: @ID = EMP_ID. E.C Logical Tables Project Design Guide Using a logical view for an outer join To perform an outer join for the case described above.

Logical view examples 393 . the EMERGENCY_CONTACT table will be joined only when necessary. Also note that if we run a report that includes only the Employee attribute. @[First Name] = CONTACT_FIRST_NAME. it will be executed against the EMPLOYEE table. © 2007 MicroStrategy. 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.Project Design Guide Logical Tables C • Department: @ID = DEPT_ID Tables: DEPARTMENT (lookup). LVW_EMERGENCY_CONTACT Child: Employee • Hire Date: @ID = HIRE_DATE Tables: EMPLOYEE (lookup). the EMPLOYEE table will be outer joined to the EMERGENCY_CONTACT table. LVW_EMERGENCY_CONTACT Child: Employee The Employee attribute is not represented in the original EMERGENCY_CONTACT table and all attributes represented in the EMPLOYEE table are also represented in the LVW_EMERGENCY_CONTACT table. @[Last Name] = CONTACT_LAST_NAME Tables: EMERGENCY_CONTACT (lookup). EMPLOYEE. Now if we run a report with Employee and Emergency Contact attributes. Inc. and NULLs will be returned for any employees who do not have emergency contacts. LVW_EMERGENCY_CONTACT Child: Employee • Emergency Contact: @ID = CONTACT_PHONE_NUMBER.

Inc. .C Logical Tables Project Design Guide 394 Logical view examples © 2007 MicroStrategy.

Mapping of external data types to MicroStrategy data types 395 . 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 generalizes them into a set of MicroStrategy-specific data types. Inc. Each column from your database becomes associated with a MicroStrategy data type.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 automatically maps the columns within those tables to MicroStrategy-specific data types. © 2007 MicroStrategy.

In your relational database. and generating the correct syntax for literals. as with custom groups. a column within that table has a data type of “SMALLINT. see the MicroStrategy Advanced Reporting Guide. The data type is also used whenever multi-pass SQL is used. Therefore. The MicroStrategy data type stores data values internally and in the metadata repository and is later used during SQL generation when defining intermediate tables. in part. 396 Mapping of external data types to MicroStrategy data types © 2007 MicroStrategy. for example. “INTEGER. For more information about data marts and custom groups. because each database names data types in different ways.” This allows MicroStrategy to maintain a consistent SQL generation process. and data mart tables. Data types that may be conceptually the same can have different names. MicroStrategy must map every column brought into the project schema to an internal data type. For information about how your relational database’s data types are mapped to MicroStrategy data types and the specific mappings that pertain to your RDBMS. Suppose you add a table to the Warehouse Catalog. It is strongly recommended that you do not alter the mapping file (DTMAPPING.D Data Types Project Design Guide This external-to-internal mapping is necessary.pds) in any way. Inc. refer to MicroStrategy Technical Note TN5200-7X0-0166.” MicroStrategy maps this column to a MicroStrategy-specific data type. .

MicroStrategy data types 397 . Time Time of day. Similar to ANSI DECIMAL. all columns in the database are automatically mapped to one of the following MicroStrategy data types. Float 4-byte floating point numbers. Real 4-byte floating point numbers. Similar to ANSI DOUBLE PRECISION. LongVarChar Large strings of characters. Fixed-length bit strings. Timestamp Combinations of calendar date and time of day. Similar to ANSI CLOB. Char Fixed-length character strings. Integer Signed integer values. Similar to ANSI DATE. Similar to ANSI NUMERIC. Unsigned Unsigned integer values. Similar to ANSI FLOAT. Similar to ANSI INTEGER.Project Design Guide Data Types D MicroStrategy data types When the data warehouse catalog is read from the Warehouse Catalog. Similar to ANSI BIT. Date Calendar dates. Inc. Similar to ANSI CHAR. Similar to ANSI BLOB. © 2007 MicroStrategy. LongVarBin Large strings of bits. Similar to ANSI TIME. Numeric Fixed point numbers up to 15 digits of precision. Data Type Big Decimal Binary Description High-precision fixed point numbers. Decimal Fixed point numbers up to 15 digits of precision. Similar to ANSI TIMESTAMP. Similar to ANSI REAL. Double 8-byte floating point numbers.

Date Datetime Email HTML Tag Number 398 Format types © 2007 MicroStrategy. it implies that the data type in the database has not mapped to one of the MicroStrategy data types. Varchar Variable-length character strings. It represents dates in the MM/DD/YYYY format. Information is stored and displayed as dates in a sequential form to perform calculations on the dates. If the Warehouse Catalog displays a column with data type as Unknown. The date follows the MM/DD/YYYY format and time follows the HH:MM:SS format. Information is stored and displayed in a number format. Similar to ANSI VARCHAR. Information is stored and displayed both as date and time in the format specific to the data. Format Type Big Decimal Description Information is stored and displayed in the Big Decimal form. see Big Decimal. You specify the format type of an attribute form in the Form Format: Type drop-down menu in the Attribute Editor. Similar to ANSI BIT VARYING. The attribute form format types are described in the following table. For more information about Big Decimal. Information is stored and displayed in the form of an e-mail address. .D Data Types Project Design Guide Data Type Varbin Description Variable-length bit strings. which represents high-precision fixed point numbers. Format types Attribute forms are also associated with a MicroStrategy format type. which specifies how attribute form values should be displayed on MicroStrategy interfaces. page 400. Inc. Information is stored and displayed as an HTML tag.

Project Design Guide Data Types D Format Type Picture Text Time Description stored and displayed the form of an image file. Information is stored and displayed as time in the HH:MM:SS format. If you select a format type that is incompatible with the data type and click OK to exit the Attribute Editor. JPG. URL 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. doing so can still result in SQL generation issues. This displays only the time and not the date. 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 edit the ID form of the Year attribute in the Attribute Editor. Although you have the option to continue by clicking Yes. a warning message appears notifying you of the incompatibility. You are warned in the Attribute Editor whenever you have selected a format type that is incompatible with the data type of your column. When you return to the Definition pane in the Attribute Editor. This format type must be compatible with the data type you assigned in the Column Alias tab. © 2007 MicroStrategy. Inc. you notice that the Year attribute is assigned an “Integer” data type. you create a new column alias and assign it the “Date” data type. such as bitmap. for example—you must also change the format type of the attribute. Data type and format type compatibility 399 . Information is stored and displayed in a text format. or GIF. However. you must select an appropriate format type from the Form Format: Type drop-down menu. Information is stored and displayed as either an absolute or a relative Universal Resource Locator. In the Column Alias tab.

Different format types are compatible with different data types given the specific data in your column. . Text Number Number Time. Datetime Number Number Number Number Picture. HTML Tag Date. Date or Time depending on data Number Picture. Therefore. Inc. Picture Text. 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. Datetime Datetime. Text Text.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. URL. E-mail. E-mail. Data Type Big Decimal Binary Char Date Decimal Double Float Integer LongVarBin LongVarChar Numeric Real Time Timestamp Unsigned Varbin Varchar Compatible Format Types Big Decimal Number. such as BIGINT and 400 Big Decimal © 2007 MicroStrategy. some of the data type-format type combinations below may not work with your specific data. Text depending on data Picture. URL. Text.

you can define a filter as "Customer@ID exactly #12345678#". drilling. credit card numbers. and long integers. When using the Big Decimal data type. you must also select Big Decimal as the form format type in the Form format: Type drop-down menu in the Definition tab. You must use the Big Decimal data type to handle these values. such as account numbers and other long integers.Project Design Guide Data Types D DECIMAL (precision. even though 12345678 does not necessarily require the Big Decimal data type. Attribute ID: Follow the steps in the topic Defining attributes with high-precision ID forms in the MicroStrategy Desktop online help. For more information about these operations. Attribute form: If you change the column data type to Big Decimal on the Column Alias tab in the Attribute Editor. Using the Big Decimal data type With the Big Decimal data type. see the MicroStrategy Basic Reporting Guide. because these data values have higher precision and cannot be stored in normal numeric data types. You can define attributes that are identified by numeric columns in the database. scale) data types. Examples of such attribute ID values are account numbers. Big Decimal 401 . and page-by may not return results. MicroStrategy preserves the precision of attribute ID values and attribute ID forms when displaying IDs and performing operations such as filtering. For example. These numeric columns can have more than 15 digits of precision. Inc. • • © 2007 MicroStrategy. and page-by. If you do not associate high-precision database fields with the Big Decimal data type. The WHERE clause in the report SQL statement in drill reports may truncate numbers starting from the 16th digit. follow the rules listed below: • Constant: You can force a constant to be stored as a Big Decimal value by enclosing it in hash marks. you may see numbers truncated starting with the 16th digit.

s) or NUMERIC(p. the metric is subtotaled. consider the following drawbacks: Precision is lost when any Analytical Engine calculation is performed. When qualifying on a Big Decimal metric. the metric is used in a calculated field in a document. or metric values are displayed in Graph view. #1234567890123456#. This is because Big Decimal should only be used when the column is used as an attribute ID form. 402 Big Decimal © 2007 MicroStrategy. you must explicitly identify high-precision constants by enclosing the value within hash (#) symbols. s) columns to the Big Decimal MicroStrategy data type even when the precision is greater than 15. Inc. . For example. Number formatting strings are not supported on the Web. Some number formatting strings are not supported in MicroStrategy Desktop. Note that the Warehouse Catalog does not automatically map DECIMAL(p.D Data Types Project Design Guide • Metric: Although it is possible to define Big Decimal as the data type for metric values.

© 2007 MicroStrategy. Reports and documents can also be created and manipulated in MicroStrategy Web. metrics. MAX. Inc. documents. custom groups. Examples include SUM. the application rather than partition the database server manages the partition tables. COUNT. MIN. The definition of application objects such as reports. Compare database-level partition. and AVG. MicroStrategy supports two methods of application-level partitioning: metadata partition mapping and warehouse partition mapping. See pre-aggregation. aggregate function 403 . application object An object used to provide analysis of and insight into relevant data. aggregate table A fact table that stores data that has been aggregated along one or more dimensions. filters.GLOSSARY aggregate function A numeric function that acts on a column of data and produces a single result. application-level In application-level partitioning. templates. and prompts are derived from schema objects. All of these objects can be built and manipulated in MicroStrategy Desktop.

and Year. Billing City and Shipping City are two attributes that have the same table and columns defined as a lookup table. Age. Inc. For example.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. attribute form One of several columns associated with an attribute that are different aspects of the same thing. defined by the attribute forms. See also: • • • • • • attribute element attribute form child attribute constant attribute derived attribute parent attribute attribute element A unique set of information for an attribute. Customer. Name. . Long Description. New York and Dallas are elements of the attribute City. attribute role A database column that is used to define more than one attribute. They provide a means for aggregating and filtering at a given level. 404 attribute © 2007 MicroStrategy. City. Every attribute supports its own collection of forms. February. and March are elements of the attribute Month. attribute relationship See relationship. Last Name. Item. January. For example. and Abbreviation could be forms of the attribute Customer. ID. Order. Attributes include data classifications like Region. attribute form A mapping to the columns in the warehouse that are used to expression represent a specific attribute form in SQL.

metrics.Project Design Guide Glossary axis A vector along which data is displayed. consolidations. Results from the data warehouse are stored separately and can be used by new job requests that require the same data. the results can be returned immediately without having to wait for the database to process the job the next time the report is run. and custom groups—along each axis. cardinality The number of unique elements for an attribute. he places template units—attributes. Column. See also: • • column row base fact column A fact column represented by a single column in a fact table. © 2007 MicroStrategy. and Page. Inc. the job is submitted to the database for processing. When a user defines a template for a report. axis 405 . In the MicroStrategy environment. cache A special data store holding recently accessed information for quick future access. There are three axes—Row. if the results of that report are cached. when a user runs a report for the first time. This is normally done for frequently requested reports. browse attribute An attribute a user can directly browse to from a given attribute in a user hierarchy. However. dimensions. whose execution is faster because they need not run against the database. 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.

Glossary Project Design Guide child attribute The lower-level attribute in an attribute relationship. 406 child attribute © 2007 MicroStrategy. the more you stand to gain by creating an aggregate table that pre-calculates the higher-level data. compression ratio The average number of child records combined to calculate one parent record. 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. Inc. This is used to determine where aggregate tables would have the greatest impact. compound key In a relational database. The larger the compression ratio between two attributes. For example. See also: • • parent attribute relationship column 1) A one-dimensional vertical array of values in a table. compound attribute An attribute that has more than one key (ID) form. . the compression of ratio between monthly data and yearly data is 12:1. the specific name of the column to be used in temporary tables and SQL statements. See also: • • axis row column alias In a fact definition. 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. a primary key consisting of more than one database column.

or storage location which stores data that is to be used in MicroStrategy for query. Inc. and analysis. configuration object A MicroStrategy object appearing in the system layer and usable across multiple projects. database login IDs. Microsoft Analysis Services 2000 and 2005. reporting. conditionality 407 . and OLAP cube sources such as SAP BW. Configuration objects include these object types: users. and Hyperion Essbase. data source A data source is any file. © 2007 MicroStrategy. typically very large. Data Explorer A portion of the interface used to browse through data contained in the warehouse. database instances. system. A data warehouse can be thought of as one type of data source. Other data sources include text files. Used for decision support or business intelligence. reporting. it organizes data and allows coordinated updates and loads. 2) A copy of transaction data specifically structured for query. which refers more specifically to using a database as your data source. See also: • • data warehouse OLAP cube source data warehouse 1) A database.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. Excel files. containing the historical data of an enterprise. Users can navigate through hierarchies of attributes that are defined by the administrator to find the data they need. schedules. constant attribute See implicit attribute. and analysis. See also data source.

It is calculated by Intelligence Server. For example. Inc. Database server software running on a particular machine. not in the database. description column Optional columns that contain text descriptions of attribute elements. Login ID and password. derived fact column A fact column created through a mathematical combination of other existing fact columns. A database instance specifies warehouse connection information. derived attribute An attribute calculated from a mathematical operation on columns in a warehouse table. such as the data warehouse DSN. 2. . Although it is technically possible to have more than one instance running on a machine. there is usually only one instance per machine. calculations on other metrics. derived metric A metric based on data already available in a report. on report data after it has been returned from the database. and other data warehouse specific information. Use a derived metric to perform column math. degradation A type of fact extension in which values at one level of aggregation are reported at a second. 408 database instance © 2007 MicroStrategy. Age might be calculated from this expression: Current Date–Birth Date Compare implicit attribute. A MicroStrategy object created in MicroStrategy Desktop that represents a connection to the warehouse. Compare allocation.Glossary Project Design Guide database instance 1. that is. lower attribute level.

a store may decide to reclassify the department to which items belong. reclassification. 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. Inc. 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. geographical realignment. For example. or discontinuation of items or services. entry level The lowest level set of attributes at which a fact is available for analysis. drill 409 . © 2007 MicroStrategy. entry point In a user hierarchy. 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. The new data is retrieved by re-querying the Intelligent Cube or database at a different attribute or fact level. viewing the list of months in a year. or the addition. For example. element browsing Navigating through hierarchies of attribute elements.Project Design Guide Glossary drill A method of obtaining supplementary information after a report has been executed.

Using a filter on a report narrows the data to consider only the information that is relevant to answer your business question. 410 extraction. fact 1) A measurement value. often numeric and typically aggregatable. See also metric. or sales in dollars. A filter is composed of at least one qualification. filter A MicroStrategy object that specifies the conditions that the data must meet to be included in the report results. transformation. Fact tables can contain atomic or summarized data. fact expression A mapping of facts to physical columns in the warehouse. which is the actual condition that must be met for the data to be included on a report. 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. 2) A schema object representing a column in a data warehouse table and containing basic or aggregated numbers—usually prices. stored in a data warehouse. loading (ETL) 2) Third-party software used to facilitate such a process. and loading (ETL) © 2007 MicroStrategy.Glossary Project Design Guide extraction. A filter is normally implemented in the SQL WHERE clause. fact table A database table containing numeric data that can be aggregated along one or more dimensions. 1) The process used to populate a data warehouse from transformation. and disparate existing database systems. Examples include "Region = Northeast" or "Revenue > $1 million". or inventory quantities in counts. . fact column A column in a database table that contains fact data. Multiple qualifications in a single filter are combined using logical operators. since a report queries the database against all the data stored in the data warehouse. Inc.

form group 411 © 2007 MicroStrategy. For example. highly normalized Schema type where lookup tables contain unique schema developer-designed attribute keys. 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. homogeneous column Columns in different tables of a database that contain the naming same data and have the same column name. implicit attribute An attribute that does not physically exist in the database because it is created at the application level. but the description columns are present as well. which identifies that an attribute form requires more than one ID column to uniquely identify its elements. . you may wish to create columns in the database with a value of 1 for every row to get around COUNT limitations. All attributes must have an ID column. heterogeneous column Columns in different tables in a database that store the same naming data but have different names. highly denormalized Schema type where not only are higher-level attribute ID schema columns present within all related tables. because in the Attribute Editor. hierarchy A set of attributes defining a meaningful path for element browsing or drilling. A form group must be created to create a compound key. For example. both containing customer names. ID column A column that contains attribute element identification codes. one column named Customer in one table and one named Customer Name in a different table. You do not have to actually create the column.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. though nothing is saved in a column. though. Such an attribute has its expression defined as a constant value. Inc. See also compound key.

An example of a promotion might be a “Red Sale” where all red items are on sale. When analyzing data. as opposed to the physical data model or warehouse schema. Any constant is acceptable. promotion has a many-to-many relationship to both item and quarter. You can use constant attributes when building metrics. Implicit attributes are useful in analyzing and retrieving information. Inc. consider the relationship between three attributes: promotion. In this case. Lookup tables are usually joined to fact tables to group the numeric facts in the fact table by dimensional attributes in the lookup tables. A business might run this promotion around Valentine's Day (Q1) and again at Christmas time (Q4).For example. 412 joint children © 2007 MicroStrategy. they exist at the intersection of multiple attribute levels. Compare derived attribute. . logical data model A graphical representation of data that is arranged logically for the general user. and quarter. These relationships can be modeled and conceptualized like traditional attributes. locked hierarchy A hierarchy that has at least one attribute that may not be browsed by end users. you can use constant attributes to create a COUNT to keep track of the number of rows returned. lookup table A database table used to uniquely identify attribute elements. which arranges data for efficient database use. Hierarchies are usually locked if there are so many attribute elements that element browsing is not usable. item. where you can sum the column holding the constant to create a COUNT. but like facts. They typically consist of descriptions of dimensions. 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.Glossary Project Design Guide you can just enter a “1” in the expression to create a count.

See also metadata shell. Query Builder. © 2007 MicroStrategy. metrics. 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. many-to-many An attribute relationship in which multiple elements of a parent attribute can relate to multiple elements of a child attribute. and needs to the underlying database structure. and vice versa. It can even be held in a different RDBMS. managed object 413 .Project Design Guide Glossary managed object A schema object unrelated to the project schema. hierarchies and other schema objects for Freeform SQL. Inc. Managed objects are used to map data to attributes. Metadata can reside on the same server as the data warehouse or on a different database server. and OLAP cube reports. and (2) every element of the child attribute can relate to multiple elements of the parent. which is created by the system and stored in a separate system folder. 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.

or other metrics.[Cost] 2) The MicroStrategy object that contains the metric definition. See also metadata. More concretely. The startup code initiates the primary thread of a process by passing the main function address to the operating system. attributes.Glossary Project Design Guide metadata shell A set of blank tables that are created when you initially implement a MicroStrategy business intelligence environment. . facts. an object is any item that can be selected and manipulated. reports. and mobile devices. In MicroStrategy. object Conceptually. multithreaded Characteristic of a process that supports the simultaneous execution of multiple threads. including folders. printers. metric 1) A business calculation defined by an expression built with functions. file services. and so on. an object is the highest grouping level of information about one concept. metrics. See also fact. used by the user to achieve the goal of specified data analysis. SMS. Narrowcast Server is a proactive information delivery server that allows for this distribution of information through e-mail. but here the higher-level attribute ID columns are present within all related tables. When the primary thread terminates. For example: sum(dollar_sales) or [Sales] . 414 metadata shell © 2007 MicroStrategy. Inc. the process terminates. facts. moderately normalized Schema type having the same basic structure as the highly schema normalized schema. MOLAP Multidimensional online analytical processing. narrowcast application In a business intelligence environment. an application that allows for the distribution of personalized business information to subscribed users.

Microsoft Analysis Services. report on. You can import and map data from these different OLAP cube sources in MicroStrategy to query. MicroStrategy can integrate with OLAP cube source data as well as access data from a relational database concurrently. which is imported into MicroStrategy and mapped to various objects to allow query. Inc. 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. and analysis on the data. reporting. The one-to-many attribute relationship is the most common in data models.Project Design Guide Glossary OLAP cube An OLAP cube is a collection or set of data retrieved from an OLAP cube source. while every element of the child attribute relates to only one element of the parent. the third-party tools SAP BW. OLAP cube source When integrated with MicroStrategy. and analyze data with MicroStrategy. See also OLAP cube source. and Hyperion Essbase are referred to as OLAP cube sources. OLAP cube 415 . See also: • • • • one-to-one many-to-many many-to-one relationship © 2007 MicroStrategy.

withdrawals. and vice versa. inventory. databases or mainframes that store transactional processing (OTLP) data. and metrics on a third axis called the Page axis. the user can page through the cube. Since a grid is two-dimensional. or deposits. page-by Segmenting data in a grid report by placing available attributes. online transaction Typically. and profit analysis. See also: • • • • • drill pivot sort subtotal surf 416 one-to-one © 2007 MicroStrategy. growth patterns. By varying the selection of elements. percent to total contributions. . trend reporting. Transactional processing involves the simple recording of transactions such as sales. Inc. only a slice of the cube can be seen at any one time. consolidations. The slice is characterized by the choice of elements on the Page axis. 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.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.

partitions improve the speed and efficiency of database queries. Partitions minimize the number of tables and records within a table that must be read to satisfy queries issued against the warehouse.Project Design Guide Glossary parent attribute The higher-level attribute in an attribute relationship with one or more children. Inc. such as month or department. Also referred to as a PBT. 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. while the opposite is not necessarily true. partition mapping The division of large logical tables into smaller physical tables based on a definable data level. See also: • • child attribute relationship partial relationship An attribute relationship in which elements of one attribute relate to elements of a second attribute. Partition tables are usually divided along logical lines. such as time or geography. See also partition mapping. parent attribute 417 . By distributing usage across multiple tables. © 2007 MicroStrategy.

when the Intelligence Server machine receives a network call from a client (Desktop. Inc. . Web. it knows to forward those calls to the Intelligence Server port number that is specified in the call. and so on). Command Manager. Narrowcast Server. 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. and hence the associated data. metrics. pivot To reconfigure data on a grid report by placing report objects (attributes. 418 partition mapping table © 2007 MicroStrategy. consolidations) on different axes. to reconfigure a grid report by interchanging row and column headers. Also. For example. 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. Subset of cross-tab.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 schema. It organizes the logical data model in a method that make sense from a database perspective.

Processes use temporary private address spaces and control operating system resources such as files. process An executing application comprising one or more threads. metadata repository. 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.Project Design Guide Glossary pre-aggregation Aggregation. and user community. containing reports. © 2007 MicroStrategy. pipes. 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. with the results stored in an aggregate table. and functions. Prefixes can be defined and modified from the Warehouse Catalog interface. or the calculation of numeric data at a specific attribute level. as defined in (1). Also. project 1) The highest-level intersection of a data warehouse. See also table name space. A server project source is a 3-tier connection to a MicroStrategy Intelligence Server. dynamic memory allocations. that is completed before reports are run. A direct project source is a two-tier connection directly to a metadata repository. 2) An object containing the definition of a project. project source Defines a connection to the metadata repository and is used by various MicroStrategy products to access projects. filters. metrics. The project object is specified when requesting the establishment of a session. In most cases. pre-aggregation 419 . the Catalog Server uses it to obtain table sample values and row counts. Inc. 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. and synchronization objects.

2) In general. and then set how to combine the qualifications using the logical operators AND. AND NOT. quality relationship The relationship between a parent attribute and two or more “joint child” attributes. relate table A table containing the ID columns of two or more attributes. 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. update.” qualification The actual condition that must be met for data to be included on a report. OR. IBM DB2 and Microsoft SQL Server.Glossary Project Design Guide prompt 1) MicroStrategy object in the report definition that is incomplete by design. Examples include "Region = Northeast" or "Revenue > $1 million". Qualifications are used in filters and custom groups. and OR NOT. thus defining associations between them. as in “type login ID and password at the prompt. 420 prompt © 2007 MicroStrategy. The parent attribute is referred to as a “quality” because its definition is complete only with the intersection of its joint children. You can create multiple qualifications for a single filter or custom group. or size between the cardinalities of related attributes. See also cardinality. ratio The relationship in quantity. Inc. The leading RDBMS products are Oracle. The user is asked during the resolution phase of report execution to provide an answer that completes the information. amount. and administer a relational database. A typical example with a filter is choosing a specific attribute on which to qualify. relational database A relational database management system (RDBMS) is a management system program that lets you create. a window requesting user input. .

report design The process of building reports from basic report components using the Report Editor in MicroStrategy Desktop or MicroStrategy Web. a report allows users to query for data.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). predesigned reports in MicroStrategy Desktop or in MicroStrategy Web. © 2007 MicroStrategy. and then present it in a visually pleasing manner. relationship 421 . See also: • • filter template report creation The process of building reports from existing. 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. analyze that data. For example. City is a child attribute of State. Inc.

Schema objects directly reflect the warehouse structure and include attributes. 2) The layout or structure of a database system. partition mappings. In relational databases. which can be accessed from MicroStrategy Desktop. shortcut object A MicroStrategy object that represents a link to any other MicroStrategy object such as report. The attribute and fact columns in those tables are considered part of the schema itself. See also: • • axis column schema 1) The set of tables in a data warehouse associated with a logical data model. server definition A MicroStrategy object stored in the metadata containing information about the configuration of an Intelligence Server. Inc. a primary key that requires only one column to uniquely identify a record within a table. hierarchies. .Glossary Project Design Guide row The horizontal axis of a report. that relates the information in the logical data model and physical warehouse schema to the MicroStrategy environment. tables. operators. schema object A MicroStrategy object created. simple key In a relational database. the fields in each table. server instance The combination of an Intelligence Server running with a particular server definition. and the relationships between fields and tables. the schema defines the tables. and transformations. filter. functions. facts. usually by a project designer. and so forth. metric. 422 row © 2007 MicroStrategy. These objects are developed in MicroStrategy Architect.

Project Design Guide Glossary sort Arranging data according to some characteristic of the data itself (alphabetical descending. statistics tables Tables that are used to record a variety of statistical information about the usage and performance of a MicroStrategy system. 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. drill page-by pivot sort surf sort 423 . 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. See also: • • • • • drill page-by pivot subtotal surf source system Any system or file that captures or holds data of interest. numeric ascending. Inc. See also: • • • • • © 2007 MicroStrategy. subtotal A totaling operation performed for a portion of a result set. and so forth).

See also: • • • • • drill page-by pivot sort subtotal system hierarchy The superset hierarchy containing all attributes in a project. template The data definition portion of the template consists of the group of objects (attribute. Unlike a browse hierarchy. and functions to existing analysis objects.Glossary Project Design Guide surf To add filters. Compare user hierarchy. Inc. and so on) that defines the columns of data to be included in the result set. 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. attribute elements. attributes. The layout and format of these objects are defined within the template's view definition. metrics. 424 surf © 2007 MicroStrategy. Each table object in the metadata stores the name space or owner from which it came. it is not explicitly created but is automatically deduced by the MicroStrategy platform from all information available to it. This field cannot be modified from the product since it is actually stored in the warehouse. table size The estimated size of a database table in terms of number of rows. custom groups. metrics. . table name space A field that is read from the warehouse catalog and used to organize databases.

For example. Add a transformation for last year and the metric now calculates last year’s total sales. user hierarchy A named set of attributes and their relationships. They are user-defined and are used to define the browse and drill relationships between attributes. A virtual cube maps MicroStrategy objects such as hierarchies and metrics to OLE DB for OLAP objects. virtual cube 1) In an OLAP data model. but a definition of the virtual cube structure is stored in MicroStrategy metadata. Unlike a physical cube. such as this year versus last year or current date versus month-to-date. such as defunct product codes to new ones. 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. transformation 425 . transformation metric An otherwise simple metric that takes the properties of the transformation applied to it. a metric calculates total sales. Time transformations are used in metrics to compare values at different times. © 2007 MicroStrategy. Inc. multidimensional representation of data. if revenue is greater than $200. a transformation can also map different objects. applying an offset value. a conceptual. For example. such as current month minus one month. a virtual cube does not perform data retrieval and consequently lacks the performance problems and size limitations associated with a physical cube. Although the vast majority are based on time. threshold Used to create conditional formatting for metric values. arranged in specific sequences for a logical business organization. No physical cube is created or loaded. format that cell to have a blue background with bold type.Project Design Guide Glossary transformation A schema object that maps a specified time period to another time period.

. Inc.Glossary Project Design Guide 426 virtual cube © 2007 MicroStrategy.

105 table 178. Inc. 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 A accessing Project Creation Assistant 78 Warehouse Catalog 219 adding tables to a project 79 aerial perspective of hierarchy 200. fact column 96. 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.

See attribute role. simple expression 148 system hierarchy 159 attribute component. time-series 257 application for Essbase 313 application-level partition defined on 251 architecture. heterogeneous mapping 153 identifying 30 implicit. compound 183 compound key 184 creating in Project Creation Assistant 130 creating using Attribute Editor 136 cross-dimensional. derived attribute 150 derived expression 150 display 189 element. See report display form and browse form. See attribute relationship. attribute constant 155 in hierarchy 25 joint child relationship 171 many-to-many relationship 160. 128 qualification 253 ratio 35 relationship. 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.Index Project Design Guide 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. 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. 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. expression 127 filtering in a hierarchy 203 form. Inc. See attribute form. See joint-child relationship. report display form 190 role. 428 . See report display form and browse form. See attribute element.

characteristic attribute vs. 223 base fact column 47 data type. See column data type. 41 column alias attribute 156 429 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.Project Design Guide Index 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. See hierarchy. See hierarchy. . SAP BW 300 child attribute 24 class. column defined on 41. derived fact 47 description 41 fact 41 heterogeneous naming 49 homogeneous naming 50 ID 41 physical warehouse schema 40. attribute form 307 characteristic value 307 characteristics. 180 authenticating OLAP cube reports 297 automatic attribute role recognition 177 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.

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 D Data Explorer defined on 209 about 209 enabling hierarchy browsing 196. Inc. See project source.Index Project Design Guide fact 96. 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 430 © 2007 MicroStrategy. 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. data provider. . See database instance. 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. 209 data model. See logical data model. See joint child relationship. 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.

See MicroStrategy Desktop. example data model sample 26 physical schema 289 project 267 table data sample 225 explicit table alias 178. 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. transformation. dimension for Analysis Services 2000 319. transformation. 320 for Analysis Services 2005 325 for Essbase 314. 315 for SAP BW 306 See also hierarchy. level 107 extraction.Project Design Guide Index attribute 150 fact 99 fact column 47 description column defined on 41 Desktop. Inc. 180 expression map 98 expression. 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. member 316 relating objects 311 ETL. entry level defined on 87 entry point 205 ERD. 6 F fact defined on 85 allocation expression 121 base fact column 47 column defined on 41 column alias 96. 92 fact entry level 87 431 . direct access approach 292 disallowing fact entry level 122 drilling using hierarchies 209 dynamic aggregation 243 dynamic relationship defined on 247 E element. and loading (ETL) process defined on 4. 97 Fact Editor 88. attribute 140 entity relationship diagram (ERD) defined on 29 entity. 315 level 315 © 2007 MicroStrategy. fact 98 expression-based transformation 259 creating 261 member expressions 264 member tables 263 extension. See extraction. See hierarchy. See entity relationship diagram. and loading.

107 overview 21 table 46 table relation 110 table. 210 Hierarchy Viewer 200 © 2007 MicroStrategy. Inc.Index Project Design Guide fact relation 114 heterogeneous fact column 102 identifying 29 implicit 99 in hierarchy 25 level extension 96. structure 199 system hierarchy 197 unbalanced 355 user hierarchy 197 Hierarchy Editor 198. . 200. See fact table. 209 Attribute Editor 197 attribute filter 203 attributes in 25 browse attribute 207 browsing 207 browsing. 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 fact column 102 partition mapping 252 hierarchy defined on 193 aerial perspective 212 and the Data Explorer 196. 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. 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.

. 280 ratio 35 sample 26 schema type 51 source of structure 29 unique identifier 34 Logical Table Editor 250 logical table size 249 login. 304 InfoObjects 299 InfoProviders 299 international technical support xxiii J Java Connector 328. 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. 254 Hyperion Essbase. I implicit attribute 155 fact 99 importing OLAP cubes 343. custom 227 lookup table defined on 43 attribute relationships and 44 consolidating 58 many-to-many relationship 44 one-to-one relationship 44 K key compound 42 figures 300 simple 42 M 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 433 L level extension 107 for Analysis Services 2000 321 © 2007 MicroStrategy. Inc. See Essbase.Project Design Guide Index highly denormalized schema 57 higher level lookup tables 58 highly normalized schema 52 homogeneous column naming 50 partition mapping 252. 344 InfoCube 303. 330 join.

. MicroStrategy architecture 294 object model 7i 295 object model 8 296 MicroStrategy Desktop 11 MicroStrategy metadata. member attributes 263 expressions 263 for Analysis Services 2000 321 for Analysis Services 2005 326 for Essbase 316 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 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. Inc.Index Project Design Guide 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 Project Builder. See metadata. 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 434 © 2007 MicroStrategy. Microsoft Analysis Services 2005. See member property. See Analysis Services 2005. See MultiDimensional Expressions. See Analysis Services 2000. MicroStrategy Project Builder.

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 N nonrelated attributes 161 normalized schema 53. general 280 view physical schema 289 MicroStrategy Web Universal 13 migrating tables 232 moderately normalized schema 54 MOLAP defined on 242 multidimensional data model. MultiDimensional Expressions about 291 remapping objects 356 multiple counting 164 MultiProviders 299 O object models in MicroStrategy 7i 295 in MicroStrategy 8 296 using SAP direct access 296 object. 55 © 2007 MicroStrategy. 435 . See OLAP cube. user 10 ODS object 299 OLAP BAPI certification 293 Cube Catalog 309 Cube Editor 349 cube. Inc. 280 physical warehouse schema 281 schema. viewing 279 logical data model 271. See logical data model.Project Design Guide Index 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. 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.

80 aggregate table. Inc.See ODS object. 255 PBT. 255 partition mapping defined on 250 application-level 251 attribute qualification 253 data slice 253 heterogeneous 252 homogeneous 252. opening Project Creation Assistant 78 Warehouse Catalog 219 Operational Data Store object. defined on 255 types 251 warehouse 254. See joint child relationship. P parent attribute 24 parent-child relationship 246 dynamic 247 overview 25 static 247 partition base table defined on 251. See OLTP. 254 metadata 251. © 2007 MicroStrategy. in metrics with custom MDX 366 properties for SAP BW 311 Q qualification for an attribute form 253 quality. 255 partition base table 255 server-level 251 table 222. managing 220 Warehouse Catalog 79 warehouse tables in 79 Project Builder 74 Project Creation Assistant 77. 80 removing tables from 80 sample project 267 schema 216 source. perspective 324 physical warehouse schema defined on 39 design factors 59 for MicroStrategy Tutorial 281 sample 289 planning a project 76 PMT. online transaction processing. . See project source tables. 197 project source defined on 65 connecting to 72 creating 77 prompt. integrating 248 creating 75 data warehouse 79 integrating aggregate tables 248 managing tables for 220 planning 76 Project Builder 74 Project Creation Assistant 78. See OLAP. See partition mapping table. See partition base table. 436 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.Index Project Design Guide one-to-one relationship defined on 160 lookup table 44 online analytical processing.

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 © 2007 MicroStrategy. 308 SAP BW to MicroStrategy characteristic attribute 307 characteristic value 307 characteristics 305 hierarchy 306 InfoCube 303. See RDBMS. 304 relating objects 302 virtual level 306 SAP. relating objects to MicroStrategy from Analysis Services 2000 317 from Analysis Services 2005 322 from Essbase 311 from SAP BW 302 relation. 330 key figures 300 mapping cubes 349 metadata models 302 OLAP Cube Catalog 309. See attribute relationship.sh. 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 characteristics 300 connecting to 327 on UNIX/Linux 330 on Windows 328 database instance 329.sh 331 structures 311 terminology 298 variable properties 309 variables 300. Inc. 343 query cubes 299 relating objects to MicroStrategy 302 SAP.Project Design Guide Index 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. 437 . fact 114 relational database management system. 333 hierarchies 300 InfoObjects 299 InfoProviders 299 Java Connector 328.

86 key 42 Logical Table Editor 250 lookup 43. See joint child relationship. 44 managing for a project 221 migrating 232 name space 222. 261 many-to-many 259 mapping types 264 member attributes 263 member expressions 263 member tables 263 438 © 2007 MicroStrategy.Index Project Design Guide type. See schema type. defined on 197 T table adding to a project 79 aggregate 241 alias 178. 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. 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. Inc. summary table 241 support. system hierarchy 159. . See SQL. 180 calculating logical sizes 231 calculating size 231 compound key 42 fact table defined on 46. time-series analysis 257 transformation defined on 258 components 263 double-counting 264 expression-based 259. See technical support. 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.

metrics 258 one-to-one mapping types 264 table-based 259. 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 . 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. user hierarchy defined on 197 browse attribute 207 browsing 207 browsing. See transformation metric. 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. 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 U unbalanced and ragged hierarchy 355 unique identifier 34 UNIX/Linux.Project Design Guide Index metric. 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 V variables overview 300 properties. See fact expression.

Index Project Design Guide warehouse. 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. . physical schema defined on 39. Inc.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times