Installation and Porting Guide For the Analytics Modules Version: 9.5 Document Number: 09900950 Version 9.5 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: 09900950 Copyright © 2015 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-2015 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., 1850 Towers Crescent Plaza, Tysons Corner, VA 22182. Rights are reserved under copyright laws of the United States with respect to unpublished portions of the Software. The following 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 9, MicroStrategy Distribution Services, MicroStrategy MultiSource Option, MicroStrategy Command Manager, MicroStrategy Enterprise Manager, MicroStrategy Object Manager, MicroStrategy Reporting Suite, MicroStrategy Power User, MicroStrategy Analyst, MicroStrategy Consumer, MicroStrategy Email Delivery, MicroStrategy BI Author, MicroStrategy BI Modeler, MicroStrategy Evaluation Edition, MicroStrategy Administrator, MicroStrategy Agent, MicroStrategy Architect, MicroStrategy BI Developer Kit, MicroStrategy Broadcast Server, MicroStrategy Broadcaster, MicroStrategy Broadcaster Server, MicroStrategy Business Intelligence Platform, MicroStrategy Consulting, MicroStrategy CRM Applications, MicroStrategy Customer Analyzer, MicroStrategy Desktop, MicroStrategy Desktop Analyst, MicroStrategy Desktop Designer, MicroStrategy eCRM 7, MicroStrategy Education, MicroStrategy eTrainer, MicroStrategy Executive, MicroStrategy Infocenter, MicroStrategy Intelligence Server, MicroStrategy Intelligence Server Universal Edition, MicroStrategy MDX Adapter, MicroStrategy Narrowcast Server, MicroStrategy Objects, MicroStrategy OLAP Provider, MicroStrategy SDK, MicroStrategy Support, MicroStrategy Telecaster, MicroStrategy Transactor, MicroStrategy Web, MicroStrategy Web Business Analyzer, MicroStrategy World, Application Development and Sophisticated Analysis, Best In Business Intelligence, Centralized Application Management, Information Like Water, Intelligence Through Every Phone, Intelligence To Every Decision Maker, Intelligent E-Business, Personalized Intelligence Portal, Query Tone, Rapid Application Development, MicroStrategy Intelligent Cubes, The Foundation For Intelligent E-Business, The Integrated Business Intelligence Platform Built For The Enterprise, The Platform For Intelligent E-Business, The Scalable Business Intelligence Platform Built For The Internet, Office Intelligence, MicroStrategy Office, MicroStrategy Report Services, MicroStrategy Web MMT, MicroStrategy Web Services, Pixel Perfect, Pixel-Perfect, MicroStrategy Mobile, MicroStrategy Integrity Manager and MicroStrategy Data Mining Services are all registered trademarks or trademarks of MicroStrategy Incorporated. All other company and product names may be trademarks of the respective companies with which they are associated. Specifications subject to change without notice. MicroStrategy is not responsible for errors or omissions. MicroStrategy makes no warranties or commitments concerning the availability of future products or versions that may be planned or under development. Patent Information This product is patented. One or more of the following patents may apply to the product sold herein: U.S. Patent Nos. 6,154,766, 6,173,310, 6,260,050, 6,263,051, 6,269,393, 6,279,033, 6,400,265, 6,567,796, 6,587,547, 6,606,596, 6,658,093, 6,658,432, 6,661,340, 6,662,195, 6,671,715, 6,691,100, 6,694,316, 6,697,808, 6,704,723, 6,741,980, 6,765,997, 6,768,788, 6,772,137, 6,788,768, 6,798,867, 6,801,910, 6,820,073, 6,829,334, 6,836,537, 6,850,603, 6,859,798, 6,873,693, 6,885,734, 6,940,953, 6,964,012, 6,977,992, 6,996,568, 6,996,569, 7,003,512, 7,010,518, 7,016,480, 7,020,251, 7,039,165, 7,082,422, 7,113,993, 7,127,403, 7,174,349, 7,181,417, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181, 7,272,212, 7,302,639, 7,324,942, 7,330,847, 7,340,040, 7,356,758, 7,356,840, 7,415,438, 7,428,302, 7,430,562, 7,440,898, 7,486,780, 7,509,671, 7,516,181, 7,559,048, 7,574,376, 7,617,201, 7,725,811, 7,801,967, 7,836,178, 7,861,161, 7,861,253, 7,881,443, 7,925,616, 7,945,584, 7,970,782, 8,005,870, 8,051,168, 8,051,369, 8,094,788, 8,130,918, 8,296,287, 8,321,411, 8,452,755, 8,521,733, and 8,522,192. 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-2015. Three D Graphics, Inc. All rights reserved. Actuate® Formula One. Copyright © 1993-2015 Actuate Corporation. All rights reserved. XML parser Copyright © 2003-2015 Microsoft Corporation. All rights reserved. Xalan XSLT processor. Copyright © 1999-2015. The Apache Software Foundation. All rights reserved. Xerces XML parser. Copyright © 1999-2015. The Apache Software Foundation. All rights reserved. FOP XSL formatting objects. Copyright © 2004-2015. The Apache Software Foundation. All rights reserved. Portions of Intelligence Server memory management Copyright © 1991-2015 Compuware Corporation. All rights reserved. ASIHTTPRequest library. Copyright © 2007-2015, All-Seeing Interactive. All rights reserved. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) International Components for Unicode Copyright © 1999-2015 Compaq Computer Corporation Copyright © 1999-2015 Hewlett-Packard Company Copyright © 1999-2015 IBM Corporation Copyright © 1999-2015 Hummingbird Communications Ltd. Copyright © 1999-2015 Silicon Graphics, Inc. Copyright © 1999-2015 Sun Microsystems, Inc. Copyright © 1999-2015 The Open Group All rights reserved. Real Player and RealJukebox are included under license from Real Networks, Inc. Copyright © 1999-2015. All rights reserved. CONTENTS Book Overview and Additional Resources Description of this guide............................................................ ix About the Analytics Modules ..........................................................x About this book ..............................................................................xi Additional formats ....................................................................xi How to find business scenarios and examples ....................... xii Prerequisites ........................................................................... xii Who should use this guide..................................................... xiii Resources.................................................................................... xiii Documentation....................................................................... xiii Education .............................................................................. xxii Consulting ............................................................................. xxii International support ............................................................. xxii Technical Support ................................................................ xxiii Feedback ..................................................................................xxviii 1. Introduction to MicroStrategy Analytics Modules Introduction.................................................................................. 1 2. Installation Introduction.................................................................................. 9 Documentation............................................................................... 2 MicroStrategy Analytics Modules................................................... 2 An analysis of portable analytical applications......................... 4 Analytics Modules as best practices examples........................ 6 About building analytical applications ...................................... 7 Installation prerequisites ................................................................ 9 System hardware recommendations ..................................... 10 System software requirements .............................................. 10 © 2015 MicroStrategy, Inc. v Contents Installation and Porting Guide Installation procedures................................................................. 11 The Setup Wizard .................................................................. 11 Installation verification ........................................................... 17 Uninstalling a MicroStrategy component ..................................... 18 3. Configuration Introduction................................................................................ 21 Configuring your software............................................................ 21 Configuration preparation ...................................................... 21 Configuration prerequisites .................................................... 23 Configure the production metadata repository....................... 24 Duplicate the Analytics Modules ............................................ 25 Configure the data warehouse connection ............................ 26 4. Using the Analytics Modules Introduction................................................................................ 31 Using the Analytics Modules as an initial design ......................... 32 Initial data warehouse ............................................................ 33 Customize and extend the Analytics Modules ............................. 34 Customization scenarios........................................................ 34 Scenario: Adding customer characteristics to CAM............... 36 Customization steps .............................................................. 37 Roll out to production................................................................... 37 Tuning and performance........................................................ 38 MicroStrategy users ............................................................... 38 Security .................................................................................. 38 Direct and server connections ............................................... 38 5. Porting the Analytics Modules Introduction................................................................................ 41 Introduction to portability.............................................................. 42 Portability methodology ............................................................... 43 Portability design drivers........................................................ 43 General porting prerequisites ...................................................... 46 MicroStrategy tools ................................................................ 46 Documentation....................................................................... 47 Other prerequisites ................................................................ 47 Port an Analysis Module .............................................................. 48 Porting overview .................................................................... 48 Perform a gap analysis ................................................................ 48 Gap analysis prerequisites..................................................... 49 vi © 2015 MicroStrategy, Inc. Installation and Porting Guide Contents Map the target data warehouse to the module’s physical schema .................................................................................. 49 Map the module’s logical data model to the target schema... 54 Identify application objects..................................................... 62 Identify additional requirements ............................................. 73 Map the module ........................................................................... 73 Mapping prerequisites ........................................................... 74 Map the module with Object Manager ................................... 74 Map the module without Object Manager .............................. 90 Customize and extend the module ............................................ 103 6. Creating Portable Analytical Applications Introduction.............................................................................. 105 Architecture of portable analytical applications.......................... 105 Best practices for building portable applications........................ 107 Design and development premises...................................... 108 Development process overview ........................................... 109 Phase I: Define the analytical domain.................................. 109 Phase II: Develop the logical data model............................. 115 Phase III: Define the report library ....................................... 123 Phase IV: Develop and test the reports ............................... 127 Portability rules and recommendations...................................... 131 Schema objects ................................................................... 131 Application objects ............................................................... 136 Glossary ................................................................................... 145 Index ......................................................................................... 157 © 2015 MicroStrategy, Inc. vii Contents viii Installation and Porting Guide © 2015 MicroStrategy, Inc. BOOK OVERVIEW AND ADDITIONAL RESOURCES Description of this guide This guide is a technical reference for the MicroStrategy Analytics Modules that come with MicroStrategy Architect. This guide provides installation and configuration steps for setting up the Analytics Modules. It also provides a detailed explanation of the MicroStrategy porting methodology to let you implement the Analytics Modules with an existing data warehouse; customization and extension details; and procedures to create your own analytical applications based on the best practices represented by the Analytics Modules components: • Chapter 1, Introduction to MicroStrategy Analytics Modules presents an introduction to the Analytics Modules, and provides an analysis of analytical applications as well as a detailed description of the MicroStrategy Analytics Modules components. • Chapter 2, Installation presents steps to install and uninstall the Analytics Modules. • Chapter 3, Configuration presents steps to configure your Analytics Modules software. • Chapter 4, Using the Analytics Modules presents methods to use the Analytics Modules as your initial data warehouse when you do not have © 2015 MicroStrategy, Inc. ix Book Overview and Additional Resources Installation and Porting Guide an existing data warehouse in the given analysis area. It also provides steps and scenarios to customize and extend your Analytics Modules implementation. • Chapter 5, Porting the Analytics Modules presents an introduction to portability, a description of the MicroStrategy portability methodology, and detailed procedures to port an Analysis Module to an existing data warehouse. • Chapter 6, Creating Portable Analytical Applications presents a description of the benefits of building portable analytical applications, provides a discussion of the architecture and best practices for designing and developing analytical applications, and presents detailed procedures for using the Analytics Modules as a template to build an analytical application. Technical terms that need more clarification are defined in the glossary section of this guide. Consult each Analysis Module’s individual reference guide for detailed descriptions of the given module’s analysis area, scorecards and reports, logical data model, physical schema, and data dictionary. About the Analytics Modules MicroStrategy helps you build analytical applications by offering a rapid application development framework consisting of analytic starter kits, development products, and methodologies. There are five Analytics Modules that are built to be portable. You can choose to deploy the analytical applications against your existing data warehouse, use the packaged schema as the basis of a new data warehouse, or use the modules as templates to build analytical applications. The components are: • Analytics Modules Prepackaged metadata: Best practices reports, scorecards and dashboards, key performance indicators, attributes, business metrics, filters, and custom groups Default physical and logical data model: Analytics that are designed to work with your physical schemas and data model or with the module’s packaged data warehouse schema x About the Analytics Modules © 2015 MicroStrategy, Inc. Installation and Porting Guide • Book Overview and Additional Resources Reference guides: Documentation on each analysis module’s data model, the individual analysis areas, metadata object definitions, data dictionary, and individual report use scenarios Implementation methodology Documentation that guides you step-by-step through implementing analytic modules against existing data warehouses (known as porting) Design rules and tenets for designing and developing portable analytical applications MicroStrategy Architect: A development tool that allows you to map Analytics Modules to existing data warehouses The Advanced Reporting Guide and other documentation for MicroStrategy Developer and MicroStrategy Architect is available on your MicroStrategy disk (see Resources, page xiii). See each Analysis Module’s reference guide for a description of the given module’s analysis area, packaged reports, logical and physical models, and data dictionary. About this book This book is divided into chapters that begin with a brief overview of the chapter’s content. The following sections provide the location of examples, list prerequisites for using this book, and describe the user roles the information in this book was designed for. in the MicroStrategy Tutorial project are updated to reflect the Dates current year. The sample documents and images in this guide, as well as the procedures, were created with dates that may no longer be available in the Tutorial project. Replace them with the first year of data in your Tutorial project. Additional formats This book is also available as an electronic publication in the Apple iBookstore, and can be read on an iPhone or iPad with the iBooks app © 2015 MicroStrategy, Inc. About this book xi Book Overview and Additional Resources Installation and Porting Guide installed. To download this book, search for the book’s title in the iBookstore search bar, or scan the QR code below using your device’s camera. How to find business scenarios and examples For examples of report features and a basic introduction to the MicroStrategy business intelligence system, use the MicroStrategy Tutorial, which is MicroStrategy’s sample warehouse, metadata, and project. Information about the MicroStrategy Tutorial can be found in the MicroStrategy Basic Reporting Guide. For extensive examples of metrics, filters, and other report objects, see the MicroStrategy Advanced Reporting Guide. Prerequisites How you use this document depends on the type of user you are and your goals for working with the Analytics Modules. If you intend to evaluate the business value of the modules, you should have: • Experience with MicroStrategy reports and metrics using MicroStrategy technology If you intend to implement and customize the modules, you should have: • Experience with logical data modeling and creating business intelligence applications using MicroStrategy technology • A basic understanding of RDBMS concepts and data modeling xii About this book © 2015 MicroStrategy, Inc. Installation and Porting Guide Book Overview and Additional Resources Who should use this guide This document is designed for: • Advanced users and administrators evaluating the business value of the Analytics Modules • Consultants and developers implementing and customizing the Analytics Modules Resources Documentation MicroStrategy provides both manuals and online help; these two information sources provide different types of information, as described below: • Manuals: In general, MicroStrategy manuals provide: Introductory information and concepts Examples and images Checklists and high-level procedures to get started The steps to access the manuals are described in Accessing manuals and other documentation sources, page xx. Most of these manuals are also available printed in a bound, soft cover format. To purchase printed manuals, contact your MicroStrategy Account Executive with a purchase order number. • Help: In general, MicroStrategy help provides: Detailed steps to perform procedures Descriptions of each option on every software screen Translations For the most up-to-date translations of MicroStrategy documentation, refer to the MicroStrategy Knowledge Base. Due to translation time, manuals in © 2015 MicroStrategy, Inc. Resources xiii Book Overview and Additional Resources Installation and Porting Guide languages other than English may contain information that is one or more releases behind. You can see the version number on the title page of each manual. Finding information You can search all MicroStrategy books and Help for a word or phrase, with a simple Google™ search at www.google.com. For example, type “MicroStrategy derived metric” or “MicroStrategy logical table” into a Google search. As described above, books typically describe general concepts and examples; Help typically provides detailed steps and screen options. To limit your search to MicroStrategy books, on Google’s main page you can click More, then select Books. Manuals for MicroStrategy overview and evaluation • Introduction to MicroStrategy: Evaluation Guide Instructions for installing, configuring, and using the MicroStrategy Evaluation Edition of the software. This guide also includes a detailed, step-by-step evaluation process of MicroStrategy features, where you perform reporting with the MicroStrategy Tutorial project and its sample business data. • MicroStrategy Evaluation Edition Quick Start Guide Overview of the installation and evaluation process, and additional resources. • MicroStrategy Suite: Quick Start Guide Evaluate MicroStrategy as a departmental solution. Provides detailed information to download, install, configure, and use the MicroStrategy Suite. Resources for Identity and Loyalty • Alert Commerce Management System (CMS) Guide and Alert API Reference Content resources providing steps to deliver and manage marketing and commerce content through the Alert mobile applications. xiv Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide • Book Overview and Additional Resources Usher Administration Guide Steps to perform mobile identity validation using the Usher mobile identity network to issue electronic badges for identifying users. Manuals for query, reporting, and analysis • MicroStrategy Installation and Configuration Guide Information to install and configure MicroStrategy products on Windows, UNIX, Linux, and HP platforms, as well as basic maintenance guidelines. • MicroStrategy Upgrade Guide Instructions to upgrade existing MicroStrategy products. • MicroStrategy Project Design Guide Information to create and modify MicroStrategy projects, and understand facts, attributes, hierarchies, transformations, advanced schemas, and project optimization. • MicroStrategy Basic Reporting Guide Instructions to get started with MicroStrategy Developer and MicroStrategy Web, and how to analyze data in a report. Includes the basics for creating reports, metrics, filters, and prompts. • MicroStrategy Advanced Reporting Guide: Enhancing Your Business Intelligence Application Instructions for advanced topics in the MicroStrategy system, building on information in the Basic Reporting Guide. Topics include reports, Freeform SQL reports, Query Builder reports, filters, metrics, Data Mining Services, custom groups, consolidations, and prompts. • Document and Dashboard Analysis Guide Instructions for a business analyst to execute and analyze a document in MicroStrategy Developer and MicroStrategy Web, building on basic concepts about projects and reports presented in the MicroStrategy Basic Reporting Guide. • MicroStrategy Report Services Document Creation Guide: Creating Boardroom Quality Documents Instructions to design and create Report Services documents, building on information in the Document and Dashboard Analysis Guide. It is © 2015 MicroStrategy, Inc. Resources xv Book Overview and Additional Resources Installation and Porting Guide organized to help guide you through creating a new document, from creating the document itself, to adding objects to the new document, and formatting the document and its objects. • MicroStrategy Dashboards and Widgets Creation Guide: Creating Interactive Dashboards for your Data Instructions for designing and creating MicroStrategy Report Services dashboards, a type of document that is optimized for viewing online and for user interactivity. It builds on the basic concepts about documents presented in the MicroStrategy Report Services Document Creation Guide. • MicroStrategy OLAP Services Guide Information on MicroStrategy OLAP Services, which is an extension of MicroStrategy Intelligence Server. OLAP Services features include Intelligent Cubes, derived metrics, derived elements, dynamic aggregation, view filters, and dynamic sourcing. • MicroStrategy Office User Guide Instructions for using MicroStrategy Office to work with MicroStrategy reports and documents in Microsoft® Excel, PowerPoint, and Word, to analyze, format, and distribute business data. • MicroStrategy Mobile Analysis Guide: Analyzing Data with MicroStrategy Mobile Information and instructions for using MicroStrategy Mobile to view and analyze data, and perform other business tasks with MicroStrategy reports and documents on a mobile device. • MicroStrategy Mobile Design and Administration Guide: A Platform for Mobile Intelligence Information and instructions to install and configure MicroStrategy Mobile, as well as instructions for a designer working in MicroStrategy Developer or MicroStrategy Web to create effective reports and documents for use with MicroStrategy Mobile. • MicroStrategy System Administration Guide: Tuning, Monitoring, and Troubleshooting your MicroStrategy Business Intelligence System Concepts and high-level steps to implement, deploy, maintain, tune, and troubleshoot a MicroStrategy business intelligence system. xvi Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide • Book Overview and Additional Resources MicroStrategy Supplemental Reference for System Administration: VLDB Properties, Internationalization, User Privileges, and other Supplemental Information for Administrators Information and instructions for MicroStrategy administrative tasks such as configuring VLDB properties and defining data and metadata internationalization, and reference material for other administrative tasks. • MicroStrategy Functions Reference Function syntax and formula components; instructions to use functions in metrics, filters, attribute forms; examples of functions in business scenarios. • MicroStrategy MDX Cube Reporting Guide Information to integrate MicroStrategy with MDX cube sources. You can integrate data from MDX cube sources into your MicroStrategy projects and applications. Manuals for Analytics Modules • Analytics Modules 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 Manuals for Narrowcast Services products • MicroStrategy Narrowcast Server Getting Started Guide Instructions to work with the tutorial to learn Narrowcast Server interfaces and features. • MicroStrategy Narrowcast Server Installation and Configuration Guide Information to install and configure Narrowcast Server. © 2015 MicroStrategy, Inc. Resources xvii Book Overview and Additional Resources • Installation and Porting Guide MicroStrategy Narrowcast Server Application Designer Guide Fundamentals of designing Narrowcast Server applications. • MicroStrategy Narrowcast Server System Administrator Guide Concepts and high-level steps to implement, maintain, tune, and troubleshoot Narrowcast Server. • MicroStrategy Narrowcast Server Upgrade Guide Instructions to upgrade an existing Narrowcast Server. Software Development Kits • MicroStrategy Developer Library (MSDL) Information to understand the MicroStrategy SDK, including details about architecture, object models, customization scenarios, code samples, and so on. • MicroStrategy Web SDK Web SDK is available in the MicroStrategy Developer Library, The which is part of the MicroStrategy SDK. • Narrowcast Server SDK Guide Instructions to customize Narrowcast Server functionality, integrate Narrowcast Server with other systems, and embed Narrowcast Server functionality within other applications. Documents the Narrowcast Server Delivery Engine and Subscription Portal APIs, and the Narrowcast Server SPI. Documentation for MicroStrategy Portlets • Enterprise Portal Integration Help Information to help you implement and deploy MicroStrategy BI within your enterprise portal, including instructions for installing and configuring out-of-the-box MicroStrategy Portlets for several major enterprise portal servers. This resource can be accessed from the MicroStrategy Product Manuals page, as described in Accessing manuals and other documentation sources, page xx. xviii Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide Book Overview and Additional Resources Documentation for MicroStrategy GIS Connectors • GIS Integration Help Information to help you integrate MicroStrategy with Geospatial Information Systems (GIS), including specific examples for integrating with various third-party mapping services. This resource can be accessed from the MicroStrategy Product Manuals page, as described in Accessing manuals and other documentation sources, page xx. Help Each MicroStrategy product includes an integrated help system to complement the various interfaces of the product as well as the tasks that can be accomplished using the product. Some of the MicroStrategy help systems require a web browser to be viewed. For supported web browsers, see the MicroStrategy Readme. MicroStrategy provides several ways to access help: • Help button: Use the Help button or ? (question mark) icon on most software windows to see help for that window. • Help menu: From the Help menu or link at the top of any screen, select MicroStrategy Help to see the table of contents, the Search field, and the index for the help system. • F1 key: Press F1 to see context-sensitive help that describes each option in the software window you are currently viewing. MicroStrategy Web, MicroStrategy Web Administrator, and For MicroStrategy Mobile Server, pressing the F1 key opens the context-sensitive help for the web browser you are using to access these MicroStrategy interfaces. Use the Help menu or ? (question mark) icon to access help for these MicroStrategy interfaces. © 2015 MicroStrategy, Inc. Resources xix Book Overview and Additional Resources Installation and Porting Guide Accessing manuals and other documentation sources The manuals are available from http://www.microstrategy.com/ producthelp, as well as from your MicroStrategy disk or the machine where MicroStrategy was installed. Acrobat Reader is required to view these manuals. If you do not Adobe have Acrobat Reader installed on your computer, you can download it from http://get.adobe.com/reader/. The best place for all users to begin is with the MicroStrategy Basic Reporting Guide. To access the installed manuals and other documentation sources, see the following procedures: • To access documentation resources from any location, page xx • To access documentation resources on Windows, page xx • To access documentation resources on UNIX and Linux, page xxi To access documentation resources from any location 1 Visit http://www.microstrategy.com/producthelp. To access documentation resources on Windows 1 From the Windows Start menu, choose Programs (or All Programs), MicroStrategy Documentation, then Product Manuals. A page opens in your browser showing a list of available manuals in PDF format and other documentation sources. 2 Click the link for the desired manual or other documentation source. 3 If you click the link for the Narrowcast Services SDK Guide, a File Download dialog box opens. This documentation resource must be downloaded. Select Open this file from its current location, and click OK. bookmarks are not visible on the left side of an Acrobat (PDF) Ifmanual, from the View menu click Bookmarks and Page. This step varies slightly depending on your version of Adobe Acrobat Reader. xx Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide Book Overview and Additional Resources To access documentation resources on UNIX and Linux 1 Within your UNIX or Linux machine, navigate to the directory where you installed MicroStrategy. The default location is /opt/MicroStrategy, or $HOME/MicroStrategy/install if you do not have write access to /opt/MicroStrategy. 2 From the MicroStrategy installation directory, open the Help folder. 3 Open the Product_Manuals.htm file in a web browser. A page opens in your browser showing a list of available manuals in PDF format and other documentation sources. 4 Click the link for the desired manual or other documentation source. 5 If you click the link for the Narrowcast Services SDK Guide, a File Download dialog box opens. This documentation resource must be downloaded. Select Open this file from its current location, and click OK. bookmarks are not visible on the left side of an Acrobat (PDF) Ifmanual, from the View menu click Bookmarks and Page. This step varies slightly depending on your version of Adobe Acrobat Reader. Documentation standards MicroStrategy online help and PDF manuals (available both online and in printed format) use standards to help you identify certain types of content. The following table lists these standards. standards may differ depending on the language of this manual; These some languages have rules that supersede the table below. Type Indicates bold • Button names, check boxes, options, lists, and menus that are the focus of actions or part of a list of such GUI elements and their definitions Example: Click Select Warehouse. italic • Names of other product manuals and documentation resources • When part of a command syntax, indicates variable information to be replaced by the user Example: The aggregation level is the level of calculation for the metric. Example: Type copy c:\filename d:\foldername\filename © 2015 MicroStrategy, Inc. Resources xxi Book Overview and Additional Resources Type Indicates Courier font • • • • • • • Installation and Porting Guide Calculations Code samples Registry keys Path and file names URLs Messages displayed in the screen Text to be entered by the user Example: Sum(revenue)/number of months. Example: Type cmdmgr -f scriptfile.scp and press Enter. + A keyboard command that calls for the use of more than one key (for example, SHIFT+F1). A note icon indicates helpful information for specific situations. A warning icon alerts you to important information such as potential security risks; these should be read before continuing. Education MicroStrategy Education Services provides a comprehensive curriculum and highly skilled education consultants. Many customers and partners from over 800 different organizations have benefited from MicroStrategy instruction. For a detailed description of education offerings and course curriculums, visit http://www.microstrategy.com/Education. Consulting MicroStrategy Consulting Services provides proven methods for delivering leading-edge technology solutions. Offerings include complex security architecture designs, performance and tuning, project and testing strategies and recommendations, strategic planning, and more. For a detailed description of consulting offerings, visit http://www.microstrategy.com/ Services. International support MicroStrategy supports several locales. Support for a locale typically includes native database and operating system support, support for date formats, xxii Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide Book Overview and Additional Resources numeric formats, currency symbols, and availability of translated interfaces and certain documentation. MicroStrategy is certified in homogeneous configurations (where all the components lie in the same locale) in the following languages—English (US), French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Spanish, Chinese (Simplified), Chinese (Traditional), Danish, and Swedish. A translated user interface is available in each of the above languages. For information on specific languages supported by individual MicroStrategy system components, see the MicroStrategy readme. MicroStrategy also provides limited support for heterogeneous configurations (where some of the components may lie in different locales). Please contact MicroStrategy Technical Support for more details. Technical Support If you have questions about a specific MicroStrategy product, you should: 1 Consult the product guides, Help, and readme files. Locations to access each are described above. 2 Consult the MicroStrategy Knowledge Base online at https:// resource.microstrategy.com/support. administrator in your organization may be able to help Ayoutechnical resolve your issues immediately. 3 If the resources listed in the steps above do not provide a solution, contact MicroStrategy Technical Support directly. To ensure the most productive relationship with MicroStrategy Technical Support, review the Policies and Procedures document in your language, posted at http:// www.microstrategy.com/Support/Policies. Refer to the terms of your purchase agreement to determine the type of support available to you. MicroStrategy Technical Support can be contacted by your company’s Support Liaison. A Support Liaison is a person whom your company has designated as a point-of-contact with MicroStrategy’s support personnel. All customer inquiries and case communications must come through these named individuals. Your company may designate two employees to serve as their Support Liaisons, and can request to change their Support Liaisons two times per year with prior written notice to MicroStrategy Technical Support. © 2015 MicroStrategy, Inc. Resources xxiii Book Overview and Additional Resources Installation and Porting Guide It is recommended that you designate Support Liaisons who have MicroStrategy Administrator privileges. This can eliminate security conflicts and improve case resolution time. When troubleshooting and researching issues, MicroStrategy Technical Support personnel may make recommendations that require administrative privileges within MicroStrategy, 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. Ensure issues are resolved quickly Before logging a case with MicroStrategy Technical Support, the Support Liaison may follow the steps below to ensure that issues are resolved quickly: 1 Verify that the issue is with MicroStrategy software and not a third party software. 2 Verify that the system is using a currently supported version of MicroStrategy software by checking the Product Support Expiration Schedule at http://www.microstrategy.com/Support/Expiration.asp. 3 Attempt to reproduce the issue and determine whether it occurs consistently. 4 Minimize the complexity of the system or project object definition to isolate the cause. 5 Determine whether the issue occurs on a local machine or on multiple machines in the customer environment. 6 Discuss the issue with other users by posting a question about the issue on the MicroStrategy Customer Forum at https:// resource.microstrategy.com/forum/. The following table shows where, when, and how to contact MicroStrategy Technical Support. If your Support Liaison is unable to reach MicroStrategy Technical Support by phone during the hours of operation, they can leave a voicemail message, send email or fax, or log a case using the Online Support xxiv Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide Book Overview and Additional Resources Interface. The individual Technical Support Centers are closed on certain public holidays. North America Email: [email protected] Web: https://resource.microstrategy.com/support Fax: (703) 842–8709 Phone: (703) 848–8700 Hours: 9:00 A.M.–7:00 P.M. Eastern Time, Monday–Friday except holidays EMEA: Europe The Middle East Africa Email: [email protected] Web: https://resource.microstrategy.com/support Fax: +44 (0) 208 711 2525 The European Technical Support Centre is closed on national public holidays in each country. Phone: • Belgium: + 32 2792 0436 • France: +33 17 099 4737 • Germany: +49 22 16501 0609 • Ireland: +353 1436 0916 • Italy: +39 023626 9668 • Poland: +48 22 459 52 52 • Scandinavia & Finland: +46 8505 20421 • Spain: +34 91788 9852 • The Netherlands: +31 20 794 8425 • UK: +44 (0) 208 080 2182 • International distributors: +44 (0) 208 080 2183 Hours: • United Kingdom: 9:00 A.M.–6:00 P.M. GMT, Monday-Friday except holidays • EMEA (except UK): 9:00 A.M.–6:00 P.M. CET, Monday-Friday except holidays Asia Pacific Email: [email protected] Web: https://resource.microstrategy.com/support Phone: • Australia: +61 2 9333 6499 • Korea: +82 2 560 6565 Fax: +82 2 560 6555 • Japan: +81 3 3511 6720 Fax: +81 3 3511 6740 • Singapore: +65 6303 8969 Fax: +65 6303 8999 • Asia Pacific (except Australia, Japan, Korea, and Singapore): +86 571 8526 8067 Fax: +86 571 8848 0977 Hours: • Japan and Korea: 9:00 A.M.–6:00 P.M. JST (Tokyo), Monday-Friday except holidays • Asia Pacific (except Japan and Korea): 7 A.M.-6 P.M. (Singapore) Monday-Friday except holidays Latin America Email: [email protected] Web: https://resource.microstrategy.com/support Phone: • LATAM (except Brazil and Argentina): +54 11 5222 9360 Fax: +54 11 5222 9355 • Argentina: 0 800 444 MSTR Fax: +54 11 5222 9355 • Brazil: +55 11 3054 1010 Fax: +55 11 3044 4088 Hours: • Latin America (except Brazil): 9:00 A.M.–7:00 P.M. (Buenos Aires), Monday-Friday except holidays • Brazil: 9 A.M. - 6 P.M. (São Paulo), Monday–Friday except holidays © 2015 MicroStrategy, Inc. Resources xxv Book Overview and Additional Resources Installation and Porting Guide 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. Required information when calling When contacting MicroStrategy Technical Support, please provide the following information: • • Personal information: Name (first and last) Company and customer site (if different from company) Contact information (phone and fax numbers, e-mail addresses) Case details: • Configuration information, including MicroStrategy software product(s) and versions Full description of the case including symptoms, error messages(s), and steps taken to troubleshoot the case thus far Business/system impact If this is the Support Liaison’s first call, they should also be prepared to provide the following: • Street address • Phone number • Fax number • Email address To help the Technical Support representative resolve the problem promptly and effectively, 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, 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 xxvi Resources © 2015 MicroStrategy, Inc. Installation and Porting Guide • 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? When did the condition first occur? • Book Overview and Additional Resources What events took place immediately prior to the first occurrence of the condition (for example, a major database load, a database move, or a software upgrade)? If there was an error message, what was its exact wording? What steps have you taken to isolate and resolve the issue? What were the results? System configuration (the information needed depends on the nature of the problem; not all items listed below may be necessary): Computer hardware specifications (processor speed, RAM, disk space, and so on) Network protocol used ODBC driver manufacturer and version Database gateway software version (For MicroStrategy Web-related problems) browser manufacturer and version (For MicroStrategy Web-related problems) Web server manufacturer and version If the issue requires additional investigation or testing, the Support Liaison and the MicroStrategy Technical Support representative should agree on certain action items to be performed. The Support Liaison should perform any agreed-upon actions before contacting MicroStrategy Technical Support again regarding the issue. If the Technical Support representative is responsible for an action item, the Support Liaison may call MicroStrategy Technical Support at any time to inquire about the status of the issue. © 2015 MicroStrategy, Inc. Resources xxvii Book Overview and Additional Resources Installation and Porting Guide Feedback Please send any comments or suggestions about user documentation for MicroStrategy products to: [email protected] Send suggestions for product enhancements to: [email protected] When you provide feedback to us, please include the name and version of the products you are currently using. Your feedback is important to us as we prepare for future releases. xxviii Feedback © 2015 MicroStrategy, Inc. 1 1. INTRODUCTION TO MICROSTRATEGY ANALYTICS MODULES Introduction The MicroStrategy Analytics Modules are analytical starter kits designed to solve business problems. Each of the modules ships with a sample data model and numerous reports and analytics. The MicroStrategy Analytics Modules are designed with a portability paradigm, which means they can work against existing data warehouses and allow businesses to make use of data investments without the need for extensive data extraction and loading concerns. MicroStrategy helps you build analytical applications by offering a rapid application development framework consisting of analytic starter kits, development products, and design and development methodologies. The development framework includes five analytics modules that are built to be portable. You can choose to: • Deploy the analytical applications against your existing data warehouse • Use the packaged physical schema as the basis of your data warehouse • Use the modules as templates to build analytical applications © 2015 MicroStrategy, Inc. 1 1 Introduction to MicroStrategy Analytics Modules Installation and Porting Guide Documentation Documentation includes a separate reference guide for each Analysis Module, and this Installation and Porting Guide. Documentation for Developer Designer and Architect is available to help you use these development tools. The MicroStrategy Advanced Reporting Guide contains most of the information pertinent to the procedures required in this document. MicroStrategy Analytics Modules The MicroStrategy Analytics Modules are a set of packaged analytical components built using the MicroStrategy platform. The modules can be mapped to a different data warehouse or used as starter kits to develop custom applications. This release includes Analysis Modules for customer analysis, sales analysis, financial reporting analysis, sales distribution analysis, and human resources analysis. Each Analysis Module consists of a MicroStrategy project in a metadata repository and comes with a default physical data model and documentation covering that module’s reports and metadata. Each module contains approximately 50-60 reports, a set of key performance indicators (KPIs) and business metrics, and sample scorecards. You can use these reports and KPIs as building blocks to create and deploy additional reports and performance measurements. MicroStrategy provides report-building wizards that anyone can use to design and build reports. Developers have access to over 150 functions (arithmetic, aggregate, statistical, financial, mathematical, and OLAP) that they can use to build new KPIs and business metrics. For example, a developer can use the Revenue metric included in the Customer Analysis Module to build additional metrics such as the running sum, moving average, and standard deviation of revenue. Developers can also customize the areas of analysis and navigation paths for end users, and create workflow wizards for end users to build their own reports and analyze information. You can take advantage of the Analytics Modules in different ways: • 2 Documentation If you have an existing data warehouse containing data pertinent to a given Analysis Module’s analytical area, you can “map” the Analysis Module and its reports to work with your data warehouse’s existing data structures. © 2015 MicroStrategy, Inc. Installation and Porting Guide Introduction to MicroStrategy Analytics Modules 1 • If you do not have a data warehouse containing data pertinent to a given Analysis Module’s analytical area, you can use the physical schema that comes with each of the Analytics Modules, as well as the logical data model and reports, to serve as a starter design for a new data warehouse. • You can use the components of the Analytics Modules as best practices examples in a given analytical area. You can use the packaged components, documentation, and best practices scenarios and examples as templates to build analytical applications. The Analytics Modules: • Provide best practices analysis and MicroStrategy expertise in the areas of customer analysis, sales analysis, sales and distribution analysis, human resources analysis, and financial reporting analysis • Can be integrated into an existing data warehouse, taking advantage of MicroStrategy platform flexibility, schema support, and database independence while protecting your data warehouse investments • Use an easily extendable and modifiable architecture • Are developed with MicroStrategy standard tools so an additional application framework is not required; standard MicroStrategy tools are used to implement and extend the application • Are modular by nature, allowing you to implement only parts of a module or to combine several modules together, while providing a seamless experience for users The MicroStrategy Analytics Modules include metadata content and documentation, as described below. • Metadata content is the definition of the logical data model and reports in the MicroStrategy metadata repository. • Documentation includes: Business content, such as business concept (attribute) definitions and report usage scenarios located in each Analysis Module’s reference guide Technical content, such as the chapters in this guide that describe the portability methodology and explain how to implement the modules © 2015 MicroStrategy, Inc. MicroStrategy Analytics Modules 3 1 Introduction to MicroStrategy Analytics Modules Installation and Porting Guide Analytics Modules documentation The documentation is an essential component of the modular analytical applications, providing both business and technical content. Documentation Description Reference Guides Each of the Analytics Modules has its own reference guide, containing all the definitions for that module. Each reference guide includes: • An introduction to each module’s analysis area and reporting challenges • Business value information and a complete definition, with a report screen shot, for each packaged report • A complete list of all metrics and their descriptions • A logical data model definition with all hierarchies and attributes, including metadata definitions • The default physical schema provided with the module and the data dictionary (tables and columns) Installation and Porting Guide This guide contains • Installation information specific to the Analytics Modules • Configuration steps for the Analytics Modules • Information for customizing and extending the Analytics Modules to suit your business requirements • The MicroStrategy porting methodology, along with detailed steps and examples for porting an Analysis Module to your existing data warehouse • Best practices for using the Analytics Modules as a template for designing and building analytical applications An analysis of portable analytical applications Prepackaged analytical applications like the MicroStrategy Analytics Modules provide two major benefits: • They deliver best practices reports for a given domain area. • They allow reduced time for implementation. Drawbacks of traditional analytical applications Unfortunately, many prepackaged analytical applications also come with costs, like the following: • A fixed physical schema and reports force you to model your business around packaged components instead of around your own business requirements. 4 MicroStrategy Analytics Modules © 2015 MicroStrategy, Inc. Installation and Porting Guide Introduction to MicroStrategy Analytics Modules 1 • Fixed metadata components are difficult to customize and extend to support your business requirements. • Data must be extracted to a new database schema, requiring an extraction tool and very intensive services. • They have a high cost entry point. Additional costs include a required ETL tool, end-user licenses, and implementation services. Traditional Packaged Analytics Apps Existing Analytics Apps and Data Warehouse Existing Reports Fixed packaged Reports Existing Reports Hard Wired Fixed Schema New ETL New ETL Existing Data Warehouse ETL ETL ETL OLTP CRM ERP Advantages of MicroStrategy analytical applications The MicroStrategy Analytics Modules let you benefit from the advantages of using a prepackaged analytical application and provide additional benefits without the costs inherent in traditional packaged analytical applications. MicroStrategy advantages include: • Best practices reports for a given domain area, developed with over a decade of MicroStrategy business intelligence implementation experience and best practices methodologies • Integration into your existing data warehouse, which is critical to make use of existing data warehouse investments • Rapid deployment, providing packaged components without additional, extensive data extraction © 2015 MicroStrategy, Inc. MicroStrategy Analytics Modules 5 1 Introduction to MicroStrategy Analytics Modules Installation and Porting Guide • No fixed components, making it easy to extend and customize the analytical applications to address your business and analysis requirements • Modularity, which allows you the flexibility to implement some analysis areas within an Analysis Module or to combine several Analytics Modules • A low cost entry point; the five Analytics Modules plus standard project development tools have a low per-developer price, while end users only require standard licenses using an existing data warehouse, the value obtained from the When Analytics Modules depends on existing data structures and data elements. If your data warehouse has non-optimal schemas or missing key data elements, it can limit the value obtained from the MicroStrategy Analytics Modules. Analytics Modules as best practices examples The MicroStrategy Analytics Modules reflect best practices for analytical applications. Because of this, you can use the Analytics Modules and their components as templates on every level. 6 MicroStrategy Analytics Modules © 2015 MicroStrategy, Inc. Installation and Porting Guide Introduction to MicroStrategy Analytics Modules 1 Examples of best practices templates include • Best practices reports: Use the documentation and metadata definitions to reproduce your favorite Analysis Module reports in an existing MicroStrategy project. You can use the Analytics Modules reports as templates, reflecting best practices examples for customer analysis, sales analysis, financial analysis, human resources analysis, and sales distribution analysis. • Best practices schema design: Use portions of the physical schema design to enhance a data warehouse that has no existing data in the given analysis area. • Best practices documentation: Use the documentation as a template to document the processes and tasks required to define any packaged analytical application. • Best practices analytical applications: Use the Analytics Modules as a template to design and develop your own portable analytical applications. About building analytical applications Many of the benefits of implementing portable analytical applications are described in An analysis of portable analytical applications, page 4. But your design and development efforts can also benefit when you use the portability paradigm and the information in Chapter 6, Creating Portable Analytical Applications, whether you are building internal applications, developing packaged applications, or performing integration and consulting services for portable analytical applications. Building internal applications If you are building internal analytical applications and implementing them in different sites, there are many ways to benefit from the MicroStrategy Analytics Modules: • Define best analytical practices for reports, metrics, the logical data model, and so on; and save time implementing them through different database engines and data warehouses. • Protect your investment in existing data warehouses across the company. • Take advantage of MicroStrategy best practices and documentation. © 2015 MicroStrategy, Inc. MicroStrategy Analytics Modules 7 1 Introduction to MicroStrategy Analytics Modules Installation and Porting Guide For example, a global telecommunications company implements a customer analysis application based on the MicroStrategy Customer Analysis Module for its American operations. The portable nature of the MicroStrategy application allows the company to implement analytical best practices in their international operations as well, even if they use different physical schemas or database engines. The application is also easy to customize to the needs of each site. Developing packaged applications For software companies developing packaged analytical applications, benefits are numerous: • Increase your market by targeting companies with existing data warehouses in a given domain area. • Focus on making the best use of intellectual property in the form of best practices analyses instead of creating physical schemas and performing extensive data extraction. • Take advantage of MicroStrategy’s best practices and documentation. • Save time during implementation and deployment because MicroStrategy’s Analytics Modules are the easiest to customize and extend. Integrating and consulting For MicroStrategy’s system integrators and consultants, they can: • Reuse best practices implementations and proofs of concept, saving time and providing consistency for future implementations • Package intellectual property in the form of the logical data model, metrics, reports, and so on without requiring a fixed physical schema • Implement, customize, and extend analytical applications easily 8 MicroStrategy Analytics Modules © 2015 MicroStrategy, Inc. 2 2. INSTALLATION Introduction This chapter describes the prerequisites and procedures for installing the MicroStrategy Analytics Modules and their related packaged components. Developer and MicroStrategy Architect are the MicroStrategy additional products that work with the Analytics Modules. Developer and Architect are necessary to make use of the Analytics Modules. If you have already installed Developer and Architect, you can proceed to install the Analytics Modules. However, if you have not yet installed Developer and Architect, see the MicroStrategy Installation and Configuration Guide to install them either before or at the same time as you install the Analytics Modules. Installation prerequisites Before installing the Analytics Modules, review the requirements below. © 2015 MicroStrategy, Inc. Installation prerequisites 9 2 Installation Installation and Porting Guide System hardware recommendations Make sure you have sufficient hard drive space to install all of the Analytics Modules and their related documentation. with version 7.5.1, depending on the license you have Beginning purchased and the installation options you choose, you may install files within one of several scenarios, as follows: • A default (clean) installation of Analytics Modules files automatically installs the MicroStrategy Tutorial files along with the Analytics Modules files, and both products share a single metadata. • If you have previously installed either the Analytics Modules or the Tutorial, the installation process prompts you as to whether you wish to overwrite your old Analytics Modules or Tutorial files. The options for each decision are noted in the appropriate places in the installation steps below. There are no additional system hardware requirements to install the Analytics Modules, other than those required for your other MicroStrategy products. See the MicroStrategy Installation and Configuration Guide for a complete list of recommended and required hardware, software, and other installation prerequisites before you install any MicroStrategy product. System software requirements If you are installing the Analytics Modules at a different time than any other MicroStrategy products, make sure MicroStrategy Developer and MicroStrategy Architect have been installed before you install the Analytics Modules. If you have already installed Developer and Architect, there are no additional system software requirements to install the Analytics Modules outside of those required for your other MicroStrategy products. See the MicroStrategy Installation and Configuration Guide for a complete list of recommended and required hardware, software, and other installation prerequisites before you install any MicroStrategy product. 10 Installation prerequisites © 2015 MicroStrategy, Inc. Installation and Porting Guide Installation 2 Installation procedures For information about installing the Analytics Modules in a manner different than that listed in this section, see the MicroStrategy Installation and Configuration Guide for advanced installation functionality. You can also install the Analytics Modules by following the standard installation procedure for the suite of MicroStrategy products in the MicroStrategy Installation and Configuration Guide. Select the MicroStrategy Analytics Modules along with MicroStrategy Developer, and MicroStrategy Architect during the installation. The Setup Wizard The MicroStrategy Setup Wizard provides step-by-step instructions to guide you through the installation process. To access the Setup Wizard 1 Log on to the machine where you are installing the Analytics Modules. You must log on using a domain account with Windows administrative privileges for the domain or target machine. The domain must include your database servers. 2 Exit all Windows applications before beginning the installation process. 3 Run the setup program to begin the installation: • If you are installing the Analytics Modules from a CD, insert the CD into the CD-ROM drive and wait a few moments for the MicroStrategy Main Menu window to automatically display. If the MicroStrategy Main Menu does not display, locate and run the Setup.exe file on the CD. • If you are installing the Analytics Modules from a set of downloaded files, locate and run the Setup.exe file. 4 Click Install Software. 5 Click Install MicroStrategy Platform. © 2015 MicroStrategy, Inc. Installation procedures 11 2 Installation Installation and Porting Guide 6 If this is the first time you are running this installation, you are prompted to choose the language for the wizard. Select the appropriate language from the drop-down list and click OK. 7 The Setup Wizard opens and walks you through the rest of the installation process. The following sections of this guide describe the actions you need to take for each page in the wizard. Note the following: • The installation screens you see depend on what products you choose to install. These instructions describe only those screens necessary to install the Analytics Modules. • At any time during the setup, click Cancel to quit the installation. Welcome Page Content Options Welcome statement Click Next to proceed. If any Windows services are running for previously installed MicroStrategy products, you are prompted to stop them. Click Yes to proceed. If you click No, you cannot install any MicroStrategy products until you stop all MicroStrategy services.If you opened the Setup Wizard through the 12 Installation procedures © 2015 MicroStrategy, Inc. Installation and Porting Guide Installation 2 Microsoft Control Panel Add/Remove Programs option, the wizard opens the Welcome page in maintenance mode. Page Content Options Welcome statement • Click Modify to add new program components or to remove currently installed components. The remaining pages are the same as for a first-time installation. • Click Repair to reinstall program components if you have problems with previously installed components. Your program components are returned to their original installation state. • Click Remove to quickly remove all installed MicroStrategy components without going through all the Setup Wizard pages. • Click Next to proceed. you installed using a CD, you need your original installation CD to Ifrepair the installation by reinstalling. License Agreement Page Content Options License-related terms • Read the license agreement. and conditions • Select to accept or to decline the agreement. If you choose to decline, you cannot install MicroStrategy products. • Click Next to proceed. • Click Back to return to the previous page. Customer Information Page Content Options Boxes for name, company name, and product license key • • • • • © 2015 MicroStrategy, Inc. Enter your name. Enter the name of your company. Enter the license key. Click Next to proceed. Click Back to return to the previous page. Installation procedures 13 2 Installation Installation and Porting Guide Setup Type Page Content Options Options to select either a typical or advanced setup • Select Typical to place the Analytics Modules in a given root directory. • Select Advanced to specify a different directory for each MicroStrategy product you install. • Click Next to proceed. • Click Back to return to the previous page. There is one significant difference between a typical setup and an advanced one. With the advanced setup option, you can select a different location for each product selected in the Select Components window; with the typical option, the Analytics Modules are placed by default in C:\ Program Files (x86)\MicroStrategy\Analytics Modules\ Analytics_Metadata.mdb. Choose Destination Location Page Content Options Location where the MicroStrategy products will be installed • Click Browse to select a location different from the default value (see the following Notes). • Click Next to proceed. • Click Back to return to the previous page. An MS Access file called Analytics_Metadata.mdb will be installed. It contains the production version of the Customer Analysis Module (CAM), Sales Force Analysis Module (SFAM), Financial Reporting Analysis Module (FRAM), Sales and Distribution Analysis Module (SDAM), and Human Resources Analysis Module (HRAM) projects, as well as three tutorial projects. 14 Installation procedures © 2015 MicroStrategy, Inc. Installation and Porting Guide Installation 2 By default the Analytics_Metadata.mdb file is installed in the following location: C:\Program Files (x86)\MicroStrategy\ Analytics Modules\Analytics_Metadata.mdb. Note the following: • While this setting determines the default root directory for the installed Analytics Modules, you can change the destination of a product later if you chose an advanced setup. • With both typical and advanced setup types, you can choose the directory for a product only if that product is not already installed on the server machine. Otherwise, the product can only be installed in the same directory in which it already exists and you will not see this page. Select Components Page Content Options • A list of MicroStrategy products • Space Required: Space needed for the MicroStrategy products selected; the count changes dynamically as check boxes are selected and cleared • Description: Details about each MicroStrategy product • Select or clear the appropriate check boxes. • Click Next to proceed. • Click Back to return to the previous page. If you have not uninstalled previous versions of MicroStrategy products, you are prompted to overwrite them. If you have an old metadata repository and warehouse for MicroStrategy Tutorial for example, perhaps from an evaluation, and you want to keep them, you must rename them or move them to another location; otherwise, they will be overwritten. If you are prompted to overwrite existing files, click Yes to ensure that all products and product tutorials will work properly. © 2015 MicroStrategy, Inc. Installation procedures 15 2 Installation Installation and Porting Guide Select Program Folder Page Content Options • Box to specify the name of the program folder in your Windows Start menu from which MicroStrategy products will be accessed • List of the existing program folders found under the Windows Start menu • If you want, type a folder name different from the default or select an existing folder; otherwise leave as is (recommended). • Click Next to proceed. • Click Back to return to the previous page. Start Copying Files Page content Options Current Settings: • Products that will be installed or updated • Locations in which the products will be installed (target directories) • Name of the Windows Start menu program folder • Virtual directories for Web and Subscription Portal • Service account for MicroStrategy Narrowcast Server • Location of the installation log file • License details • Click Next to proceed. • Click Back to return to the previous page. Click Next and the installation process begins, which can take several minutes depending on your computer’s hardware configuration. When the installation process has finished, you are prompted to either view the ReadMe file (click Yes or No) or go directly to the InstallShield Wizard Complete page. 16 Installation procedures © 2015 MicroStrategy, Inc. Installation and Porting Guide Installation 2 InstallShield Wizard Complete Page Content Options • Message confirming installation completion • Options (yes/no) to restart the machine (if necessary) • Check box to open the ReadMe file (if restarting is not required) • Instructions to empty drives and click Finish • Click Yes to restart the machine. • Click No to continue without restarting. • Select the check box to open the ReadMe file (if restarting is not required). • Click Finish to complete the setup. the option to restart your machine appears, to ensure that the Ifinstallation process finishes correctly you should select Yes I want to restart my computer now. After installation is complete, you are ready to configure the MicroStrategy components you have installed. This will ensure that the software can be used immediately. To configure your MicroStrategy software with the Configuration Wizard, see Configuration, page 21. Installation verification During the installation process, the Setup Wizard gathers and records information about your system and your installation selections. You can verify installation setup information through the installation log file (install.log), located by default in C:\Program Files (x86)\ Common Files\MicroStrategy. The installation log file includes the following information: • Installation date • Target directories • Program folder name • Operating system identification • Hardware specifications • Selected installation options • Registry paths © 2015 MicroStrategy, Inc. Installation procedures 17 2 Installation • Installation and Porting Guide List of registered files installation log file can be particularly helpful if you encounter The errors during the installation process. For example, the log can tell you if a registry key or path was not added or if a critical file was not registered successfully. Uninstalling a MicroStrategy component You might choose to uninstall one or more MicroStrategy components, perhaps to install those components on a different machine. The uninstall function: • Unregisters and removes selected files, registry entries, and shortcuts logged in the Uninst.isu log file • Calls a custom DLL to handle unlogged items such as registry entries and files Before uninstallation begins, the DLL file • Checks for user privileges. If they are not valid, uninstallation stops. • Checks for running components. If one is found, uninstallation stops. • Stops and deletes the MicroStrategy Intelligence Server service (only when uninstalling Intelligence Server). • Deletes application-created files such as *.log, *.gid, *.ldb, and *.tb. To uninstall from the Control Panel 1 Close all installed MicroStrategy products. 2 From the Windows Start menu, point to Settings and select Control Panel. 3 In the Control Panel, double-click the Add/Remove Programs icon. The Add/Remove Programs dialog box opens. 4 Select MicroStrategy and click Change/Remove (or Add/Remove in Windows NT). The MicroStrategy Setup/Maintenance program opens. 18 Uninstalling a MicroStrategy component © 2015 MicroStrategy, Inc. Installation and Porting Guide Installation 2 5 Select Modify and click Next. you want to remove all MicroStrategy components, select IfRemove. Click Yes for any prompts that appear, then click Finish when maintenance is complete to close the maintenance program. 6 Select to accept the license agreement and click Next. 7 Verify your customer information and click Next. 8 Verify your setup type and click Next. 9 Currently installed components appear with a check mark. Clear the check boxes for the components to uninstall and click Next. 10 If you are prompted about stopping your Web server, click Yes to stop it and continue with the uninstallation. 11 Verify the settings and click Next to begin removing files. 12 When the uninstall routine is complete, select Yes to restart your computer or No to restart it later. Then click Finish to close the maintenance program. You should restart the computer to achieve a clean uninstall. © 2015 MicroStrategy, Inc. Uninstalling a MicroStrategy component 19 2 Installation 20 Uninstalling a MicroStrategy component Installation and Porting Guide © 2015 MicroStrategy, Inc. 3 3. CONFIGURATION Introduction Once you have installed your MicroStrategy Analytics Modules software, you complete a few configuration tasks before you can begin using them with your own data. This chapter provides steps to configure the installed Analytics Modules projects. Configuring your software Follow the sections below to prepare your system. Then perform the procedures that follow to configure your system to use the Analytics Modules. Configuration preparation Make the following decisions about product setup and use. © 2015 MicroStrategy, Inc. Configuring your software 21 3 Configuration Installation and Porting Guide Project sources Each Analysis Module consists of a MicroStrategy project in a metadata repository. A project source contains the information necessary for MicroStrategy to connect to the metadata in which your projects are stored. The project source stores the location of the metadata repository or the MicroStrategy Intelligence Server that is used to run the project. There are two types of project sources: • Direct project sources connect directly to the metadata through ODBC. This is known as a direct connection. • Server project sources connect to the metadata via a MicroStrategy Intelligence Server. This is known as a server connection. The Configuration Wizard guides you through the process of creating both types of project sources. You will use the Configuration Wizard during the configuration procedures described below. Connection types You can configure the Analytics Modules projects to run with a direct connection or a server connection. • A direct connection connects the project source to the metadata repository directly through ODBC. • A server connection connects the project source to the metadata repository through MicroStrategy Intelligence Server. A server connection is the most commonly used connection type. See the MicroStrategy Installation and Configuration Guide for more detailed information on connection types. use the Analytics Modules documents (for example, for Todashboards and scorecards), you must be connected through a server connection using MicroStrategy Intelligence Server. With or without a data warehouse The Analytics Modules can be used with or without an existing data warehouse. If you have an existing data warehouse in a given analytical area, you can take advantage of best practices reports and metrics, while making the best use of your existing data warehouse investments. If you have no data warehouse storing data for a given analysis area, you can use the Analytics 22 Configuring your software © 2015 MicroStrategy, Inc. Installation and Porting Guide Configuration 3 Modules’ default physical schema and packaged metadata components as an initial design for your own data warehouse and analytical application. you do not have an existing data warehouse in the given analytical Ifarea, you can follow the procedures below to create a data warehouse. For your new warehouse, you must create the required tables using the scripts generated from the Erwin files that come with the MicroStrategy Analytics Modules. The configuration procedures below include steps important for both uses. These include: • Configuring a production metadata repository • Duplicating selected Analytics Modules projects into the production metadata repository • Configuring the chosen MicroStrategy projects to point to the target data warehouse Configuration prerequisites Before you begin using the Configuration Wizard you should satisfy the following requirements: • Install the necessary MicroStrategy products. At a minimum, you should have MicroStrategy Architect and MicroStrategy Developer (Architect is a subcomponent of Developer) and the MicroStrategy Analytics Modules installed. For steps to install these products, see Chapter 2, Installation. • During the Analytics Modules configuration procedures below, you will create project sources, when you can set up the Analytics Modules projects to run through either a direct connection or a server connection. To run the Analytics Modules projects through a server connection, you must have MicroStrategy Intelligence Server installed. See the Installation and Configuration Guide for details to install and configure Intelligence Server. • Be sure you have access to an empty database location certified to house the metadata repository. For a list of certified metadata platforms, see the MicroStrategy Readme file. From the Windows Start menu, point to Programs, then MicroStrategy Documentation, and then select Product Manuals. Click the MicroStrategy ReadMe link. products must be configured on the machine on which MicroStrategy they are installed. You cannot configure remotely. © 2015 MicroStrategy, Inc. Configuring your software 23 3 Configuration Installation and Porting Guide Configure the production metadata repository In this procedure, you create a DSN for the metadata repository that comes with the Analytics Modules, connect it to a project source, and then create a space to serve as your production metadata repository. To configure the production metadata repository 1 On a machine with a MicroStrategy installation, create a data source name (DSN) using an Access ODBC driver that points to the Analytics_Metadata.mdb file. Name the DSN “Analytics_Metadata”. 2 Create a direct connection (a 2-tier project source) pointing to the Analytics_Metadata DSN you created in the step above. You can create a project source in the following ways: • If you need guidance, use the MicroStrategy Configuration Wizard. See the MicroStrategy Installation and Configuration Guide for steps to open the wizard and create a direct (2 tier) project source. • If you are familiar with creating project sources, use MicroStrategy Developer. From Developer’s Tools menu, select Project Source Manager. 3 Connect to this metadata repository by logging in as Administrator with no password. The metadata repository should display five different projects for the Analytics Modules, plus three projects for Tutorial. in these projects do not run because the data warehouses Reports are not yet set up. However, you can browse through the metadata objects. 4 In your database of choice, create a space for storing the project metadata. See the MicroStrategy Readme for supported databases. 5 Create a DSN that points to the new space created in the step above. it is possible to use a Microsoft Access database for the While metadata repository, it is not a suitable metadata repository for a production project. Use Access only for a proof-of-concept type of application. 6 Using the MicroStrategy Configuration Wizard, create a metadata shell for this new space by running appropriate table and trigger creation 24 Configuring your software © 2015 MicroStrategy, Inc. Installation and Porting Guide Configuration 3 scripts. See the MicroStrategy Installation and Configuration Guide for steps to open and use the Configuration Wizard. Once the scripts are run, an empty metadata shell is created in this location. This metadata repository is your production metadata repository and will be called the production metadata through the rest of the configuration procedures. 7 Using either the Configuration Wizard or MicroStrategy Developer, create a direct connection (a 2-tier project source) pointing to the DSN created in step 5 above. You can name this new direct connection anything you want, but it is called PROD_MD (or production metadata) throughout the rest of this chapter. 8 Connect to the production metadata by logging in as Administrator with no password. There will be no projects in this shell. Duplicate the Analytics Modules In this procedure, you duplicate selected Analytics Modules into the production metadata created in the procedure above. To duplicate the Analytics Modules 1 In Developer, from the Schema menu, select Duplicate Project. Follow each step in the Project Duplication Wizard, using the following information: • Step 1 - Select source project location: Use Analytics_Metadata as the source project location. • Step 2 - Select project to duplicate: Select the Analysis Module you want to duplicate. • Step 3 - Select a location for the duplicated project: Use PROD_MD as the target location. • Steps 4 - 9: Accept the default settings. 2 Depending on your system configuration, the project duplication process can take several minutes. When the process is complete, examine the logs and make sure the duplication ran error-free. © 2015 MicroStrategy, Inc. Configuring your software 25 3 Configuration Installation and Porting Guide Configure the data warehouse connection Use this procedure to configure the production metadata to point to the target data warehouse. To configure the data warehouse connection 1 Create a DSN that points to the target data warehouse. • If you intend to use an existing data warehouse with the Analytics Modules, the target data warehouse will be your existing data warehouse. • If you do not have an existing data warehouse in the given analytical area, the target data warehouse will be a data warehouse created using the physical schema that comes with the Analytics Modules. This data warehouse must have the required tables created using the scripts generated from the Erwin files that come with the MicroStrategy Analytics Modules. 2 Open the Database Instance Manager. (From MicroStrategy Developer, select Analytics Modules, select Administration, and then select Database Instance Manager.) 3 Edit the database instance for the duplicated project, and point it to the new data warehouse DSN. Select an appropriate database connection type. Changes to the database instance automatically update the project level VLDB settings. Any additional changes to VLDB settings can be made in the project’s Project Configuration menu. 4 Depending on the type of data warehouse to which you port a module and the Analysis Module you choose to port, you may need to change certain settings in your system so the module recognizes the new data warehouse. See Database settings, page 26 to locate your database type and required project and other object settings. 5 After making appropriate changes to the database instance, disconnect and reconnect to the project source so your changes can take effect. Database settings Settings for the following certified database types are provided below: 26 Configuring your software © 2015 MicroStrategy, Inc. Installation and Porting Guide • Oracle 8i2 and later versions • SQL Server 2000 • IBM DB2 UDB 5.2 and later versions • Teradata v2R4 and later versions Configuration 3 the Supplemental Reference for System Administration for a See complete list of default VLDB settings and an explanation of Join Type settings. See the online help for steps to change join types. Oracle databases For porting to an Oracle 8i2 or later database, use the following table to locate the Analysis Module you are porting and identify the necessary changes to make. Analysis Module Port from MS Access to Oracle 8i2 (or later) database CAM Change the value of the Join Type VLDB property to Join 89. FRAM Change the value of the Join Type VLDB property to Join 89. HRAM 1 Change the project level join type to Join 89. 2 Change the join type to Join 89 for the Current Headcount and Average Tenure Summary report, located by default in the Human Resources Analysis Module project under Public Objects\Reports\Scorecards\ HR Summary Scorecard Base Reports\ Current Headcount and Average Tenure Summary. SFAM No changes are required. SDAM Change the project level join type to Join 89. SQL Server database For porting to a SQL Server 2000 database, use the following table to locate the Analysis Module you are porting and identify the necessary changes to make. Analysis Module Port from MS Access to SQL Server 2000 database CAM No changes are required. FRAM No changes are required. © 2015 MicroStrategy, Inc. Configuring your software 27 3 Configuration Installation and Porting Guide Analysis Module Port from MS Access to SQL Server 2000 database HRAM Calculating dates: For the Date metrics located by default in the Human Resources Analysis Module project under Public Objects\Metrics\ Dates, you may need to modify the default metric definition for the metric you want to use, to comply with the SQL Server syntax requirements. For example, for the metric Current Tenure, you must change the definition to: Applysimple(‘Avg(abs(datediff(day,CurrentDate(),#0)))’, [Hire Date]). SFAM No changes are required. SDAM • Change the definition to: ([NET_ITEM_AMOUNT] * (1 - 1.0001* [ITEM_QTY_DELIV_BU] / 1.0001* [ITEM_QTY_BU]))) for the Backlog Net Item Amount fact, located by default in the Sales and Distribution Analysis Module project under Schema Objects\ Facts\Sales Documents\Backlog New Item Amount. • Calculating dates: You may be required to modify the default fact expressions for the fact you want to use. See Calculating dates and times in the SDAM Reference for complete information. • Calculating times: You may want to calculate time differences using a different time scale than that used in the project. See Calculating dates and times in the SDAM Reference for complete information. • Contribution metrics are handled differently in different databases, due to the way integers are truncated. See Contribution metrics ported to a database in the SDAM Reference for complete information. DB2 databases For porting to a DB2 UDB 5.2 or later database, use the following table to locate the Analysis Module you are porting and identify the necessary changes to make. Analysis Module Port from MS Access to DB2 UDB 5.2 (or later) database CAM No changes are required. FRAM No changes are required. HRAM Change the formula to: ApplyAgg(“Max(DAYS(Current Date) - DAYS(#0))”, [Hire Date]) {~+} for the Current Tenure metric, located by default in the Human Resources Analysis Module project under Public Objects\Metrics\Dates\ Current Tenure. 28 Configuring your software © 2015 MicroStrategy, Inc. Installation and Porting Guide Configuration 3 Analysis Module Port from MS Access to DB2 UDB 5.2 (or later) database SFAM No changes are required. SDAM • Change the definition to: ([NET_ITEM_AMOUNT] * (1 - 1.0001* [ITEM_QTY_DELIV_BU] / 1.0001* [ITEM_QTY_BU]))) for the Backlog Net Item Amount fact, located by default in the Sales and Distribution Analysis Module project under Schema Objects\Facts\ Sales Documents\Backlog New Item Amount. • Calculating dates: You may be required to modify the default fact expressions for the fact you want to use. See Calculating dates and times in the SDAM Reference for complete information. • Calculating times: You may want to calculate time differences using a different time scale than that used in the project. See Calculating dates and times in the SDAM Reference for complete information. • Contribution metrics are handled differently in different databases, due to the way integers are truncated. See Contribution metrics ported to a database in the SDAM Reference for complete information. Teradata databases For porting to a Teradata V2R4 or later database, use the following table to locate the Analysis Module you are porting and identify the necessary changes to make. Analysis Module Port from MS Access to Teradata V2R4 (or later) database CAM No changes are required. FRAM Not supported. HRAM No changes are required. SFAM No changes are required. SDAM • Calculating dates: You may be required to modify the default fact expressions for the fact you want to use. See Calculating dates and times in the SDAM Reference for complete information. • Calculating times: You may want to calculate time differences using a different time scale than that used in the project. See Calculating dates and times in the SDAM Reference for complete information. • Contribution metrics are handled differently in different databases, due to the way integers are truncated. See Contribution metrics ported to a database in the SDAM Reference for complete information. © 2015 MicroStrategy, Inc. Configuring your software 29 3 Configuration 30 Configuring your software Installation and Porting Guide © 2015 MicroStrategy, Inc. 4 4. USING THE ANALYTICS MODULES Introduction The MicroStrategy Analytics Modules are designed to let you take advantage of best practices analysis for a given analysis area, while making the best use of your existing data warehouse investments by porting an Analysis Module to your target data warehouse. For more details on porting, see Chapter 5, Porting the Analytics Modules. If you have no data warehouse storing data for a given analysis area, you can take advantage of the Analytics Modules by using the physical schema and packaged metadata components that come with the modules as an initial design for your own data warehouse. You can also use the Analytics Modules as templates to design and develop analytical applications. This chapter explains how to use the Analytics Modules when you do not have an existing data warehouse in a given analysis area. It also provides information on customizing and extending the Analytics Modules. For information on using the Analytics Modules with an existing data warehouse, see Chapter 5, Porting the Analytics Modules. For information on designing © 2015 MicroStrategy, Inc. 31 4 Using the Analytics Modules Installation and Porting Guide and creating your own analytical applications using the Analytics Modules as a template, see Chapter 6, Creating Portable Analytical Applications. Be aware of the following: • MicroStrategy provides the Analytical Modules and their related components, including the default physical schema, as examples. If you decide to populate, customize, enhance, or otherwise change the Analytics Modules or any individual components, these become the property of your company and you or your company are responsible for any additions, modifications, enhancements, or customizations made. • MicroStrategy does not provide ETL routines or tools to populate the physical schemas that come with the Analytics Modules; they are simply provided as an example. If you choose to use the physical schemas, you must identify data sources and create the ETL routines necessary to populate the database schema. Using the Analytics Modules as an initial design MicroStrategy Analytics Modules provide the key data elements necessary to define a given analytical area. If you do not have an existing data warehouse in the sales, financial reporting, human resources, sales distribution, or customer analysis areas, you can use the default physical schema and prepackaged metadata components in the Analytics Modules as an initial design for your own new data warehouse. There are two approaches to using the default physical schema that comes with each Analysis Module as an initial design for your own data warehouse: • Initial Data Warehouse: You can take immediate advantage of the default physical schema for the data warehouse that comes with each module, populating it with your own data. Once you have established your own data warehouse using the modules, you can expand and customize the application as you identify additional business and analytical requirements. • Initial Customization: Alternatively, you can enhance the default physical schema initially with your own customizations, to reflect immediate 32 Using the Analytics Modules as an initial design © 2015 MicroStrategy, Inc. Installation and Porting Guide Using the Analytics Modules 4 business and analytical requirements you may have. Once the default schema has been customized, you can then populate it with your data. For customization scenarios and steps to customize and extend the Analytics Modules, see Customize and extend the Analytics Modules, page 34. Initial data warehouse You can use a given Analysis Module as an initial design for your analysis solutions in the module’s analytical area and then add your company’s specific business and analysis requirements by customizing and extending the module. You begin this approach by selecting an Analysis Module and then populating the physical schema that comes with your chosen module. Each Analysis Module’s reference guide contains the logical and physical view of the default data warehouse schema, as well as a complete data dictionary with all tables and columns, and how to populate them. Each Analysis Module’s metadata components provide best practices analytics that can be used to define reports addressing any additional requirements of your company. As you continue to add data to the default physical schema, you can decide at any point to enhance the module by customizing or extending the application. Each Analysis Module provides its physical schema definition in an Erwin format, allowing you to edit definitions and then generate table creation scripts for any database platform. See Customize and extend the Analytics Modules, page 34 for more information on enhancing the default physical schema. provides the Analytics Modules and their related MicroStrategy components, including the default physical schema, as examples. If you decide to populate, customize, enhance, or otherwise change the Analytical Modules or any individual components, these become the property of your company and you or your company are responsible for any additions, modifications, enhancements, or customizations made. © 2015 MicroStrategy, Inc. Using the Analytics Modules as an initial design 33 4 Using the Analytics Modules Installation and Porting Guide Customize and extend the Analytics Modules MicroStrategy Analytics Modules can be customized and extended to address your specific business needs. Whether you are using the Analytics Modules as your initial data warehouse (see above), porting them to an existing data warehouse (see Chapter 5), or using them as a template to create your own analytical applications (see Chapter 6), you can customize and extend the metadata objects (attributes and facts) to address additional business and reporting requirements. When you customize or extend the Analytics Modules, you are customizing existing data elements to reflect your company’s requirements or adding data elements that are specific to your company. Typical enhancements include the following: • Adding additional customer characteristics to the Customer Analysis Module, which is described in detail in Customization scenarios, page 34 • Converting some prompted reports to static selections for end users • Changing a Sales Force Analysis Module (SFAM) report’s Time analysis to Month instead of Quarter Customization and extension are accomplished using the standard MicroStrategy design and development tools, MicroStrategy Architect and MicroStrategy Developer. Both of these products come with the Analytics Modules. For more information, see Chapter 1, About the Analytics Modules. does not provide ETL routines or tools to populate the MicroStrategy physical schemas provided with the Analytics Modules; they are provided as an example. If you choose to use them, you must identify data sources and create the ETL routines required to populate the database’s physical schema. Customization scenarios There are two general types of scenarios when you customize or extend an Analysis Module, depending on what elements you want to change. You can make changes or additions to the application objects (such as reports, metrics, and filters, located in the Public Objects folder). Or you can make changes or additions to the schema objects (such as attributes and facts, located in the Schema Objects folder). 34 Customize and extend the Analytics Modules © 2015 MicroStrategy, Inc. Installation and Porting Guide Using the Analytics Modules 4 Knowing the different efforts required for each of these approaches can help you decide whether and how to make a modification. The following list presents examples of typical changes based on the two general scenarios and any related updates necessary based on the change. Application objects These scenarios detail changes to application objects only. It does not include changes to logical data models. Examples of changes to the application objects include: • Converting prompts, which enable dynamic selections, of packaged reports to static selections. • Modifying a metrics definition. For example, you might modify Quarter Comparison metrics to compare data at the Month level, using the Previous Month transformation instead of the Previous Quarter. • Updating filter conditions to use values in the target data warehouse. Since packaged filters can include conditions based on values existing in the default database, you may need to do this when you port an Analysis Module to an existing data warehouse. • Modifying report templates to include different attributes or metrics. For example, SFAM reports analyze data at the Quarter level. If you want to analyze data at the Month level, substitute Quarter by Month in the reports. Examples of creating new application objects include: • Creating new reports based on existing attributes and metrics. The prepackaged reports can be used as best practices examples to create new reports. • Creating new metrics, such as Percent to all Contributions and Month to Month comparisons, that are not included in the prepackaged modules. Schema objects These scenarios include changes to the schema objects. These changes require updates to the physical database schema, and may drive changes to the application objects (reports and metrics) as well. © 2015 MicroStrategy, Inc. Customize and extend the Analytics Modules 35 4 Using the Analytics Modules Installation and Porting Guide Examples of changes to the logical data model include: • Changing attribute keys for fact tables. For example, in SFAM, the Opportunity fact table does not include a product key. To allow users to calculate product information at the Opportunity level, you would modify the fact table and then update it in the project. • Modifying a hierarchy to include additional levels. For example, the packaged Product hierarchy includes two levels, Product and Product Group. If you require additional levels, you would add corresponding attributes and relationships. This type of change also requires you to update the physical schema. Examples of additions to the logical data model include: • Adding additional characteristic attributes to an existing attribute. For example, SFAM includes a number of characteristics for the Account attribute. You may require additional attributes to reflect your company’s Account data. This addition requires you to update the structure of lookup tables and add attributes and relationships to the project. • Adding facts to existing tables. For example, SFAM includes revenue data. You might update the table to include Cost and Number of Units, and add them to the MicroStrategy project. Examples of enhancements to the application objects, driven by changes or additions to the schema objects, such as those described above, include: • Adding new Product attributes to existing reports • Creating new metrics and reports to analyze Cost and Profit data Scenario: Adding customer characteristics to CAM The Customer Analysis Module (CAM) provides a limited number of common customer characteristics, such as Customer Name, Customer Address, and so on. This is a common area to add company-specific data elements to reflect information your company needs to store and use. To customize CAM by adding additional customer characteristics, you add the additional attributes as new columns in the Customer lookup table. You use the Erwin file that comes with CAM to edit the default physical schema and then generate the table script. may have to define additional lookup tables to store descriptions You and relationships with other attributes. 36 Customize and extend the Analytics Modules © 2015 MicroStrategy, Inc. Installation and Porting Guide Using the Analytics Modules 4 Once the table is created, you use MicroStrategy Architect to add the new attributes to the project, thus linking the project to the new data structures. For the end user, the additions cannot be distinguished from the existing packaged components and the existing components can be enhanced to take advantage of the new data elements. Customization steps You usually identify necessary additions and modifications for the Analytics Modules during a gap analysis, as described in Port an Analysis Module, page 48. After you complete a gap analysis, you enhance the logical data model for your chosen Analysis Module to include any additional attributes and facts you require. This may include adding data elements in the data warehouse. Finally, you modify the module’s packaged components or add new ones, such as metrics, prompts, reports, and so on. For details on adding or modifying attributes, facts, metrics, prompts, reports, and so on, see the MicroStrategy Advanced Reporting Guide. The comprehensive documentation and packaged components that come with the Analytics Modules can be used as templates for your customization and enhancements. Developers can access and reverse-engineer all packaged components using MicroStrategy developer tools. Roll out to production Before the final version of the Analytics Modules is made available to end users, you must complete some preparation tasks. Each section listed below describes aspects of your Analytics Modules implementation that can cause performance issues for users. Each section also suggests actions to be taken that can lessen or eradicate the potential issue. You must consider the tasks listed below when identifying resources and determining a schedule for rolling out the Analytics Modules to your production environment and making them available to users. You can find details for many of the MicroStrategy-specific procedures in the MicroStrategy System Administration Guide. © 2015 MicroStrategy, Inc. Roll out to production 37 4 Using the Analytics Modules Installation and Porting Guide Tuning and performance The Analytics Modules do not include any type of tuning or performance optimization. Consider using the following techniques to optimize performance for your users: • aggregate tables (details available in the MicroStrategy System Administration Guide) • partitioning (details available in the MicroStrategy System Administration Guide) • indexes MicroStrategy users Different users and user profiles may be required to allow or restrict access to areas of the Analytics Modules. Users and user profiles are defined based on your company’s requirements, which include configuring permissions to access MicroStrategy functionality. default, the Analytics Modules include a single user By(Administrator) with all privileges. Security Your company may require you to limit access to certain objects, and to implement data level security with security filters. See the MicroStrategy System Administration Guide for information on implementing these security features. default, the Analytics Modules include a single user By(Administrator) with full control for all objects. Additionally, all objects are set up with View access for all users. Direct and server connections The Analytics Modules are packaged as direct connection projects (also known as 2-tier projects), which means they run in two architectural layers—the business logic/user interface layer and the database layer. For 38 Roll out to production © 2015 MicroStrategy, Inc. Installation and Porting Guide Using the Analytics Modules 4 optimum performance, they should run on a server connection (also known as 3-tier mode), through MicroStrategy Intelligence Server. A given Analysis Module can be easily set up to run on a server connection, through MicroStrategy Intelligence Server, by making the appropriate changes to the project configuration. More details are available in the MicroStrategy System Administration Guide, and also in Chapter 3, Configure the production metadata repository. © 2015 MicroStrategy, Inc. Roll out to production 39 4 Using the Analytics Modules 40 Roll out to production Installation and Porting Guide © 2015 MicroStrategy, Inc. 5 5. PORTING THE ANALYTICS MODULES Introduction The packaged MicroStrategy Analytics Modules applications can be used in many ways. The modules can be integrated into your existing data warehouse, serve as an initial design for a new data warehouse, and facilitate the deployment of enterprise-class portable analytical applications. For any of these scenarios, you can also customize and extend the Analytics Modules to meet changing reporting and business requirements. • Existing data warehouse: If you have a data warehouse already holding data for a given analytical area, you can reconfigure the packaged logical data model and analytical reports to work with your existing data warehouse structures. This chapter describes the reconfiguration process, known as porting. • No existing data warehouse: If you do not have a data warehouse containing data for a given analysis area, you can use the default logical data model, physical schema, and analytical reports as a starter design for a new data warehouse. For more information, see Chapter 4, Using the Analytics Modules. • Building analytical applications: If you want to build analytical applications, you can use the Analytics Modules as best practices © 2015 MicroStrategy, Inc. 41 5 Porting the Analytics Modules Installation and Porting Guide examples for each analysis area by treating the Analytics Modules components as a template. For more information, see Chapter 6, Creating Portable Analytical Applications. • Customize and extend the Analytics Modules: You can easily customize and extend the Analytics Modules for any of the scenarios above, to meet changing reporting and business requirements. For more information, see Customize and extend the Analytics Modules, page 34. This chapter explains how to port the Analytics Modules so they work with an existing data warehouse. does not provide ETL routines or tools to populate data MicroStrategy warehouses. You must identify data sources and create the ETL routines necessary to populate your particular database schema. Introduction to portability Portability is the ability of an analytical application to be integrated into an existing data warehouse. Porting a given analytical application involves mapping the application to an existing physical data warehouse schema while retaining the logical data model definition. A portable analytical application such as a MicroStrategy Analysis Module is a prepackaged project which has been built using portability design rules. These rules are defined to minimize the changes required to map an application’s logical data model to a target data warehouse’s physical schema. To achieve this, MicroStrategy technology provides an abstraction 42 Introduction to portability © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 layer between the logical data model and the physical data warehouse schema, making it possible to map the existing links to a physical schema with a similar data set. By retaining the logical data model definition, all MicroStrategy object definitions such as attributes, facts, metrics, and reports are also retained. MicroStrategy has developed a detailed methodology to support the mapping of metadata objects from the logical data model to physical database objects in a target data warehouse’s physical schema using MicroStrategy tools. Portability methodology When you port an Analysis Module to an existing data warehouse, you map the facts and attributes in the logical data model to the structure of the physical schema in an existing data warehouse, allowing the analytical reports to reflect the data stored in your data warehouse. Portability centers on the concept of “Metadata Only” analytical applications. By packaging Analytics Modules with reports, metrics, facts, and attributes, but no hard-wired data warehouse, MicroStrategy provides you with the tools to perform best practices analysis in each of the given analysis areas, based on the data in your existing data warehouse. Portability design drivers The MicroStrategy Analytics Modules were designed to be portable. This section describes design drivers that are built into the Analytics Modules architecture and that are reflected in the porting procedures that follow. For a complete description of the design rules, see Portability rules and recommendations, page 131. Well-known analysis area Each Analysis Module focuses on a well-known analysis area. Analysis areas include customer analysis, sales analysis, financial reporting analysis, human resources analysis, and sales distribution analysis. Different analysis areas increase the chance that companies will have a data warehouse for such analysis. © 2015 MicroStrategy, Inc. Portability methodology 43 5 Porting the Analytics Modules Installation and Porting Guide Generic data elements The logical data model is built based on generic data elements. Using generic data elements maximizes the probability that data elements will exist in the target data warehouse. For example: • Sales analysis is defined based on generic elements such as Opportunity, Order, Day, Product, Revenue, and the like. • Customer analysis includes generic customer characteristics such as Gender or Age Range, but not others that are specific to a company (Head of Household, Pet Owner Flag, and so on). Specific attributes can be added later. No specific physical structure The logical data model should not be dependent on any specific physical structure. • The MicroStrategy metadata repository allows the definition of the logical data model, that is, the business representation, to be independent from the physical schema, that is, the storage structure. • The Analytics Modules are not hard-coded to a specific physical schema; therefore, they can be mapped to different schemas for different data warehouses. For example, the modules avoid using many-to-many relationships because these require a specific table structure. Simplicity The logical data model is simple but complete. • Simplicity is achieved through a manageable number of data elements; each module includes 20 to 30 attributes and 5 to 10 facts. • Completeness is achieved by including the key elements that define a given analytical area and by providing best practices reports. can extend the model to add specific details required by your You organization; see Customize and extend the Analytics Modules, page 34. 44 Portability methodology © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Common hierarchies The modular approach provides clear, defined analysis areas based around fact tables and common hierarchies across Analysis Modules. • Modularity minimizes the impact when a fact table does not exist in the target data warehouse. Each module includes 5 to 10 facts; these are typically stored in 2 or 3 fact tables. If all reports are based on facts from different fact tables, a missing fact table can impact all reports. Modularity ensures that the maximum number of reports can be used. • A report usually focuses on one analysis area, although when required it can include several areas. This does not limit the value of the reports. • Each Analysis Module was designed to be combined with other modules. Common analysis hierarchies exist across different Analysis Modules. Best practices reports Analytics Module reports provide best practices analysis. • Each Analysis Module provides 40 to 50 advanced reports using a total of 75-100 metrics, representing best practices analysis for each analytical area. • Packaged elements can be used as templates when defining new reports. • Reports can be modified to address additional reporting requirements. For example, the Customer Segmentation by Customer Characteristics report can be easily modified to add additional attributes reflecting company-specific customer characteristics. Portability design rules All metadata objects are defined based on a number of rules that ensure portability. For example: • Database functions were avoided if they were tied to a specific database engine. • Filters were avoided when possible. Most reports provide prompts that can be modified to meet custom requirements. © 2015 MicroStrategy, Inc. Portability methodology 45 5 Porting the Analytics Modules • Installation and Porting Guide Base formulas were used to isolate metric definition of facts. can read the complete list of design rules; see Chapter 6, Creating You Portable Analytical Applications. General porting prerequisites MicroStrategy tools To port any of the Analytics Modules to your existing data warehouse, you only need MicroStrategy Developer and MicroStrategy Architect. Developer and Architect allow you to access metadata objects such as attributes, facts, metrics, and reports. MicroStrategy Object Manager is an optional tool that can make the porting process more efficient. Object Manager allows you to implement only those portions of the Analytics Modules that are relevant to a company’s requirements. Object Manager also provides enhanced searching functionality that facilitates the gap analysis. See the MicroStrategy System Administration Guide for information about using Object Manager. 46 General porting prerequisites © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Documentation In addition to the tools listed above, you must also have all necessary documentation: Documentation Description Analytics Modules reference guides Each Analysis Module has its own reference guide which includes: • An introduction to the module’s analysis area and reporting challenges • A list of packaged reports, and for each report, the business value, report definition, and report screen shots • A complete list of all metrics and descriptions • The logical data model definition, with all hierarchies and attributes, including metadata definitions • The default physical schema provided with the module and a data dictionary Physical model, in Erwin format This file contains a definition of the physical schema provided with the module, in an Erwin format: • This file can be used to generate database creation scripts for any database platform. • This file can be used as an initial design for your company’s data warehouse. Portability methodology and porting process This content appears in this Porting chapter, and includes: • The Portability methodology section with portability design drivers, necessary tools, and overview information for porting a module. • The Port an Analysis Module section with a detailed explanation of how to implement the Analytics Modules using an existing data warehouse. Best practices for portable analytical applications This content appears in Chapter 6, and includes: • A comprehensive explanation of how to design and build applications using the portability paradigm • Best practices used by MicroStrategy to develop the Analytics Modules • Development project guidelines (task and plan) • Recommendations for creating MIcroStrategy objects Other prerequisites Drill maps must be removed from your chosen module before the module can be ported. A drill map is essentially a customized drill path for the attributes and metrics in reports. For some of the reports within the Analytics Modules, the drill paths have been customized by assigning a drill map, so that only selected attributes can be drilled on within given reports. A common example is the quarterly reports that are available in many of the modules. The data in quarterly reports is, logically, only available for the Quarter level. Therefore, users are restricted within these quarterly reports by an associated drill map so that they cannot drill down to Month. © 2015 MicroStrategy, Inc. General porting prerequisites 47 5 Porting the Analytics Modules Installation and Porting Guide Port an Analysis Module To port a given MicroStrategy Analysis Module, you map the module to the physical schema of an existing data warehouse. However, you keep the logical data model and analytics library for the Analysis Module. This allows you to use all the related MicroStrategy objects, such as attributes (analysis-friendly business concepts), hierarchies (relationships between attributes), facts (measures), metrics (business calculations), and reports. Porting overview Porting involves the following general steps: 1 Perform a gap analysis: Identify the overlap between the chosen Analysis Module, your existing data warehouse, and your company’s reporting requirements. Once you determine the overlap, you can identify any gaps. 2 Map the module: Using the overlap information from the step described above, map the Analysis Module to the data warehouse. 3 Customize and extend the module: Using the gap information from the step described above, customize the module to accommodate additional business and reporting requirements. Complete the steps below in the order they appear. Perform a gap analysis A gap analysis identifies which areas of a given Analysis Module’s logical data model and reports can be implemented using the structures of your existing data warehouse. The gap analysis is broken into the following procedures: 1 Map the target data warehouse to the module’s physical schema. 2 Map the module’s logical data model to the target schema. 3 Identify application objects. 48 Port an Analysis Module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 4 Optionally, identify additional business requirements. Each procedure is presented below with a description, examples, and many alternative scenarios to support your own gap analysis process. Gap analysis prerequisites To complete a successful gap analysis, make sure you have access to the following: Skills Good knowledge of your company’s target data warehouse schema and your company’s reporting requirements, if these exist. Experience using MicroStrategy tools and with logical data modeling and physical data modeling. Physical schema and data dictionary for the target data warehouse and logical data model, if available. The MicroStrategy Analytics Modules reference guides, each of which provides a given module’s default physical schema, data dictionary, and logical data model. Tools Erwin file for the Analysis Module; contains the module’s default physical schema and production metadata. MicroStrategy Developer and MicroStrategy Architect, to access definitions of attributes, facts, reports, metrics, and so on; and to search for dependencies. For example, if a fact does not exist in the target data warehouse schema, dependencies identify which reports, metrics, and so on will be impacted. (Optional) MicroStrategy Object Manager, to search for child-parent and parent-child dependencies. This tool provides a thorough impact analysis. Map the target data warehouse to the module’s physical schema In this first procedure of the gap analysis, you identify whether each data element from the module’s physical schema exists in the target data warehouse. For elements that do not exist, you check whether they can be replaced with data elements that are present in the target data warehouse. The result is a document presenting a complete mapping that focuses on available data elements and any proposed changes needed. An example follows this procedure, and a list of typical scenarios and actions follows the example. © 2015 MicroStrategy, Inc. Perform a gap analysis 49 5 Porting the Analytics Modules Installation and Porting Guide To map the target schema to the module’s schema 1 Prepare a document to record the information you will identify in this procedure. The document should include space for a list of data elements (tables and columns) and for comments. example document can be found at the end of this procedure; An see Example: Mapping physical schemas, page 52. 2 Compare the target data warehouse’s physical schema (target schema) with the selected module’s physical schema (module’s schema). Identify the list of tables in the target schema that are relevant to the module’s analysis area. Record this information in the document you created above. 3 In the module’s physical schema, for each table, identify whether there is an equivalent table in the target schema. Begin with the lookup tables, then move on to the fact tables. Add this information to your document. 4 For each matching table identified in the previous step, map the module’s schema columns to the corresponding ones in the target schema, and add this information to your document. some cases, you can map a data element from the module’s Inschema to a similar but not identical data element in the target schema; the target schema’s data element will replace the data element from the module’s schema. For example, assume the AGE data element does not exist in the target schema but AGE_RANGE does. You can map the AGE column from the module’s schema with the AGE_RANGE column in the target schema. 5 Identify areas in the target schema where a given hierarchy is stored in a different number of tables than in the module’s schema. For example, the target schema might have several lookup tables for the Time hierarchy: 50 Perform a gap analysis L_YEAR L_QUARTER L_MONTH year_id quarter_id month_id year_desc quarter_desc month_desc year_id quarter_id © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 But the module’s schema might have a single lookup table for the Time hierarchy: L_TIME year_id year_desc quarter_id quarter_desc month_id month_desc In the example above, the Time hierarchy in the target schema is stored in more tables than the Time hierarchy in the module’s schema. 6 Identify areas in the target schema where a given hierarchy has a different number of levels than in the module’s schema. For example, referring to the L_TIME table in the step above, the module’s schema has three levels in the Time hierarchy: year, quarter, and month. But the target schema might only have two levels in its Time hierarchy (quarter and month), or it might have four (year, quarter, month, and date), and so on. 7 Identify relevant aggregates and fact tables in the target schema that have information at different levels than that in the module’s schema. 8 Review your document to ensure that: • For all tables and columns in the module’s physical schema, you have a list of corresponding tables and columns from the target schema. • You have marked or otherwise indicated any data elements from the module’s schema that cannot be used because there are no corresponding data elements in the target schema. • (Optional) You have included a list of tables from the module’s schema that do not exist in the target schema but will be added to support packaged reports. • (Optional) You have included a list of tables from the target schema that have no equivalent in the module’s schema but will be added to support additional analysis requirements. © 2015 MicroStrategy, Inc. Perform a gap analysis 51 5 Porting the Analytics Modules Installation and Porting Guide Example: Mapping physical schemas The following table records example information discovered using the procedure above. The table explains how an (imaginary) existing data warehouse’s structures map with an Analysis Module’s default physical schema. module used in this example is the Sales Force Analysis Module The (SFAM); see the SFAM Reference guide for the physical schema and data dictionary. Table in imaginary target schema Columns in imaginary target schema Results of mapping target schema with SFAM’s physical schema, and comments L_CUSTOMER CUSTOMER_ID Lookup table for Customer CUSTOMER_NAME This maps with L_ACCOUNT in the module’s schema. • Account is Customer in the module’s schema. • Different names, similar structure. • Module’s concept of Company does not exist but can be replaced by target schema’s Customer Group. CUST_GROUP_ID CUST_GROUP_NAME INDUSTRY_ID INDUSTRY_NAME EMPLOYEE_COUNT ADDRESS ZIP A number of additional target schema columns are not present in the module’s schema. These can be added later to enhance the Analysis Module and provide additional objects for reporting. CITY_ID REGION_ID COUNTRY_ID VENDOR_FLAG L_PRODUCT PRODUCT_ID Lookup table for Product PRODUCT_DESC This is L_SALES _PROD in the module’s schema. • Different names, same structure. PRODUCT_GROUP_ID PRODUCT_GROUP_DESC L_TIME CALENDAR_DATE Lookup table for Time hierarchy CALENDAR_MONTH CALENDAR_QUARTER CALENDAR_YEAR FISCAL_MONTH FISCAL_YEAR This table maps to several tables in the module’s schema: L_CAL_DATE, L_CAL_ MNTH, L_CAL_QTR, and L_CAL_YEAR. • Different names. • Provide same relationships. • Last Period columns are missing in target schema, so trend analysis is not supported. DAY_IN_WEEK L_SALES_PERSON SALES_PERSON_ID SALES_PERSON_NAME 52 Perform a gap analysis This maps to L_SALES_REP in the module’s schema. • Region and District do not exist in this table in the target schema. © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Table in imaginary target schema Columns in imaginary target schema Results of mapping target schema with SFAM’s physical schema, and comments L_SALES_OFFICE SALES_OFFICE_ID This table does not exist in the module’s schema. SALES_OFFICE_NAME However, it can be mapped to the module’s Sales District concept, although the relationship with Sales Representative is broken. ADDRESS ZIP CITY_ID REGION_ID COUNTRY_ID L_CITY CITY_ID CITY_NAME REGION_ID L_REGION REGION_ID REGION_NAME COUNTRY_ID L_COUNTRY COUNTRY_ID COUNTRY_NAME F_SALES_ORDER Fact table with sales order data ORDER_ID - unique identifier for the order ORDER_LINE_ITEM_ID an order can contain several different products; this ID identifies different products within the same order CUSTOMER_ID SALES_PERSON_ID A number of additional columns are not present in the module’s schema. They can be added later to enhance the Analysis Module and provide additional objects for reporting. This table does not exist in the module’s schema. • It can be added to provide a new Sales Geography hierarchy. This table does not exist in the module’s schema. • It can be added to provide a new Sales Geography hierarchy. This table does not exist in the module’s schema. • It can be added to provide a new Sales Geography hierarchy. This maps with F_ORDER in the module’s schema. • Different table name and column names, but similar structure and keys. • The module’s Fact ORDER_AMT maps with the target schema’s NET_LINE_AMOUNT. A number of additional columns are not present in the module’s schema. They can be added later to enhance the Analysis Module and provide additional objects for reporting. SALES_OFFICE_ID PRODUCT_ID DATE_ID NET_LINE_AMOUNT NET_ORDER_AMOUNT NUM_UNITS UNIT_MEASURE COST Additional comments: Some tables in the module’s schema have a corresponding table in the target schema, including F_LEAD_STATUS, F_OPTY, L_OPTY, L_LEAD_SOURCE, and L_ORDER. © 2015 MicroStrategy, Inc. Perform a gap analysis 53 5 Porting the Analytics Modules Installation and Porting Guide Scenarios: Mapping physical schemas The table below presents some typical scenarios you can encounter while completing the physical schema mapping procedure above. Object Scenario Action Table Different name Map all related schema objects together. Not available Facts and attributes available only in this table should be eliminated after resolving dependencies. Missing one or more columns Update relevant attributes and facts that use the missing column in their expressions. Partitioned Create a partition mapping table and add all partitioned tables to the project. Aggregates tables present Add aggregates tables to project. Information distributed in multiple tables Add tables to the project and map each table to relevant schema objects. Different name Map all related objects together. Not available Update relevant attributes and facts that use the missing column in their expressions. Column Information distributed in multiple columns • in the same table • in different tables • Update attribute or fact expressions. • Create additional attribute forms or add facts. Different data types Update the warehouse catalog to read in new data types. Columns with same information have same names. Use automated mapping for corresponding schema objects and when adding tables to the project. Columns with same Use manual mapping for corresponding schema objects and information have different when adding tables to the project. names Map the module’s logical data model to the target schema In this second gap analysis procedure, you identify which of the module’s logical data model objects can be mapped to the target data warehouse. These objects, also called schema objects, include attributes, facts, hierarchies, and so on. The results are high-level guidelines for mapping the module’s logical data model to your target data warehouse schema (target schema). 54 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 An example follows this procedure, and a list of typical scenarios and actions follows the example. To map the logical data model to the target schema 1 Prepare a document to record the results of your analysis in this procedure. The document will need space for a list of supported schema objects and for guidelines to map those objects to the target schema. documents (one each for attributes, facts, and other Example schema objects) can be found at the end of this procedure; see Example: Mapping the logical data model, page 56. 2 Identify the list of the Analysis Module’s logical data model objects that are relevant to the target schema. For attributes, include all tables with relevant information, unless there are good reasons to exclude certain tables. Note the following: • You will be working with only a subset of the logical data model objects, based on the fact that missing data elements were identified in the previous procedure. • Refer to the reference guide for the Analysis Module you are using, to find definitions for all objects in the logical data model. Refer to the production metadata for relationships with the module’s physical schema. You can also access object definitions and physical structure links for attributes, facts, and so on using MicroStrategy Architect. 3 Using the document completed in the procedure above (Map the target data warehouse to the module’s physical schema, page 49), determine whether each object is supported by the data elements that exist in the target schema. Start by analyzing attributes, then facts, hierarchies, and so on. • For attributes, identify the following for each form expression: target schema columns lookup table other tables where the data element is present type of relationship with other attributes © 2015 MicroStrategy, Inc. Perform a gap analysis 55 5 Porting the Analytics Modules • Installation and Porting Guide relationship tables in the target schema For facts, identify the following for each form expression: target schema fact tables/columns and their entry level attributes • For hierarchies, identify constituent attributes and relationships. • For transformations, identify the following: • attribute mapping type member expression target schema member table (Optional) Use MicroStrategy Developer or Object Manager to identify dependencies between objects. For example, for an unsupported object, use these tools to identify other objects that depend on it. See the MicroStrategy System Administration Guide for details on using Object Manager. 4 For each supported object, identify changes required to map it to the target schema. Note the following: • In some cases, schema objects might be partially mapped. For example, the target schema might support only one of two attribute forms or a relationship between two attributes might not exist in the target schema. • Schema objects without matching data elements cannot be implemented. Example: Mapping the logical data model The tables below present examples of a document that reflects the results of mapping a module’s logical data model to a target data warehouse. This example includes a list of logical data model objects that are supported in the sample target schema, as well as actions required for mapping. The Sales Force Analysis Module (SFAM) is used in this example. 56 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Attributes This example table identifies the attributes that can be mapped to the sample target data warehouse and the actions required to map them. Attributes Exists in target data warehouse? Account Yes • Can be mapped to L_CUSTOMER. Attribute name and hierarchy name are now “Customer.” • Different table and column names for the attribute forms; requires updating attribute form expression to use new columns (ID: CUSTOMER_ID, DESC: CUSTOMER_NAME) and new tables (L_CUSTOMER and F_SALES_ORDER). Company Yes • Can be mapped to Customer Group in the L_CUSTOMER table. • Requires updating attribute name to Customer Group and form expressions (ID: CUST_GROUP_ID, DESC: CUST_GROUP_NAME). Industry Yes • Can be mapped to Industry in the L_CUSTOMER table. • Requires updating attribute form expression (ID: INDUSTRY_ID, DESC: INDUSTRY_NAME). Sales Representative Yes • Can be mapped to Sales Person in the L_SALES_PERSON table, but relationships with Sales District and Sales Region do not exist. • Requires updating name to Sales Person, form expressions (ID: SALES_PERSON_ID, DESC: SALES_PERSON_NAME), tables (L_SALES_PERSON and F_SALES_ORDER), and delete relationships. Sales District Yes • This attribute can be mapped to Sales Office in the L_SALES_OFFICE table, but relationships with Sales District and Sales Region do not exist. • Requires updating name to Sales Office, form expressions (ID: SALES_PERSON_ID, DESC: SALES_PERSON_NAME), tables (L_SALES_OFFICE and F_SALES_ORDER), and delete relationships. Sales Region No None. Data element does not exist in the target data warehouse. Product Yes • Can be mapped to Product in L_PRODUCT. • Requires updating form expressions to new tables (L_PRODUCT and F_SALES_ORDER) and columns (ID: PRODUCT_ID, DESC: PRODUCT_DESC). Product Group Yes • Can be mapped to Product Group in L_PRODUCT. • Requires updating form expressions to new table (L_PRODUCT) and columns (ID: PRODUCT_GROUP_ID, DESC: PRODUCT_GROUP_DESC). Lead attributes No None of them exist in the target schema; eliminate them from the MicroStrategy project. © 2015 MicroStrategy, Inc. Action Perform a gap analysis 57 5 Porting the Analytics Modules Attributes Exists in target data warehouse? Installation and Porting Guide Action Opportunity attributes No None of them exist in the target schema; eliminate them from the MicroStrategy project. Order Yes • Can be mapped to Order in the F_SALES_ORDER table. There is not a lookup table but the fact table can be used instead. • Requires updating form expression to use new table (F_SALES_ORDER) and column (ID: ORDER_ID). Discount Indicator No Eliminate it from the MicroStrategy project. Date Yes • Can be mapped to Calendar Date in L_TIME. • Requires updating form expressions to new tables (L_TIME and F_SALES_ORDER) and column (ID: CALENDAR_DATE; DATE_ID in fact table.) Month Yes • Can be mapped to Calendar Month in L_TIME. • However, target schema does not include Previous Month for historical analysis. Table L_CAL_MONTH from module’s schema will be added to target data warehouse to support this type of analysis. • Requires updating form expression to use new tables (L_TIME and L_CAL_MONTH) and form expressions. Quarter Yes • Can be mapped to Calendar Quarter in L_TIME. • However, target schema does not include Previous Year for historical analysis. Table L_CAL_QTR from module’s schema will be added to target data warehouse to support this type of analysis. • Requires updating form expression to use new tables (L_TIME and L_CAL_QTR) and form expressions. Year Yes • Can be mapped to Calendar Year in L_TIME. • However, target schema does not include Previous Year for historical analysis. Table L_CAL_YEAR from module’s schema will be added to target data warehouse to support this type of analysis. • Requires updating form expression to use new tables (L_TIME and L_CAL_YEAR) and form expressions. 58 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Facts The example table below identifies the facts that can be mapped to the sample target data warehouse schema and the actions required to map them. Facts Exists in the target data warehouse? Action Lead Size No None. Not supported in the target schema. Opportunity Size No None. Not supported in the target schema. Weighted Opportunity Size No None. Not supported in the target schema. Order Amount Yes Map to NET_LINE_AMOUNT in F_SALES _ORDER. Sales Representative Quota No For this example this concept will be added by creating the table F_SALES_REP_QTA in the target schema. Index for Lead Counts No None. Not supported in the target schema. Index for Opportunity Counts No None. Not supported in the target schema. Index for Order Counts Yes Requires updating to point to ORDER_ID column in F_SALES_ORDER table. Hierarchies and transformations The example table below identifies actions for other schema objects. Other schema objects Exists in the target data warehouse? Action/Comments Hierarchies Time - Year to Month Yes All attributes exist in the target schema. Sales Organization No Update it to eliminate Sales Representative relationships with District and Region. Product Yes All attributes exist in the target schema. Time Yes All attributes exist in the target schema. © 2015 MicroStrategy, Inc. Perform a gap analysis 59 5 Porting the Analytics Modules Installation and Porting Guide Other schema objects Exists in the target data warehouse? Transformations No Previous Month Action/Comments The table L_CAL_MNTH will be added to target schema to support this time transformation. Previous Quarter No The table L_CAL_QTR will be added to target schema to support this time transformation. Previous Year The table L_CAL_YEAR will be added to target schema to support this time transformation. No Scenarios: Mapping the logical data model The table below presents some typical scenarios you can encounter while completing the logical data model mapping procedure above. Object Scenario Action Attribute Different name Update the name. All dependents read the change automatically. Not available Remove after resolving dependencies. Additional forms Add forms if relevant to analysis and update the display tab where appropriate. Missing forms: ID or DESC If no substitution is possible, consider eliminating the attribute. Remove the form and update the display as appropriate. Split columns for forms Create an additional form expression. Merged columns for forms Remove the form expression or modify the form expression. Changed relationship with parent or child Update the parent-child relationship, hierarchies, and dimensional metrics. Additional parent or child Add to relationships and update the hierarchy. Missing parent or child Update attribute relationships appropriately and modify any relevant hierarchies. Change in relate table Choose a new relate table for the parent or child attribute. 60 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules Object Scenario Action Fact Different name Update the name. All dependents read the change automatically. Not available Remove after resolving dependencies. Different column name Update the fact. Expression derived with multiple columns Update the fact expression and base formulas or metrics. Additional expressions: • Information is at same level • Information is at different level Hierarchy 5 • Update the fact expression. No changes to the base formulas or metrics are required. • Update fact expressions to use the ApplySimple function and update base formulas or metrics to use ApplyAgg functions in the platform. Another option is to create separate metrics and update dependent application objects appropriately. Missing expression If there is only one expression, the fact is no longer supported. In the case of multiple expressions, identify metrics/reports that use the missing expression and eliminate those. Checking on the report SQL may be required. Change in column data type Update the warehouse catalog to read in new data types. Fact available in partitioned tables Add a partition mapping table and update the fact appropriately. Fact available in aggregates Add aggregates to the list of other tables. Fact available but at different entry levels Create additional expressions if appropriate. Update related metrics and base formulas. Table for dummy fact has different keys Update the fact and change the base formula/metric appropriately. Different name Update the name. All dependents read the change automatically. Not available Eliminate the hierarchy after resolving dependencies. Metrics using the hierarchy for dimensionality change in meaning and filters/prompts using the hierarchy are removed. Additional attribute Add an attribute if it is a parent or child of other attributes in the hierarchy. The attribute should also be added if it has relationships (parent and/or child) and meaning similar to those of other attributes in the hierarchy. Missing attribute Update the hierarchy. © 2015 MicroStrategy, Inc. Perform a gap analysis 61 5 Porting the Analytics Modules Object Scenario Transformation Different name Installation and Porting Guide Action Update the name. All dependents read the change automatically. Not available Eliminate the transformation after resolving dependencies. Any metrics using the transformation are no longer supported. Same mapping type not available Remove the transformation after resolving dependent metrics. New name for member expression or table Update the transformation. Identify application objects Using the results from the two procedures above, this third gap analysis procedure helps you identify the Analysis Module’s components that can be implemented with your target data warehouse. Components include application objects (located by default in the Public Objects folder) such as reports, metrics, filters, and so on. Results of this procedure include a list of supported components, unsupported components, and those that require changes to be supported. An example follows this procedure, and a list of typical scenarios and actions follows the example. To identify application objects 1 Prepare a document to record the results of your analysis in this procedure. The document will need space for a list of supported application objects, unsupported objects, and objects requiring changes, as well as space for the actions required. documents (one for base formulas and metrics, one for Example prompts, one for filters, and one for reports) can be found at the end of this procedure; see Example: Identifying application objects, page 63. 62 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 2 Using the results from the procedure above (Map the module’s logical data model to the target schema, page 54), identify the dependencies between logical data model objects and application objects. Note the following: • See the appropriate Analysis Module’s reference guide for a list of reports, metrics, and so on. You can use the production metadata to determine dependencies between different objects. • You can use also MicroStrategy Developer or Object Manager to complete this task. Object Manager provides enhanced functionality to identify child-parent and parent-child dependencies. 3 Determine which application objects can be implemented using the target data warehouse schema. Document the results of this analysis and be sure to include: • A list of supported application objects • A list of application objects that require changes and how to implement those changes • A list of application objects not supported can complete the analysis either at the report level or at a You more detailed level by taking into account the attributes, metrics, filters, and custom groups that make up a report. Example: Identifying application objects The tables below present examples of analysis results from the procedure above. They reflect the results of mapping a module’s application objects to a target data warehouse. This example includes a list of application objects that are supported in the target schema, as well as unsupported objects and objects that require changes to be supported. In this example, the Sales Force Analysis Module (SFAM) is used; only two of the analysis areas within SFAM are supported by the sample target schema. © 2015 MicroStrategy, Inc. Perform a gap analysis 63 5 Porting the Analytics Modules Installation and Porting Guide Base formulas and metrics This example table identifies the base formulas and metrics that can be reused with the sample target data warehouse, and any actions required to use them. Base formulas and metrics Base Sum of Lead Size Formulas Can be implemented in target warehouse? Action/Comments No Underlying fact is not present in the target schema. Sum of Opportunity Size No Underlying fact is not present in the target schema. Sum of Weighted Opportunity Size No Underlying fact is not present in the target schema. Sum of Sales Representative Quota Yes For this example, the fact containing quota data was added to the target data warehouse. Sum of Order Amount Yes A data element supporting this base formula exists in the target data warehouse. Count of Leads No Underlying fact is not present in the target schema. Count of Opportunities No Underlying fact is not present in the target schema. Count of Orders Yes A data element supporting this base formula exists in the target data warehouse. Update the definition to point to the correct column for counts. Count of Sales Representatives Yes A data element supporting this base formula exists in the target data warehouse. Update the definition to point to the correct column for counts. 64 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide 5 Porting the Analytics Modules Base formulas and metrics Can be implemented in target warehouse? Metrics All Lead Analysis metrics No These metrics are not supported in the target data warehouse. All Pipeline Analysis metrics No These metrics are not supported in the target data warehouse. Revenue Yes An underlying data element defining this metric is present in the target data warehouse. Revenue (Region Filtered) No Sales Region data element does not exist in the target data warehouse. Action/Comments Revenue Yes (Previous Quarter) Underlying data elements defining this metric are present in the target data warehouse. % Contribution to Total Revenues No Sales Region data element does not exist in the target data warehouse. % Revenue Change vs. Previous Quarter Yes Underlying data elements defining this metric are present in the target data warehouse. Number of Sales Representatives Yes An underlying data element defining this metric is present in the target data warehouse. Revenue by Sales Representative Yes Underlying data elements defining this metric are present in the target data warehouse. Target Quota Yes Quota data was added to the target data warehouse. % Quota Achieved Yes All data elements that define this metric are present in the target data warehouse (quota data was added to the existing schema). Opportunity Size No Data elements that define this metric are not present in the target data warehouse. % Conversion vs. Opportunity Size No Data elements that define this metric are not present in the target data warehouse. Weighted Opportunity Size No Data elements that define this metric are not present in the target data warehouse. Orders Yes An underlying data element defining this metric is present in the target data warehouse. Opportunities No A data element that defines this metric is not present in the target data warehouse. % Opportunities Converted No Data elements that define this metric are not present in the target data warehouse. © 2015 MicroStrategy, Inc. Perform a gap analysis 65 5 Porting the Analytics Modules Base formulas and metrics Metrics (cont.) Installation and Porting Guide Can be implemented in target warehouse? Action/Comments Target Quota Yes (Previous Quarter) All data elements that define this metric are present in the target data warehouse (quota data was added to the existing schema). % Quota Achieved (Previous Quarter) All data elements that define this metric are present in the target data warehouse (quota data was added to the existing schema). Wins vs. Competitors No Data elements that define this metric are not present in the target data warehouse. % Wins vs. Competitors No Data elements that define this metric are not present in the target data warehouse. Lost Opportunities vs. Competitor No Data elements that define this metric are not present in the target data warehouse. % Lost vs. Competitor No Data elements that define this metric are not present in the target data warehouse. Deals No A data element that defines this metric is not present in the target data warehouse. Deal Size No A data element that defines this metric is not present in the target data warehouse. Lost Deal Size No Data elements that define this metric are not present in the target data warehouse. Orders containing Product Yes Underlying data elements defining this metric are present in the target data warehouse. Revenue Yes Underlying data elements defining this metric are present in the target data warehouse. Average Product Yes Revenue by Order Underlying data elements defining this metric are present in the target data warehouse. Revenue Yes (Previous Quarter) Underlying data elements defining this metric are present in the target data warehouse. Revenue (Product Group) Yes Underlying data elements defining this metric are present in the target data warehouse. % Contribution to Product Group Revenue Yes Underlying data elements defining this metric are present in the target data warehouse. Revenue (Sales District, Quarter) Yes Underlying data elements defining this metric are present in the target data warehouse. % Contribution to Quarter Sales District Revenue Yes Underlying data elements defining this metric are present in the target data warehouse. 66 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Prompts The example table below identifies prompts that can be reused with the sample target data warehouse, and any actions required to use them. Prompts Can be implemented in target warehouse? Account List Yes Attribute is supported in the target warehouse (Customer). Company List Yes Attribute is supported in the target warehouse (Customer Group). Action/Comments Lead Characteristics No Attribute does not exist in the target data warehouse. Lead Source Multiple selections No Attribute does not exist in the target data warehouse. Product Group Multiple selections Yes Attribute is supported in the target data warehouse. Quarter - Multiple selections Yes Attribute is supported in the target data warehouse. Quarter - One selection only Yes Attribute is supported in the target data warehouse. Sales District Multiple selections Yes Attribute is supported in the target data warehouse (Sales Office). Sales District - One selection only Yes Attribute is supported in the target data warehouse (Sales Office). Sales Region Multiple selections No Attribute does not exist in the target data warehouse. Sales Region - One selection only No Attribute does not exist in the target data warehouse. Time - Year to Month hierarchy Yes Hierarchy is supported in the target data warehouse. Year - One selection only Yes Attribute is supported in the target data warehouse. © 2015 MicroStrategy, Inc. Perform a gap analysis 67 5 Porting the Analytics Modules Installation and Porting Guide Filters The example table below identifies the filters that can be reused with the sample target data warehouse, and any changes required. Can be implemented in target warehouse? Filters Action/Comments Rank of Top 10 Companies by Deal Size Yes If updated to use Revenue instead of Deal Size. Rank of Top Deals by Deal Size Yes If updated to use Revenue instead of Deal Size. Rank of Top 10 Lost Opportunities by Lost Deal Size No Opportunity data is not present in the target data warehouse. Rank of Top 3 Deals by Deal Size, break by Primary Competitor No Opportunity data is not present in the target data warehouse. Rank of Top 3 Deals by Deal Size, break by Sales Region Yes If updated to use Revenue instead of Deal Size and another sales organization attribute instead of Sales Region. Rank of Top Lost Opportunities by Lost Deal Size, break by ... No Opportunity data is not present in the target data warehouse. Rank Top N Products by Revenue Yes All objects required for this report are supported by the target data warehouse. All filters in folder: “Filters for conditional metrics” No Data elements defining these filters are not present in the target data warehouse. Reports The example table below identifies the reports that can be reused with the sample target data warehouse, and any changes required. In this example, 11 out of the 28 reports in the Sales Performance and Product Sales analysis areas are supported out of the box (39% initial set), with 9 additional reports requiring simple modifications (totaling 71% of the initial set). Reports Can be implemented in target warehouse? Action/Comments All reports: Lead Analysis folder No These reports are not supported in the target data warehouse. All reports: Pipeline Analysis folder No These reports are not supported in the target data warehouse. 68 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Reports 5 Porting the Analytics Modules Can be implemented in target warehouse? Action/Comments Summary Sales Performance by Sales Region & Quarter Yes If the Opportunity metrics are removed from the report it can be reused. Revenue Distribution by Sales Region Yes If Sales Region is replaced by another sales organization attribute, the report can be reused. Quarterly Revenue Trend by Sales Region Yes If Sales Region is replaced by another sales organization attribute, the report can be reused. Quarterly Revenue & Closure Trend No Required data elements do not exist in the target data warehouse. Quarterly Revenue & Closure Trend by Sales Region Yes If Sales Region is replaced by another sales organization attribute and all Opportunity metrics are removed, the report can be reused. Quarterly Quota Performance by Sales District Yes In this example, a fact with quota performance data will be added to the target data warehouse to support this type of analysis. Quota Achievement by Quarter & Sales Organization Yes If Sales Region is replaced by another sales organization attribute and all Opportunity metrics are removed, the report can be reused. Competitive Activity by Quarter No Required data elements (Primary Competitor) do not exist in the target data warehouse. Quarterly Competitive Win Rate Trend No Required data elements (Primary Competitor) do not exist in the target data warehouse. Top 10 Companies by Deal Size - Quarter Yes If report is modified to rank attributes by Revenue, implying changing metrics and rank filter. Top 10 Deals by Quarter Yes If report is modified to rank attributes by Revenue, implying changing metrics and rank filter. Top 3 Deals by Quarter & Primary Competitor No Required data elements (Primary Competitor) do not exist in the target data warehouse. Top 3 Deals by Quarter & Sales Region Yes If report is modified to rank attributes by Revenue, implying changing metrics and rank filter, and Sales Region replaced by any other sales organization attribute. Top 10 Lost No Opportunities by Quarter Required data elements (Opportunity data) do not exist in the target data warehouse. Top 3 Lost Opportunities by Quarter & Primary Competitor No Required data elements (Opportunity data) do not exist in the target data warehouse. Top 3 Lost Opportunities by Quarter & Sales Region No Required data elements (Opportunity data) do not exist in the target data warehouse. © 2015 MicroStrategy, Inc. Perform a gap analysis 69 5 Porting the Analytics Modules Reports Can be implemented in target warehouse? Installation and Porting Guide Action/Comments Product Performance Summary by Quarter Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Products with Increasing Sales by Sales District Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Products with Decreasing Sales by Sales District Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Products with Increasing Quarterly Sales Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Products with Decreasing Quarterly Sales Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Top N Products Sold Quarter Revenue Trend Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Top N Products Sold by Sales District Yes If Sales Region is removed from the template and prompt. Quarter Product Contribution to Sales District Revenues Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Quarterly Orders Trend by Product Group Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Product Revenue Trend Yes Data elements for the attributes and metrics (facts) exist in the target data warehouse. Revenue Distribution by Yes Product Group & Quarter Data elements for the attributes and metrics (facts) exist in the target data warehouse. Quarterly Closure Rate based on Product Required data elements (Opportunity data) do not exist in the target data warehouse. 70 Perform a gap analysis No © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Scenarios: Identifying application objects The table below presents some typical scenarios you can encounter while completing the application object mapping procedure above. The scenarios are listed by object type. Object Scenario Action Metrics / Base Formula Different name Update the name. All dependents read the change automatically. Not available Delete after resolving dependencies. Filters and custom groups that use such a metric also have to be removed. Fact used is not available Delete the base formula and its dependent metrics after resolving dependencies. Table used for counts has different keys Check the Count Distinct and Fact ID parameters. Attribute or hierarchy used for dimensionality is not available Evaluate whether the metric is meaningful without the dimensionality. If it is, change the name and use it only on appropriate reports. Filter used for condition is not available Evaluate whether the metric is meaningful without the condition. If it is, change the name and use it only on appropriate reports. Transformation is not available Delete the metric after resolving dependencies, because the metric meaning is completely changed. Compound metric: Constituent metric is not available Evaluate whether the remaining constituent metric combination is useful. If it is, change the name and use it only on appropriate reports. Different name Update the name. All dependents read the change automatically. One or more embedded filters not supported Evaluate whether the remaining custom grouping is worth using on the report. Embedded filters not supported Eliminate the custom group after resolving dependencies. Custom Groups © 2015 MicroStrategy, Inc. Perform a gap analysis 71 5 Porting the Analytics Modules Installation and Porting Guide Object Scenario Action Prompts Different name Update the name. All dependents read the change automatically. Embedded attribute or Delete the prompt and dependent filter after resolving hierarchy not dependencies. available Filters For object prompts, one or more of the constituent list not available Evaluate whether the remaining list of objects is worth using in a report. If a single object remains, place it on the report and eliminate the object prompt. Different name Update the name. All dependents read the change automatically. Attribute Qualification: Eliminate the filter after resolving dependencies. Attribute not supported Reports Metric qualification: Metric not supported Eliminate the filter after resolving dependencies. Relationship filters: Output level, filter qualification, or relate by fact/table not supported Eliminate the filter after resolving dependencies. Different name Update the name. Analysis not supported Eliminate related reports, or move to a separate folder if there are plans for support at a later stage of the deployment. Attribute on template not available Remove the report unless a suitable substitution can be found in the target data model. Metric on template not available Remove the metric and keep the report. Filter or parts of it not supported If the entire filter is not supported: • With relationship type set filters, the report may have to be removed. • With other filters, a substitution should be considered for limiting the result set. If part of a filter is not supported, a substitution should be considered but may not be essential. 72 Perform a gap analysis © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Identify additional requirements This procedure is optional. The three gap analysis procedures performed above can include identifying data elements from the target data warehouse that can be added to the application metadata. This optional procedure is not described in this methodology. For a list of typical scenarios to customize and extend the Analytics Modules, see Customize and extend the Analytics Modules, page 34. Map the module After you perform a gap analysis as described previously, you can map the schema objects (attributes, facts, and so on) to the new target schema and update application objects (reports, metrics, filters, and so on) to ensure they work against the new schema. You can choose from the following methods for the mapping, depending on whether you want to use MicroStrategy Object Manager: • With Object Manager: Using MicroStrategy Architect and Developer, duplicate the packaged project and map the schema objects. Then move the application objects to the mapped project using MicroStrategy Object Manager. If you decide to use Object Manager, see Map the module with Object Manager, page 74. • Without Object Manager: Using MicroStrategy Architect and Developer, make all changes in the original project. First update all application objects to use only those schema objects supported in the target data warehouse, and then map schema object links to use the new physical schema. If you decide not to use Object Manager, see Map the module without Object Manager, page 90. Mapping with Object Manager is more efficient because it allows you to implement only those portions of an Analysis Module that are relevant to your company’s requirements. © 2015 MicroStrategy, Inc. Map the module 73 5 Porting the Analytics Modules Installation and Porting Guide Mapping prerequisites Before you map the Analysis Module, make sure you have access to the following: Experience creating analytical applications with MicroStrategy Developer and MicroStrategy Architect. Skills The results from your gap analysis, performed above. MicroStrategy Architect, to modify attribute and fact definitions so they use the tables and columns from the target data warehouse. MicroStrategy Developer, to modify definitions for the reports, metrics, filters, and so on that may be impacted by the missing attributes and facts in the target data warehouse. Tools The appropriate MicroStrategy Analysis Module’s reference guide. (Optional) MicroStrategy Object Manager, to move objects (such as reports and metrics) between projects. Map the module with Object Manager If you decide to use MicroStrategy Object Manager to assist you in the mapping part of the porting process, you will perform the following procedures: • Use MicroStrategy Architect and Developer to duplicate the packaged project and map schema objects. • Use MicroStrategy Object Manager to move application objects to the mapped project. If you decide not to use Object Manager, see Map the module without Object Manager, page 90. Overview: Mapping with Object Manager This mapping method uses two MicroStrategy projects: • Master project: The original project for the Analytics Modules • Destination project: The project that will be mapped to the target schema; created by duplicating the master project Complete both mapping procedures below in the order they appear. 74 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Map schema objects This first procedure uses MicroStrategy Architect to map schema objects in the destination project to the target schema, based on results from your gap analysis at the beginning of this chapter. For details on the gap analysis, see Perform a gap analysis, page 48. An example follows this procedure. To map schema objects 1 Using MicroStrategy Architect, duplicate the project for the MicroStrategy Analysis Module you are interested in. Use the project provided in the production metadata, and duplicate it to a new location. Use the option Duplicate only schema objects. all actions taken during this mapping process to allow Document you to backtrack if necessary. 2 Update the data warehouse catalog to point to the target schema, adding relevant tables from the target schema to the destination project. 3 Map hierarchies based on the results from your gap analysis: • If a hierarchy exists in the destination project, proceed with mapping. Actions can include changing the name, removing or adding attributes, and so on. • If a hierarchy does not exist, remove it from the project. can only be removed from the MicroStrategy metadata Objects if no dependents exist in the project. The order for removing objects throughout this procedure is determined based on that principle. 4 Map transformations based on the results from your gap analysis: • If a transformation exists in the destination project, proceed with mapping. Actions can include changing the name, updating the definition to the target schema tables and columns, and so on. • If a transformation does not exist, remove it from the project. 5 Map facts based on the results from your gap analysis: © 2015 MicroStrategy, Inc. Map the module 75 5 Porting the Analytics Modules Installation and Porting Guide • If a fact exists in the destination project, proceed with mapping. Actions can include changing the fact name, updating fact expressions to point to the target schema tables and columns, removing or adding fact expressions, and so on. • If a fact does not exist, remove it from the project. 6 Map attributes based on the results from your gap analysis: • Start with the lowest attributes in each hierarchy, and proceed sequentially with all parents. • If an attribute exists in the destination project, proceed with mapping. Actions can include changing the attribute name; updating forms to point to the target schema tables and columns; adding or removing forms; updating, removing or adding relationships; and so on. • If an attribute does not exist, remove it from the project. 7 Update the project schema using the default options to make your changes available. Then follow the final mapping procedure, Update application objects with Object Manager, page 79, to move all application objects to the destination project. Example: Mapping schema objects This example summarizes the actions taken to map packaged schema objects from the MicroStrategy Sales Force Analysis Module (SFAM) to the example target data warehouse. 1 To update the connection to the target schema, begin by defining the database connection to the target data warehouse. example, some tables from the default physical schema are Inused,thissuch as F_SALES_REP_QTA. Tables must be created before this step is taken; the Erwin file containing the default physical schema can be used to generate scripts for these tables. 2 Update the warehouse catalog, selecting the relevant tables based on the gap analysis between physical schemas. For more details, see Example: Mapping physical schemas, page 52. 76 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 3 Map all schema objects in the destination project. • Hierarchies: The following table summarizes the example actions taken to map SFAM hierarchies to the target data warehouse. Order Packaged Object Action 1 Time - Year to Month No changes are required. 2 Product No changes are required. 3 Time No changes are required. 4 Sales Organization Delete Sales District and Sales Region from this hierarchy. • Transformations: No changes are required for transformations because all base attributes and tables are the same. • Facts: The following table summarizes the example actions taken to map the SFAM facts to the target data warehouse. Order Packaged Object 1 Order Amount Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 2 Sales Representative Quota Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 3 Index for Order Counts Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 4 Opportunity Size Delete the fact from the MicroStrategy project. 5 Weighted Opportunity Size Delete the fact from the MicroStrategy project. 6 Lead Size Delete the fact from the MicroStrategy project. © 2015 MicroStrategy, Inc. Action Map the module 77 5 Porting the Analytics Modules Packaged Object Action 7 Index for Lead Counts Delete the fact from the MicroStrategy project. 8 Index for Opportunity Counts Delete the fact from the MicroStrategy project. Order • Installation and Porting Guide Attributes: The following table summarizes the example actions taken to map SFAM attributes to the target data warehouse. of the folders require name changes based on new attribute Some names. For example, change the name of the Account folder to Customer. Order Packaged Object 1 Account Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 2 Company Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 3 Industry Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 4 Lead Delete the attribute from the MicroStrategy project. 5 Lead Source Delete the attribute from the MicroStrategy project. 6 Lead Status Delete the attribute from the MicroStrategy project. 7 Lead Type Delete the attribute from the MicroStrategy project. 8 Opportunity Delete the attribute from the MicroStrategy project. 9 Current Opportunity Status Delete the attribute from the MicroStrategy project. 10 Opportunity Open Date Delete the attribute from the MicroStrategy project. 11 Opportunity Close Date Delete the attribute from the MicroStrategy project. 12 Primary Competitor Delete the attribute from the MicroStrategy project. 13 Opportunity Status Delete the attribute from the MicroStrategy project. 78 Map the module Action © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Order Packaged Object 14 Order Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 15 Discount Indicator Delete the attribute from the MicroStrategy project. 16 Product Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 17 Product Group Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 18 Sales Representative Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 19 Sales District Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 20 Sales Region Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 21 Date Delete the attribute from the MicroStrategy project. 22 Month Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 23 Quarter Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 24 Year Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. Action 4 Finally, after all schema objects have been mapped, remove all tables that are not used. The project schema must be updated to reflect all of the changes. Update application objects with Object Manager This second procedure uses MicroStrategy Object Manager to move all application objects that can be implemented to the destination project, based on the gap analysis completed earlier in this chapter. The schema objects represent the building blocks on which application objects are defined. Once schema object definitions are updated to use the target schema, using the procedure above, application objects can be moved to the destination project. © 2015 MicroStrategy, Inc. Map the module 79 5 Porting the Analytics Modules Installation and Porting Guide Application objects must be moved in a certain order, based on which application objects are used as building blocks for other application objects. For example, to move a report with its attributes, metrics, and so on, the defining report must be present in the destination project. The procedure below will prompt you to move application objects in the appropriate order, based on specific considerations. The example following this procedure contains additional specifics on the appropriate order for moving objects. Be aware of the following: • Before you move any application objects, you must check on the components (schema and application objects) in the master project and determine whether these exist in the destination project. During the procedure below, use MicroStrategy Object Manager child-parent dependencies and its Search functionality to identify object components for a given object in the master project and determine whether all components exist in the destination project. • Document in detail all actions taken during this procedure. To update application objects with Object Manager 1 Move prompts and filters, based on the results from the gap analysis, proceeding first with prompts and then filters. • If all components of the object exist in the destination project, move the object to the destination project using the option Use existing definition in the destination project. If a name change is required, do that in the destination project. • If all components are not present, do one of the following: – Move the necessary components to update the definition in the master project and then move the object. – Skip the object and update the definition to remove any unavailable components. Note the following: • 80 Map the module Metrics can use filters in their definition, and filters can use metrics. In this case, filters are considered before metrics because the Analytics Modules minimize the use of metrics qualification within filters, while many metrics include filters in their qualifications. If a filter requires a metric, the metric must be moved first. © 2015 MicroStrategy, Inc. Installation and Porting Guide • 5 Porting the Analytics Modules Filters qualifying on attribute or metric values must be updated after the filter is moved to the destination project. They also must use suitable new values in the existing data warehouse. For example, a filter like Lost Deals qualifies Opportunities when Opportunity Status=“Lost,” but if the value in the target data warehouse is “Loss,” the filter must be updated accordingly. 2 Move base formulas, based on the results from the gap analysis. • If all facts or attributes defining the base formula exist in the destination project, move the object to the destination project using the option Use existing definition in the destination project. If a name change is required, do that in the destination project. • If all components are not present, do one of the following: – Move the necessary components to update the definition in the master project and then move the object. – Skip the object and update the definition to remove any unavailable components. 3 Move metrics, based on the results from the gap analysis. Start with simple metrics, and then proceed with conditional, transformation, dimensional, and compound metrics. This order is important because, for example, compound metrics can be defined based on other metrics. • If all components of the object exist in the destination project, move the object to the destination project using the option Use existing definition in the destination project. If a name change is required, do that in the destination project. • If all components are not present, do one of the following: – Move the necessary components to update the definition in the master project and then move the object. – Skip the object and update the definition to remove any unavailable components. some components such as dimensionality or Changing conditionality can have some unexpected results in the reports. 4 Move reports, based on the results from the gap analysis. • If all components (attributes, metrics, prompts, filters, and so on) exist in the destination project, move the object to the destination project using the option Use existing definition in the destination © 2015 MicroStrategy, Inc. Map the module 81 5 Porting the Analytics Modules Installation and Porting Guide project. If a name change is required, do that in the destination project. • If all components are not present, do one of the following: – Move the necessary components to update the definition in the master project and then move the object. – Skip the object and update the definition to remove any unavailable components. 5 Execute all reports to test the application objects and ensure that the results of your work in this procedure are correct. Example: Updating application objects with Object Manager This example summarizes the actions taken to implement application objects from the MicroStrategy Sales Force Analysis Module (SFAM) against the example target data warehouse, based on the gap analysis. For details on the gap analysis, see Example: Identifying application objects, page 63. 1 Prompts: The following table shows the example actions taken to move SFAM prompts to the destination project. Order Packaged Object Action 1 This prompt can be moved because all objects defining this object are present in the destination project. Account List Change the name to Customer List. 2 Company List This prompt can be moved because all objects defining this object are present in the destination project. Change the name to Customer Group Account. 3 Lead Characteristics No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63 4 Lead Source Multiple Selections No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 5 Product Group Multiple Selections This prompt can be moved because all objects defining this object are present in the destination project. 6 Quarter - Multiple Selections This prompt can be moved because all objects defining this object are present in the destination project. 7 Quarter - One Selection Only This prompt can be moved because all objects defining this object are present in the destination project. 82 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules Order Packaged Object Action 8 This prompt can be moved because all objects defining this object are present in the destination project. Sales District Multiple Selections 5 Change the name to use Sales Office. 9 Sales District - One Selection Only This prompt can be moved because all objects defining this object are present in the destination project. Change the name to Sales Office. 10 Sales Region Multiple Selections No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 11 Sales Region - One Selection Only No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 12 Time - Year to Month Hierarchy This prompt can be moved because all objects defining this object are present in the destination project. 13 Year - One Selection Only This prompt can be moved because all objects defining this object are present in the destination project. 2 Filters: The following table shows the example actions taken to move SFAM filters to the destination project. Order Packaged Object Action 1 Note: This filter requires that the metric is present in the destination project first, so move the Revenue metric before proceeding with this filter. Rank of Top 10 Companies by Deal Size Proceed based on the gap analysis (see Example: Identifying application objects, page 63). Modify the filter in the source project to use the Revenue metric instead of Deal Size. Then move it and change the name. 2 Rank of Top Deals by Deal Size Note: This filter requires that the metric is present in the destination project first, so move the Revenue metric before proceeding with this filter. Proceed based on the gap analysis (see Example: Identifying application objects, page 63). Modify the filter in the source project to use the Revenue metric instead of Deal Size. Then move it and change the name. 3 Rank of Top 10 Lost Opportunities by Lost Deal Size No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 4 Rank of Top 3 Deals by Deal Size, break by Primary Competitor No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. © 2015 MicroStrategy, Inc. Map the module 83 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 5 Note: This filter requires that the metric is present in the destination project first, so move the Revenue metric before proceeding with this filter. Rank of Top 3 Deals by Deal Size, break by Sales Region Proceed based on the gap analysis (see Example: Identifying application objects, page 63). Modify the filter in the source project to use the Revenue metric instead of Deal Size, and use Sales District instead of Sales Region. Then move it and change the name. 6 Rank of Top Lost Opportunities by Lost Deal Size, break by Sales Region No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 7 Rank Top N Products by Revenue Note: This filter requires that the metric is present in the destination project first, so move the Revenue metric before proceeding with this filter. All objects defining this object are present in the destination project; move the filter. 8 All filters in Folder “Filter for Conditional Metrics” No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 3 Base formulas: The following table shows the example actions taken to move SFAM base formulas to the destination project. Order Packaged Object Action 1 Sum of Lead Size No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 2 Sum of Opportunity Size No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 3 Sum of Weighted Opportunity Size No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 4 Sum of Sales Representative Quota This base formula can be moved because the fact used for this base formula is present in the destination project. 5 Sum or Order Amount This base formula can be moved because the fact used for this base formula is present in the destination project. 6 Count of Leads No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 7 Count of Opportunities No action; not supported in the target data warehouse. For details, see Example: Identifying application objects, page 63. 84 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules Order Packaged Object Action 8 Count of Orders This base formula can be moved because the fact used for this base formula is present in the destination project. 9 Count of Sales Representatives This base formula can be moved because the fact used for this base formula is present in the destination project. 5 4 Metrics: The following table shows the example actions taken to move SFAM metrics to the destination project. Order Packaged Object Action Simple metrics 1 Revenue The metric can be moved because the base formula was moved in the previous step, so the base formula exists in the destination project. 2 Target Quota The metric can be moved because the base formula was moved in the previous step, so the base formula exists in the destination project. 3 Orders The metric can be moved because the base formula was moved in the previous step, so the base formula exists in the destination project. 4 Orders containing Product The metric can be moved because the base formula was moved in the previous step, so the base formula exists in the destination project. 5 Opportunity Size No action; the metric cannot be moved because the base formula does not exist in the target data warehouse. 6 Weighted Opportunity No action; the metric cannot be moved because the base formula Size does not exist in the target data warehouse. 7 Opportunities No action; the metric cannot be moved because the base formula does not exist in the target data warehouse. 8 Number of Sales Representatives The metric can be moved because the attribute defining the metric was moved in the previous step, so it exists in the destination project. Name the updated metric to Number of Sales Persons. Simple metrics with transformation 9 Revenue (Previous Quarter) The metric can be moved because both the base formula and transformation exist in the destination project. 10 Target Quota (Previous Quarter) The metric can be moved because both the base formula and transformation exist in the destination project. Simple metrics with dimensionality 11 Revenue (Region Filtered) © 2015 MicroStrategy, Inc. No action; Sales Region attribute is not supported. Note: This metric can be moved if it was updated earlier to use Sales Office, although this may change the results in the reports that use the metric. Map the module 85 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 12 Revenue (Product Group) The metric can be moved because both the base formula and metric level attribute exist in the destination project. 13 Revenue (Sales District, Quarter) The metric can be moved because both the base formula and metric level attributes exist in the destination project. Name the updated metric to Revenue (Sales Office, Quarter). Simple metrics with conditionality 14 Deals No action; the underlying fact is not supported in the target data warehouse. 15 Deal Size No action; the underlying fact is not supported in the target data warehouse. 16 Lost Deal Size No action; the underlying fact is not supported in the target data warehouse. 17 Opportunities with a Competitor No action; the underlying fact is not supported in the target data warehouse. 18 Lost Opportunities vs. Competitor No action; the underlying fact is not supported in the target data warehouse. 19 Wins vs. Competitors No action; the underlying fact is not supported in the target data warehouse. Compound metrics 20 Revenue by Sales Representative This object can be moved because the metrics defining it were already moved to the destination project. Name the updated object to Revenue by Sales Person. 21 Average Product Revenue by Order This object can be moved because the metrics defining it were already moved to the destination project. 22 % Opportunities Converted No action; the Opportunities metric does not exist in the destination project. 23 % Wins vs. Competitor No action; one of the metrics is not supported because the Primary Competitor attribute does not exist in the target data warehouse. 24 % Lost vs. Competitor No action; one of the metrics is not supported because the Primary Competitor attribute does not exist in the target data warehouse. 25 % Quota Achieved This object can be moved because the metrics defining it were already moved to the destination project. 26 % Quota Achieved (Previous Quarter) This object can be moved because the metrics defining it were already moved to the destination project. 27 % Revenue Change vs. Previous Quarter This object can be moved because the metrics defining it were already moved to the destination project. 28 % Contribution to Total Revenues No action; one of the metrics is not supported in the target data warehouse. 86 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules Order Packaged Object Action 29 % Conversion vs. Opportunity Size No action; one of the metrics is not supported in the target data warehouse. 30 % Conversion vs. No action; one of the metrics is not supported in the target data Weighted Opportunity warehouse. Size 31 % Contribution to Product Group Revenue This object can be moved because the metrics defining it were already moved to the destination project. 32 % Contribution to Quarter Sales District Revenue This object can be moved because the metrics defining it were already moved to the destination project. 5 Update the name to % Contribution to Quarter Sales Office Revenue. Note: Metrics used for Lead and Pipeline Analysis are not supported; no action. 5 Reports: The following table shows the example actions taken to move SFAM reports to the destination project. Order Packaged Object Action Product Sales Analysis reports 1 Product Performance Summary by Quarter This report can be moved because all components of this report (attributes, metrics, and prompts) exist in the destination project. 2 Products with Increasing Sales by Sales District This report can be moved because all components of this report (attributes, metrics, and prompts) exist in the destination project. Update the name to Products with Increasing Sales by Sales Office. 3 Products with Decreasing This report can be moved because all components of this report Sales by Sales District (attributes, metrics, and prompts) exist in the destination project. Update the name to Products with Decreasing Sales by Sales Office. 4 Products with Increasing Quarterly Sales This report can be moved because all components of this report (attributes, metrics, and prompts) exist in the destination project. 5 Products with Decreasing This report can be moved because all components of this report Quarterly Sales (attributes, metrics, and prompts) exist in the destination project. 6 Top N Products Sold Quarter Revenue Trend This report can be moved because all components of this report (attributes, metrics, and prompts) exist in the destination project. 7 Top N Products Sold by Sales District The report in the master project includes a prompt that does not exist in the destination project. Remove the Sales Region attribute and prompt from this report, then move the report and change the name to Top N Products Sold by Sales Office. Note: This can be done because the report still has business value after replacing Sales Region by Sales District (Sales Office in the destination project). © 2015 MicroStrategy, Inc. Map the module 87 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 8 Quarter Product Contribution to Sales District Revenues The report in the master project includes a prompt that does not exist in the destination project. Remove the prompt from the master project report, then move the report to the destination project. 9 Quarterly Orders Trend by Product Group This report can be moved because all components of this report (attributes, metrics, and prompts) exist in the destination project. 10 Product Revenue Trend This report can be moved because all components of this report (attributes, metrics, and prompts) exist in the destination project. 11 Revenue Distribution by This report can be moved because all components of this report Product Group & Quarter (attributes, metrics, and prompts) exist in the destination project. 12 Quarterly Closure Rate based on Product No action; Opportunity-related objects are not supported in the target schema. Sales Performance Analysis reports 13 Summary Sales Performance by Sales Region & Quarter The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing Sales Region with Sales District, and remove metrics related to Opportunity analysis. Then move the report and change the name to Summary Sales Performance by Sales District & Quarter. Note: After testing the report, the metrics Target Quota and Quota Achieved do not make sense in this scenario, because Sales Person is not present. This is because the relationship between Sales Person and Sales Office does not exist in the target schema (as compared with packaged components where there was a hierarchy relationship between Sales District and Sales Representative). Remove the metrics. 14 Revenue Distribution by Sales Region The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing Sales Region with Sales District. Then move the report and change the name. 15 Quarterly Revenue Trend by Sales Region The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing Sales Region with Sales District. Then move the report and change the name. 16 Quarterly Revenue & Closure Trend No action; Opportunity-related objects are not supported in the target schema. 17 Quarterly Revenue & Closure Trend by Sales Region The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing Sales Region with Sales District, and removing all Opportunity-related metrics. Then move the report and change the name. 88 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Order Packaged Object Action 18 All components required for the report exist in the destination project; however, because the relationship between Sales Person and Sales Office has been removed, the report meaning is changed. Quarterly Quota Performance by Sales District Replace Sales District with Sales Representative in the master project, then move the report to the destination project and change the name to Quarterly Quota Performance by Sales Person. 19 Quota Achievement by Quarter & Sales Organization The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by removing Sales Region. Then move the report and change its name. Note: After testing this report, the metrics Target Quota and Quota Achieved do not make sense in this report because they are not calculated at the Sales Office level. Remove Sales Office. 20 Competitive Activity by Quarter No action; Opportunity-related objects are not supported in the target schema. 21 Quarterly Competitive Win Rate Trend No action; Opportunity-related objects are not supported in the target schema. 22 Top 10 Companies by Deal Size - Quarter The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing the Deal Size metric with Revenue, and replace the Deals metric and the Opportunity metric with Orders. (The Rank filter was updated previously.) Then move the report and change its name to Top 10 Customer Groups by Deal Size. 23 Top 10 Deals by Quarter The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing the Deal Size metric with Revenue, and remove all Opportunity attributes. (The Rank filter was updated previously.) Then move the report and change its name to Top 10 Orders by Quarter. 24 Top 3 Deals by Quarter & Primary Competitor No action; Opportunity-related objects are not supported in the target schema. 25 Top 3 Deals by Quarter & Sales Region The report in the master project includes some objects that do not exist in the destination project. Update the definition in the master project by replacing the Deal Size metric with Revenue, remove all Opportunity attributes, and replace the attribute Sales Region with Sales District. (The Rank filter was updated previously.) Then move the report and change its name to Top 3 Deals by Quarter and Sales District. 26 Top 10 Lost Opportunities by Quarter No action; Opportunity-related objects are not supported in the target schema. 27 Top 3 Lost Opportunities by Quarter & Primary Competitor No action; Opportunity-related objects are not supported in the target schema. © 2015 MicroStrategy, Inc. Map the module 89 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 28 No action; Opportunity-related objects are not supported in the target schema. Top 3 Lost Opportunities by Quarter & Sales Region Note: Lead and Pipeline Analysis reports are not supported; no action. 6 Execute all reports to test the application objects and ensure that the results of your work in this procedure are correct. Map the module without Object Manager If you decide not to use MicroStrategy Object Manager to assist you in the mapping part of the porting process, you will: • Use MicroStrategy Architect and Developer to update all application objects to use only those schema objects supported in the target schema • Map schema object links to use the new schema In this mapping method, all changes are completed in the original project, using Architect and Developer. If you decide to use Object Manager, see Map the module with Object Manager, page 74. Update application objects without Object Manager This first procedure updates the definition of the application objects to use only those schema objects that are supported, based on your gap analysis completed earlier in this chapter. For gap analysis details, see Example: Identifying application objects, page 63. Be aware of the following: 90 Map the module • You must update application objects in a certain order, based on which application objects are used as building blocks for other application objects. For example, metrics must be removed from all reports before they can be deleted from the project. An object can be removed from the MicroStrategy metadata only if no dependents exist in the project. • Document in detail all actions taken during this procedure. © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 An example follows this procedure. To update application objects without Object Manager 1 Move reports based on the results from the gap analysis: • If all components of the application object are supported, no change is required. • If all underlying objects are not supported, remove underlying objects from the definition. • If an application object is not supported, delete it from the project. 2 Move metrics based on the results from the gap analysis: • If all components of the application object are supported, no change is required. • If all underlying objects are not supported, remove underlying objects from the definition. • If an application object is not supported, delete it from the project. 3 Move base formulas based on the results from the gap analysis: • If all components of the application object are supported, no change is required. • If all underlying objects are not supported, remove underlying objects from the definition. • If an application object is not supported, delete it from the project. 4 Move filters based on the results from the gap analysis: • If all components of the application object are supported, no change is required. • If all underlying objects are not supported, remove underlying objects from the definition. • If an application object is not supported, delete it from the project. 5 Move prompts based on the results from the gap analysis: • If all components of the application object are supported, no change is required. © 2015 MicroStrategy, Inc. Map the module 91 5 Porting the Analytics Modules Installation and Porting Guide • If all underlying objects are not supported, remove underlying objects from the definition. • If an application object is not supported, delete it from the project. 6 Execute all reports to test the application objects and ensure that the results of your work in this procedure are correct. Then follow the final mapping procedure, Update application objects without Object Manager, page 90. Example: Updating application objects without Object Manager This example summarizes the actions taken to implement application objects from the MicroStrategy Sales Force Analysis Module (SFAM) against the example data warehouse. For details on the gap analysis, see Example: Identifying application objects, page 63. 1 Reports: The following table shows the example actions taken to update the reports. Order Packaged Object Action Product Sales Analysis reports 1 Product Performance Summary by Quarter No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 2 Products with Increasing Sales by Sales District No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. Update the name to Products with Increasing Sales by Sales Office. 3 Products with Decreasing Sales by Sales District No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. Update the name to Products with Decreasing Sales by Sales Office. 4 Products with Increasing Quarterly Sales No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 5 Products with Decreasing Quarterly Sales No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 92 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Order Packaged Object Action 6 Top N Products Sold Quarter Revenue Trend No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 7 Top N Products Sold by Sales District Remove the Sales Region attribute and prompt from this report; the remaining components of the report are supported in the new target schema. Change the name to Top N Products Sold by Sales Office, to synchronize the report with the new attribute name for Sales District. 8 Quarter Product Contribution to Sales District Revenues Remove the Sales Region prompt from the report; the remaining components of the report are supported in the new target schema. 9 Quarterly Orders Trend by Product Group No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 10 Product Revenue Trend No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 11 Revenue Distribution by Product Group & Quarter No action; all components of this report are supported with the new target schema; once the underlying objects (attributes, metrics, and prompts) are updated, this report will work with the new schema. 12 Quarterly Closure Rate based on Product Delete the report from the project; it is not supported in the target schema. Change the name to use Sales Office. Sales Performance Analysis reports 13 Summary Sales Performance by Sales Region & Quarter Replace Sales Region with Sales District, and remove metrics related to Opportunity analysis and Target Quota. The other components of the report are supported in the new target schema.Then change the name to use Sales Office. 14 Revenue Distribution by Sales Region Replace Sales Region with Sales District. The other components of the report are supported in the new target schema. Then change the name to use Sales Office. 15 Quarterly Revenue Trend by Sales Region Replace Sales Region with Sales District. The other components of the report are supported in the new target schema. Then change the name to use Sales Office. 16 Quarterly Revenue & Closure Trend Delete the report from the project; it is not supported in the target schema. 17 Quarterly Revenue & Closure Trend by Sales Region Replace Sales Region with Sales District and remove all Opportunity metrics. The other components of the report are supported in the new target schema. Then change the name to use Sales Office. © 2015 MicroStrategy, Inc. Map the module 93 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 18 Quarterly Quota Performance by Sales District Replace Sales District with Sales Representative. The other components of the report are supported in the new target schema. Then change the name to use Sales Person. 19 Quota Achievement by Quarter & Sales Organization Remove Sales Region and all quota metrics in the report. The other components of the report are supported in the new target schema. 20 Competitive Activity by Quarter Delete the report from the project; it is not supported in the target schema. 21 Quarterly Competitive Win Rate Trend Delete the report from the project; it is not supported in the target schema. 22 Top 10 Companies by Deal Size - Quarter Remove all Opportunity metrics and replace the Deal Size metric with Revenue. The other components of the report are supported in the new target schema, but the filter requires changes to adapt it to the new schema. Change the report name to use Customer Group instead of Companies. 23 Top 10 Deals by Quarter Remove all Opportunity metrics and substitute Deal Size metric with Revenue. The other components of the report are supported in the new target schema, but the filter requires changes to adapt it to the new schema. Change the report name to use Orders instead of Deals. 24 Top 3 Deals by Quarter & Primary Competitor Delete the report from the project; it is not supported in the target schema. 25 Top 3 Deals by Quarter & Sales Region Remove all Opportunity attributes and substitute Deal Size metric with Revenue, and Sales Region with Sales District. The other components of the report are supported in the new target schema, but the filter requires changes to adapt it to the new schema. Change the report name to use Orders instead of Deals, and Sales Office instead of Sales Region. 26 Top 10 Lost Opportunities by Quarter Delete the report from the project; it is not supported in the target schema. 27 Top 3 Lost Opportunities by Quarter & Primary Competitor Delete the report from the project; it is not supported in the target schema. 28 Top 3 Lost Opportunities Delete the report from the project; it is not supported in the target by Quarter & Sales Region schema. Lead Analysis & Pipeline Analysis reports 29 All Lead Analysis reports Delete the report from the project; it is not supported in the target schema. 30 All Pipeline Analysis reports Delete the report from the project; it is not supported in the target schema. 94 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 2 Metrics: The following table shows the example actions taken to update the metrics. Order Packaged Object Action Compound metrics 1 Revenue by Sales Representative No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to Revenue by Sales Person. 2 Average Product Revenue by Order No action; all components are supported and will work with the new target schema once the underlying objects are updated. 3 % Opportunities Converted Delete from the project; not supported with the new target schema. 4 % Wins vs. Competitor Delete from the project; not supported with the new target schema. 5 % Lost vs. Competitor Delete from the project; not supported with the new target schema. 6 % Quota Achieved No action; all components are supported and will work with the new target schema once the underlying objects are updated. 7 % Quota Achieved (Previous Quarter) No action; all components are supported and will work with the new target schema once the underlying objects are updated. 8 % Revenue Change vs. Previous Quarter No action; all components are supported and will work with the new target schema once the underlying objects are updated. 9 % Contribution to Total Revenues Delete from the project; not supported with the new target schema. 10 % Conversion vs. Opportunity Size Delete from the project; not supported with the new target schema. 11 % Conversion vs. Weighted Delete from the project; not supported with the new target schema. Opportunity Size 12 % Contribution to Product Group Revenue No action; all components are supported and will work with the new target schema once the underlying objects are updated. 13 % Contribution to Quarter Sales District Revenue No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to % Contribution to Quarter Sales Office Revenue. Simple metrics with conditionality 14 Deals Delete from the project; not supported with the new target schema. 15 Deal Size Delete from the project; not supported with the new target schema. Because this is used in several filters, it cannot be deleted until the filters are updated. 16 Lost Deal Size Delete from the project; not supported with the new target schema. Because this is used in several filters, it cannot be deleted until the filters are updated. © 2015 MicroStrategy, Inc. Map the module 95 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 17 Opportunities with a Competitor Delete from the project; not supported with the new target schema. 18 Lost Opportunities vs. Competitor Delete from the project; not supported with the new target schema. 19 Wins vs. Competitors Delete from the project; not supported with the new target schema. Simple metrics with dimensionality 20 Revenue (Region Filtered) Delete from the project; not supported with the new target schema. 21 Revenue (Product Group) No action; all components are supported and will work with the new target schema once the underlying objects are updated. 22 Revenue (Sales District, Quarter) No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to Revenue (Sales Office, Quarter). Simple metrics with transformation 23 Revenue (Previous Quarter) No action; all components are supported and will work with the new target schema once the underlying objects are updated. 24 Target Quota (Previous Quarter) No action; all components are supported and will work with the new target schema once the underlying objects are updated. Simple metrics 25 Revenue No action; all components are supported and will work with the new target schema once the underlying objects are updated. 26 Target Quota No action; all components are supported and will work with the new target schema once the underlying objects are updated. 27 Orders No action; all components are supported and will work with the new target schema once the underlying objects are updated. 28 Orders containing Product No action; all components are supported and will work with the new target schema once the underlying objects are updated. 29 Opportunity Size Delete from the project; not supported with the new target schema. 30 Weighted Opportunity Size Delete from the project; not supported with the new target schema. 31 Opportunities Delete from the project; not supported with the new target schema. 32 Number of Sales Representatives No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to Number of Sales Persons. Note: Metrics used for Lead Analysis and Pipeline Analysis are not supported; delete them. 96 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 3 Base formulas: The following table shows the example actions taken to update the base formulas. Order Packaged Object Action 1 Sum of Lead Size Delete from the project; not supported with the new target schema. 2 Sum of Opportunity Size Delete from the project; not supported with the new target schema. 3 Sum of Weighted Opportunity Size Delete from the project; not supported with the new target schema. 4 Sum of Sales Representative Quota No action; all components are supported and will work with the new target schema once the underlying objects are updated. 5 Sum or Order Amount No action; all components are supported and will work with the new target schema once the underlying objects are updated. 6 Count of Leads Delete from the project; not supported with the new target schema. 7 Count of Opportunities Delete from the project; not supported with the new target schema. 8 Count of Orders No action; all components are supported and will work with the new target schema once the underlying objects are updated. 9 Count of Sales Representatives No action; all components are supported and will work with the new target schema once the underlying objects are updated. 4 Filters: The following table shows the example actions taken to update the filters. Order Packaged Object Action 1 Rank of Top 10 Companies by Deal Size Change the filter to use Revenue instead of Deal Size for the ranking. Change the filter name to use Revenue. Note: This filter must be updated before the Deal Size metric is removed from the project. 2 Rank of Top Deals by Deal Size Change the filter to use Revenue instead of Deal Size for the ranking. Change the filter name to use Revenue. Note: This filter must be updated before the Deal Size metric is removed from the project. 3 Rank of Top 10 Lost Opportunities by Lost Deal Size Delete from the project; not supported with the new target schema. 4 Rank of Top 3 Deals by Deal Size, break by Primary Competitor Delete from the project; not supported with the new target schema. © 2015 MicroStrategy, Inc. Map the module 97 5 Porting the Analytics Modules Installation and Porting Guide Order Packaged Object Action 5 Rank of Top 3 Deals by Deal Size, break by Sales Region Change the filter to use Revenue instead of Deal Size for the ranking. Change the filter name to use Revenue. Note: This filter must be updated before the Deal Size metric is removed from the project. 6 Rank of Top Lost Opportunities by Lost Deal Size, break by Sales Region Delete from the project; not supported with the new target schema. 7 Rank Top N Products by Revenue No action; all components are supported and will work with the new target schema once the underlying objects are updated. 8 All filters in Folder “Filter for Conditional Metrics” Delete from the project; not supported with the new target schema. 5 Prompts: The following table shows the example actions taken to update the prompts. Order Packaged Object Action 1 Account List No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to Customer List. 2 Company List No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to Customer Group Account. 3 Lead Characteristics Delete from the project; not supported with the new target schema. 4 Lead Source - Multiple Selections Delete from the project; not supported with the new target schema. 5 Product Group - Multiple Selections No action; all components are supported and will work with the new target schema once the underlying objects are updated. 6 Quarter - Multiple Selections No action; all components are supported and will work with the new target schema once the underlying objects are updated. 7 Quarter - One Selection Only No action; all components are supported and will work with the new target schema once the underlying objects are updated. 8 Sales District - Multiple Selections No action; all components are supported and will work with the new target schema once the underlying objects are updated.Change the name to Sales Office. 98 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules 5 Order Packaged Object Action 9 Sales District - One Selection Only No action; all components are supported and will work with the new target schema once the underlying objects are updated. Change the name to Sales Office. 10 Sales Region - Multiple Selections Delete from the project; not supported with the new target schema. 11 Sales Region - One Selection Only Delete from the project; not supported with the new target schema. 12 Time - Year to Month Hierarchy No action; all components are supported and will work with the new target schema once the underlying objects are updated. 13 Year - One Selection Only No action; all components are supported and will work with the new target schema once the underlying objects are updated. 6 Execute all reports to test the application objects and ensure that the results of your work in this procedure are correct. Map schema objects This second procedure maps schema object links to the target schema, based on results from your gap analysis at the beginning of this chapter. For details on the gap analysis, see Perform a gap analysis, page 48. all actions taken during this mapping process to allow you Document to backtrack if necessary. An example follows this procedure. To map schema objects 1 Map hierarchies based on the results from your gap analysis: • If a hierarchy is supported in the target schema, proceed with mapping. Actions can include changing the name, removing or adding attributes, and so on. • If a hierarchy is not supported, remove it from the project. can only be removed from the MicroStrategy metadata if no Objects dependents exist in the project. The order for removing objects throughout this procedure is determined based on that principle. © 2015 MicroStrategy, Inc. Map the module 99 5 Porting the Analytics Modules Installation and Porting Guide 2 Map transformations based on the results from your gap analysis: • If a transformation is supported in the target schema, proceed with mapping. Actions can include changing the name, updating the definition to the target schema tables and columns, and so on. • If a transformation is not supported, remove it from the project. 3 Map facts based on the results from your gap analysis: • If a fact is supported in the target schema, proceed with mapping. Actions can include changing the fact name, updating facts expressions to point to the target schema tables and columns, removing or adding fact expressions, and so on. • If a fact is not supported, remove it from the project. 4 Map attributes based on the results from your gap analysis: • Start with the lowest attributes in each hierarchy and proceed sequentially with all parents. • If an attribute is supported in the target schema, proceed with mapping. Actions can include changing the attribute name; updating forms to point to the target schema tables and columns; adding or removing forms; updating, removing or adding relationships; and so on. • If an attribute is not supported, remove it from the project. 5 Finally, after all schema objects have been mapped, remove all tables that are not used. The project schema must be updated to reflect all of the changes. Example: Mapping schema objects This example summarizes the actions taken to map packaged schema objects from the MicroStrategy Sales Force Analysis Module (SFAM) to the example target data warehouse. 1 To update the connection to the target schema, define the database connection to the target data warehouse. example, some tables from the default physical schema are Inused,thissuch as F_SALES_REP_QTA. Tables must be created before this step is taken; the Erwin file containing the default physical schema can be used to generate scripts for these tables. 100 Map the module © 2015 MicroStrategy, Inc. Installation and Porting Guide 5 Porting the Analytics Modules 2 Update the warehouse catalog, selecting the relevant tables based on the gap analysis between physical schemas. For more details, see Example: Mapping physical schemas, page 52. 3 Map all schema objects in the destination project: • Hierarchies: The following table summarizes the example actions taken to map SFAM hierarchies. Order Packaged Object Action 1 Time - Year to Month No changes are required. 2 Product No changes are required. 3 Time No changes are required. 4 Sales Organization Delete Sales District and Sales Region from this hierarchy. • Transformations: No changes are required for transformations because all base attributes and tables are the same. • Facts: The following table summarizes the example actions taken to map the SFAM facts to the example target data warehouse. Order Packaged Object Action 1 Order Amount Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 2 Sales Representative Quota Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 3 Index for Orders Counts Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 4 Opportunity Size Delete the fact from the MicroStrategy project. 5 Weighted Opportunity Size Delete the fact from the MicroStrategy project. 6 Lead Size Delete the fact from the MicroStrategy project. 7 Index for Lead Counts Delete the fact from the MicroStrategy project. 8 Index for Opportunity Counts Delete the fact from the MicroStrategy project. © 2015 MicroStrategy, Inc. Map the module 101 5 Porting the Analytics Modules • Installation and Porting Guide Attributes: The following table summarizes the example actions taken to map SFAM attributes to the example target data warehouse. of the folders require name changes based on new attribute Some names. For example, change the name of the Account folder to Customer. Order Packaged Object 1 Account Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 2 Company Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 3 Industry Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 4 Lead Delete the attribute from the MicroStrategy project. 5 Lead Source Delete the attribute from the MicroStrategy project. 6 Lead Status Delete the attribute from the MicroStrategy project. 7 Lead Type Delete the attribute from the MicroStrategy project. 8 Opportunity Delete the attribute from the MicroStrategy project. 9 Current Opportunity Status Delete the attribute from the MicroStrategy project. 10 Opportunity Open Date Delete the attribute from the MicroStrategy project. 11 Opportunity Close Date Delete the attribute from the MicroStrategy project. 12 Primary Competitor Delete the attribute from the MicroStrategy project. 13 Opportunity Status Delete the attribute from the MicroStrategy project. 14 Order Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 15 Discount Indicator Delete the attribute from the MicroStrategy project. 16 Product Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 17 Product Group Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 102 Map the module Action © 2015 MicroStrategy, Inc. Installation and Porting Guide Porting the Analytics Modules Packaged Object Action 18 Sales Representative Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 19 Sales District Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 20 Sales Region Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 21 Date Delete the attribute from the MicroStrategy project. 22 Month Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 23 Quarter Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. 24 Year Proceed with changes based on the gap analysis; see Example: Mapping the logical data model, page 56 for details. Order 5 4 Finally, after all schema objects have been mapped, remove all tables that are not used. The project schema must be updated to reflect all of the changes. Customize and extend the module When you customize or extend any of the existing Analytics Modules, you are adding data elements that are specific to your company. For typical customization scenarios, ideas and suggestions, and specific information on how to customize and extend an Analysis Module, see Customize and extend the Analytics Modules, page 34. © 2015 MicroStrategy, Inc. Customize and extend the module 103 5 Porting the Analytics Modules 104 Customize and extend the module Installation and Porting Guide © 2015 MicroStrategy, Inc. 6 6. CREATING PORTABLE ANALYTICAL APPLICATIONS Introduction This chapter presents the MicroStrategy best practices for designing and building enterprise-class analytical applications using the portability paradigm. Portability and the MicroStrategy portability methodology are explained fully in Portability methodology, page 43. MicroStrategy has developed the content in this chapter based on experience developing the MicroStrategy Analytics Modules. This chapter describes how to build analytical applications using the portability paradigm and helps you understand how the MicroStrategy Analytics Modules were designed and developed. For specific examples and more details, see each Analysis Module’s individual reference guide and their related metadata components in your MicroStrategy software. Architecture of portable analytical applications The portability paradigm revolves around the concept of metadata-only applications. The MicroStrategy metadata repository allows the logical data © 2015 MicroStrategy, Inc. Architecture of portable analytical applications 105 6 Creating Portable Analytical Applications Installation and Porting Guide model to be defined independently from the physical schema. This means that the business representation of the data is separate from the data’s storage structure. For a given logical data model, MicroStrategy supports a large number of physical schemas. The diagram below reflects the independence of the Analytics Modules, with their analytics library and logical data model, from the physical schema. Each major element’s role in the architecture is also described. • Logical Data Model: This is the cornerstone of the architecture. It is the representation of the analytical domain in the MicroStrategy metadata. The logical data model is defined purely in terms of MicroStrategy schema objects such as facts (measures) and attributes (analysis concepts). The logical data model definition should not depend on any set physical data structures. • Analytics Library: The reports, or analytics, for a given analytical domain are built on top of the logical data model. The reports consist of purely MicroStrategy application objects such as metrics, reports, filters, and so on. Reports are organized within a given domain into several analysis areas. Definitions of the analytic objects should not depend on any set physical data structures but should be based entirely on the logical data model objects. • Physical Schema: (Optional) The physical schema that comes with each Analysis Module describes the data warehouse that links to the logical data model, and ultimately holds the data. It is used to build and test the logical data model, as well as to store data for evaluation purposes. Although the Analytics Modules each come with a default physical schema, you can use the Modules’ portability feature to substitute an existing physical schema. The physical schemas that come with the 106 Architecture of portable analytical applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications Modules are an optional part of the final components delivered as an analytical application. Analytics Modules versions Each MicroStrategy Analysis Module includes two MicroStrategy projects, an Evaluation project and a Production project, as described in the table below. You can use this concept for your own analytical applications. MicroStrategy Project Description Evaluation version of a given Analysis Module • This project allows you to evaluate the Analytics Modules reports without setting up a data warehouse. • The project metadata repository and warehouse are built using Microsoft Access 2000. • The project is included in the evaluation CD of the MicroStrategy products. Installation automatically configures the project in a direct connection (in 2-tier mode). Note: The Access database presents some limitations for supporting count distinct and outer join, because some of the reports in the evaluation version were specifically modified to support the Access data warehouse. Therefore, this project cannot be used directly against any warehouse other than Access 2000. Production version of a given Analysis Module • This project contains a production-ready metadata repository, and logical data model objects are mapped to a default physical schema. • The project metadata repository is built using Access 2000. • The project is configured for an Oracle database, but can be used to access any other major relational database such as DB2 or SQL Server. See the MicroStrategy readme file for details on supported databases. Best practices for building portable applications This section outlines the best practices for designing and developing analytical applications using the portability paradigm. It presents development project guidelines with procedures and a development plan. The development process starts with selecting an analytical domain (the business analysis area) and defining the basic analysis requirements. Then © 2015 MicroStrategy, Inc. Best practices for building portable applications 107 6 Creating Portable Analytical Applications Installation and Porting Guide developers can use the best practices outlined in this section to design and build the analytical application. Analytical Domain Development Process Package Business Documentation Metadata Content Using Portability Rules & Recommendations Design and development premises Developing a portable analytical application is not very different from developing a typical business intelligence application. However, the portability paradigm and architecture introduce a number of specific design and development premises: • The application must model a well-known and standard business problem area. The MicroStrategy development process ensures that most data elements in the application have a high probability of existing in the target data warehouse. • The application must be divided into several modular analysis areas, each of them aligned with sub-areas of the application business model. The MicroStrategy development process limits the impact on an analysis area if certain data elements do not exist in the data warehouse. • The logical data model must be defined to support typical analysis types. The MicroStrategy development process minimizes changes required to customize the application to each company’s requirements. • The logical data model must be tested against existing physical schemas (data warehouses) in the domain area, using different database platforms. The MicroStrategy development process ensures the application’s independence from a specific physical schema and database platform. • The development process must accomplish the dual goal of developing the application using MicroStrategy technology and developing the required business and technical documentation. The MicroStrategy 108 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide Creating Portable Analytical Applications 6 development process builds documentation to support implementation and later customization and extension of the packaged components. Documentation is a key part of the analytical application package. Development process overview Based on the premises listed above and the application deliverables, MicroStrategy uses the following general process to build the analytics modules: 1 Define the analytical domain. 2 Design and develop the logical data model, ensuring that it meets the analytical and portability requirements. 3 Define the report library. 4 Develop and test reports, including the packaged application components. Throughout the development process, each phase includes creating important technical or business documentation. The documentation is used both for specifications for the next step of the development process and as the basis of the final business and technical documentation delivered with the application. The development process is broken down into four main phases. Each phase is, in turn, broken down into several procedures. Follow each phase and its procedures in the order that they appear below. Phase I: Define the analytical domain In this first phase, you follow the procedures as they appear below, to: • Select the analytical domain (business analysis area) • Define the analytical domain by identifying the analysis requirements that specify the application’s logical data model • Review the domain specifications that result from your work in the previous two procedures © 2015 MicroStrategy, Inc. Best practices for building portable applications 109 6 Creating Portable Analytical Applications Installation and Porting Guide To complete this phase successfully, make sure you have access to the following: Knowledge of the analytical domain area. Knowledge of the criteria necessary to build portable applications. Experience defining and building analytical applications. Skills Experience with overall application architecture and design, including the logical data model, physical schema, and report specifications. This role can be filled by experts in the domain, such as consultants with experience implementing this type of application. Experience with defining the business requirements. Select the analytical domain In this first Phase I procedure, you select an analytical domain and check to ensure it meets the criteria required for portable applications. procedure should be performed by a person responsible for This defining the business requirements. To select the analytical domain 1 Apply the criteria listed in this step to determine an appropriate analytical domain. Based on the requirements for portability, not all analytical domains can be used to build this type of analytical application. Ensure you select your analytical domain with the following criteria in mind: Criteria 1: The analytical domain must represent one of the following: • A standard business process, such as sales as defined by Miller-Heiman • A business problem area, such as customer retention • A functional area, such as marketing or service • A standard data source type, such as Web logs or SAP ERP By restricting the application to a standard domain, you will ensure that the solution applies to a wide number of existing data warehouses and 110 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide Creating Portable Analytical Applications 6 that it takes advantage of standard processes, best practices, and standard data that apply to the domain area. are developing packaged analytical applications, complete Ifanyyoupreliminary market research necessary to decide on a given analytical domain. Criteria 2: The analytical domain’s business concepts must be standard. For example, sales analysis is defined by standard, generic concepts such as lead, opportunity, revenue, cost, order, product, and sales organization. To identify a data element as standard, review different sources for the analysis area. These sources can include data warehouses, operational systems, logs, and so on. If the data element (for example, Product) is always present in most or all data sources, you can consider Product as a standard data element. However, if you identify a data element, such as Product Family, that is not always present in data sources, do not consider it a standard data element and do not include it in your application. This criteria determines the scope of the application, since standard business concepts define the analytical domain. It also ensures that those data elements will exist in the majority of the data warehouses for that domain. 2 Taking the criteria above into consideration, select the analytical domain that your application will address. 3 Evaluate your chosen analytical domain to assess the feasibility of building the application. Consider the following characteristics: • Size of the analysis area, measured as the number of standard data elements, process complexity, potential number of different report types, and so on. As the analysis domain becomes bigger, development becomes more complicated and the portability paradigm becomes more difficult to accomplish. • In-house domain expertise. This is the knowledge required to define and build the application. This knowledge must exist internally. © 2015 MicroStrategy, Inc. Best practices for building portable applications 111 6 Creating Portable Analytical Applications • Installation and Porting Guide Stability of the business rules associated with the domain area, due to industry/regulatory changes. For example, in a financial analysis application, the accounting rules can change frequently. are developing packaged analytical applications, you should Ifalsoyouevaluate the following: • The domain’s applicability across multiple verticals/industries. Be sure the application can be reused without major changes in existing data warehouses, independent of the industry. • Applicability across a sizeable geographic market. For example, a general ledger application supports American requirements, but not those required in European countries. 4 Document the information you gather from the steps above. Your documentation should include: • A description of the analysis domain • Key business processes and problem areas • Typical data sources and data elements for the domain This information will define the general scope of the analytical application and will identify the initial analysis requirements. Define the analytical domain specifications In this second Phase I procedure, you define the business analysis specifications to build the portable application. procedure should be performed by a person responsible for This defining the business requirements. To define the analytical domain specifications 1 Define and document the data elements that make up the analytical domain. Begin by documenting a business process, including: • An explanation of the business process and main entities; for example, in a sales analysis, the different stages in the sales cycle, such as lead, qualification, opportunity, deal, order, and revenue • Business process diagrams 112 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide • 6 Creating Portable Analytical Applications Analytical needs, including typical usage scenarios and user roles 2 Document a list of business concepts, which describes all key concepts such as: • Business attributes (business-oriented concepts) • Facts • Metrics (measures) • The relationships between the previous items; for example, how each fact relates to the different business attributes and how they are calculated 3 Define and document the analytical domain’s reporting areas. These are the logical analysis areas into which the domain can be broken. Focus on defining independent analysis areas to limit the impact of non-existent data elements in a future target data warehouse. Be sure this documentation includes: • A description of each reporting area within the analytical domain (the analytical scope) • For each reporting area, an explanation of the key analysis challenges, a list of the relevant attributes and facts, user analysis requirements, and how this reporting area fits with other analysis areas • A list and description of the key reports and types of questions they answer for each reporting area, with a focus on defining which and how concepts are analyzed together 4 Document a glossary of terms, including detailed descriptions and examples. 5 Combine all documented content from the first procedure above, with the content from this procedure to create your Analytical Domain Specifications document. See any of the MicroStrategy Analytics Modules reference guides for examples of these different types of content. © 2015 MicroStrategy, Inc. Best practices for building portable applications 113 6 Creating Portable Analytical Applications Installation and Porting Guide Review the analytical domain specifications In this third Phase I procedure, you discuss the analytical domain with external experts and the development team. You also identify the necessary quality assurance criteria for the application. procedure should be performed by a person responsible for This overall application architecture and design, working with other management, development, and testing team members, as well as domain experts, as appropriate. To review the analytical domain specifications and define quality assurance criteria 1 Using the Analytical Domain Specifications document from the previous procedure, review the domain with external domain experts and your development team, or the project team in charge of developing the analytical application. Be sure discussions include: • Identifying potential issues and challenges that can appear when you define the logical data model that supports the application • Identifying the criteria necessary to ensure logical data model quality best strategy to ensure logical data model quality is to build The the key reports that identify the typical analysis types and relationships between business concepts. Success reproducing the key reports assures the robustness of the logical data model. 2 Update your Analytical Domain Specifications document to reflect the reviews above and any revisions necessary due to feedback, corrections, and potential issues. 3 Create a document of the list of key reports. This document will eventually summarize the criteria that assure the logical data model meets the analytical domain requirements. It will be finalized in a subsequent procedure, when the testing plan for the logical data model is defined. 114 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications Phase II: Develop the logical data model In this second phase, you follow the procedures as they appear below, to: • Create the logical data model • Create the physical schema • Define an assurance/testing plan • Create a MicroStrategy project and execute testing To complete this phase successfully, make sure you have access to the following: Knowledge of the analytical domain area, typical logical data models used to model the domain, and typical physical schemas used. Knowledge of the criteria necessary to build portable applications. Extensive experience building analytical applications, as well as solid logical data and physical modeling skills. Working experience creating analytical solutions using MicroStrategy technology, including creating reports, metrics, filters, and other MicroStrategy objects. Skills Experience with overall application architecture and design, including the logical data model, physical schema, and report specifications. This role can be filled by experts in the domain, such as consultants with experience implementing this type of application, or expert users in the analysis domain. Experience with defining business requirements. Experience with application development using MicroStrategy technology. Experience performing testing tasks. rules that appear in each of the Phase II procedures below are a The collection of general design strategies. Additional rules and recommendations apply when defining and building logical data model objects and reports for portability using MicroStrategy tools and technology. For more details see Portability rules and recommendations, page 131. Create the logical data model In this first Phase II procedure, you define the logical data model on which the application will be built, by following the logical data model design rules listed within the procedure. This is a key procedure in the design and © 2015 MicroStrategy, Inc. Best practices for building portable applications 115 6 Creating Portable Analytical Applications Installation and Porting Guide development process, since all further work depends on a robust logical data model that supports all the requirements of the analytical domain. design rules listed in this procedure are general design strategies. The When you design a logical data model for portability and are using MicroStrategy technology, additional design rules apply. For detailed rules for each object, see Portability rules and recommendations at the end of this chapter. procedure should be performed by a person responsible for This overall application architecture and design, working with developers and domain experts. To create the logical data model 1 Using the Analytical Domain Specifications document you created in Phase I: Define the analytical domain, page 109, identify the data elements that define the core of the analytical domain and that are required to provide the core analysis. This step helps you adhere to the following rule: Rule 1: Use only objects (data elements) that are standard across the domain. • Logical data model elements must be based on viable source system data. For example, sales analysis must include the data elements that usually exist in a standard source system, such as Account, Item, and Order. • The logical data model must incorporate only the basic facts captured by a standard organization. For example, avoid adding a fact such as Profit because it could be a precalculated value or dynamically calculated as “Revenue less Cost.” • Avoid elements that are industry- or country-specific, as well as those that may require customization. For example, some levels of the Product hierarchy can be different for each industry and/or client. 2 Using the Analytical Domain Specifications document, identify and document the key analysis types for the analytical domain. This step helps you adhere to the following rule: 116 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications Rule 2: The logical data model must be designed to support generic types of analysis, not fixed reports. • For example, you might define a customer analysis logical data model to support certain analyses such as customer count by geographic and/or demographic characteristics. • A logical data model based on fixed reports is more rigid and harder to customize further. 3 Using the examples and tips listed in this step, identify and document 30-40 data elements (attributes and facts) to be included in the model. This step helps you adhere to the following rule: Rule 3: Limit the logical data model to a manageable number of data elements and relationships. • Limiting the number of data elements and relationships helps keep the model simple. • By limiting the number to 30-40, you maximize the probability that the majority of the data elements are present in the target data warehouse. • Use simple (one-to-many) parent-child relationships. This ensures the model is less dependent on a specific physical schema. 4 Identify and document how different areas of the logical data model relate to each other. This includes identifying fact-attribute relationships and whether different facts exist at the same level of analysis. This step helps you adhere to the following rule: Rule 4: Use a modular approach. • A modular approach ensures the different analysis areas depend on limited portions of the logical data model. If some data elements are missing from the target data warehouse, modularity limits the impact to only the areas using those data elements. are developing packaged analytical applications, you should Ifalsoyouidentify areas that can be customized and extended by customers. This allows you to provide guidance to clients when they customize and extend the application. 5 Identify and document any elements that depend on specific physical structures. This step helps you adhere to the following rule: © 2015 MicroStrategy, Inc. Best practices for building portable applications 117 6 Creating Portable Analytical Applications Installation and Porting Guide Rule 5: The logical data model should not depend on a fixed physical data structure. • For example, avoid many-to-many relationships because they require a specific physical schema. • This rule implies that the logical data model is supported by different types of physical schemas. This will be discussed further in the next procedure, Create the physical schema, page 118. 6 Create a graphical view of your logical data model. 7 Combine all your documentation from this procedure. Make sure it includes technical and business content explaining each of the model objects with a description, relationships, data examples, and loading strategies. any of the MicroStrategy Analytics Modules reference guides See for examples of this documentation. 8 Review your work products from this procedure with appropriate team members, and incorporate any feedback. 9 If applicable, incorporate any changes or additions to the Analytical Domain Specifications document you created in Phase I: Define the analytical domain, page 109 that may be required due to additions or corrections that occurred during this procedure. Be sure to track the changes in a revision table or similar method. Create the physical schema In this second Phase II procedure, you define a physical schema to support the analytical application development. This physical schema will be used to develop all MicroStrategy objects, such as attributes, facts, metrics, reports, and so on. The physical schema will be populated with test data for development, and with demonstration (demo) data to create a demo or evaluation version of the analytical application. Most of the physical schema rules that appear in this procedure exist to facilitate a gap analysis between the default physical schema (the one you are creating with this procedure) and any future target physical schema (a data warehouse to which you will port the logical data model later). These rules 118 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications also facilitate the mapping process that occurs during the porting process. For more details on porting, see Portability methodology, page 43. design rules listed in this procedure are general design strategies. The When you design a physical schema for portability and are using MicroStrategy technology, additional design rules apply. For detailed rules on designing a physical schema, see Portability rules and recommendations, page 131. procedure should be performed by a person responsible for This overall application architecture and design, working with developers and testers. To create the physical schema 1 Using the logical data model and related documentation you created in the procedure above, design the physical schema using a star or snowflake pattern. This step helps you adhere to the following rule: Rule 1: The physical schema must be designed to be simple and efficient. • Star and snowflake schemas are more common database schemas for analysis. • While different physical schemas can support the same logical data model, using the simplest one requires the fewest tables, joins, and columns. • Minimize the number of tables, especially lookup and relationship tables. For example, the attributes Product and Product Group have a one-to-many relationship. This can be implemented with two lookup tables and a relationship table, or with a single lookup table that includes all the attribute columns. Using a single lookup table minimizes the number of tables, and the logical data model remains flexible enough to use an existing data warehouse that has tree tables. • Avoid consolidated models and recursive hierarchies. They require a specific physical schema. • Avoid using any views in the schema design. Views can be dependent on the database engine. If they are required, use them when the target schema is mapped to the application during the porting process; see Map the module, page 73 for more details. © 2015 MicroStrategy, Inc. Best practices for building portable applications 119 6 Creating Portable Analytical Applications Installation and Porting Guide 2 Establish a naming convention to facilitate a gap analysis. For more information on a gap analysis and porting, see Port an Analysis Module, page 48. This step helps you adhere to the following rule: Rule 2: Define a naming convention for all schema objects. • Use prefixes to indicate specific table types. For example, use F_ to denote fact tables, L_ for lookup tables, A_ for aggregate tables, and so on. • Schema object names should be self-explanatory. For example, the CUST_ID column identifies the ID assigned to a customer. Similarly, F_CUST_TXN_HIST provides historical tracking of customer transactions. • Limit object names to 18 characters since some DB2 databases have a limit of 18 characters. • Use suffixes to identify column types. For example, use _ID and _DESC for identifier and descriptor fields, respectively. • Ensure that a data element has the same column name across all tables. For example, a customer numeric identifier (CUST_ID) can exist in several tables. In all the tables, the column name must be CUST_ID. 3 To support portability across database engines, check to ensure your physical model avoids specific database parameters. This step helps you adhere to the following rule: Rule 3: The physical model should be defined to avoid any specific database platform parameters. • Use standard data types across database platforms. For example, use VARCHAR2(30). • Use the same data type for all columns representing the same data element. For example, the CUST_ID column should have the same data type in all tables where it exists. • Use the same data type for all data elements containing similar data. For example, define all description columns as VARCHAR2(50). 4 Document the following items to facilitate mapping the application to a target physical schema: • Naming conventions, standard data types, and so on 120 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications • Any deviation from the rules listed in this procedure, including an explanation of why the deviation occurred • Loading procedures for each of the physical schema tables 5 Make sure your physical schema adheres to the final two rules: Rule 4: The physical schema will not include any query performance optimization. Optimization is addressed during implementation, to account for specific client requirements and needs of the physical schema. Rule 5: Document primary keys based on the logical data model relationships, although they are not required during the definition of the physical schema. The logical data model, including attributes, relationships, and facts, determines which keys define the primary key for each physical schema table. 6 Review the physical schema with the appropriate individuals to ensure quality. Incorporate any feedback into the model where appropriate. can also modify and update the logical data model to fit with You these design rules or to address issues not previously considered. Be sure to track any changes made. 7 Using the information you have documented in this procedure, create: • A physical schema in Erwin format • A data dictionary and loading requirements to populate data structures • A mapping between the logical data model and the physical schema Define an assurance/testing plan In this third Phase II procedure, you determine the quality criteria that will ensure the logical data model supports the requirements of the analytical domain, and that the application is portable. procedure should be performed by a person responsible for This overall application architecture and design, working with developers and testers. © 2015 MicroStrategy, Inc. Best practices for building portable applications 121 6 Creating Portable Analytical Applications Installation and Porting Guide To define an assurance/testing plan 1 Using the Analytical Domain Specifications document created above, as well as the logical data model and physical schema also created above, identify the key reports that define the analytical domain. 2 Based on the key reports, create data scenarios for testing purposes. Be sure to include expected results. 3 Create a Test Plan document to ensure the logical data model can support different physical schema variations. This can include developing a few variations of your default physical schema. 4 Once your Test Plan is created, review it with appropriate individuals. Incorporate any feedback into the test plan where appropriate. In your review, be sure the Test Plan includes: • Report specifications and expected results based on your test data set • Data scenarios and a plan to generate the data to populate the default physical schema • A plan to map the MicroStrategy project to several physical schemas Create a project and execute testing In this last Phase II procedure, you develop and test a MicroStrategy project to ensure the logical data model meets requirements. This procedure should be performed by developers and testers. To create a project and execute testing 1 Using the logical data model and physical schema documentation you created, as well as the Test Plan you created in the procedure above with its list of key reports and test data, create the MicroStrategy schema objects that represent the logical data model. Portability rules and recommendations, page 131, for See important rules on building MicroStrategy objects for portability. to your MicroStrategy documentation for basic information Refer on creating a MicroStrategy project and objects. 122 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide Creating Portable Analytical Applications 6 2 Link the newly created schema objects to your default physical schema. 3 Create the reports you have identified and test them to ensure the data results are correct, the generated SQL is optimal and uses the appropriate tables, and so on. 4 Map the MicroStrategy project to different physical schemas to ensure that it supports other physical schema variations. See Porting the Analytics Modules, page 41, for details on mapping a logical data model to a different physical schema. 5 Review the results of your testing from the steps above, and identify and complete any fixes necessary to the MicroStrategy project. to update the Analytical Domain Specifications document, Bethesure logical data model and physical schema documentation, the Test Plan, and any other related documentation. Track any changes made to each individual document. Once you have completed your review and made any updates, you have confirmed the quality of your MicroStrategy project, its logical data model, and its related set of reports. You will reuse this project in the next two phases to build the final report library. Phase III: Define the report library In this third phase, you follow the procedures as they appear below to define the reports library. The procedures are: • Define reports specifications • Review reports specifications and defining testing criteria © 2015 MicroStrategy, Inc. Best practices for building portable applications 123 6 Creating Portable Analytical Applications Installation and Porting Guide To complete this phase successfully, make sure you have access to the following: Knowledge of the analytical domain area and the best analytical practices in that area. Working experience creating reports, metrics, filters, and other MicroStrategy objects. Experience with overall application architecture and design, including the logical data model, physical schema, and report specifications. Skills This role can be filled by experts in the domain, such as consultants with experience implementing this type of application, or expert users in the analysis domain. Experience with defining business requirements. Experience with application development using MicroStrategy technology. Experience performing testing tasks. Define the reports library In this first Phase III procedure, you define a library with 30 to 50 reports that address the key analytical requirements for your analytical domain. design rules listed in this procedure are general design strategies. The When you design a report library for portability using MicroStrategy technology, additional design rules apply. See Portability rules and recommendations, page 131 for detailed rules for designing reports. procedure should be completed by a person responsible for This overall application architecture and design and a person responsible for gathering business requirements. It can include input from developers. To define the reports library 1 Research the analytical domain and identify the reports that need to be developed. This step should adhere to the following rule: Rule 1: The report library should be defined within the boundaries of the given logical data model. only objects and relationships that exist in the model. Do not Use modify a tested model to support new report requirements. Changes can impact the integrity and robustness of the model. If 124 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications new reports require changes, move back to Phase II: Develop the logical data model, page 115 and proceed again from that point. 2 Define a set of 30 to 50 reports that focus on the best analytical practices for your analytical domain. This step helps you adhere to the following rule: Rule 2: The application should provide 30 to 50 reports. This set of reports will include: • Key reports defined in the procedures completed above • Additional reports that use MicroStrategy advanced analytical capabilities such as ranks, contribution, transformations, and so on; see the MicroStrategy Advanced Reporting Guide for details on advanced reporting features sure the reports do not rely on any physical schema Make structure. The design rules listed in this procedure are general design strategies. When you design reports for portability and are using MicroStrategy technology, additional design rules apply. See Portability rules and recommendations, page 131 for detailed rules for designing a report. This step provides a core group of reports to address key business questions in the analytical domain. They can also be used as templates to create additional reports later. 3 Arrange your reports into groups that reflect business problem areas. This step helps you adhere to the following rule: Rule 3: The analytical library should be organized using analysis areas. • Make sure the analysis areas are aligned with specific problem areas, so that each group of reports consists of a unique report collection. For example, customer analysis is organized into analysis areas such as customer acquisition, customer retention, and customer attrition. • Make sure each analysis area uses a different part of the logical data model, so reports do not overlap. This limits the impact on the porting process later, if data elements are missing from the target data warehouse. 4 For each report identified in the steps above, write a definition that includes: • Report display (grid/graph) © 2015 MicroStrategy, Inc. Best practices for building portable applications 125 6 Creating Portable Analytical Applications Installation and Porting Guide • Report formatting • Report filter conditions • Any other report definitions that are appropriate any of the MicroStrategy Analytics Modules reference guides See for examples of the types of report definitions to be documented. 5 Identify all the objects required to build each report, such as metrics and filters. 6 Using the information gathered in this procedure, as well as the Analytical Domain Specifications document, the logical data model and physical schema documentation, and the MicroStrategy project created in the procedures above, create a Report Specifications document. The Report Specifications document should contain the following information for each report: • A description of each report’s business value, key performance indicators (KPIs), and usage scenarios • The layout and formatting for each report • The filter conditions applied to each report • Typical drilling scenarios for each report, where applicable • The definition of all objects required to build the reports, such as metrics, custom groups, filters, attributes, and so on any of the MicroStrategy Analytics Modules reference guides See for examples of this documentation. Review report specifications and define testing criteria In this last Phase III procedure, you review the report specifications you created in the procedure above, and you define the report testing criteria. procedure should be completed by developers and testers. It can This include input from management, a person responsible for overall application architecture and design, and/or other experts in the analytical domain area. 126 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications To review reports specifications and define testing criteria 1 Using the Reports Specifications you created in the previous procedure, review each report with experts in the analytical domain. 2 Define criteria to test each report. Document your criteria in the Reports Specifications document, and be sure to track the update to the document. Portability rules and recommendations, page 131 for special See object design rules for portability. These rules can also inform your report testing scenarios. 3 Define and document a real scenario for data generation to address testing and demonstration (demo) needs. Your documentation should include: • A data generation plan • Your data scenarios for testing and demo needs Phase IV: Develop and test the reports In this fourth (and final) phase, you follow the procedures as they appear below to create and test the reports for your analytical application. The procedures are: • Develop the reports • Test the reports • Package the application © 2015 MicroStrategy, Inc. Best practices for building portable applications 127 6 Creating Portable Analytical Applications Installation and Porting Guide To complete this phase successfully, make sure you have access to the following: Knowledge of the analytical domain, logical data model, physical schema, reports library, and report specifications. Working experience creating reports, metrics, filters, and other MicroStrategy objects. Experience building and documenting analytical applications. Working experience developing technical documentation. Skills Experience with overall application architecture and design, including the logical data model, physical schema, and report specifications. This role can be filled by experts in the domain, such as consultants with experience implementing this type of application, or expert users in the analysis domain. Experience with application development using MicroStrategy technology. Experience performing testing tasks. Develop the reports In this first Phase IV procedure, you create the report library for your analytical application, including any supporting objects such as metrics and filters. you develop reports for portability and are using MicroStrategy When technology, additional design rules apply. See Portability rules and recommendations at the end of this chapter for detailed rules for reports. procedure should be completed by developers, working with a This person responsible for overall application architecture and design. To develop the reports 1 Make sure you have the Reports Specifications document as well as the logical data model and physical schema documentation available. Make sure you also have access to the MicroStrategy project as created in Phase II: Develop the logical data model, page 115. 128 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications 2 Create all objects required for the reports. Objects to be created include such supporting objects as metrics and filters. sure to add a detailed description to all objects created with BeMicroStrategy tools. 3 Once the objects are created, design the reports to include the final formatting. Your completed reports form the report library for your MicroStrategy project. sure to update the Reports Specifications document if any Bemodifications were required during report development. Test the reports In this second Phase IV procedure, you test all reports to ensure they meet your documented Reports Specifications. This procedure should be performed by developers and testers. To test the reports 1 Make sure you have access to your MicroStrategy project, including your default data warehouse with test/demo data loaded. Also be sure you have your Report Specifications document and your Test Plan. 2 Execute your Test Plan. 3 Review report results, such as the following: • Report data set • Report display • Report formatting • SQL 4 Identify any issues and resolve them. Be sure to update any related documentation that may be affected. 5 Take final screen shots of each report, and include the screen shots in your Report Specifications document. © 2015 MicroStrategy, Inc. Best practices for building portable applications 129 6 Creating Portable Analytical Applications Installation and Porting Guide Once this procedure is complete, you have produced the final version of your MicroStrategy project. You have also produced updated versions of the Report Specifications document to include screen shots of the final reports. Package the application In this last Phase IV procedure, you create the final package for your analytical application, including the metadata components and documentation. procedure should be performed by developers, testers, and This writers. To package the application 1 Gather all documentation created during the development process (Phases I-III plus the completed procedures in Phase IV). Be sure to include all business and technical specifications. 2 Be sure you have access to the MicroStrategy project, including metadata, default physical schema, and demonstration (demo) database. 3 Transform your existing documentation to a format appropriate for your target audience (such as developers, system administrators, end users, or another group). Depending on the audience, your documentation’s level of detail can differ significantly. For example, a software company developing a packaged application intended for an outside audience might create more detailed documentation. A company producing an application for internal use might need less detailed documentation in certain areas. 4 Package the software components, and create installation routines if required. MicroStrategy Analytics Modules, page 2 for details about See packaged components included with the MicroStrategy Analytics Modules. The Analytics Modules can be used as templates for documentation and packaging. Your final package includes documentation, metadata-ware (MicroStrategy metadata, a demo data warehouse, and so on), and a demo/evaluation version of your analytical application. 130 Best practices for building portable applications © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications Portability rules and recommendations This section presents development rules and recommendations for creating enterprise-class portable analytical applications within the context of the MicroStrategy platform, based on best practices used by MicroStrategy to develop the Analytics Modules. It includes recommendations for creating MicroStrategy objects. The rules and recommendations are important to ensure that an analytical application is portable. See Chapter 5, Porting the Analytics Modules for a full explanation of portability. These rules help minimize the impact a missing data element in the target data warehouse has on the logical data model (the packaged components). Some of the rules and recommendations are best practices guidelines and can be applied when you are developing any analytical application. The rules also facilitate application customization and extension. This section is organized into two subsections: • Schema Objects: This subsection has rules for developing the schema objects (attributes, facts, and hierarchies) in the logical data model. • Application Objects: This subsection has rules for developing the application objects (reports, metrics, filters, and so on). Rules and recommendations include examples from the MicroStrategy Analytics Modules. See each module’s reference guide and metadata components for details and definitions. defining MicroStrategy objects, it is recommended that you When always add a detailed description. This facilitates future changes and additions, particularly if an object does not comply with the rules and recommendations below. A detailed description can include such information as an object’s type, a specific design rule and the reason why it was not used, a general object definition, guidelines for customization, and so on. Schema objects MicroStrategy schema objects are the representation of the logical data model in MicroStrategy technology. Schema objects include such items as attributes, facts, and hierarchies. They are defined with MicroStrategy Architect. © 2015 MicroStrategy, Inc. Portability rules and recommendations 131 6 Creating Portable Analytical Applications Installation and Porting Guide Attribute rules and recommendations Attributes are the entities that represent the business dimensions (business concepts), such as Customer or Product. Attribute forms Attributes are represented by at least one attribute form. • Designing the logical data model: • Defining the physical schema: • Assign two forms to each attribute, an identifier and descriptor. For example, in the Sales Force Analysis Module (SFAM), a numeric identifier and a product name represent the Product attribute. Each form requires a column in the database. For example, an attribute with two forms requires two columns. Defining the attribute in MicroStrategy: Define two forms, ID and DESC, using the standard form of numeric for ID and text for DESC. For date attributes, use one form, defined as ID with a form type of Date. Set the ID form as the key for the attribute. Set the DESC form as the display default. Add descriptions to all forms. Descriptions should indicate the business meaning and the source. Avoid compound keys and group forms. Only specific physical schemas support compound keys. Attribute form expression Each attribute form is linked to the physical schema, defining a form expression. A form expression can be column names from the physical schema such as CUST_ID or a combination of names using a database operator, such as [FIRST_NAME]+[LAST_NAME]. 132 Portability rules and recommendations © 2015 MicroStrategy, Inc. Installation and Porting Guide • Defining the physical model: • 6 Creating Portable Analytical Applications Map each attribute form to a single column in the physical schema. Avoid combining columns using database operators. Use a homogeneous naming convention by applying the same column name in all tables where it appears. This convention requires only one form expression to be set up. If the target warehouse has different column names, additional form expressions can be added. For example, in the Sales Force Analysis Module (SFAM), the Order attribute is represented in all tables by the ORDER_ID column. Defining the form expression in MicroStrategy: Use the guidelines in the bullet above for a single column and one form expression per form, with the same column name in all tables. If a more complex form is required, avoid database-specific operators or functions. Avoid constant values (also called derived attributes) in the form expression. These are mapped to a specific table and require a similar table to exist in the target data warehouse. Attribute relationships Attribute relationships define how different attributes are associated. • Designing the logical data model: • Use one-to-many or one-to-one relationships whenever possible, since they are less dependent on specific table structures. The Customer Analysis Module Reference Guide provides an example where all relationships are one-to-many relationships. Avoid many-to-many or many-to-one relationships, because such relationships assume a certain physical schema and require a relationship table. Defining the physical schema: Use lookup or relationship tables to establish attribute relationships. Avoid using fact tables. For example, CAM and SFAM primarily use lookup tables to establish relationships. A many-to-many relationship cannot be defined in lookup tables and requires an additional relationship table. For example, SFAM has a many-to-many relationship between Opportunity and Product. It is © 2015 MicroStrategy, Inc. Portability rules and recommendations 133 6 Creating Portable Analytical Applications Installation and Porting Guide defined using a relationship table with Opportunity ID and Product ID columns. • Defining the attribute relationship in MicroStrategy: Use lookup tables as the relationship table, based on the guidelines in the bullet above. Fact rules and recommendations Facts are the entities that define the business measures, such as revenue, cost, and price. Fact expressions Facts are represented by at least one fact expression in MicroStrategy. Fact expressions link facts with the physical schema. They can be a single column such as REVENUE, several columns combined using operations such as profit=REVENUE-COST, or a constant value. • Designing the logical data model: • Defining the physical schema: • Define facts based on a single column. Use a homogeneous naming convention by using the same column name in all the tables where the fact exists. For example, the Opportunity Size fact exists in two tables in SFAM. In both tables, the column name is OPTY_SIZE. Defining the fact expression in MicroStrategy: • Represent each fact by a single concept in the logical data model. Use one fact expression per fact, mapped to a single column. Irregularities in the target data warehouse, such as different column names or multiple columns, can be addressed during the implementation. If several columns and operators are required, avoid database-specific functions. Defining fact expressions with a constant value (derived facts): Fact expressions with a constant value (derived facts) are used to define count metrics in a specific fact table, and so they assume a 134 Portability rules and recommendations © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications specific table name and table structure. Document any derived facts, including table structure. This facilitates mapping to a target data warehouse, since derived facts require a fact table with a similar structure. The Sales and Distribution Analysis Module (SDAM) provides an example of derived facts, where they are used to enable counting different attributes from a specific table. Fact levels The fact level determines the attribute level at which the fact can be analyzed. • Designing the logical data model: • Defining the physical schema: • Define facts at the lowest attribute level that can be used for analysis. For example, CAM is defined at the lowest levels used for analysis, which are Customer, Date, Transaction ID, and Product. Ensure all required attribute keys are in the fact table. These are usually the lowest attribute in the hierarchy. Defining the fact level in MicroStrategy: Avoid fact level extensions whenever possible. All required relations must exist at the fact table level. Hierarchy rules and recommendations Hierarchies are groups of attributes, organized in a way which defines their relationships to each other. For example, the Time hierarchy consists of the group of all time-related attributes such as Year, Quarter, Month, and Date. MicroStrategy comes with one hierarchy, called System, which represents the relationships defined at the attribute level. You can also define user hierarchies to create custom groupings. • Defining hierarchies in MicroStrategy: Use the System hierarchy. Avoid user hierarchies. However, you can use them to provide prompt selections for any level in a hierarchy. For example, in both SFAM and CAM a Time hierarchy is defined to allow time selection in any time period. © 2015 MicroStrategy, Inc. Portability rules and recommendations 135 6 Creating Portable Analytical Applications Installation and Porting Guide Rules for other schema objects You must consider some additional schema objects when building analytical applications. They include transformations, tables, and mapping methods. Transformations • Defining transformations in MicroStrategy: If you need transformations, use simple base table transformations. For example, SFAM includes typical Time transformations such as Last Quarter. The Quarter lookup table includes an extra column for the Last Quarter transformation. Do not use expression-based transformations, especially if they require database-specific functions. Tables • Defining the physical schema tables in MicroStrategy: Use the table size calculated by MicroStrategy Architect. Use the default values generated by MicroStrategy Architect for the keys. Mapping methods This parameter, which applies to attributes and facts, indicates how to update physical mappings when the data warehouse catalog is updated. • Defining a mapping method: Use the Automatic method because it automatically updates all mappings when new tables are added. If required, change the mappings manually in each attribute or fact. Alternatively, disable automatic checking for all objects. Application objects MicroStrategy application objects are the representation of the reports and business measures in MicroStrategy, such as metrics, filters, prompts, 136 Portability rules and recommendations © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications reports, and so on. These are defined based on schema objects (attributes and facts) and are created using MicroStrategy Developer. Consolidations and custom groups rules and recommendations These application objects are used to define special groupings of attributes. Consolidations Avoid using consolidations because their definition is based on filter conditions. Consolidations assume that certain attribute values exist in the target data warehouse. For more information, see Filters rules and recommendations, page 140. Custom groups Custom groups can be based on filters (qualifying attributes or metrics) or on banding metric values. • Avoid using custom groups based on filters. They assume that certain attribute values exist in the target data warehouse. • Use custom groups based on metric bands. See the Customer Analysis Module Reference Guide for examples of custom group definitions. • Document the definition, including the steps required to customize them for the target data warehouse. Base formulas and metrics rules and recommendations Base formulas are used to define a metric formula without including other parameters such as level, conditionality, transformation, VLDB properties, and so on. Base formulas create an additional level of abstraction between the physical schema and the metrics, that is, the actual calculations. Base formulas Use base formulas if several metrics share the same formula. © 2015 MicroStrategy, Inc. Portability rules and recommendations 137 6 Creating Portable Analytical Applications • Installation and Porting Guide If changes are required when implementing the analytical application against a target data warehouse, applying the changes to the base formula automatically updates all metrics using that base formula. The Analytics Modules make extensive use of base formulas. The majority of the metrics are defined based on a collection of key formulas, which are located in one folder for easy access. For example, in SFAM, all Revenue metrics are based on the “Sum of Order Amount” base formula, defined as SUM(REVENUE). If revenue is calculated as UNITS multiplied by PRICE in the target data warehouse, updating the base formula to SUM(UNITS*PRICE) automatically updates all metric definitions that rely on the “Sum of Order Amount” base formula. This makes the schema change transparent to the metrics. • Do not use database-specific functions in the formula. • Minimize the number of facts or attributes (for counts) used. • Use simple functions or operators. • For some count metrics, special parameters such as FACT ID may be required. The associated fact must be updated to point to the new physical schema. If a table with a similar structure does not exist, then the base formula cannot be implemented. Metrics Metrics define how facts are calculated when used in reports. The definition can include a formula based on facts, attribute counts, or other metrics. Simple metrics Simple metrics include a calculation applied to facts or attributes. For example, the simple metric for Sales is ($)=SUM(DOLLAR_SALES). • Creating the metric formula: Use base formulas whenever possible. See Base formulas and metrics rules and recommendations, page 137, for more details. Use simple functions or operators. Do not use database-specific functions. Minimize the number of facts or attributes (for counts) used. Avoid special operator parameters, although FACT ID and count distinct may be required for some count metrics. 138 Portability rules and recommendations © 2015 MicroStrategy, Inc. Installation and Porting Guide • 6 Creating Portable Analytical Applications Adding conditionality to metrics: Avoid conditions because a qualification implies the existence of specific values in the target data warehouse. For more information, see Filters rules and recommendations, page 140. If conditions are required, document the qualification and how to customize it to the target data warehouse. • For example, a number of conditional metrics were added to SFAM, such as Qualified Leads, which identifies only those leads that are transformed into sales opportunities. All filters are located in the same folder. The Sales Force Analysis Module Reference Guide provides strategies for updating the qualification to the values that exist in the data warehouse. • Adding metric levels: Use the default value of the report level. Avoid defining a specific level, which implies the existence of the attribute in the target data warehouse. For non-aggregatable metrics, levels require a specific physical schema. If a level is required, document the definition and how to customize it to the target data warehouse. For example, the Analytics Modules include a number of dimensional metrics as examples of contribution analysis (percent to all calculations). The modules also include a number of non-aggregatable metrics. • Creating transformation metrics: Add examples based on typical time transformations, such as Month vs. Previous Month. For example, the Analytics Modules include some transformation metrics as examples of time-based analysis. Compound metrics Compound metrics are defined based on other metrics and arithmetical operators. These metrics do not include level, condition, or transformation. • Creating compound metrics: Limit the number of metrics used in the definition. This minimizes the impact if some metrics are missing from the target data warehouse. © 2015 MicroStrategy, Inc. Portability rules and recommendations 139 6 Creating Portable Analytical Applications Installation and Porting Guide Other metric parameters Other metric parameters include formatting, subtotals, VLDB properties, join type, and so on. Use outer join as the default for all metrics in both the formula and metric join type. The join required could differ depending on the report in which the metric is used. However, this setting can be changed at the report level. Most of the metrics in the Analytics Modules use outer joins by default. This ensures that data for an attribute is always returned, even if one metric does not return any values. Use the default value for all VLDB properties. To address irregularities, change the property at the report level and document the change. The metric format is based on the business purpose of the metric. For example, a Revenue metric is formatted as currency, Lead Counts is an integer, and so on. Use defaults for the subtotals. If changes are required for a particular report, make the changes at the report level and document them as part of the definition. Filters rules and recommendations A filter specifies the conditions that apply to the data included in the report. A qualification assumes the existence of certain values or a particular data structure in the target data warehouse. Minimize filter usage. If a filter is needed, document it and how to change the definition. Create a collection of reusable filters. Creating standard filters and reusing them in metrics and reports minimizes the number of filters that are needed. When a filter must be modified, the changes are automatically applied to all objects using it. If filters are defined in each report, changes must be made in each embedded filter. A collection of filters has been defined for the Analytics Modules. Use prompts to define a qualification when the report is executed, rather than hard-coding it. 140 Portability rules and recommendations © 2015 MicroStrategy, Inc. Installation and Porting Guide 6 Creating Portable Analytical Applications Attribute qualification Avoid qualifying on attributes, because this assumes the values exist in the target data warehouse. For example, a filter is defined as month=Oct-2001. However, the value may not exist or the client may use a different format for the month ID, such as month=102001. Do not use database-specific functions when defining the qualification. If data functions are required for date type filters, use the MicroStrategy date functions such as Current Date. These are independent of the database engine. Set qualification: metrics Avoid metric qualifications, because they assume the values exist in the target data warehouse. Do not use database-specific functions when defining the qualification. Set qualification: relationship filters Avoid using output level, including relate output level and filter qualification, because it assumes a physical schema structure or table name. Prompts rules and recommendations Prompts can be used to define a run-time qualification or to select attributes and metrics to be displayed in the report. Use prompts instead of static filters, as discussed in Filters rules and recommendations, page 140. Create a collection of reusable prompts. All the reports in SFAM and CAM include prompts, which are saved in a central location. Use object prompts to define the report template dynamically or select it from a list of filters. Document the attributes or metric used, including an explanation of how to update the prompt if the objects are missing from the target data warehouse. Avoid value prompts. If a value prompt is required, do not define the default values. © 2015 MicroStrategy, Inc. Portability rules and recommendations 141 6 Creating Portable Analytical Applications Installation and Porting Guide Avoid level prompts, because they assume that the metric can be calculated at a certain attribute level in the target data warehouse. Reports rules and recommendations The report object defines how information is calculated and displayed for each analytic. Filter definition Use the rules from Filters rules and recommendations, page 140. Use embedded filters and prompts instead of static filters. SFAM and CAM use embedded filters that are stored in the Filters folder. All reports include prompts to allow dynamic selection. In SFAM, some reports have static filters to calculate the top ten deals, top three deals, and so on. These are embedded filters as well. Template definition: report layout Limit the number of metrics and attributes in the report. This minimizes changes if some data elements do not exist in the target data warehouse. Use object prompts to allow dynamic selection of metrics or attributes when they could be different in the target data warehouse. In CAM, many reports include object prompts to select customer characteristics such as Age Range and Gender. Because these attributes may not exist in the target data warehouse, attributes will need to be added or changed. Consequently, the reports must change. The advantage to object prompts is that the attributes can be added without modifying the report definition. Template definition: formatting Use the defaults for sorting, attribute display, subtotal, and so on. Avoid advanced sorting and subtotals. Users can set them up based on their needs. Minimize using graphs, because they are very dependent on the report template and values. If the report changes, the graph may be invalidated. 142 Portability rules and recommendations © 2015 MicroStrategy, Inc. Installation and Porting Guide Creating Portable Analytical Applications 6 Template definition: other parameters Use the default VLDB properties. Use the default values for the report data options. Avoid report limits because they assume certain values exist in the target data warehouse. Avoid metric aliases. © 2015 MicroStrategy, Inc. Portability rules and recommendations 143 6 Creating Portable Analytical Applications 144 Portability rules and recommendations Installation and Porting Guide © 2015 MicroStrategy, Inc. GLOSSARY aggregate data Information or facts added together or "aggregated" to form summaries of information considered as a whole. For example, weekly revenues are aggregated to determine a company's monthly profits. aggregate table A fact table that stores data that has been aggregated along one or more dimensions. analytical application In MicroStrategy, a software application designed to provide predefined reports and other analytics, based on a predefined metadata repository, for various industries to gain insight into their business data. The application is not fixed to a specific physical schema, giving it the flexibility to be ported to a company’s existing data warehouse. analytics library The collection of reports and related objects in the MicroStrategy metadata repository. Library objects include reports, metrics, filters, and prompts. Library objects are defined based on attributes and facts (objects in the logical data model.) application object MicroStrategy object used to provide analysis of and insight into relevant data. Application objects are developed in MicroStrategy Developer and they are the building blocks for reports and documents. Application objects include these object types: report, document, template, filter, metric, custom group, consolidation, prompt. © 2015 MicroStrategy, Inc. Glossary: aggregate data 145 Glossary Installation and Porting Guide attribute A data level defined by the system architect and associated with one or more columns in a data warehouse lookup table. Attributes include data classifications like Region, Order, Customer, Age, Item, City, and Year. They provide a means for aggregating and filtering data at a given level. See also: • form • expression • child attribute • parent attribute attribute drill path See drill path. attribute form One of several columns associated with an attribute that are different aspects of the same thing. For example, ID, Name, Last Name, Long Description, and Abbreviation could be forms of the attribute Customer. Every attribute supports its own collection of forms. banding A method of organizing values according to a set of descriptive or meaningful data ranges called buckets. For example, customers in the age ranges of 10–20, 21–30, and 31–40, where each set of ages is a band. Banding is also used for display purposes, where every other row is a different color and the two colors alternate. Compare consolidation. base table A fact table that stores data at the lowest level of dimensionality. 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. 146 Glossary: attribute © 2015 MicroStrategy, Inc. Installation and Porting Guide Glossary catalog A table that contains the names of all non-temporary tables in a data warehouse. category See dimension or hierarchy. characteristic attribute An attribute that is a parent of a child attribute, but not part of the "main" hierarchy associated with the child attribute. For example, consider a hierarchy consisting of Year, Month, Day. Day of Week is a parent of Day, and a characteristic attribute. child attribute The lower-level attribute in an attribute relationship. See also: parent attribute relationship column 1) A one-dimensional vertical array of values in a table. 2) The set of fields of a given name and datatype in all rows of a given table. 3) MicroStrategy object in the schema layer that can represent one or more physical table columns or no columns. compound metric A metric that cannot have a level placed on the entire metric, although it can be set separately on each of the components. conditional metric A metric containing filter criteria in its definition. consolidation An object that can be placed on a template and is made up of an ordered collection of elements called consolidation elements. Each element is a grouping of attribute elements that accommodates inter-row arithmetic operations. Compare custom group. © 2015 MicroStrategy, Inc. Glossary: catalog 147 Glossary Installation and Porting Guide custom group An object that can be placed on a template and is made up of an ordered collection of elements called custom group elements. Each element contains its own set of filtering qualifications. data modeling A method used to define and analyze data requirements needed to support the business functions of an enterprise. These data requirements are recorded as a conceptual data model with associated data definitions. Data modeling defines the relationships between data elements and data structures. data source name Provides connectivity to a database through an ODBC driver. (DSN) A DSN generally contains host machine name or IP address, instance name, database name, directory, database driver, User ID, password, and other information. The exact information included in the DSN varies by DBMS. Once you create a DSN for a particular database, you can use it in an application to call information from the database. data warehouse 1) A database, typically very large, containing the historical data of an enterprise. Used for decision support or business intelligence, it organizes data and allows coordinated updates and loads. 2) A copy of transaction data specifically structured for query, reporting, and analysis. database connection Stores all database-specific connection information such as DSN, driver mode and SQL execution mode as well as connection caching information. database instance 1) Database server software running on a particular machine. Though it is technically possible to have more than one instance running on a machine, there is usually only one instance per machine. 2) The MicroStrategy object that represents a logical definition of a data warehouse. It stores all information necessary for MicroStrategy to access the data warehouse for a particular project. 148 Glossary: custom group © 2015 MicroStrategy, Inc. Installation and Porting Guide Glossary derived attribute An attribute calculated from a mathematical operation on columns in a warehouse table. For example, Age can be calculated from the expression [Current Date–Birth Date]. See also attribute. dimension An element or factor making up a complete entity or variable (a quantity that may assume any one of a set of values). For example, product types, times and regions are three dimensions pertaining to sales. Different product types are sold over different time zones in different regions. dimensionality See level. drill path (attribute drill In MicroStrategy, a path that determines which attributes are path) presented to an interface; typically a project defines drill paths from parent attributes to their children. entry level The lowest level set of attributes at which a fact is available for analysis. ETL (extraction, 1) The process used to populate a data warehouse from transformation, and disparate existing database systems. loading) 2) Third-party software used to facilitate such a process. expression Formulas built from functions, attributes, facts, metrics, and consolidations that can be used to define attribute forms, fact calculations, metrics, or filters. fact 1) A measurement value, often numeric and typically aggregatable, stored in a data warehouse. 2) A schema object representing a column in a data warehouse table and containing basic or aggregated numbers—usually prices, or sales in dollars, or inventory quantities in counts. See also metric. © 2015 MicroStrategy, Inc. Glossary: derived attribute 149 Glossary Installation and Porting Guide fact table A database table containing numeric data that may be aggregated along one or more dimensions. Fact tables may contain atomic or summarized data. Compare base table. filter A MicroStrategy object that specifies a set of criteria used to limit the data returned in a report. Specifically, it limits the returned values of an attribute in the result set to a specified range. It is normally implemented in the SQL WHERE clause. Examples include: “1997”, “All weekdays in May”, “Stores in the Northeast”. folder A MicroStrategy object used for grouping and storing in a single place a set of objects that are similar, such as filters, templates, and reports. form One of several columns that are different representations of the same thing, as ID, Name, Long Description, Abbreviation. hierarchy A set of attributes defining a meaningful path for element browsing or drilling. The order of the attributes is typically—though not always—defined such that a higher attribute has a one-to-many relationship with its child attributes. hint A comment that passes instructions to a database optimizer about choosing an execution plan for a given SQL statement. In MicroStrategy, a hint can be defined in VLDB properties to appear within a MicroStrategy-issued SQL statement. HTML document 1) A compound report displaying multiple grids and graphs. 2) The MicroStrategy object that supports such a report. join A SQL operation that combines data from multiple tables into a single result table. 150 Glossary: fact table © 2015 MicroStrategy, Inc. Installation and Porting Guide Glossary level 1) In a data warehouse, facts are said to be stored at a particular level defined by the attribute IDs present in the fact table. For example, if a fact table has a Date column, an Item_ID column, and a fact column, that fact is stored at the Date/Item level. 2) With regard to metric calculation, the level is the level of calculation for the metric. For example, a metric on a report with Year and Store attributes would be calculated at the Year/Store level. logical data model A representation of the business logic of a given analytical domain in the MicroStrategy metadata repository. The logical data model shows the facts and attributes of that business logic, and the hierarchies between them. lookup table A database table used to uniquely identify attribute elements. They typically consist of descriptions of dimensions. Lookup tables are usually joined to fact tables to group the numeric facts in the fact table by dimensional attributes in the lookup tables. many-to-many An attribute relationship in which multiple elements of a relationship parent attribute can relate to multiple elements of a child attribute, and vice versa. many-to-one An attribute relationship in which (1) multiple elements of a relationship parent attribute relate to only one element of a child attribute, and (2) every element of the child attribute can relate to multiple elements of the parent. metadata (or metadata A repository whose data associates the tables and columns of repository) a data warehouse with user-defined attributes and facts to enable the mapping of the business view, terms, and needs to the underlying database structure. Metadata can reside on the same server as the data warehouse or on a different database server. It can even be held in a different RDBMS. © 2015 MicroStrategy, Inc. Glossary: level 151 Glossary Installation and Porting Guide metric 1) A business calculation defined by an expression built with functions, facts, attributes, or other metrics. For example: sum(dollar_sales) or [Sales] - [Cost] 2) The MicroStrategy object that contains the metric definition. See also fact. MicroStrategy A group of MicroStrategy projects with prepackaged Analytics Modules metadata, including best practices reports, scorecards, and dashboards, key performance indicators, attributes, business metrics, filters, and custom groups; default physical and logical data models to allow the modules to work with your physical schemas and data model or with the module’s packaged data warehouse schema; and reference guides for each Analysis Module’s data model, the individual analysis areas, metadata object definitions, data dictionary, and individual report use scenarios. MicroStrategy Core of the MicroStrategy architecture, MicroStrategy Intelligence Server Intelligence Server manages and organizes users, projects, and database connections; coordinates, prioritizes, and executes all user requests; and allocates the resources necessary to complete them. It tracks schedules, manages security, and provides the ability to monitor and analyze the daily activity of the entire decision support environment. object Conceptually, an object is the highest grouping level of information about one concept, used by the user to achieve the goal of specified data analysis. More concretely, an object is any item that can be selected and manipulated, including folders, reports, facts, metrics, and so on. ODBC (open database An open standard with which client computers can connectivity) communicate with relational database servers. Client machines make a connection to a particular logical database, on a particular physical database server, using a particular ODBC driver. OLAP See online analytical processing. 152 Glossary: metric © 2015 MicroStrategy, Inc. Installation and Porting Guide Glossary one-to-many An attribute relationship in which every element of a parent relationship attribute can relate to multiple elements of a child attribute, while every element of the child attribute relates to only one element of the parent. The one-to-many attribute relationship is the most common in data models. one-to-one relationship An attribute relationship in which every element of the parent attribute relates to exactly one element of the child attribute, and vice versa. online analytical In general, a system with analytical processing that involves processing activities such as manipulating transaction records to calculate sales trends, growth patterns, percent to total contributions, trend reporting, and profit analysis. parent attribute The higher-level attribute in an attribute relationship with one or more children. See also: child attribute relationship partition A relational database table broken down into smaller component tables. This can be done at the database level or at the application level. See the MicroStrategy System Administration Guide for more information. partition mapping The division of large logical tables into smaller physical tables based on a definable data level, such as month or department. Partitions minimize the number of tables and records within a table that must be read to satisfy queries issued against the warehouse. By distributing usage across multiple tables, partitions improve the speed and efficiency of database queries. partition mapping table A warehouse table that contains information used to identify the partitioned base tables as part of a logical whole. (A partitioned base table is a warehouse table that contains one © 2015 MicroStrategy, Inc. Glossary: one-to-many relationship 153 Glossary Installation and Porting Guide part of a larger set of data. Partition tables are usually divided along logical lines, such as time or geography.) Also referred to as a PMT. physical warehouse A detailed graphic representation of your business data as it schema is stored in the data warehouse. It organizes the logical data model in a method that make sense from a database perspective. portability The ability of an analytical application to be integrated into an existing data warehouse. To port a given Analysis Module, you “map” the module to the physical schema of an existing data warehouse. primary key In a relational database, the set of columns required to uniquely identify a record in a table. production metadata The repository you create during the configuration portion of the installation process, and which works with your data warehouse and serves as your working metadata repository. project 1) The highest-level intersection of a data warehouse, metadata repository, and user community, containing reports, filters, metrics, and functions. 2) An object containing the definition of a project, as defined in (1). The project object is specified when requesting the establishment of a session. project source Defines a connection to the metadata database and is used by various MicroStrategy products to access projects. A direct project source is a direct (two-tier) connection to a metadata repository. A server project source is a server (three-tier) connection to a MicroStrategy Intelligence Server. One project source can contain many projects, and the administration tools found at the project source level are used to monitor and administer all projects in the project source. 154 Glossary: physical warehouse schema © 2015 MicroStrategy, Inc. Installation and Porting Guide Glossary prompt MicroStrategy object in the report definition that is incomplete by design. The user is asked during the resolution phase of report execution to provide an answer that completes the information. A typical example with a filter is choosing a specific attribute on which to qualify. ranking A type of OLAP function that returns the rank of a value in a group of values. Rows with equal values with respect to the ordering are assigned the same rank. relate table A table containing the ID columns of two or more attributes, thus defining associations between them. relationship An association specifying the nature of the connection between one attribute (the parent) and one or more other attributes (the children). For example, City is a child attribute of State. See also: child attribute parent attribute report The central focus of any decision support investigation, a report allows users to query for data, analyze that data and then present it in a visually pleasing manner. See also: filter template schema 1) The set of tables in a data warehouse associated with a logical data model. The attribute and fact columns in those tables are considered part of the schema itself. 2) The layout or structure of a database system. In relational databases, the schema defines the tables, the fields in each table, and the relationships between fields and tables. © 2015 MicroStrategy, Inc. Glossary: prompt 155 Glossary Installation and Porting Guide schema object MicroStrategy object created, usually by a project designer, that relates the information in the logical data model and physical warehouse schema to the MicroStrategy environment. These objects are developed in MicroStrategy Architect, which can be accessed from MicroStrategy Developer. Schema objects directly reflect the warehouse structure and include attributes, facts, functions, hierarchies, operators, partition mappings, tables, and transformations. simple metric A type of metric that can stand alone or be used as a building block for compound metrics. Simple metrics always contain at least one aggregate function, such as sum or average, applied to a fact, attribute, or another metric. The entire metric can only contain one level. SQL (Structured Query The standardized query language established in 1986 by the Language) American National Standards Institute (ANSI) and used to request information from tables in a relational database and to manipulate the tables' structure and data. table The primary physical component of a data warehouse, logically consisting of columns of data of varying types. transformation A schema object that encapsulates a business rule used to compare results of different time periods. Transformations are used in the definition of a metric to alter the behavior of that metric. 156 Glossary: schema object © 2015 MicroStrategy, Inc. INDEX A Access database 24, 107 aggregate 51 analytical application 4 advantages 5 architecture 105 best practices 107 designing 105 disadvantages 4 packaging 130 analytical domain defining 109 designing a report and 125 reporting areas 113 rules 110 size 111 specifications 112 stability 111 analytics library defined on 106 in the architecture 106 porting and 48 Analytics Modules. See MicroStrategy Analytics Modules. application object defined on 34, 62 comparing 63 © 2015 MicroStrategy, Inc. design rules 131, 136 identification example 63 identifying dependencies 62 moving example 82 order of 79 to a new project 79 updating example 92 order of 90 attribute defined on 3 design rules 132 determining support 55 mapping. See attribute mapping. relationship 133 troubleshooting 60 attribute mapping example 57, 77 to target schema 54 with Object Manager 76 without Object Manager 100 B banding 137 base formula defined on 137 157 Index design rules 137, 138 identifying dependencies 64 moving example 83 moving to a new project 81 updating example 95 base table 136 building an analytical application 105 C catalog, data warehouse 75, 136 characteristic attribute 36 child attribute 60 column 36 compound metric design rules 139 moving 81 conditional metric design rules 139 moving 81 configuring a Microsoft Access database 24 configuring MicroStrategy Analytics Modules 21 data warehouse connection 25 metadata 23 prerequisites 23 connection type 22, 38 creating 24 consolidation defined on 137 design rules 137 custom group design rules 137 D data modeling 49 data provider. See project source. data source name (DSN) 24, 26 data warehouse 158 Installation and Porting Guide catalog 75, 136 default 32 mapping target schema to logical data model 54 mapping target warehouse to physical schema 49 database connection 26, 76 database instance 26 derived attribute 133 derived fact 134 design and development premises 108 designing an analytical application 105 development process overview 109 dimensional metric moving 81 dimensionality 71, 81 direct project source 22 documentation Analytics Modules 3 developing 108 DSN. See data source name (DSN). E Erwin file 121 ETL routine 32, 34 evaluation version 107 expression mapping logical model to schema and 55 missing 61 missing column and 54 F fact defined on 134 design rules 134 determining support 56 mapping. See fact mapping. troubleshooting 61 © 2015 MicroStrategy, Inc. Installation and Porting Guide fact level 135 fact mapping example 59, 77 to target schema 54 with Object Manager 75 without Object Manager 100 fact table identifying 51 mapping 50 filter defined on 140 design rules 140 identifying dependencies 68 moving example 82 order of 80 to a new project 80 updating 91 example 97 folder, changing the name of 78 form expression 55, 132 G gap analysis designing software to facilitate 118 facilitating 46 overview 48 prerequisites 49 troubleshooting 60 H hardware requirements 9 hierarchy defined on 135 comparing 51 design rules 135 determining support 56 mapping. See hierarchy mapping. troubleshooting 61 © 2015 MicroStrategy, Inc. Index hierarchy mapping example 59, 77 to target schema 54 with Object Manager 75 without Object Manager 99 HTML document object 22 I installation file 14 MicroStrategy Architect 23 MicroStrategy Developer 23 prerequisites 9 procedure 10 setup type 14 system requirements 9 international support xxii J join type 140 L logical data model design quality 114 designing independence 118 designing modularity 117 developing 114 element 116 in the architecture 106 mapping example 56 mapping to target schema 54 mapping to the target schema 54 portability 42 testing 108 lookup table comparing 50 159 Index mapping 50 M mapping schema object example 76 schema object without Object Manager 99 metadata defined on 3, 22, 25 building an analytical application and 105 certified platform 23 configuring 23 metric defined on 138 alias 143 compound, moving 81 conditional design rules 139 moving 81 design rules 138 dimensional, moving 81 formatting 140 identifying dependencies 64 join type 140 level 139 moving example 84 order of moving 80 simple, moving 81 transformation, moving 81 updating 91 updating example 92 Microsoft Access configuring 24 in evaluation version 107 MicroStrategy Analytics Module configuring 21 MicroStrategy Analytics Modules defined on 2 as a template 105 160 Installation and Porting Guide customization scenario 34 customizing 34, 103 documentation 3, 47 extending 34, 103 porting 41 using 31 version 107 MicroStrategy Architect 34 as a prerequisite 49 for mapping 73 installing 23 porting and 46 MicroStrategy Developer 22, 34 as a prerequisite 49 for mapping 73 identifying dependencies 56 installing 23 porting and 46 MicroStrategy Intelligence Server 23 MicroStrategy Object Manager 46 as a prerequisite 49 identifying dependencies 56, 80 in mapping 73 modularity 108 module ix O object application 35 customizing 34 HTML document 22 portability and 45 public 35 schema 35 ODBC 22 OLAP 2 outer join 140 © 2015 MicroStrategy, Inc. Installation and Porting Guide Index P partition mapping 54 partitioning 38 performance optimization 38 permissions 38 physical schema designing 118 Erwin file and 121 ETL routine and 32 in the architecture 106 mapping example 51 solutions 53 to target warehouse 49 portability defined on 42 building an analytical application and 105 design driver 43 introduction 42 methodology 43 rules and recommendations 130 porting documentation 47 overview 48 prerequisites 46 prerequisites for using the Analytics Modules xii primary key 121 production preparation 37 project duplication 75 project source defined on 22 connecting 24 direct 22 server 22 prompt design rules 141 identifying dependencies 67 moving example 82 © 2015 MicroStrategy, Inc. moving to a new project 80 updating 91 updating example 97 R ranking 97 reference guide 49 application object and 63 object definition 55 relate table 60 report design rules 142 designing a library of 123 developing for library 128 identifying dependencies 68 limit 143 moving example 85 moving to a new project 81 testing 82, 92, 126, 129 updating 91 updating example 92 S schema object defined on 34 design rules 131 mapping. See schema object mapping. schema object mapping 73 example 76 partial 56 with Object Manager 74 without Object Manager 99 security 38 server project source 22 simple metric design rules 138 moving 81 software requirements 10 161 Index SQL missing expression and 61 testing 123 SQL Server 107 subtotals 140 support international xxii support. See technical support. Installation and Porting Guide V VLDB properties 26, 140, 143 T table design rules 136 removing after update 100 technical support xxiii testing a report 126 testing plan designing 121 executing 122 transformation design rules 136, 139 determining support 56 mapping. See transformation mapping. troubleshooting 62 transformation mapping example 59, 77 with Object Manager 75 without Object Manager 99 transformation metric moving 81 troubleshooting attribute 60 fact 61 gap analysis 60 U uninstalling 18 162 © 2015 MicroStrategy, Inc.
© Copyright 2026 Paperzz