› producthelp › manuals › en › projectdesign.pdf · project design guide -...

Project DesignGuide

Version 2020

MicroStrategy 2020

December 2019Copyr ight © 2019 by MicroStrategy Incorporated. Al l r ights reserved.

Trademark Information

The fol lowing are ei ther trademarks or registered trademarks of MicroStrategy Incorporated or i ts affi l iates in the Uni ted States and cer tain other countr ies:

MicroStrategy, MicroStrategy 2020, MicroStrategy 2019, MicroStrategy 11, MicroStrategy 10, MicroStrategy 10 SecureEnterprise, MicroStrategy 9, MicroStrategy 9s, MicroStrategy Analytics, MicroStrategy Analytics Platform, MicroStrategyDesktop, MicroStrategy Library, MicroStrategyOperationsManager, MicroStrategy Analytics Enterprise, MicroStrategyEvaluation Edition, MicroStrategy Secure Enterprise, MicroStrategyWeb, MicroStrategyMobile, MicroStrategy Server,MicroStrategy Parallel Relational In-Memory Engine (MicroStrategy PRIME), MicroStrategyMultiSource, MicroStrategyOLAPServices, MicroStrategy Intelligence Server, MicroStrategy Distribution Services, MicroStrategy Report Services, MicroStrategyTransaction Services, MicroStrategy Visual Insight, MicroStrategyWeb Reporter, MicroStrategyWeb Analyst, MicroStrategyOffice, MicroStrategy Data Mining Services, MicroStrategyGeospatial Services, MicroStrategy Narrowcast Server,MicroStrategy Analyst, MicroStrategy Developer, MicroStrategyWeb Professional, MicroStrategy Architect, MicroStrategy SDK,MicroStrategy Command Manager, MicroStrategy Enterprise Manager, MicroStrategyObject Manager, MicroStrategy IntegrityManager, MicroStrategy SystemManager, MicroStrategy Analytics App, MicroStrategyMobile App, MicroStrategy TechSupport App, MicroStrategyMobile App Platform, MicroStrategy Cloud, MicroStrategy R Integration, Dossier, Usher,MicroStrategy Usher, Usher Badge, Usher Security, Usher Security Server, Usher Mobile, Usher Analytics, Usher NetworkManager, Usher Professional, MicroStrategy Identity, MicroStrategy Badge, MicroStrategy Identity Server, MicroStrategyIdentity Analytics, MicroStrategy Identity Manager, MicroStrategy Communicator, MicroStrategy Services, MicroStrategyProfessional Services, MicroStrategy Consulting, MicroStrategy Customer Services, MicroStrategy Education, MicroStrategyUniversity, MicroStrategyManaged Services, BI QuickStrike, Mobile QuickStrike, Transaction ServicesQuickStrike PerennialEducation Pass, MicroStrategyWeb Based Training (WBT), MicroStrategyWorld, Best in Business Intelligence, Pixel Perfect,Global Delivery Center, Direct Connect, Enterprise Grade Security For Every Business, Build Your Own Business Apps, Code-Free, Intelligent Enterprise, HyperIntelligence, HyperCard, HyperVoice, HyperVision, HyperMobile, HyperScreen, Zero-ClickIntelligence, Enterprise Semantic Graph, Information Like Water, TheWorld’sMost Comprehensive Analytics Platform, TheWorld’sMost Comprehensive Analytics Platform. Period.

Other product and company names mentioned herein may be the trademarks of their respective owners.

Speci fications subject to change without notice. MicroStrategy is not responsible for er rors or omissions. MicroStrategy makes no warranties or commitmentsconcerning the avai labi l i ty of future products or versions that may be planned or under development.

CONTENTS

Book Overview and Additional Resources 1

About this book 3

Education 4

1. BI Architecture and the MicroStrategy Platform 1

Business intel l igence archi tecture 2

The MicroStrategy platform 8

The project design process 18

2. The Logical Data Model 20

Overview of a logical data model 21

Facts: Business data and measurements 23

Attributes: Context for your levels of data 25

Hierarchies: Data relationship organization 28

Sample data model 29

Bui lding a logical data model 29

Logical data model ing conventions 36

3. Warehouse Structure for Your Logical Data Model 41

Columns: Data identi fiers and values 43

Tables: Physical groupings of related data 44

Schema types: Data retrieval performance versus redundant storage 54

Design trade-offs 61

Schema type comparisons 62

Supporting data international ization 64

Supporting map data and Geo Location 70

4. Creating and Configuring a Project 74

Overview of project creation 76

Project connectivi ty components 89

Creating the metadata reposi tory 93

Connecting to the metadata reposi tory and data source 93

Creating a production project 95

Creating facts and attributes 112

Configuring addi tional schema-level settings 113

Deploying your project and creating reports 114

5. Creating a Project Using Architect 116

Creating and modi fying projects 117

Adding, removing, and administering tables 140

Creating and modi fying facts 154

Creating and modi fying attributes 168

Prerequisi tes 184

Defining attribute relationships 194

Creating and modi fying user hierarchies 202

6. The Building Blocks of Business Data: Facts 206

Creating facts 208

The structure of facts 218

How facts are defined 219

Fact column names and data types: Column al iases 227

Modifying the levels at which facts are reported: Level extensions 229

7. The Context of Your Business Data: Attributes 247

Overview of attributes 248

Creating attributes 251

Unique sets of attribute information: Attribute elements 264

Column data descriptions and identi fiers: Attribute forms 270

Attribute relationships 290

Attributes that use the same lookup table: Attribute roles 307

Attributes with multiple ID columns: Compound attributes 315

Using attributes to browse and report on data 318

8. Optimizing and Maintaining Your Project 323

Updating your MicroStrategy project schema 325

Data warehouse and project interaction: Warehouse Catalog 326

Accessing multiple data sources in a project 353

Improving database insert performance: parameterized queries 368

Using summary tables to store data: Aggregate tables 370

Dividing tables to increase performance: Parti tion mapping 378

9. Creating Hierarchies to Organize and Browse Attributes 385

Creating user hierarchies 387

Types of hierarchies 389

Hierarchy organization 391

Configuring hierarchy display options 393

Using the Hierarchy Viewer and Table Viewer 407

10. Creating Transformations to Define Time-Based and OtherComparisons 411

Creating transformations 412

Transformation components 417

Transformation metrics and joint chi ld attributes 419

11. Designing a Project for Financial Reporting 422

Prerequisi tes 424

Physical warehouse requirements 424

Designing the financial reporting project 436

Creating reporting objects for financial data 441

A. MicroStrategy Tutorial 455

What is the MicroStrategy Tutorial? 456

MicroStrategy Tutorial data model 460

MicroStrategy Tutorial schema 471

B. Logical Tables 503

Logical tables 504

Creating logical tables 507

Creating logical views 512

Logical view examples 516

C. Data Types 536

Mapping of external data types to MicroStrategy data types 537

MicroStrategy data types 587

Format types 588

Data type and format type compatibi l i ty 590

Big Decimal 592

MicroStrategy support for binary data types 596

Supporting barcode data with VarChar 597

Copyr ight © 2019 All Rights Reserved 1

Book Overview and Additional Resources

The MicroStrategy Project Design Guide provides comprehensiveinformation on planning, creating, and modi fying a project in MicroStrategyand covers a wide range of project-related topics, including the fol lowing:

Chapter 1, BI Archi tecture and the MicroStrategy Platform, provides anintroduction to business intel l igence archi tecture and some of the maincomponents wi thin the MicroStrategy platform.

Chapter 2, The Logical Data Model , explores logical data model ing andhow it can help you identi fy the di fferent elements wi thin your business dataand plan your project.

Chapter 3, Warehouse Structure for Your Logical Data Model , describescomponents of the physical warehouse schema such as columns and tablesand explores how you can map components from the logical data model tocomponents in the database to form the physical warehouse schema.

Chapter 4, Creating and Configuring a Project, describes the majorcomponents involved in project creation and guides you through theprocess of creating a project in MicroStrategy.

Chapter 5, Creating a Project Using Archi tect, guides you through theprocess of creating a project in MicroStrategy using Archi tect.

Chapter 6, The Bui lding Blocks of Business Data: Facts, describes thestructure of facts and explores di fferent types of facts and how they relate toyour business data. This chapter also covers al l the steps necessary tocreate facts for your project.

Chapter 7, The Context of Your Business Data: Attributes, provides aconceptual look at the structure of attributes and explores di fferent types ofattributes and how they relate to your business data. This chapter alsocovers al l the steps necessary to create attributes for your project.

Pro ject Design Gu id e


Chapter 9, Creating Hierarchies to Organize and Browse Attributes,discusses the di fferent types of hierarchies in MicroStrategy, and explainshow you can create user hierarchies to help organize and enhance yourproject.

Chapter 8, Optimizing and Maintaining Your Project, describes methods youcan implement to better optimize and maintain your project for both theshort and long term.

Chapter 10, Creating Transformations to Define Time-Based and OtherComparisons, discusses the di fferent types of transformations inMicroStrategy and describes how you can create transformations in yourproject.

Chapter 11, Designing a Project for Financial Reporting, provides a step-by-step example of using your own data to design a project for financialreporting and analysis, including profi t and loss reporting.

The appendixes contain the fol lowing addi tional reference information,which you may or may not require depending on your speci fic needs:

Appendix A, MicroStrategy Tutorial , provides information on theMicroStrategy Tutorial project, which includes a metadata and warehouse,and a set of demonstration appl ications designed to i l lustrate the featuresof the MicroStrategy platform.

Appendix B, Logical Tables, discusses logical tables, the di fferent types oflogical tables, and how to create logical tables and views in MicroStrategy.

Appendix C, Data Types, provides information about the di fferent data typesin MicroStrategy.

Information on integrating MicroStrategy with your MDX Cube sources suchas SAP BW, Microsoft Analysis Services, and Hyperion Essbase isprovided in the MDX Cube Reporting Guide.


https://www2.microstrategy.com/producthelp/2020/MDXCubeReporting/WebHelp/Lang_1033/index.htm


About this book

This book is divided into chapters that begin wi th a brief overview of thechapter's content.

The fol lowing sections provide the location of examples, l ist prerequisi tesfor using this book, and describe the user roles the information in this bookwas designed for.

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

How to find business scenarios and examplesWithin this guide, many of the concepts discussed are accompanied bybusiness scenarios or other descriptive examples. Many of the examplesuse the MicroStrategy Tutorial , which is MicroStrategy's sample warehouseand project. Information about the MicroStrategy Tutorial can be found inthe Basic Reporting Guide.

Detai led examples of advanced reporting functional i ty can be found in theAdvanced Reporting Guide.

What's new in this guide

MicroStrategy 10

MicroStrategy can automatical ly recognize area codes as geographicaldata, as described in Strategies to include supplemental data in a project,page 77.


https://www2.microstrategy.com/producthelp/2020/BasicReporting/WebHelp/Lang_1033/index.htm

https://www2.microstrategy.com/producthelp/2020/AdvancedReportingGuide/WebHelp/Lang_1033/index.htm


MicroStrategy Analytics Enterprise

The name of MicroStrategy Desktop has been changed to MicroStrategyDeveloper.

MicroStrategy 9.4

Any updates to this guide were minor and not di rectly related toMicroStrategy 9.4. For a l ist of new features in MicroStrategy 9.4, see theMicroStrategy Readme for that release.

PrerequisitesBefore working with this document, you should be fami l iar wi th:

The information provided in the Instal lation and Configuration Guide

The nature and structure of the data you want to use for your businessintel l igence appl ication.

Who should use this guideThis document is designed for al l users who require an understanding ofhow to design, create, and modi fy a MicroStrategy project using theMicroStrategy platform.

In short, the fol lowing business intel l igence appl ication users should readthis guide:

Project Designers

Database Administrators

Education

MicroStrategy Education Services provides a comprehensive curriculumand highly ski l led education consul tants. Many customers and partners fromover 800 di fferent organizations have benefi ted from MicroStrategyinstruction.


https://www2.microstrategy.com/producthelp/2020/InstallConfig/index.htm


Courses that can help you prepare for using this manual or that addresssome of the information in this manual include:

MicroStrategy Archi tect: Project Design Essentials

For the most up-to-date and detai led description of education offerings andcourse curricula, visi t http://www.microstrategy.com/Education.


http://www.microstrategy.com/Education


BI ARCHITECTURE ANDTHE M ICROSTRATEGYPLATFORM



Before planning and creating a project in MicroStrategy, i t is important tounderstand how business intel l igence systems work and, speci fical ly, howthe MicroStrategy platform interacts wi th your business data to provide awide range of functional i ty.

Business intel l igence (BI) systems faci l i tate the analysis of volumes ofcomplex data by providing the abi l i ty to view data from multipleperspectives. An optimum business intel l igence appl ication:

Gives users access to data at various levels of detai l

Al lows users to request information and have i t del ivered to them accuratelyand quickly

Provides a foundation for the proactive del ivery of information to systemsubscribers

This chapter introduces you to the basic archi tecture of BI systems, as wel las some of the components wi thin the MicroStrategy platform that al low youto create and analyze your business intel l igence.

Business intelligence architecture

A BI archi tecture has the fol lowing components:

A source system—typical ly an onl ine transaction processing (OLTP)system, but other systems or fi les that capture or hold data of interest arealso possible

An extraction, transformation, and loading (ETL) process

A data warehouse—typical ly an onl ine analytical processing (OLAP) system

A business intel l igence platform such as MicroStrategy



The diagram above illustrates the common setup for standardiz ing data fromsource systems and transferring that data into MicroStrategy. MicroStrategycan also access data from text files, Excel files, SAP BI, Hyperion Essbase,Microsoft Analysis Services, and other data sources. For more information onhow MicroStrategy can access your data sources, see Data warehouse fordata storage and relational design, page 5 .

Source systems for data collectionSource systems refer to any system or fi le that captures or holds data ofinterest. A bank is an example of a business with many source systems. Anaverage bank offers several services such as account activi ty updates andloan disbursement, and therefore has many source systems to supportthese services. For example, suppose one source system—a database fi leon the bank's server—keeps track of deposi ts and withdrawals as theyoccur. Meanwhi le, a di fferent source system—another fi le on the server—keeps track of each customer's contact information.

A source system is usual ly the most signi ficant si te of onl ine transactionprocessing (OLTP). Transactional processing involves the simple recordingof transactions and other business data such as sales, inventory, e-commerce, deposi ts, web si te usage, and order processing. This processingis rel ied upon dai ly by nearly every industry, including heal th care,telecommunications, manufacturing, and many others.



OLTP systems are databases or mainframes that store real-time processingdata and have the fol lowing characteristics:

Data access is optimized for frequent reading and wri ting, as the systemrecords huge volumes of data every day. An example of data that benefi tsfrom this type of optimization is the number of credi t card transactions thatan OLTP system might record in a single day. This is in contrast to datawarehouses which are often designed for reading data for analysis wi th aminimum number of updates, insertions, or deletions. For more informationon data warehouse design, see Data warehouse for data storage andrelational design, page 5.

Data is al igned by appl ication, that is, by business activi ties and workflow.

Data formats are not necessari ly uni form across systems.

Data history is l imi ted to recent or current data.

Recal l the example of a bank that rel ies on several source systems to storedata related to the many services the bank offers. Each of these businessservices has a di fferent and speci fic workflow.

At an automated tel ler machine (ATM), you can withdraw or deposi t moneyas wel l as check on balances. However, to get a money order, you mustenter the bank and perform the transaction with a bank tel ler. This isbecause the operational systems supporting these two services aredesigned to perform speci fic tasks, and these two services require di fferentoperational systems.

If a bank wants to see a uni fied view of a particular customer, such as acustomer's ATM activi ty, loan status, account balances, and money marketaccount information, the customer information stored in each of thesedi fferent systems must be consol idated. This consol idation is achievedusing the extraction, transformation, and loading (ETL) process.

The ETL process consol idates data so i t can be stored in a datawarehouse.



Extraction, transformation, and loading processThe extraction, transformation, and loading (ETL) process represents al l thesteps necessary to move data from different source systems to an integrateddata warehouse.

The ETL process involves the fol lowing steps:

Data is gathered from various source systems.

The data is transformed and prepared to be loaded into the datawarehouse. Transformation procedures can include converting data typesand names, el iminating unwanted data, correcting typographical errors,fi l l ing in incomplete data, and simi lar processes to standardize the formatand structure of data.

The data is loaded into the data warehouse.

This process can be explained with the example of a bank that wants toconsol idate a variety of information about a particular customer, includingthe customer's ATM activi ty, loan status, and account balances. Each ofthese di fferent sets of data is l ikely gathered by di fferent source systems.Since each source system can have i ts own naming conventions, the datathat comes from one system may be inconsistent wi th the data that comesfrom another system.

In this case, the ETL process extracts the data from the di fferent bankingsource systems, transforms i t unti l i t is standardized and consistent, andthen loads the data into the data warehouse.

Data warehouse for data storage and relational designA wel l -designed and robust data warehouse is the source of data for thedecision support system or business intel l igence system. It enables i tsusers to leverage the competi tive advantage that the business intel l igenceprovides. Data warehouses are usual ly based on relational databases orsome form of relational database management system (RDBMS) platform.These relational databases can be queried directly wi th Structured Query



Language (SQL), a language developed speci fical ly to interact wi th RDBMSsoftware. However, MicroStrategy does not require that data be stored in arelational database. You can integrate di fferent types of data sources withMicroStrategy such as text fi les, Excel fi les, and MDX Cubes. For moreinformation on accessing data stored in al ternative data sources, seeStoring and analyzing data with al ternative data sources, page 7.

The source systems described above, such as OLTP systems, are general lydesigned and optimized for transactional processing, whereas datawarehouses are usual ly designed and optimized for analytical processing.In combination with MicroStrategy tools and products, the data warehousealso provides the foundation for a robust onl ine analytical processing(OLAP) system. Analytical processing involves activi ties such as choosingto see sales data by month and selecting the appl icable metric to calculatesales trends, growth patterns, percent-to-total contributions, trend reporting,and profi t analysis.

Most data warehouses have the fol lowing characteristics:

Data access is typical ly read-only. The most common action is the selectionof data for analysis. Data is rarely inserted, updated, or deleted. This is incontrast to most OLTP source systems which must be able to handlefrequent updates as data is gathered. For more information on sourcesystems, see Source systems for data col lection, page 3.

Data is al igned by business subjects.

Data formats are uni formly integrated using an ETL process (see Extraction,transformation, and loading process, page 5).

Data history extends long-term, usual ly two to five years.

A data warehouse is populated with data from the existing operationalsystems using an ETL process, as explained in Extraction, transformation,and loading process, page 5.



The structure of data in a data warehouse and how it relates to yourMicroStrategy environment can be defined and understood through a logicaldata model and physical warehouse schema. Defining a project's logical datamodel and physical warehouse schema are important steps in preparing yourdata for a MicroStrategy project. For more information on the steps of theproject design process, see Chapter 2, The Logical Data Model andChapter 3, Warehouse Structure for Your Logical Data Model .

Storing and analyzing data with alternative data sources

Along with integrating with relational databases, which are a common typeof data warehouse, MicroStrategy can also integrate wi th a number ofal ternative data sources. A data source is any fi le, system, or storagelocation which stores data that is to be used in MicroStrategy for query,reporting, and analysis. A data warehouse can be thought of as one type ofdata source, and refers speci fical ly to using a database as your datasource.

The fol lowing are di fferent data source al ternatives which MicroStrategycan integrate wi th:

MDX Cube sources: In MicroStrategy you can integrate wi th sets of datafrom SAP BW, Microsoft Analysis Services, Hyperion Essbase, and IBMCognos TM1, which are referred to as MDX Cube sources. MicroStrategycan integrate wi th these data sources whi le simul taneously accessing arelational database effectively. For more information on connecting to andintegrating MDX Cube sources in MicroStrategy, see the MDX CubeReporting Guide.

Text files and Excel files: With MicroStrategy's Freeform SQL and QueryBui lder features, you can query, analyze, and report on data stored in textfi les and Excel fi les. As with MDX Cube sources described above,MicroStrategy can report against these al ternative data sources whi leconcurrently accessing a relational database to integrate al l of your datainto one cohesive project. For more information on using text fi les and





Excel fi les wi th the Freeform SQL and Query Bui lder features, see the MDXCube Reporting Guide.

Addi tional ly, the Data Import feature lets you use MicroStrategy Web toimport data from different data sources, such as an Excel fi le, a table in adatabase, or the resul ts of a SQL query, wi th minimum project designrequirements. For more information on how Data Import can be used tointegrate data from various data sources into your project, see Strategies toinclude supplemental data in a project, page 77.

For more information on how to use the Data Import feature, refer to theMicroStrategy Web Help.

The MicroStrategy platform

A business intel l igence platform offers a complete set of tools for thecreation, deployment, support, and maintenance of business intel l igenceappl ications. Some of the main components of the MicroStrategy platforminclude:

MicroStrategy metadata, page 10—a reposi tory that stores MicroStrategyobject defini tions and information about the data warehouse

MicroStrategy Intel l igence Server, page 12—an analytical server optimizedfor enterprise querying, reporting, and OLAP analysis

MicroStrategy Developer, page 13—an advanced, Windows-basedenvironment providing a complete range of analytical functions designed tofaci l i tate the deployment of reports

MicroStrategy Web, page 14—a highly interactive user environment and alow-maintenance interface for reporting and analysis

MicroStrategy project, page 15—where you bui ld and store al l schemaobjects and information you need to create appl ication objects such asreports in the MicroStrategy environment, which together provide a flexiblereporting environment




https://www2.microstrategy.com/producthelp/2020/MSTRWeb/WebHelp/Lang_1033/index.htm


MicroStrategy Archi tect, page 16—a project design tool , which al lows youto define al l the required components of your project from a central izedinterface

MicroStrategy Integri ty Manager, page 16—an automated report anddocument comparison tool

MicroStrategy Object Manager, page 17—a complete l i fe cycle managementtool for MicroStrategy environments that al lows you to copy objects wi thin aproject or across related projects

MicroStrategy has a range of products and components that you can instal lon di fferent operating systems. Depending on the type of setup that youhave, you can instal l various combinations of MicroStrategy components.See the Instal lation and Configuration Guide for a complete l ist of howthese products are packaged.

The MicroStrategy platform components work together to provide ananalysis and reporting environment to your user community, as shown inthe fol lowing diagram.




The sections that fol low provide a brief overview of each of thesecomponents. For more detai led information about these and the othercomponents that make up the MicroStrategy platform, refer to theInstal lation and Configuration Guide. To learn how to administer and tunethe MicroStrategy platform, see the System Administration Guide.

MicroStrategy metadataMicroStrategy metadata is a reposi tory that stores MicroStrategy objectdefini tions and information about your data warehouse. The information isstored in a proprietary format wi thin a relational database. The metadatamaps MicroStrategy objects—which are used to bui ld reports and analyzedata—to your data warehouse structures and data. The metadata alsostores the defini tions of al l objects created with MicroStrategy Developerand Web such as templates, reports, metrics, facts, and so on.

In general , report creation in MicroStrategy is achieved through usingvarious types of objects which represent your data as report bui ldingblocks. You can bui ld and manipulate several fundamental ly di fferent kindsof objects in MicroStrategy; these objects, which are described below, areal l created and stored in the metadata reposi tory.

Configuration objects—Objects that provide important information orgoverning parameters for connectivi ty, user privi leges, and projectadministration. Examples include database instances, users, groups, andso on. These objects are not used directly for reporting, but are created bya project archi tect or administrator to configure and govern the platform. Asa general rule, configuration objects are created and maintained with themanagers in MicroStrategy Developer wi thin the Administration icon. Formore information about creating and administering configuration objects,see the System Administration Guide.

Schema objects—Objects that are created in the appl ication to correspondto database objects, such as tables, views, and columns. Schema objectsinclude facts, attributes, hierarchies, and other objects which are stored inthe Schema Objects folder in MicroStrategy Developer's folder l ist. Facts,



https://www2.microstrategy.com/producthelp/2020/SystemAdmin/WebHelp/Lang_1033/index.htm



attributes, and hierarchies are three essential pieces to any businessintel l igence appl ication. These schema objects are often created andmanaged by a MicroStrategy archi tect:

Facts relate numeric data values from the data warehouse to theMicroStrategy reporting environment. Facts are used to create metrics,which are analytical calculations that are displayed on a report. Thenumber of uni ts sold is one example of a fact. Facts are discussed in moredetai l in Chapter 6, The Bui lding Blocks of Business Data: Facts.

Attributes represent the business context in which fact data is relevant. Inthe example of regional sales in the Southeast, Southeast represents theattribute or context of the sales data. Attributes are used to define the levelat which you want to view the numeric data on a report. Attributes arediscussed in more detai l in Chapter 7, The Context of Your Business Data:Attributes.

Hierarchies are groupings of attributes so that they can be displayed toreflect their relationships to other attributes. These groupings can helpusers make logical connections between attributes when reporting andanalyzing data. One of the most common examples of a hierarchy is a timehierarchy which includes attributes such as Year, Month, Quarter, and soon. Hierarchies are discussed in more detai l in Chapter 9, CreatingHierarchies to Organize and Browse Attributes.

Appl ication objects—Objects used to provide analysis of and insight intorelevant data. Appl ication objects include reports, documents, fi l ters,templates, custom groups, metrics, and prompts. Appl ication objects arecreated using schema objects as bui lding blocks. Al l appl ication objectscan be created and maintained in MicroStrategy Developer. Reports anddocuments can also be created and managed in MicroStrategy Web.Information on creating appl ication objects is in the Basic Reporting Guideand Advanced Reporting Guide.

For more information about MicroStrategy Web, see MicroStrategy Web,page 14 .





The metadata enables the sharing of objects across MicroStrategyappl ications by providing a central reposi tory for al l object defini tions.MicroStrategy Intel l igence Server evaluates the most efficient data retrievalscenario to provide excel lent query performance.

MicroStrategy metadata also faci l i tates the retrieval of data from the datawarehouse when using MicroStrategy appl ications. It converts userrequests into SQL queries and translates the resul ts of those SQL queriesback into MicroStrategy objects such as reports and documents which canbe easi ly analyzed and understood.

MicroStrategy Intelligence ServerMicroStrategy Intel l igence Server is an analytical server optimized forenterprise querying, reporting, and OLAP analysis. The important functionsof MicroStrategy Intel l igence Server are:

Sharing objects

Sharing data

Managing the sharing of data and objects in a control led and secureenvironment

Protecting the information in the metadata

MicroStrategy Intel l igence Server also provides a l ibrary of over 150di fferent sophisticated mathematical and statistical functions. Addi tional ly,you can add and define functions. For detai ls about the functions, see theFunctions Reference.

For information about how to instal l and configure MicroStrategyIntel l igence Server, see the Instal lation and Configuration Guide. For adetai led description of MicroStrategy Intel l igence Server functional i ty andtuning recommendations, see the System Administration Guide.


https://www2.microstrategy.com/producthelp/2020/FunctionsRef/index.htm




MicroStrategy DeveloperMicroStrategy Developer is an advanced, Windows-based environmentproviding a complete range of analytical functional i ty designed to faci l i tatethe deployment of reports. MicroStrategy Developer provides the projectdesigner functional i ty essential to creating both schema and appl icationobjects necessary to serve the user communities of both MicroStrategyDeveloper and Web.

Developer enables you to model appl ications using an intui tive, graphicalinterface. It provides a uni fied environment for creating and maintainingbusiness intel l igence projects. If you need to change how to view yourbusiness information or how the data is modeled, Developer provides theabi l i ty to modi fy one aspect of the appl ication without affecting the others.

Developer is where you can manage appl ication objects such as reports,fi l ters, and metrics. However, before appl ication objects are created,schema objects must fi rst exist. Schema objects al low appl ication objects tointeract wi th the data warehouse to access the data for analysis. Facts,attributes, hierarchies, and other schema objects are the bui lding blocks forappl ication objects such as reports and documents. For example, facts areused to create metrics, which are in turn used to design reports. Appl icationobjects such as reports are used to analyze and provide insight into therelevant data.

One of the other functions of MicroStrategy Developer is to create projects.Projects are discussed in Chapter 4, Creating and Configuring a Project.

The fol lowing examples highl ight some ways in which Developer al lowsyou to model your business intel l igence appl ications:

Every report or query can automatical ly benefi t from the tables you includein an appl ication. Tables in MicroStrategy are references to tables in yourdata warehouse, thus providing access to your data.

You can change the structure of a business hierarchy by re-ordering i t. Thismodi fication is necessary i f you have new requirements that require you to



add or remove new levels of data in a hierarchy. The change automatical lytakes effect in the appl ication, wi thout making any al terations to thedatabase.

After reports have been created, report designers and analysts can deploythem through di fferent interfaces, including MicroStrategy Developer,MicroStrategy Web, and MicroStrategy Office.

For information about the various components that comprise MicroStrategyDeveloper, refer to the Instal lation and Configuration Guide.

For more information about creating appl ication objects, such as reports inMicroStrategy Developer, refer to the Basic Reporting Guide

For information on advanced Developer functional i ty, see the AdvancedReporting Guide.

MicroStrategy WebMicroStrategy Web provides users wi th a highly interactive environmentand a low-maintenance interface for reporting and analysis. Using the Webinterface, users can access, analyze, and share data through any webbrowser on many operating systems. MicroStrategy Web provides ad-hocquerying, industry-leading analysis, quick deployment, and rapidcustomization potential , making i t easy for users to make informed businessdecisions.

MicroStrategy Web Universal is a version of MicroStrategy Web thatprovides the added benefi ts of also working with:

Appl ication servers such as Oracle WebLogic™, IBM WebSphere®, andApache Tomcat

Al l web servers and browsers supported by MicroStrategy Web

MicroStrategy Intelligence Server must be running for users to retrieveinformation from your data warehouse using MicroStrategy Web components.







For more information about deploying MicroStrategy Web, see the Instal lationand Configuration Guide .

Addi tional MicroStrategy defini tions, including many project-related terms,are discussed in Project connectivi ty components, page 89.

MicroStrategy projectA project is where you bui ld and store al l schema objects and informationyou need to create appl ication objects such as reports in the MicroStrategyenvironment, which together provide a flexible reporting environment. Aproject also represents the intersection of a data source, metadatareposi tory, and user community. In MicroStrategy Developer, projectsappear one level below project sources in the Folder List.

A project:

Determines the set of data warehouse tables to be used, and therefore theset of data avai lable to be analyzed.

Contains al l schema objects used to interpret the data in those tables.Schema objects include facts, attributes, hierarchies, and so on. Schemaobjects are discussed in later chapters in this guide.

Contains al l reporting objects used to create reports and analyze the data.Reporting objects include metrics, fi l ters, reports, and so on. Report objectsare covered in the Basic Reporting Guideand the Advanced ReportingGuide.

Defines the securi ty scheme for the user community that accesses theseobjects. Securi ty objects include securi ty fi l ters, securi ty roles, privi leges,access control , and so on. Securi ty and other project-level administrativefeatures are discussed in the System Administration Guide.

A project can contain any number of reports in addi tion to a number of otherobjects that support simple and advanced reporting requirements.Conceptual ly, a project is the environment in which al l related reporting isdone. A project can contain many types of objects, including appl ication









objects such as fi l ters, prompts, metrics, and reports that you can createusing schema objects such as attributes and facts.

Projects are often used to separate data from a data warehouse into smal lersections of related data that fi t user requirements. For example, you mayhave a project source separated into four di fferent projects wi th analysisareas such as human resources, sales distribution, inventory, and customersatisfaction. This al lows al l of your users in the human resourcesdepartment to use the human resources project and they do not have to lookthrough inventory data that they are not interested in.

Some key concepts to understand before you begin creating a project areas fol lows:

A project is created within a speci fied metadata reposi tory, determined bythe project source through which you create the project.

The project's warehouse location is speci fied by associating i t wi th theappropriate database instance.

The procedures associated with these concepts are explained in Creating aproduction project, page 95.

MicroStrategy ArchitectMicroStrategy includes a project design tool known as Archi tect. Archi tectal lows you to define al l the required components of your project from acentral ized interface. Archi tect also provides a visual representation of yourproject as you create i t, which helps to provide an intui tive workflow.Creating and modi fying a project using Archi tect is covered in Creating andConfiguring a Project, page 74 and Creating a Project Using Archi tect,page 116.

MicroStrategy Integrity ManagerMicroStrategy Integri ty Manager is an automated comparison tool designedto streaml ine the testing of MicroStrategy reports and documents inprojects. This tool can determine how speci fic changes in a project



environment, such as the regular maintenance changes to metadata objectsor hardware and software upgrades, affect the reports and documents inthat project.

For instance, you may want to ensure that the changes involved in movingyour project from a development environment into production do not al terany of your reports. Integri ty Manager can compare reports in thedevelopment and the production projects, and highl ight any di fferences.This can assist you in tracking discrepancies between the two projects.

You can use Integri ty Manager to execute reports or documents from asingle MicroStrategy project to confi rm that they remain operational afterchanges to the system. Integri ty Manager can execute any or al l reportsfrom the project, note whether those reports execute, and show you theresul ts of each report.

Integri ty Manager can also test the performance of an Intel l igence Server byrecording how long i t takes to execute a given report or document. You canexecute the reports or documents multiple times in the same test and recordthe time for each execution cycle, to get a better idea of the averageIntel l igence Server performance time.

For reports you can test and compare the SQL, grid data, graph, Excel , orPDF output. For documents you can test and compare the Excel or PDFoutput, or test whether the documents execute properly. If you choose not totest and compare the Excel or PDF output, no output is generated for thedocuments. Integri ty Manager sti l l reports whether the documents executedsuccessful ly and how long i t took them to execute.

For steps to configure Integri ty Manager and to create and execute anintegri ty test, see the Veri fying Reports and Documents wi th Integri tyManager chapter of the System Administration Guide.

MicroStrategy Object ManagerMicroStrategy Object Manager can help you manage objects as theyprogress through your project's l i fe cycle. Using Object Manager, you can




copy objects wi thin a project or across projects. Object Manager can copyappl ication, schema, and configuration objects.

In the MicroStrategy system, every object has an ID (or GUID) and aversion.

When you copy objects across projects wi th Object Manager, i f an objectwi th the same ID as the source object exists anywhere in the destinationproject, a confl ict occurs. Object Manager helps you to resolve the confl ict.For example, you can copy over the existing object, use the newer object,and so on. For steps to copy objects and resolve confl icts, as wel l asbackground information to understand how objects are copied, see theManaging Your Projects chapter of the System Administration Guide.

The project design process

When you create a project in MicroStrategy Developer, one of theconnections you create is between the project and your data warehouse. Inthe project, you can then create schema objects based on the columns andtables in the warehouse. The diagram below shows this high-level view ofdata model ing, schema design and implementation, and project creation,which are each covered in the fol lowing chapters:




Notice that the project design process includes a feedback loop. Designinga project is very rarely a single, l inear process. As projects are deployedand tested, new user requirements and project enhancements requiremodi fication to the ini tial project design. It is important to keep this in mindas you design your project and plan for the next phase of development.



THE LOGICAL DATAMODEL



Conceptual izing your business model andthe data on which to report

Devising a model of your business data can help you analyze the structureof the data, how its various parts interact, and can also help you decidewhat you intend to learn from the data.

This chapter describes one of the major components of data model ing: thelogical data model . A logical data model is a logical arrangement of data asexperienced by the general user or business analyst. This is di fferent fromthe physical data model or warehouse schema, which arranges data forefficient database use. The logical data model graphical ly depicts the flowand structure of data in a business environment, providing a way oforganizing data so i t can be analyzed from different business perspectives.

Overview of a logical data model

A logical data model is simi lar in concept to using a map and an i tinerarywhen going on a trip. You need to know where you are going and how toget there. You also need a plan that is visible and laid out correctly. Forexample, a simple logical data model for a retai l company can organize al lnecessary facts by store, product, and time, which are three commonbusiness perspectives typical ly associated with a retai l business.

Logical data models are independent of a physical data storage device.This is the key concept of the logical data model . The reason that a logicaldata model must be independent of technology is because technology ischanging so rapidly. What occurs under the logical data model can changewith need or wi th technology, but the blueprint remains the same, and youdo not need to start over completely.

If you are familiar with multidimensional data modeling, logical data modelingis similar to multidimensional data modeling. As the MicroStrategy platform



does not require you to define dimensions explic itly , the word logical is a moreaccurate term than multidimensional. While a multidimensional data modelmust have at least one dimension, a logical data model may or may not haveany explic itly defined dimensions.

The scope and complexi ty of a logical data model depends on therequirements of the reporting needs of the user community and theavai labi l i ty of source data. The more sophisticated and complex thereporting requirements and source data, the more complex the logical datamodel becomes.

The logical data model ing process produces a diagram simi lar to the oneshown in the fol lowing diagram:

A logical data model represents the defini tion, characteristics, andrelationships of data in a technical , conceptual , or business environment.This process can help you think about the various elements that composeyour company's business data and how those elements relate to oneanother.

Devising a logical data model for your business intel l igence environmental lows you to then consider various ways to physical ly store the business



data in the data warehouse. This is usual ly one of the fi rst steps indesigning a project, as shown in the fol lowing diagram:

This chapter provides conceptual information about logical data models, theelements that exist wi thin them, and also general instructions andguidel ines for creating these models.

A logical data model is a graphic representation of the fol lowing concepts:

Facts: Business data and measurements, page 23

Attributes: Context for your levels of data, page 25

Hierarchies: Data relationship organization, page 28

Facts: Business data and measurements

One of the fi rst things you do when you create a logical data model is todetermine the facts. Conceptual ly, you can think of facts as businessmeasurements, data, or variables that are typical ly numeric and sui table for



aggregation. Sales, Inventory, and Account Balance are some examples offacts you can use as business measurements.

Facts al low you to access data stored in a data warehouse and they formthe basis for the majori ty of users' analysis and report requirements. InMicroStrategy, facts are schema objects that relate data values (typical lynumeric data) from the data warehouse to the MicroStrategy reportingenvironment.

Facts are the bui lding blocks used to create business measurements ormetrics from which to derive insight into your data. The rest of datamodel ing consists mostly of providing context for the data that facts provideaccess to.

In a data warehouse, facts exist as columns within the fact tables. They cancome from different source systems and they can have di fferent levels ofdetai l . For example, you can capture sales data in one system and track i tdai ly, whi le you capture stock and inventory data in another system andtrack i t weekly.

To those familiar with SQL, facts generally represent the numeric columns indatabase tables on which you perform SQL aggregations, such as SUM andAVG .

For example, in the fol lowing SQL statement, the ORDER_AMT column in thewarehouse may correspond to the Order Amount fact in the MicroStrategyenvironment:

SELECT sum(a21.ORDER_AMT) EMP_NAME

FROM ORDER_FACT a21

JOIN LU_EMPLOYEE a22

ON (a21.EMP_ID = a22.EMP_ID)

WHERE a22.CALL_CTR_ID in (5, 9, 12)

In addi tion, whi le ORDER_AMT is the fact, sum(a21.ORDER_AMT)represents a metric. Metrics, which are business calculations often bui l tusing facts, are discussed in the Basic Reporting Guide.




For a more complete discussion about facts, see Chapter 6, The Bui ldingBlocks of Business Data: Facts.

Attributes: Context for your levels of data

After the facts are determined, the attributes must be identi fied. Attributesal low you to answer questions about a fact and provide a context forreporting and analyzing those facts.

For example, consider the sales figures of your company. If you wereinformed that your company had sales of $10,000, you can gather l i ttleuseful information. To make the sales figure meaningful , you would need toknow more about the source of that sales figure such as:

A time frame for the sales

Who and how many people contributed to the sales total

What products were sold from which departments

The scope of the sale, such as national , regional , local , or a single store

Attributes provide context and levels for convenient summarization andqual i fication of your data to help answer the type of questions l isted above.They are used to answer business questions about facts at varying levels ofdetai l . For example, i f your sales data is stored at the day level , a Monthattribute al lows you to see the same sales data summarized at the monthlevel .

To those familiar with SQL, attributes generally represent the non-numeric andnon-aggregatable columns in database tables. These columns are used toqualify and group fact data.

For example, in the fol lowing SQL statement, the MONTH_ID column in thewarehouse maps to the Month attribute in the MicroStrategy environment:

SELECT a11.MONTH_ID MONTH_ID,

max(a12.MONTH_DESC) MONTH_DESC,



sum(a11.TOT_DOLLAR_SALES) DLRSALES

FROM MNTH_CATEGORY_SLS a11

join LU_MONTH a12

on (a11.MONTH_ID = a12.MONTH_ID)

WHERE a11.MONTH_ID in

(200201,200202,200203)

GROUP BY al1.MONTH_ID

Attribute forms contain addi tional descriptive information about a givenattribute and are discussed in terms of the logical data model in Attributeforms, page 39.

For a complete discussion about attributes, refer to Chapter 7, The Contextof Your Business Data: Attributes.

Attribute elements: Data level valuesAttribute elements are the unique values or contents of an attribute. Forexample, 2005 and 2006 are elements of the Year attribute whi le New Yorkand London are elements of the City attribute. On a report, attributes areused to bui ld the report and the attribute elements are displayed in rows orcolumns on the executed report.

Attribute elements also al low you to qual i fy on data to retrieve speci ficresul ts. For example, a Customer attribute al lows you to see sales data atthe customer level and you can qual i fy on the elements of the Customerattribute to see sales data for groups such as customers with last namesbeginning with the letter h.

The fol lowing diagram shows some examples of attributes and attributeelements.



By recognizing and understanding the elements of an attribute, you canbetter design your data model and project. Al though attribute elements arenot included in the logical data model , they are necessary in understandingattribute relationships.

For a discussion of Attribute elements, see Unique sets of attributeinformation: Attribute elements, page 264.

Attribute relationshipsBui lding an effective project in MicroStrategy requires you, as the projectdesigner, to have a sol id understanding of al l the attributes in the project,as wel l as how each of them relates to the other attributes.

Attribute relationships, which are associations between attributes thatspeci fy how attributes are connected, are essential to the logical datamodel . Without relationships, there is no interaction between data, andtherefore no logical structure. The relationships give meaning to the data byproviding logical associations of attributes based on business rules.

Every direct relationship between attributes has two parts—a parent and achi ld. A chi ld must always have a parent and a parent can have multiplechi ldren. The parent attribute is at a higher logical level than the chi ld is.For example, in a relationship between Year and Quarter, Year is the parentattribute and Quarter is the chi ld.



Attributes are ei ther related or unrelated to each other. Examples of relatedand unrelated attributes, along with more detai led information aboutattribute relationships, are discussed in Attribute relationships, page 290.

Hierarchies: Data relationship organization

Hierarchies in a logical data model are ordered groupings of attributesarranged to reflect their relationship wi th other attributes. Usual ly the bestdesign for a hierarchy is to organize or group attributes into logicalbusiness areas. For example, you can group the attributes Year, Month, andDay to form the Time hierarchy.

In a logical data model , hierarchies contain attributes that are directlyrelated to each other. Attributes in one hierarchy are not di rectly related toattributes in another hierarchy.

For example, Year and Quarter are attributes that are usual ly di rectlyrelated to each other. One year has many quarters and both attributes are inthe Time hierarchy.

Year and Customer are attributes that are usual ly not in the same hierarchyand are not di rectly related to each other. However, i f you want to create areport that shows information about customer purchases in a particularyear, there must be some way to determine how these two attributes arerelated. Year and Customer are related through a fact. It is the existence ofa fact that ties the Time hierarchy to the Customer hierarchy. In this case,the fact is a customer purchase.

Therefore, facts exist at the intersection of hierarchies. They are identi fiedby multiple attributes, which represent the level at which a fact is stored. Agraphical example of how facts, attributes, and hierarchies are related andform a complete logical data model is shown in Sample data model , page29.

For a discussion about hierarchies, see Chapter 9, Creating Hierarchies toOrganize and Browse Attributes.



Sample data model

When al l of the components are placed in a single diagram—facts,attributes, relationships, and hierarchies—a logical data model begins totake shape.

The fol lowing diagram is an example of a logical data model :

Building a logical data model

The fi rst thing you must do before creating a logical data model is study thefactors that influence your design. Some of the things to consider whencreating a logical data model are:

User requirements, page 30

Existing source systems, page 31

Converting source data to analytical data, page 31



User requirementsThe primary goal of logical data model ing is to meet the needs of yourusers' reporting requirements. Developing such a model involves thefol lowing:

Identi fication of user requirements

Design of solutions

Evaluation of those solutions

Logical data model ing is a rei terative process, where addi tional questionsand concerns arise with each draft of the logical data model .

Your user community can consist of people wi th vastly di fferentrequirements. For example, company executives are typical ly interested inoveral l trends and may want reports showing data aggregated across thecompany and over a long period of time. Lower-level managers are typical lymore interested in data about their particular areas of responsibi l i ty. Thesemanagers may want reports about their speci fic region or store over short-and long-terms.

When creating the logical data model , you must consider al l the potentialusers and how to accommodate their varied requirements. In some cases,lack of data in the source systems can l imi t user requirements. Sometimes,to satisfy user requirements, you can derive addi tional data not found in thesource systems, as explained in Existing source systems, page 31.

User requirements are an important part of the ini tial project designprocess. However, addi tional user requirements can be encountered afterdeploying a project as users encounter areas for enhancement. In somecases, new user requirements can require you to modi fy the logical datamodel to better support the type of analysis and the retrieval of data thatusers demand.



Existing source systemsUnderstanding what data is avai lable is an important step in creating alogical data model . Existing data is usual ly abundant, consisting of a largenumber of facts and attributes. You must determine what facts and attributesin the existing data are necessary for supporting the decision supportrequirements of your user community.

Whi le a review of your data is ini tial ly helpful in identi fying components ofyour logical data model , you may not find al l the facts and attributes to meetyour needs within the data i tsel f. The existing data should suggest anumber of facts, attributes, and relationships, but a substantial portion ofthe work in creating a sui table logical data model involves determiningwhat addi tional components are required to satisfy the needs of the usercommunity.

For example, an insurance company's transactional system records data bycustomer and ci ty, but the business analysts want to see data for di fferentstates or regions. State and region do not appear in the existing sourcedata and so you need to extract them from another source. Addi tional ly,al though data is stored at a dai ly level in the source system, users alsowant to see data at the monthly or yearly level . In this case, you can planaddi tional attributes to provide the levels at which you intend to analyze thefacts in your data model .

Al though some data may not exist in a source system, this does not meanthat i t should not be included in the logical data model . Conversely,everything you find in the source data does not necessari ly need to beincluded in the logical data model . User requirements should drive thedecision on what to include and what to exclude.

Converting source data to analytical dataIf there are no existing systems and you are just beginning your datawarehousing ini tiative, you can bui ld the logical data model based heavi lyon current user requirements. However, most logical models begin wi th anexamination of the source data once existing systems are developed and



implemented. The source data usual ly has some sort of documentedphysical structure. For example, most OLTP systems have an enti tyrelationship diagram (ERD). An ERD provides a graphical representation ofthe physical structure of the data in the source system, which lets youeasi ly recognize tables and columns and the data stored in those columns.

A logical data model is s imilar in concept to an ERD. However, in this guide thelogical data model also takes into account how your data can be integrated intoMicroStrategy to develop a business intelligence solution.

Whether you start from nothing or have an existing source system to use,the steps to create a logical data model are as fol lows:

Step 1: Identi fy the facts, page 32

Step 2: Identi fy the attributes, page 33

Step 3: Determine attribute relationships, page 34

Step 4: Define hierarchies, page 35

The details in these steps are related to using an existing source system.

Step 1: Identify the facts

Using your existing data, make a l ist of al l data that can be represented asfacts in MicroStrategy. Remember that facts can be calculated and areusual ly numeric and aggregatable, for example, sales and profi t figures.After you have al l the facts l isted, determine the business level at whicheach fact is recorded. For example, in retai l models, sales facts are oftenstored at the store, i tem, or day level , meaning that a sale takes place in aparticular store, for a particular i tem, on a particular day. A productinventory fact, however, can be stored at the region, i tem, or week level .These business levels become the attributes in your logical data model(see Step 2: Identi fy the attributes, page 33).



Step 2: Identify the attributes

Uncover attributes by considering the levels at which you would l ike to viewthe facts on your reports. Start by looking at the levels at which each fact isrecorded and bui ld from there.

For example, in the existing data there may be fact data recorded only atthe day level . However, your users are interested in analyzing data at morethan just at the day level . They also want to view their data at the year,month, and week levels. This information may only be apparent to you afteryou deploy your project and you determine that a high percentage of yourusers are viewing sales data at the yearly level . This analysis requiresMicroStrategy to aggregate the sales data from the day level to the yearlevel . To improve performance and meet the requirements of the majori ty ofyour users, you can include an aggregate table that stores sales data at theyear level (see Using summary tables to store data: Aggregate tables, page370). You can then design a Year attribute for your project. This practice issometimes a reaction to user requirements establ ished after projectdeployment, but such considerations should be taken into account duringyour ini tial project design ini tiative.

Be careful not to include more facts and attributes than necessary. It is usuallyunnecessary to bring all data from the source system into the analyticalenvironment. Only include facts and attributes that can serve your user



community. Logical data modeling is an iterative process; if necessary, youcan always add more attributes and facts later.

Step 3: Determine attribute relationships

Once you have identi fied your data to be defined as attributes inMicroStrategy, you must then determine which attributes are related to eachother. For example, in a project, opportuni ty information is stored with anOpportuni ty attribute which is directly related to the attributes Opportuni tyClose Date, Opportuni ty Open Date, Primary Competi tor, and so on. Theseattributes are al l related to the Opportuni ty attribute because they al lanswer questions about opportuni ty information.

Addi tional ly, you should determine the type of relationship. For example, inthe diagram below, Year has a one-to-many relationship to Month, andMonth has a one-to-many relationship to Day. This one-to-manyrelationship speci fies that, for every year, several months exist, and forevery month, several dates exist. From the reverse perspective the samerelationship speci fies that, for a number of dates (in a form such as12/01/2005), only one month exists (in a form such as Dec 2005), and for anumber of months, only one year exists.



This example may not accurately define how you store time information.Consider the Year to Month attribute relationship type of one-to-many. If youdefine the attribute Month as simply the month name (Dec, Jan, and so on) andnot directly connected to a year (Dec 2005, Jan 2006, and so on) then therelationship would become many-to-many.

If you have documentation for the existing data, such as an ERD, i t is l ikelythat the documentation provides some addi tional detai ls about the nature ofthe data and any inherent relationships.

Attribute relationships are discussed in detai l in Attribute relationships,page 27.

Step 4: Define hierarchies

Hierarchies provide a structure for your data and can help your users easi lyand intui tively browse for related attributes and include them in a report. Inthe context of a logical data model , think of hierarchies as logicalarrangements of attributes into business areas. For example, you canorganize al l time-related attributes into the Time hierarchy. You can have aCustomer hierarchy containing al l attributes related to your customers and aSuppl ier hierarchy for al l attributes related to suppl ier data.



Depending on the complexity of your data and the nature of your business, youmay have very few hierarchies or you may have many. It is possible that allthe data is directly related, in which case you may have one big hierarchy.Again, the requirements of your user community should help you determinewhat hierarchies are necessary.

Logical data modeling conventions

There are numerous logical data model ing conventions you can use toenhance your logical data model . These include:

Unique identi fiers, page 37

Another enhancement to the logical data model is the addi tion ofcardinal i ties and ratios for each attribute. Cardinal i ty is the number ofunique elements for an attribute and ratios are the ratios between thecardinal i ties of related attributes., page 38

Attribute forms, page 39

These logical model ing conventions can provide cues for systemoptimization opportuni ties, help wi th system maintenance, and make for amore robust logical data model . Al though the user community is the ul timatebeneficiary of a wel l -optimized and maintained system, these conventions



are primari ly intended for project designers, administrators, and advancedreport designers.

Each convention adds more information about the data to the logical datamodel . This addi tional information can be particularly useful to a personlearning about the system.

Unique identifiersAn addi tional model ing convention is to add unique identi fiers for eachattribute and fact. Unique identi fiersdenote the key that maps an attribute toi ts source data in the source system, when appl icable. This information canhelp define primary keys in the physical warehouse schema (see Uniquelyidenti fying data in tables with key structures, page 44).

Remember that facts are usual ly identi fied by multiple attributes andtherefore wi l l have multiple unique identi fiers. The fol lowing diagram showsa logical data model wi th unique identi fiers added. Some attributes rely onmore than one ID column to identi fy i ts elements. For example, note theItem attribute, which requires both the Item_ID and Class_ID columns touniquely identi fy i ts elements.



Cardinalities and ratiosAnother enhancement to the logical data model is the addi tion ofcardinal i ties and ratios for each attribute. Cardinal i ty is the number ofunique elements for an attribute and ratios are the ratios between thecardinal i ties of related attributes.

Cardinal i ties help the database administrator estimate the size of the datawarehouse and help project designers determine the best paths for users tonavigate through the data using hierarchies in MicroStrategy, which arediscussed in Chapter 9, Creating Hierarchies to Organize and BrowseAttributes. Ratios can be particularly helpful when trying to decide wherecreating aggregate tables wi l l be most effective. This addi tional informationcan be invaluable to database administrators and project designers.

The fol lowing diagram shows a logical data model which includescardinal i ties and ratios. Note the cardinal i ties in the upper right corner of



each attribute rectangle and the ratios next to some of the relationshipsbetween attributes. Also note that the cardinal i ty of some attributes such asDate of Birth are unknown; this is because this information varies and isunpredictable. For example, i t is impossible to determine how manycustomers have di fferent dates of bi rth in the warehouse.

Attribute formsIncluding attribute forms in your logical data model can help you get a morecomplete view of al l of the information that is made avai lable in yourproject.

Attribute forms contain addi tional descriptive information about a givenattribute. For example, you create an attribute cal led Customer to representcustomers in your system, and i t is part of the Customer hierarchy. Eachelement of the Customer attribute represents a di fferent customer, and inthe data, you store the fol lowing information about your customers:



Customer number (some numeric code used to uniquely identi fy customers)

First name

Last name

Address

Emai l address

In your logical data model , you could have included each of these pieces ofinformation as separate attributes, each with a one-to-one relationship tothe Customer attribute. In real i ty, though, these attributes simply provideaddi tional information about the Customer attribute; they do not representdi fferent levels wi thin the Customer hierarchy. When a one-to-onerelationship exists between an attribute and one of i ts descriptions, you canmodel these addi tional pieces of descriptive information as attribute forms.The fol lowing diagram shows how you add attribute forms to a logical datamodel :

Attribute forms are discussed in terms of their role in MicroStrategy in Columndata descriptions and identi fiers: Attribute forms, page 270 .



WAREHOUSESTRUCTURE FOR YOURLOGICAL DATA MODEL



Physical Warehouse Schema

As discussed in the previous chapter, the logical data model can help youthink about the logical structure of your business data and the manyrelationships that exist wi thin that information.

The physical warehouse schema is based on the logical data model . It is adetai led graphic representation of your business data as i t is stored in thedata warehouse. The physical warehouse schema organizes the logicaldata model in a method that makes sense from a database perspective.

In contrast, the logical data model is a logical arrangement of data from theperspective of the general user or business analyst. For more information onwhat a logical data model is and how to create one, see Chapter 2, TheLogical Data Model .

The logical data model is only concerned with logical objects of thebusiness model , such as Day, Item, Store, or Account. Several physicalwarehouse schemas can be derived from the same logical data model . Thestructure of the schema depends on how the data representing those logicalobjects are to be stored in the warehouse. For example you can storelogical objects in the same table, in separate tables, dupl icated acrossseveral tables, or in some other arrangement.

Whi le the logical data model tel ls you what facts and attributes to create,the physical warehouse schema tel ls you where the underlying data forthose objects is stored. The physical warehouse schema describes howyour data is stored in the data warehouse and how it can be retrieved foranalysis.

Creating a physical warehouse schema is the next step in organizing yourbusiness data before you create a project, as shown below:



The key components that make up the physical warehouse schema arecolumns and tables.

Columns and tables in the physical warehouse schema represent facts andattributes from the logical data model . The rows in a table representattribute elements and fact data.

Columns: Data identifiers and values

Columns are fields in the warehouse that contain attribute and fact data.The types of columns are:

ID columns contain attribute element identi fication codes. These codes aretypical ly numeric because computers can process numbers much morerapidly than text. Al l attributes must have an ID column.

Description columns contain descriptions (text or numeric) of attributeelements. Description columns are optional .



An ID column can serve a dual purpose as both an ID and description.Date is one example of an attribute that usual ly does not have adescription column.

The majori ty of attributes typical ly have an ID column and at least onedescription column. If an attribute has many attribute forms—addi tionaldescriptive information about a given attribute—they are represented byaddi tional description columns.

Fact columns contain fact data.

Tables: Physical groupings of related data

The di fferent types of tables are

Lookup tables: Attribute storage, page 45

Relate tables: A unique case for relating attributes, page 47

Fact tables: Fact data and levels of aggregation, page 48

While each type of table may function di fferently wi thin the data warehouse,each type of table can be assigned a primary key that uniquely identi fiesthe elements wi thin the given table.

Uniquely identifying data in tables with key structuresIn relational databases, each table has a primary key that creates a uniquevalue identi fying each distinct data record or row. This appl ies to every typeof table wi thin the data warehouse.

The types of keys that can be assigned to a table include:

Simple key requires only one column to identi fy a record uniquely wi thin atable.

Compound key requires multiple columns to identi fy a unique record.

Which key structure you use to identi fy a unique attribute in a tabledepends on the nature of your data and business requirements. The



fol lowing diagram shows how the di fferent key structures can be used toidenti fy a cal l ing center.

The simple key shows how you can identi fy a cal l ing center wi th only i tsCall_Ctr_id . This means that every cal l ing center has i ts own unique ID.

In the compound key, cal l ing centers are identi fied by both Call_Ctr_id

and Region_id . This means that two cal l ing centers from different regionscan share the same Call_Ctr_id . For example, there can be a cal l ingcenter wi th ID 1 in region A, and another cal l ing center wi th ID 1 in regionB. In this case, you cannot identi fy a unique cal l ing center wi thout knowingboth the Call_Ctr_id and the Region_id .

Simple keys are general ly easier to handle in the data warehouse than arecompound keys because they require less storage space and they al low forsimpler SQL. Compound keys tend to increase SQL query complexi ty, querytime, and required storage space. However, compound keys have a moreefficient ETL process.

Which key structure you use for a particular attribute depends enti rely onthe nature of the data and your system. Consider what key structures workbest when creating lookup tables in the physical warehouse schema.

For information on defining the primary key for tables included in aMicroStrategy project, see Defining the primary key for a table, page 511.

Lookup tables: Attribute storageLookup tables are the physical representation of attributes. They providethe abi l i ty to aggregate data at di fferent levels. Lookup tables store theinformation for an attribute in ID and description columns (see Columns:Data identi fiers and values, page 43).



Depending on how you choose to organize the physical schema, a lookuptable can store information for one or more related attributes. If a table onlystores data about one attribute, i t is said to be a normal ized table. If a tableholds data about mul tiple attributes, i t is said to be a denormal ized table.

The fol lowing diagram shows the di fferent ways in which you can organizethe same attribute information. Notice that the denormal ized table holds theexact same data as the normal ized tables. Whi le the denormal ized tableconsol idates information about attributes within one table, the normal izedtables each contain only a subset of al l of the information about theattributes.

You can use ei ther structure for any table in the physical warehouseschema, though each structure has i ts advantages and disadvantages, asexplained in the fol lowing sections and outl ined in the table in Schema typecomparisons, page 62.

Attribute relationships and lookup table structure

Attribute relationships are a major factor in determining the structure oflookup tables in a physical warehouse schema. In general , the fol lowingguidel ines apply:



One-to-one relationships usual ly denote the existence of an attribute form.The description column of an attribute form should simply be included as anaddi tional column in the attribute's lookup table.

Many-to-many relationships usual ly require the use of a relate table distinctfrom ei ther attribute lookup table. A relate table should include the IDcolumns of the two attributes in question. For more information on how touse relate tables, see Relate tables: A unique case for relating attributes,page 47.

Relate tables: A unique case for relating attributesWhile lookup tables store information about attributes, relate tables storeinformation about the relationship between two attributes. Relate tablescontain the ID columns of two or more attributes, thus defining associationsbetween them. Relate tables are often used to create relationships betweenattributes that have a many-to-many relationship to each other.

With attributes whose direct relationship is one-to-many—in which everyelement of a parent attribute can relate to multiple elements of a chi ldattribute—you define parent-chi ld relationships by placing the ID column ofthe parent attribute in the lookup table of the chi ld attribute. The parent IDcolumn in the chi ld table is cal led a foreign key. This technique al lows youto define relationships between attributes in the attributes' lookup tables,creating tables that function as both lookup tables and relate tables asshown in the fol lowing diagram:



In the case of a many-to-many relationship—in which multiple elements of aparent attribute can relate to multiple elements of a chi ld attribute—youmust create a separate relate table as shown in the fol lowing diagram:

Fact tables: Fact data and levels of aggregationFact tables are used to store fact data. Since attributes provide context forfact values, both fact columns and attribute ID columns are included in facttables. Facts help to l ink indirectly related attributes. The attribute IDcolumns included in a fact table represent the level at which the facts inthat table are stored.

For example, fact tables containing sales and inventory data look l ike thetables shown in the fol lowing diagram:



For more detai ls on the level of aggregation of your fact data, see Facttable levels: The context of your data, page 51.

Base fact columns versus derived fact columns

The types of fact columns are base fact columns and derived fact columns:

Base fact columns are represented by a single column in a fact table. Thefol lowing diagram shows an example of a fact table and base fact columns:



Derived fact columns are created through a mathematical combination ofother existing fact columns. The fol lowing diagram shows an example of afact table and how you can create a derived fact column from base factcolumns:

In the example, the derived fact Tot_Dollar_Sales is created using theQty_Sold , Unit_Price , and Discount fact columns. Also, the derivedfact exists in several tables, including Item_Mnth_Sls and City_Ctr_

Sls .

Because facts in di fferent fact tables are typical ly stored at di fferent levels,derived fact columns can only contain fact columns from the same facttable.

There are advantages and disadvantages to consider when deciding i f youshould create a derived fact column. The advantage of storing derived factcolumns in the warehouse is that the calculation of data is previouslyperformed and stored separately, which translates into simpler SQL and aspeedier query at report run time. The disadvantage is that derived factcolumns require more storage space and more time during the ETL process.

You can create the same type of data analysis in MicroStrategy with the useof metrics. Metrics al low you to perform calculations and aggregations on



fact data from one or more fact columns. For more information on whatmetrics are and how to create them, see the Advanced Reporting Guide.

For more information on the di fferent types of facts in MicroStrategy andhow they are defined, see How facts are defined , page 219.

Fact table levels: The context of your data

Facts and fact tables have an associated level based on the attribute IDcolumns included in the fact table. For example, the fol lowing image showstwo facts wi th an Item/Day/Cal l Center level .

The Item_id , Day_id , and Call_Ctr_id columns in the table aboverepresent practical levels at which sales and inventory data can beanalyzed on a report. The Sales and Inventory facts can be analyzed at thei tem, day, and cal l center levels because those levels exist as ID columnsin the fact table.

You do not need to include more lookup column IDs than are necessary fora given fact table. For example, notice that the table above does not includethe Customer_id column; this is because analyzing inventory data at thecustomer level does not resul t in a practical business calculation. Facttables should only include attribute ID columns that represent levels atwhich you intend to analyze the speci fic fact data.

The levels at which facts are stored become especial ly important when youbegin to have complex queries wi th multiple facts in mul tiple tables that arestored at levels di fferent from one another, and when a reporting requestinvolves sti l l a di fferent level . You must be able to support fact reporting atthe business levels which users require.




Homogeneous versus heterogeneous column namingSuppose the data warehouse has information from two source systems, andin one source system regions are identi fied by column name Region_id

and in the other the column name is Reg_id , as shown in the diagrambelow. These naming inconsistencies occur because source systems usedi fferent naming conventions to name the data they col lect.

Though the Region_id and Reg_id columns have di fferent names, theystore the same data: information about regions. This is cal ledheterogeneous column naming.

The data for the Lookup_Region table came from a di fferent sourcesystem than the data for the Lookup_Call_Ctr and the source systemshave di fferent naming conventions. This explains why the same informationabout regions is represented by two columns with di fferent names.

When you define facts and attributes in MicroStrategy Developer, considerthe heterogeneous column names that may exist in your source systems. Inorder for reports to retrieve accurate and complete resul ts, heterogeneouscolumns must be mapped to their corresponding facts and attributes.

For example, i f you create a Region attribute given the tables in theexample above, you must map both the Region_id and Reg_id columnsto the attribute so al l information about regions is calculated correctly anddisplayed on reports when the Region attribute is used.



For consistency, i t is a good idea for columns that contain the same data tohave the same column name. This is cal led homogeneous column naming.In this case, the Region_ID column has the same name in both tables, asshown in the fol lowing diagram:

Just as i t is possible for the same attribute data to exist in di fferent lookuptables, i t is also possible for the same fact data to exist in di fferent facttables. A fact column may or may not have the same name in di fferenttables, as shown below:



Schema types: Data retrieval performance versusredundant storage

There are many ways to structure your data warehouse and no method isinherently right or wrong. How you choose to structure the warehousedepends on the nature of your data, the avai lable storage space, and therequirements of your user community. Typical ly, one of the schema types,or a combination of them, is used to organize the physical schema toenhance query performance whi le maintaining an acceptable amount ofdata storage space. These schema types are:

Highly normal ized schema: Minimal storage space, page 55

Moderately normal ized schema: Balanced storage space and queryperformance, page 56

Highly denormal ized schema: Enhanced query performance, page 58

In each of these schemas a base fact table and any number of aggregatefact tables are used (For more information about aggregate fact tables, seeUsing summary tables to store data: Aggregate tables, page 370). Facttable keys consist of attribute keys relevant to the level of data stored in thetable. The schema examples that fol low show data at the Item/Cal lCenter/Date level .

When comparing the di fferent schema types, you should keep in mind thefol lowing concepts:

Redundant data can cause a couple of drawbacks. The most obviousdrawback is that redundant data requires more storage space to hold thesame amount of data as a system with no redundancy.

Data redundancy also makes updating data a more intensive anddi fficul t process because data resides in multiple places. With no dataredundancy, data only has to be updated in a single place.



Joins are SQL operations that are required to combine two tables togetherin order to retrieve data. These operations are necessary, but as with anyoperation performed on your data warehouse, the number of joins requiredto bui ld your queries affects the performance of those queries.

The sections below are not meant to be an exhaustive l ist of al l possibleschema types. However, the sections below are meant to give a descriptionof the most common or general schema types that are used to develop aphysical warehouse schema.

Highly normalized schema: Minimal storage spaceThe fol lowing diagram is an example of a highly normal ized schema. Inhighly normal ized schemas, lookup tables contain unique developer-designed attribute keys, such as Call_Ctr_id , Dist_Ctr_id , andRegion_id , as shown in the figure below. They also contain attributedescription columns, such as Call_Ctr_desc , Dist_Ctr_desc , andRegion_desc . Also, the lookup table for an attribute contains the IDcolumn of the parent attribute, such as Dist_Ctr_id in the Lookup_

Call_Ctr table.



The fol lowing diagram shows what physical lookup tables look l ike in thewarehouse:

One benefi t of using a highly normal ized schema is that i t requires minimalstorage space in the warehouse because of i t uses smal ler lookup tablesthan the other schema types.

However, there is a drawback to using only smal l tables in the datawarehouse. When accessing higher-level lookup tables such as Lookup_

Region in the example above, numerous joins are required to retrieveinformation about the higher-level tables. This is because each tablecontains only a smal l amount of information about a given attribute;therefore, mul tiple tables must be joined unti l the required column is found.

Moderately normalized schema: Balanced storage space andquery performanceThe fol lowing diagram shows an example of a moderately normal izedschema. This schema type has the same basic structure as the highlynormal ized schema. The di fference here is the higher-level attribute ID



columns are present wi thin al l tables of related attributes. For example,Region_id is included in the Lookup_Call_Ctr table.

The fact table structure within a moderately normal ized schema is identicalto that of the highly normal ized schema. The fol lowing diagram shows whatthe physical lookup tables look l ike in the warehouse.



Using a moderately normal ized schema provides a balance between thepros and cons of normal ized and denormal ized schema types. Because theID columns of both the parents and grandparents of an attribute exist inmul tiple tables, fewer joins are required when retrieving information aboutan attribute.

However, since some tables contain the same ID columns (as shown abovewith the Region_ID column), the tables within this type of schema take upsome redundant storage space in the warehouse.

Highly denormalized schema: Enhanced query performanceThe fol lowing diagram is an example of a highly denormal ized schema. Ahighly denormal ized schema has the same basic structure as the other twoschema types. With this type, not only are higher-level attribute ID columnspresent wi thin al l related tables, but the description columns are present aswel l . For example, Region_desc is included in the Lookup_Call_Ctr

table.



Using a highly denormal ized schema further reduces the joins necessary toretrieve attribute descriptions. For example, you can include thedescriptions of Cal l Center, Distribution Center, and Region along withSales Dol lars in the same report whi le only having to join the Lookup_

Call_CTR and Fact_Sales tables. This is possible because Lookup_

Call_CTR contains al l information (including description data) for Cal lCenter as wel l as for Distribution Center and Region.

However, this schema type requires the largest amount of storage spacewithin the warehouse because of i ts large lookup tables. High denormal izedschemas also cause the highest level of data redundancy.

Star schema: Consolidating lookup tables

When using the highly denormal ized schema, i t is possible to el iminatemost of the lookup tables and leave just a few, as shown below. Arrangingthe warehouse schema this way produces a star schema. In this type of



schema, the lookup tables are consol idated so that every attribute ID anddescription column for a given hierarchy exists in one table.

Recal l that in a highly denormal ized schema, each hierarchy (for example,geography) consists of several lookup tables. In a star schema, however,only one lookup table is used to contain al l of the attribute IDs anddescription columns for a given hierarchy, as shown below:

As with any schema type model there are advantages and disadvantages tousing a star schema. As with a highly denormal ized schema type, theamount of join operations are reduced by using a star schema. A starschema can also reduce the amount of storage space necessary in a highlydenormal ized schema. However, star schemas can often require largelookup tables that can take a more time to search than the smal ler tablesthat are used in the other schema types.



Design trade-offs

Constructing a logical data model and physical warehouse schema is ani terative process of compromises and trade-offs. The fol lowing diagramshows the three major requirements that must be balanced to create aneffective system.

Each of these categories affects the others. If you try to satisfy every singleuser requirement from the simplest to the most complex, you wi l l have tocreate an extensive data model and schema to support those requirements.This resul ts in an increased load on the warehouse, slower queryperformance, and greater maintenance for the database administrator. Youmust decide which factors are most important in your particular environmentand weigh them against the other factors.

For example, i f you have the storage space necessary to accommodate datain a star schema it may seem that you would never want to normal ize yourschema. However, SQL queries directed at a consol idated table require theuse of a DISTINCT operator and these types of queries tend to be very



expensive in terms of database resources and processing time. The use ofa resource-intensive DISTINCT query could therefore negate anyperformance gain achieved by reducing the number of joins betweenhigher-level lookup tables.

In addi tion to the previous points, you may need higher level lookup tablesto take advantage of aggregate tables, which are discussed in Usingsummary tables to store data: Aggregate tables, page 370.

For more comparisons between the di fferent schema types described in thischapter, see the fol lowing section Schema type comparisons, page 62.

Schema type comparisons

One way to achieve a balance of the various trade-offs in your schemadesign is to use a variety of schema types in your physical warehouseschema. One hierarchy can be highly normal ized whi le another can behighly denormal ized. You can even use di fferent schema types within thesame hierarchy. The table below compares the di fferent schema types.

Schema TypeLookup TableStructure

Advantages Disadvantages

Highlynormalizedschema

• At t ribute ID

• At t ributedescript ioncolumn

• ID column ofparent

Minimal storage space andminimal data redundancywhich makes updat ingdata less intensive thanfor the other schema types

Requires numerous joins toretrieve informat ion fromhigher-level lookup tables

Moderatelynormalizedschema

• At t ribute ID


• ID column of

Great ly reduces thenumber of joins necessaryto relate an at t ribute to itsgrandparents as comparedto a highly normalizedschema

Requires some redundantstorage



Schema TypeLookup TableStructure

Advantages Disadvantages

parent

• ID column ofgrandparents

Highlydenormalizedschema

• At t ribute ID


• ID column ofparent

• descript ioncolumn ofparent

• ID column ofgrandparents

• descript ioncolumn ofgrandparents

Further reduces joinsnecessary to retrieveat t ribute descript ions ascompared to a moderatelynormalized schema

Requires the most storagespace and redundant datarequires a more intensiveprocess to update

Star schema

• Consolidatesan ent irehierarchyinto a singlelookup table

• Further reduces joinsnecessary to retrieveat t ribute descript ions ascompared to amoderately normalizedschema

• Requires less storagespace and dataredundancy than ahighly denormalizedschema and thus data iseasier to update

Large lookup tables cannegat ively af fect queryperformance whensearching tables andrequiring DISTINCT

operat ions to be performed



Now that you have gained an understanding of data model ing and the rolesof facts and attributes, you can learn about these same schema objects interms of how they exist in the MicroStrategy environment. As facts andattributes are the cornerstones of the reports you intend to create usingMicroStrategy, i t is essential to understand the structure of each of theseschema objects before creating a project.

Supporting data internationalization

MicroStrategy supports the international ization of your data into thelanguages required for your users. This al lows data to be displayed invarious languages that can reflect the user's language preferences.

To provide data in various languages you must include the translated datain your database. The strategy you use to include translated data in yourdatabase depends on many factors. Some guidel ines are provided below tohelp define your strategy so that international ization can be supported andintegrated easi ly into your MicroStrategy projects:

International ization through tables and columns or databases, page 64

Supporting various character sets wi thin databases, page 69

For a complete overview of international ization in MicroStrategy, see theSystem Administration Guide.

Internationalization through tables and columns or databasesMicroStrategy supports data international ization through two di fferenttechniques. You can ei ther provide translated data through the use of extratables and columns, or you can provide separate databases to store yourtranslated data. These techniques are described below:

Using tables and columns for international ization, page 65

Using separate databases for international ization, page 68




Using tables and columns for internationalization

You can support data international ization in your database by usingseparate tables and columns to store your translated data. You can usevarious combinations of tables and columns to support and identi fy thetranslated data in your database.

For example, the MicroStrategy Tutorial project includes a Month of Yearattribute which retrieves i ts primary information in Engl ish from the LU_

MONTH_OF_YEAR table shown below:

To support displaying the name of each month in multiple languages, youcan include the translated names in a separate column, one for eachrequired language, wi thin the same table. Each column can use a suffix toidenti fy that the column contains translated data for a certain language. Thesame LU_MONTH_OF_YEAR table wi th translated data for the Spanish andGerman languages is shown below:

The data for Spanish is included in a MONTH_OF_YEAR_NAME column withthe suffix _ES , and the data for German is included in a MONTH_OF_YEAR_

NAME column with the suffix _DE .



As an al ternative to supplying translations by using separate columns in thesame table, you can create separate tables for your translations. Each tablecan share the same column name for the same data in di fferent languages.In the tables below, the Spanish and German data is provided in separateSpanish and German tables:

The data for Spanish is included in a LU_MONTH_OF_YEAR table wi th thesuffix _ES , but the MONTH_OF_YEAR column shares the same column nameas in the Engl ish LU_MONTH_OF_YEAR table. The data for German usesthe same technique and is stored in a LU_MONTH_OF_YEAR table wi th thesuffix _DE .

You can also use both techniques (separate tables and extra columns inone table) to store and identi fy your translated data. This can be helpful todistinguish the language used for each table and column. It can also behelpful i f you have a primary language stored in one table, and you store al linternational izations in an international ization table. For example, you canstore the Spanish and German data in the same international ization table,as shown below:



In this scenario, the LU_MONTH_OF_YEAR_LANG table includes al ltranslations in al l languages other than the primary language, for theMONTH_OF_YEAR_NAME column. Each column is assigned a suffix toidenti fy the language of the translated data.

In the examples above, suffixes on tables and columns are used to identify thelanguage of the translated data. While it is not a requirement to use suffixes forthese identification purposes, it is the easiest method to define and support inMicroStrategy. Using prefixes or other naming conventions requires you touse some functions to recognize the location of the translated data.

If your project supports data internationalization, you cannot use logical v iewsas lookup tables for attributes that use translated data. For information onlogical v iews, see Appendix B, Logical Tables.

For information on defining your project to use tables and/or columns toenable data international ization, see Enabl ing data international izationthrough SQL queries, page 107.



Using separate databases for internationalization

You can support data international ization in your database by usingseparate databases for each supported language. A user can then begranted access, through connection mappings, to the database thatcontains their preferred language.

For example, the MicroStrategy Tutorial project includes a Month of Yearattribute which retrieves i ts primary information in Engl ish from the LU_

MONTH_OF_YEAR table shown below:

For the purposes of this example, you can assume this data is stored in adatabase named Tutorial (Engl ish). You also provide your projects inSpanish and German, which means you must have a database for Spanishand a database for German. Each database contains the same tablestructure, column structure, and naming conventions, but includestranslated data, as shown below:



This method of data international ization requires that the same data isavai lable in each international ized database.

If your project supports data internationalization, you cannot use logical v iewsas lookup tables for attributes that use translated data. For information onlogical v iews, see Appendix B, Logical Tables.

For information on defining your project to use separate databases toenable data international ization, see Enabl ing data international izationthrough SQL queries, page 107.

Supporting various character sets within databasesLanguages require a wide range of character sets to represent data. Tosupport the languages you plan to use in your MicroStrategy projects, you



must use databases that support the required character sets and areconfigured accordingly. To determine whether your database supports thecharacter sets required for the languages you want to support, refer to yourthi rd-party database documentation. For best practices information onsupporting international ization in MicroStrategy, see the SystemAdministration Guide.

Supporting map data and Geo Location

MicroStrategy can display data as part of an interactive map, which caninclude important information along with addi tional geographicalinformation. This geographical data can be displayed using features suchas the Map visual ization avai lable wi th Visual Insight, or through using theMap widget. This can quickly show you analysis such as the profi t of storeson the east coast.

The Map widget can also use geographical data to return the location of aMicroStrategy Mobi le user, which can be used to perform addi tionalanalysis. For example, the current location can be used to return detai ledinformation on the company's five closest distribution centers. Thisinformation can then be displayed in a map format on the device, as shownin the example below:





To uti l ize these geographical location features in MicroStrategy, you musthave location data stored in your data source. MicroStrategy requireslati tude and longi tude data to recognize a geographical location.

You can use various methods to develop a l ist of geographical locations.The procedure below uses a thi rd-party free uti l i ty to determine val idlati tude and longi tude values.

The third-party product discussed in this document is manufactured byvendors independent of MicroStrategy. MicroStrategy makes no warranty,express, implied, or otherwise, regarding this product, including itsperformance or reliability .

To create location data to support mapping features in MicroStrategy

To create location data

In the data source of your choosing, you must create the location datafor the locations that can be recognized when using mapping features in



MicroStrategy. This location data must include both a lati tude andlongi tude, along with any descriptive information required to bedisplayed for each location. This procedure uses a thi rd-party free uti l i tyto determine val id lati tude and longi tude points for given addresses.

In a web browser, go to the fol lowing URL:

http://www.gpsvisualizer.com/geocoder/

The GPS Visual izer's Address Locator opens.

In the Input field, type the address to determine the lati tude and longi tudefor. For example, 1600 Pennsylvania Avenue Washington DC 20500.

You can return lati tude and longi tude for mul tiple addresses at the sametime. This procedure provides the steps on how to return the lati tude andlongi tude for a single address.

In the Source drop-down l ist, select Google.

Select the Include extra fields in output (precision, city, country, etc.)check box to include addi tional information about the location. Thisaddi tional information is not required, but i t can provide addi tional detai lsthat can be displayed as part of the location.

Cl ick Start geocoding . When the page has refreshed, cl ick Create a GPXfile. A new page opens with xml script. The lati tude and longi tude valuesare embedded in the xml as "lat" and "lon," respectively. In the examplepicture below, these values are highl ighted.

Include the values in quotation marks after lat= and lon= as the lati tude andlongi tude of the location, respectively. You must store this data asnumerical values that can support the decimal precision of these values.



Include any addi tional information in your data source for each location thatyou store a lati tude and longi tude for. This can be information returned fromthe geographical location search as wel l as data pertinent to your needs.For example, i f you are storing addresses for distribution centers, you caninclude the name of the distribution center as wel l as any other pertinentinformation.

Repeat the previous steps in this procedure for al l locations that you wantto support when using mapping features in MicroStrategy.

If you do not have an entry for a given latitude and longitude point, noinformation can be returned for that geographical location.

To integrate location data with the Map widget

In MicroStrategy, create an attribute that can return al l the location data foreach entry. Separate attribute forms should be created for lati tude andlongi tude, and should also support the numeric data of these values. Thelati tude and longi tude attribute forms can serve as values to identi fy eachattribute element. Attributes that use multiple attribute forms as their ID formare referred to as compound attributes. For addi tional detai ls on creating anattribute, see Chapter 7, The Context of Your Business Data: Attributes. Forinformation on using two attribute forms to identi fy each attribute element,see Attributes with multiple ID columns: Compound attributes, page 315.

If you have addi tional descriptive information that you want to makeavai lable for display, create addi tional attribute forms for that descriptiveinformation.

After creating this attribute, you can:

Create a Map widget to display this location data. For information oncreating a Map widget, see the MicroStrategy Web Help.

Use Visual Insight to create a map visual ization to display this locationdata. For information on using Visual Insight to create dashboards thatcontain mapping visual izations, see the MicroStrategy Web Help.





CREATING ANDCONFIGURING APROJECT



Once you create a logical model of your business data and arrange the datawithin the data warehouse, you are ready to create a project inMicroStrategy.

This chapter guides you through the fi rst few major steps involved increating a project in MicroStrategy. For defini tions and descriptions of thecomponents wi thin the MicroStrategy platform that al low you to create andanalyze your business intel l igence appl ications, see Chapter 1, BIArchi tecture and the MicroStrategy Platform.

To see a sample project, access the MicroStrategy Tutorial provided with theMicroStrategy platform. The Tutorial is a sample data warehouse anddemonstration project you can use to learn about the various features of theMicroStrategy platform. It is ready to be used and requires no additionalconfiguration tasks. For more information about the Tutorial, refer to the BasicReporting Guide . To view the structure of the MicroStrategy Tutorial, seeAppendix A, MicroStrategy Tutorial .





Overview of project creation

The fol lowing procedure describes the main steps to create a MicroStrategyproject. These steps provide you with a high-level view of the projectcreation process. Bear this process in mind as you proceed through the restof this guide.

The section Project connectivi ty components, page 89 defines some of thebasic terminology used in project creation in MicroStrategy Developer. It isintended to familiarize you with some of the terms discussed in this guide.

Creating the metadata reposi tory, page 93

The metadata reposi tory contains the objects and defini tions associatedwith your project. It acts as the intermediary between your business dataand your reporting environment. Therefore, the fi rst step in the projectcreation process is to create a metadata reposi tory. For detai ledinstructions, see Creating the metadata reposi tory, page 93.

Connecting to the metadata reposi tory and data source, page 93

Once the metadata reposi tory is created and populated with ini tial izationdata, you must establ ish connections to both the metadata reposi toryand data source. For detai led instructions, see Connecting to themetadata reposi tory and data source, page 93.

Creating a production project, page 95

Having created a metadata reposi tory and establ ished the necessaryconnections between the di fferent parts of your MicroStrategyenvironment, you are ready to create the basic defini tion of your project.For detai led instructions, see Creating a production project, page 95.

Creating facts and attributes, page 112

Schema objects such as facts and attributes are the basic components ofthe logical structure of a project. The business data your user communitywants to report on is represented by schema objects in MicroStrategy.



Therefore, i t is necessary to set up schema objects before reports canbe created. This step is covered in Creating facts and attributes, page112 of this chapter.

You can use Query Builder or Freeform SQL to create schema objects as youdesign reports. For more information for these features, see the AdvancedReporting Guide .

Configuring addi tional schema-level settings, page 113

Once you create the ini tial schema objects, you can configure addi tionalschema-level settings that al low you to add complexi ty and depth toobjects in your project and to the project as a whole. For example, youcan create advanced facts and attributes to retrieve speci fic resul t sets.You can also use attributes to create time-series analysis schemaobjects cal led transformations and implement various tools to optimizeand maintain your project over time. For information about:

Advanced fact creation, see Creating and modi fying simple and advancedfacts, page 212.

Advanced attribute creation, see Adding and modi fying attributes, page257.

Hierarchies and hierarchy creation, see Chapter 9, Creating Hierarchies toOrganize and Browse Attributes.

Transformations and transformation creation, see Chapter 10, CreatingTransformations to Define Time-Based and Other Comparisons.

Project optimization and maintenance, see Chapter 8, Optimizing andMaintaining Your Project.

Strategies to include supplemental data in a projectThe steps l isted in Overview of project creation, page 76 above relate to theprocess of creating a project which connects to a database or other datasource such as a text fi le or Excel fi le.





MicroStrategy also supports strategies to include supplemental data in aMicroStrategy project. These strategies include:

Connecting to data stored in SAP BW, Microsoft Analysis Services,Hyperion Essbase, and IBM Cognos TM1 systems. When integrated withMicroStrategy, these systems are referred to as MDX cube sources. Youcan connect to any of these MDX cube sources to report and analyze thedata concurrently wi thin a project that also connects to a database, or youcan create a standalone connection to your MDX cube source (see the MDXCube Reporting Guide).

Using MicroStrategy Web to import data from different data sources, suchas a fi le on your computer or Dropbox, a database table, the resul ts of aSQL query, or Facebook with minimum project design requirements.

This capabi l i ty of using MicroStrategy Web to import data, referred to asData Import, is described in detai l in Including personal ized data anddeveloping proofs-of-concept, page 78 below.

Including personalized data and developing proofs-of-concept

The Data Import feature lets you supplement the primary data of yourproject in the fol lowing ways:

For information on creating the primary data for your project, follow the stepsprovided in Overview of project creation, page 76 .

Include personal ized data from various data sources. Along with theprimary data provided in the project, your personal ized data can then bereported on using al l the standard MicroStrategy reporting and analysisfeatures. This personal ized data can also be displayed with the primarydata in your project using documents.

Develop a reporting environment as part of a proof-of-concept. Data Importis a powerful proof-of-concept tool due to i ts abi l i ty to quickly integrate datainto MicroStrategy, wi thout requiring the ful l data model ing requirementsthat are described in this guide as part of creating a project.





MicroStrategy automatical ly maps attributes, metrics, and other objects tothe data included in a MicroStrategy project using Data Import. Theseobjects are created as managed objects.

A managed object can be removed once it is no longer referenced by anotherobject in the project. The removal of unused managed objects is usuallyperformed by an administrator. For more information on removing a databaseinstance and its related managed objects, see the System AdministrationGuide .

While managed objects al low you to quickly integrate data using DataImport, the data is not di rectly related to the rest of your project schema.This means that only data integrated using a single Data Import processcan be included together on a given report; no addi tional attributes, metrics,or other objects from the project can be included.

However, rather than al lowing MicroStrategy to automatical ly createmanaged objects for the attribute data, you can map the data to existingattributes in the MicroStrategy project that are part of the relational schema.The benefi ts of using project attributes to define the data integrated intoMicroStrategy using the Data Import feature is described in Mapping data toproject attributes , page 80 below.

Dashboards provide an addi tional option that lets you include reports thatanalyze data from different data sources together inside a singledashboard. This can be accompl ished by including the reports as separatedatasets of the dashboard, and then each dataset can be displayedseparately on the dashboard as a report, graph report, widget, or otheranalysis tool .

Dashboards provide a method to include both data from the rest of yourproject and personal ized data imported using the Data Import feature, into asingle analysis view. For example, the dashboard below displays variousinformation about a current customer's telephone service plan and theirpotential to churn.





Some of the data on the document could come from the primary project,such as the churn prediction, revenue risk indicator, and peak and off-peakminute usage. Addi tional detai ls such as the contract usage detai ls and thecustomer demographics could come from separate data sources, eachincluded into the project using Data Import. Because documents canpresent separate sets of data in a single view or location, your regularproject data and personal ized data can be displayed to analysts as i f thedata were integrated.

For important prerequisi tes and tuning information for the Data Importfeature, refer to the System Administration Guide. For more information onhow to use the Data Import feature, refer to the MicroStrategy Web Help

Mapping data to project attributes

During the process of importing data into MicroStrategy using the DataImport feature, you can use the automatical ly generated managed objectattributes to identi fy and define the levels of your data.





Alternatively, you can manual ly map the data to existing attributes in theMicroStrategy project that are part of the relational schema. Mapping thedata in this way replaces the managed objects that are used to representthe data with attributes in the MicroStrategy project. Mapping imported datato attributes that are part of a relational schema has the fol lowing benefi ts:

Report designers can integrate the logical model of the project wi th theimported data, thus creating a relation between the two sets of data. Datacan then be joined across sources within a document. In addi tion, documentfeatures such as selectors and group-by, which can restrict data displayedon a document based on attributes, are also appl ied.

For example, a document includes a report that uses Data Import and astandard report, which both use the same Year attribute. The documentalso includes a selector based on the Year attribute. Since both reportsmap year data to the same Year attribute, the selector can restrict thedata for both reports. If the Data Import report used a managed object fori ts year data, the selector would not be appl ied for that report on thedocument.

Administrators can search for dependents and manage access control l ists(ACLs) for attributes that map both to the data warehouse and another datasource.

MicroStrategy securi ty fi l ters can be appl ied to attributes in reports anddocuments that use imported data. For example, you can map a column,integrated into MicroStrategy through the use of the Data Import feature, tothe Year attribute in your project. If a user wi th a securi ty fi l ter on Year runsa report or document that uses this import data that contains Year, thesecuri ty fi l ter on Year is appl ied.

Mapping data to project attributes is performed during the process tointegrate data into MicroStrategy using the Data Import feature. During thisprocess, you must select val id attribute forms for the columns of data torepresent as project attributes, whi le meeting with the fol lowingrequirements:



The ID form of the project attribute must be mapped to the column in theData Import data source that you have created to relate the two systems ofdata. The columns must share the same data type. Numeric data types suchas Integer are commonly used to represent the ID forms for attributes.

Ensure that al l other columns mapped to attribute forms of project attributesinclude data that is relevant to the attribute form. This data must be relevantin terms of the data type as wel l as the content. If there are any datainconsistencies between the imported column data and project attributeform, using a project attribute can cause reporting issues. For example,data from two Microsoft Excel spreadsheets is shown below.

One spreadsheet is a good match to map the attribute forms of theCustomer project attribute to the columns of the spreadsheet, becausethe data in the spreadsheet is consistent wi th the project attribute's datain the project database. However, the other spreadsheet has datainconsistencies and therefore should use a managed object to representthe data instead of mapping the attribute forms of the Customer attributeto the data.



The process of integrating data using the Data Import feature is explainedin the MicroStrategy Web Help. Refer to the Help for steps on how tocomplete this process, including how to map the data to project attributes.

Integrating geographical information with your imported data

During the process of importing data into MicroStrategy using the DataImport feature, you can integrate addi tional geographical information withyour imported data. This can improve the depth of geographical informationavai lable for your data, and can also al low for easier integration withMicroStrategy mapping features such as the Map widget and mapvisual izations. An example of the type of mapping analysis avai lable inMicroStrategy is shown below.

When importing your data, the column headers and the data i tsel f areanalyzed by MicroStrategy to determine what type of geographical




information, i f any, is avai lable. MicroStrategy attempts to recognize datarelated to the geographical categories for Area Code, County, Country,State, Ci ty, Zip code, Location, Lati tude, and Longi tude.

MicroStrategy can automatical ly recognize geographical data that meets thefol lowing cri teria:

If the fol lowing names are used for the column headers of your data:

Area Code: Includes data that resembles three-digi t area codes.

County: Includes data for Uni ted States counties, such as Cooke, Tioga,and Jackson.

Country: Includes data such as Uni ted States, Germany, and Italy.

MicroStrategy can also recognize data that resembles various countryabbreviations, codes, and synonyms.

State: Includes data such as Virginia, Cal i fornia, and Oklahoma.

MicroStrategy can also recognize data that resembles various stateabbreviations, codes, and synonyms.

City: Includes data such as New York, Paris, and Tokyo.

MicroStrategy can also recognize data that resembles various cityabbreviations, codes, and synonyms.

Zipcode: Includes data resembl ing five digi t US postal codes.

Location : Includes locations, resembl ing one of the fol lowing formats:

Address, Ci ty, State, Country

For example, 1850 Towers Crescent Plaza, Tysons Corner, Virginia, Uni tedStates

Address, Ci ty, State

For example, 1850 Towers Crescent Plaza, Tysons Corner, Virginia



City, State

Tysons Corner, Virginia

Latitude: Includes data that resembles lati tude values. In addi tion torecognizing lati tude values as separate attributes, lati tude values can alsobe automatical ly appl ied as attribute forms of any of the geographicalcategories l isted above. This capabi l i ty is described below.

Longitude: Includes data that resembles longi tude values. In addi tion torecognizing longi tude values as separate attributes, longi tude values canalso be automatical ly appl ied as attribute forms of any of the geographicalcategories l isted above. This capabi l i ty is described below.

If a column of data is recognized as related to one of these geographicalcategories, addi tional geographical data can be included as part ofimporting the data into MicroStrategy:

New attributes can be automatical ly created and populated with data forCountry, State, and City. These options are avai lable i f any one of thesegeographical categories is recognized:

If a column of data is recognized as Zipcode, attributes for Ci ty of Zipcode,State of Zipcode, and Country of Zipcode can be automatical ly created aspart of the importing process.

If a column of data is recognized as City, attributes for State of Ci ty andCountry of Ci ty can be automatical ly created as part of the importingprocess.

If a column of data is recognized as State, an attribute for Country of Statecan be automatical ly created as part of the importing process.

If you already have columns of data for any of these geographicalcategories, when importing your data you can choose to not create theseattributes and instead use the attributes that are created based off ofyour data.



New attribute forms can be automatical ly created to define the lati tude andlongi tude values for any Area Code, County, Country, State, Ci ty, andZipcode. Be aware of the fol lowing i f you select to automatical ly createthese lati tude and longi tude values:

The lati tude and longi tude values for an Area Code, County, Country, State,Ci ty, or Zipcode are determined by the fi les City.csv , AreaCode.csv ,County.csv , Country.csv , State.csv , and ZipCode.csv . Thesefi les are included as part of an Intel l igence Server instal lation. You canmodi fy these tables to change the lati tude and longi tude values for a givenlocation, as wel l as add addi tional locations that can then have lati tude andlongi tude values automatical ly assigned when importing data intoMicroStrategy. Any changes to these .csv fi les are reflected when a useris connected to the associated Intel l igence Server to import their data intoMicroStrategy.

The State.csv fi le includes al ternative types of regions such asprovinces, districts, and so on.

By defaul t, lati tude and longi tude values for counties and zip codes areonly provided for locations within the Uni ted States, as defined by theCounty.csv and ZipCode.csv fi les, respectively.

If an Area Code, County, Country, State, Ci ty, or Zipcode is recognized, thefi rst val id lati tude and longi tude values that are found in the .csv tablesare automatical ly assigned to the lati tude and longi tude attribute forms.This can assign incorrect lati tude and longi tude values in some scenarios.

For example, i f the ci ty of Springfield is recognized in your data, the fi rstmatching lati tude and longi tude values found in the City.csv fi le are forSpringfield, Colorado. However there are multiple Springfields in the Uni tedStates.

To avoid automatical ly assigning incorrect lati tude and longi tude values,use the fol lowing best practices:



You can modi fy the .csv tables to only include the locations relevant toyour data.

For locations within the Uni ted States, rather than including ci ty informationdirectly in your data, you can instead include only zip code information.Using this zip code data, MicroStrategy can accurately determine thelati tude and longi tude of the location, and you can also select to create Cityof Zipcode, State of Zipcode, and Country of Zipcode attributes.

Once you import your geographical data into MicroStrategy, you can thenuse the Map widget and map visual izations to display and analyze thegeographical data. For steps to create and configure the Map widget, referto the MicroStrategy Mobi le Administration Guide. For steps to create anduse map visual izations as part of Visual Insight, refer to the MicroStrategyWeb Help.

Creating additional time-related data for your imported data

During the process of importing data into MicroStrategy using the DataImport feature, you can al low MicroStrategy to create addi tional time-relateddata for your imported data. This can help to define your data morespeci fical ly when i t comes to time information.

When importing your data, the contents of the data is analyzed to determinewhether i t is in a format that supports dates or times. MicroStrategy canautomatical ly recognize date and time data that meets the fol lowing cri teria:

The data uses a val id date or date and time format. Date data can includemonth, day, and year information in the format MM/DD/YYYY, where MM isa two digi t month, DD is a two digi t day, and YYYY is a four digi t year. Dateand time data can include month, day, and year information in the samedate format described above, as wel l as time information in the formatHH:MM:SS. For time data, HH is a two digi t hour value, MM is a two digi tminute value, and SS is a two digi t second value. A complete entry for datathat includes date and time information can have the format MM/DD/YYYYHH:MM:SS.


https://www2.microstrategy.com/producthelp/2020/MobileAdmin/WebHelp/Lang_1033/Content/home.htm




If a column of data is recognized as including date or time data, addi tionaltime data can be included as part of importing the data into MicroStrategy:

The fol lowing new attributes can be automatical ly created and populatedwith data i f date data is recognized:

Year: Includes data such as 2010, 2011, and 2012.

Quarter: Includes data such as Q1 2011, Q2 2011, and Q3 2011

Quarter of Year: Includes data such as Q1, Q2, and Q3.

Month : Includes data such as January 2011, February 2011, and March2011.

Month of Year: Includes data such as January, February, and March.

Week: Includes data such as Week 50, 2011, Week 51, 2011, and Week 52,2011.

Week of Year: Includes data such as 50, 51, and 52.

Day of Month : Includes data such as 28, 29, and 30.

Day of Week: Includes data such as Sunday, Monday, Tuesday.

Date: Includes data such as 1/27/2011, 1/28/2011, and 1/29/2011.

If you already have columns of data for any of these date categories,when importing your data you can choose to not create these attributesand instead use the attributes that are created based off of your data.

The fol lowing new attributes can be automatical ly created and populatedwith data i f time data is recognized:

Hour: Includes data such as 12, 13, and 14.

Minute: Includes data such as 57, 58, and 59.

Second : Includes data such as 57, 58, and 59.



If you already have columns of data for any of these time categories,when importing your data you can choose to not create these attributesand instead use the attributes that are created based off of your data.

Al l of the attributes l isted above can be automatical ly created andpopulated with data i f date and time data is recognized.

Once you import your data into MicroStrategy, you can then include any ofthe time attributes that were automatical ly created during the import processon your reports, documents, and dashboards. For steps to analyze the datayou have imported using Data Import, refer to the MicroStrategy Web Help.

Project connectivity components

This section defines some of the basic terminology used in project creationin MicroStrategy Developer. It is intended to fami l iarize you with some ofthe terms discussed in this guide.

MicroStrategy metadataAl l schema objects, appl ication objects, configuration objects, and projectsettings are stored in the MicroStrategy metadata. Metadata is stored in arelational database with a predefined structure. The RDBMS for themetadata and warehouse do not need to be the same.

You can find the lis t of supported RDBMS platforms in the Readme that isinstalled with MicroStrategy products. To view the Readme, from the Startmenu select Programs , then MicroStrategy Documentation , and thenselect Readme .

Metadata shellBefore you can populate the metadata reposi tory wi th data, the necessarytables to hold the data must be present. The metadata shel l is the set ofblank tables that are created when you ini tial ly implement a MicroStrategybusiness intel l igence environment.




You create the metadata shel l wi th the MicroStrategy Configuration Wizard,which creates the blank tables and populates some of the tables with basicini tial ization data.

This fi rst step in the project creation process is outl ined in Creating themetadata reposi tory, page 93.

Project sourceThe project source is a configuration object which represents a connectionto a metadata reposi tory. In MicroStrategy Developer, the project sourceappears in the Folder List wi th an icon that varies depending on the type ofconnection i t represents. A connection to a metadata reposi tory is achievedin one of two ways:

Direct or two-tier mode ( ): Connects to the metadata by speci fying a

DSN, login, and password to a metadata reposi tory.

It is highly recommended that you never use direct mode connection in aproduction environment. MicroStrategy strongly suggests you always connectto the metadata through Intelligence Server because of the security andscalability it provides. You should not connect directly to the metadata unlessyou are implementing a prototype environment.

Server or three-tier mode( ): Connects to the metadata by pointing to an

Intel l igence Server defini tion, which in turn governs and val idates theconnection to the metadata. The project metadata is the fi rst tier,MicroStrategy Developer is the second tier, and Intel l igence Server is thethi rd tier. Intel l igence Server manages al l connections to databases,enforces securi ty, and ensures metadata integri ty. For these reasons,Intel l igence Server is a necessary part of any production project.

A four-tier connection is a Server (three-tier) connection in conjunction withMicroStrategy Web deployed on a web server.

The fol lowing diagram i l lustrates server connectivi ty between aMicroStrategy metadata reposi tory, Intel l igence Server, and MicroStrategy



Developer. This is the type of connection used to create a production-readyproject in MicroStrategy.

After the connection to the metadata is establ ished, every object defini tionyou create within this project source is stored in this metadata. Thisincludes appl ication objects, schema objects, and configuration objectsfrom any number of projects defined within this project source (seeMicroStrategy metadata, page 10 for defini tions of these object types).

A project source connects to a single metadata reposi tory. However, thesame metadata reposi tory can be accessed by multiple project sources. Aproject source may contain any number of projects.

Database instanceThe database instance is a configuration object that represents aconnection to a data source. When you define a project, you speci fy thedata source location by creating and selecting a database instance with theappropriate connection parameters.

For information on database instances, see the Instal lation andConfiguration Guide.

Connecting to a data source through a database instance is explained indetai l in Connecting to a data source, page 94.





ProjectA project is where you bui ld and store al l schema objects and informationyou need to create appl ication objects such as reports in the MicroStrategyenvironment. A project also represents the intersection of a data source,metadata reposi tory, and user community. For more information on what aproject is in MicroStrategy, see MicroStrategy project, page 15.

Summary of project connectivityWith a fi rm understanding of the MicroStrategy metadata, project sources,database instances, and projects, you can begin to bui ld an understandingof how these various pieces work together to provide an integratedbusiness intel l igence environment as shown in the fol lowing diagram.



Creating the metadata repository

Your fi rst step in project creation is to create a metadata reposi tory. Thisreposi tory stores al l the objects necessary to support your project.

You can create an empty metadata reposi tory in the database location ofyour choice using the Metadata Tables option in the Configuration Wizard.

Before proceeding to the next section, make sure your metadata repositoryexists in a non-Microsoft Access database. An Access database is unsuitablefor a production project.

Create a metadata reposi tory using the guidel ines outl ined in theConfiguring and Connecting Intel l igence Server chapter of the Instal lationand Configuration Guide.

When you create the metadata reposi tory, MicroStrategy creates a defaul tconfiguration in the reposi tory. The defaul t configuration populates thetables with the basic data required for the metadata, such as the defaul tproject folder structure and basic connection information.

These tables are populated with your project information during the projectcreation step in the Project Creation Assistant, outl ined in Creating aproduction project, page 95.

For instructions on creating a metadata repository in a database, see theInstal lation and Configuration Guide .

Connecting to the metadata repository and datasource

Once you have created a metadata reposi tory, your next step is to connectMicroStrategy Developer to the metadata reposi tory and to your datasource.






Connecting to the metadata repositoryYou connect to the metadata reposi tory in MicroStrategy Developer or Webthrough a project source. Recal l that a project source is a pointer to ametadata reposi tory. It connects ei ther through a DSN that points to theappropriate database location or by pointing to an instance of Intel l igenceServer which, in turn, points to the metadata reposi tory location.

To configure Intel l igence Server and establ ish a server connection betweenthe metadata, Intel l igence Server, and MicroStrategy Developer, fol low thesteps in the Instal lation and Configuration Guide.

Connecting to a data sourceA data source contains the business data from which you intend to gainanalytical insight. Once you connect to the metadata reposi tory throughIntel l igence Server, your next step is to create a connection to the datasource to which your project can connect. You connect to the data sourceby creating a database instance in MicroStrategy Developer.

Create a database instance using the procedures outl ined in theConfiguring and Connecting Intel l igence Server chapter of the Instal lationand Configuration Guide.

MicroStrategy includes an extension to Intel l igence Server referred to asMultiSource Option. With this feature, you can connect a project to mul tipledata sources. This al lows you to integrate al l your information from variousdatabases and other relational data sources into a single MicroStrategyproject for reporting and analysis purpose. For information on connecting aproject to mul tiple data sources, see Accessing multiple data sources in aproject, page 353.

If you do not have the MultiSource Option, your projects can only connect to asingle database instance.

MicroStrategy allows you to connect to your SAP BW, Microsoft AnalysisServices, and Hyperion Essbase data sources. For information about






connecting to these MDX cube sources, see the MDX Cube ReportingGuide .

Creating a production project

You can now begin bui lding the MicroStrategy project that connects to themetadata reposi tory and data source. Project creation involves creating abasic project defini tion and creating your project's fi rst schema objects.

This section guides you through the creation of a production-readyMicroStrategy project wi th the Project Creation Assistant or Archi tect.

It is assumed you intend to implement Intelligence Server in your businessintelligence environment as the means of connecting to your project asopposed to using a direct, (two-tier) setup. To create a direct connection, seethe Instal lation and Configuration Guide .

Creating a project using the Project Creation Assistant or Archi tect inMicroStrategy Developer provides advanced functional i ty and a greatercomplexi ty to your project that can support a production environment. Ital lows you to create a new project and add the fol lowing objects to i t or toan existing project:

Tables

Facts

Attributes

With the Project Creation Assistant or Archi tect, you create and configure aproject and some of the essential schema objects that reside within i t. Theintended audience for these tools includes experienced project creatorswho have planned al l their facts, attributes, and data relationships. Thisinformation is covered elsewhere in this guide. For a l isting of informationcovered in speci fic chapters, see Planning your project, page 96 below.






One of the many benefi ts of the Project Creation Assistant and Archi tect istheir abi l i ty to create multiple schema objects at one time. Since you canefficiently add multiple tables and develop numerous attributes and facts, i tis especial ly useful for large projects which contain many tables andschema objects. With the Project Creation Assistant or Archi tect, you canalso create attributes with many-to-many relationships.

Planning your projectBefore using the Project Creation Assistant or Archi tect, you should planyour project and consider the fol lowing:

The logical data model you intend to use for this project; logical datamodels are covered in Chapter 2, The Logical Data Model .

The tables to use in the project; physical warehouse schema models arecovered in Chapter 3, Warehouse Structure for Your Logical Data Model .

The facts to include in the project and the data types used to identi fy them;facts are covered in Chapter 6, The Bui lding Blocks of Business Data:Facts.

The attributes to create in the project and the data types used to identi fythem, including:

The description column name for each attribute.

Any other attribute forms for each attribute.

The chi ld attributes for each attribute.

Attributes are covered in Chapter 7, The Context of Your Business Data:Attributes.

Whether to use Project Creation Assistant or Graphical Archi tect. Bothoptions for creating a project are compared in Archi tect versus ProjectCreation Assistant, page 97 below.



Architect versus Project Creation AssistantMicroStrategy has two tools that each provide unique ways to create aproject: the Project Creation Assistant and Archi tect.

The Project Creation Assistant provides a l inear, wizard-style workflow tocreate a project. This helps to guide you through the various steps requiredin project creation in a logical order. In general , the Project CreationAssistant provides separate steps to add and define the objects required fora project.

Whi le you can add and define multiple tables, facts, and attributes for yourproject, each is provided as a separate step in the step-by-step creation ofyour project.

Also, Project Creation Assistant is intended to be used for the ini tialcreation of your project, and thus cannot be used to modi fy an existingproject. Once a project has been created, you must use Archi tect or theindividual schema edi tors and wizards to modi fy the project.

Archi tect provides a central ized interface which al lows you to define al l therequired components of your project and perform the various tasks to createa project.

When creating projects using Archi tect, including at least some tables inyour project is a fi rst step to include some information in your project. WithArchi tect, once tables are added to your project you have much moreflexibi l i ty in the order in which you create your project. Whi le you arecreating your project in Archi tect, you can easi ly swi tch between addingtables, creating facts, creating attributes, defining relationships betweenattributes, creating user hierarchies, and any other required project creationtasks. Whi le performing these tasks, Archi tect provides a visualrepresentation of your project, which helps to provide an intui tive workflow.

Both tools provide options to automatical ly create facts and attributes basedon the columns and data avai lable in your data source. Automatic fact and



attribute creation can save a substantial amount of time in the creation of aproject.

As summarized above, Project Creation Assistant and Archi tect provide twounique workflows to support the creation of a project. To help determinewhich tool you should use to create your project, the table below comparesthese two tools:

ProjectCreationTask orFeature

Project Creation Assistant Architect

The workf lowof creat ing aproject

Provides a linear, wizard-style workf low to add tables,at t ributes, and facts to aproject

Provides a f lexible workf low to add objects toa project in an order that suits yourrequirements f rom within a centralizedinterface

Can be usedto modify aproject

Can only be used for theinit ial creat ion of a project

Can be used to both create a project andmake modif icat ions at any t ime in a project 'sl i fe cycle

Can createuserhierarchies

User hierarchies cannot becreated

User hierarchies can be created

Automat iccreat ion offacts andattributes

Can automat ically createfacts and at t ributes based onrules

Can automat ically create facts and at t ributesbased on rules

Can createin it ialpro jectobject

The init ial project object canbe created

You must f irst create the init ial project objectusing the Project Creat ion Assistant beforeusing Architect

Creating a new project using the Project Creation AssistantOnce you have planned your project and completed the prerequisi tes, youcan use the Project Creation Assistant to bui ld the project and populate themetadata based on the data structures present in your data warehouse.

The steps of the Project Creation Assistant are:



Ini tial ize/create the project.

Ini tial izing the project means giving the project a name and selecting themetadata reposi tory in which to create the project—that is, the projectsource. It also includes defining which languages are avai lable in theproject for the international ization of metadata object information.

After you speci fy these settings, the shel l of a project is created in themetadata. This configures the folder structure and defaul t connectivi tysettings. Be aware that this process can take some time to complete.

Select tables from the Warehouse Catalog.

In this step, you use the Warehouse Catalog to speci fy which datawarehouse tables to include in your project.

Create facts.

Create attributes.

You should complete all the steps in the Project Creation Assistant at thesame time. While you can save an incomplete project definition, you cannotfinish creating it later with the Project Creation Assistant. Instead, you mustcomplete it using the appropriate interface, such as the Warehouse Catalog,Fact Creation Assistant, or Attribute Creation Assistant.

To create a new project using the Project Creation Assistant

Log in to a project source in MicroStrategy Developer.

To create a project source which connects to your data throughIntel l igence Server, see the Configuring and Connecting Intel l igenceServer chapter of the Instal lation and Configuration Guide.

From the Schema menu, select Create New Project. The Project CreationAssistant opens, as shown below:




Click Create project. The New Project page opens.

You cannot create more than one project at a time.

Define the project configurations l isted below:

Name: A name for the project. This name is used to identi fy a project wi thina project source.

Description : An optional description for the project. This description cangive a brief overview of the purpose of the project as compared to yourother projects.

Default document directory: The defaul t document directory for a projectis the directory location to store al l HTML documents. For more detai ls onhow to setup HTML documents for a project, see the MicroStrategyInstal lation and Configuration Guide.

Enable the guest user account for this project: Select this check box toal low users to log in to a project wi thout any user credentials. Users can



then to connect to Intel l igence Server wi th a l imi ted set of privi leges andpermissions (defined by the Publ ic group).

Enable Change Journal for this project: Select this check box to enablethe Change Journal for the project. An entry is automatical ly included inthis journal when any object in a project is modi fied, al lowing you to keeptrack of any changes to your project. For information on the ChangeJournal , see the System Administration Guide.

Languages: Cl ick this button to define languages that are avai lable formetadata objects in this project. The languages you select are alsolanguages that are avai lable for the international ization of your metadataobjects. If a language is avai lable for a project, you can provide objectnames, descriptions, and other information in various languages. Forexample, in a project you can provide the names of attributes, metrics,folders, and other objects in mul tiple languages. For information on how toprovide translated strings for metadata objects such as attributes, metrics,folders and so on, see the System Administration Guide.

MicroStrategy provides translated strings for common metadata objects inthe defaul t avai lable languages l isted. For example, translated strings areavai lable for the name and description of the Publ ic Objects folder as wel las other common objects for each language l isted as avai lable by defaul t. Ifyou add other languages not l isted, you must supply al l translated stringsfor common metadata objects.

When you create a new project, a language check ensures that the languagesettings of the user profile of the local machine (the CURRENT_USER registrykey), the language of the local machine (the LOCAL_MACHINE registry key),and the Project locale property match. When these properties do not match, itcan lead to inconsistencies in the language display. The language checkprevents these inconsistencies and ensures that the language display isconsistent across the project.





These language options are not related to supporting the integration oftranslated data from your data source into MicroStrategy. Information ondefining your data source to support data internationalization is provided inSupporting data international ization, page 64 .

If you plan to use translated data from your data source with attributes in aproject, you must define how data internationalization is enabled beforecreating attributes. Enabling data internationalization is described in Enabl ingdata international ization for a project, page 106 .

Click OK .

Proceed to the next section below (Adding tables using the WarehouseCatalog, page 102) to determine the tables to be used in your project.

Adding tables using the Warehouse Catalog

The warehouse tables for a project determine the set of data avai lable to beanalyzed in the project. You use the Warehouse Catalog to add warehousetables to your project. The Warehouse Catalog l ists al l the tables in thedata source to which you are connected through your database instanceand to which your database login has read privi leges.

The Warehouse Catalog queries the data source and l ists the tables andcolumns that exist in i t. From this l ist, you select the lookup, fact, andrelationship tables to use in your new project. You should also include al lother tables needed to complete your project, including transformationtables, aggregate tables, and parti tion mapping tables.

MicroStrategy schema objects such as attributes, facts, and tables areabstractions bui l t on top of the tables and columns in the data source. Oncetables are selected from the data source and added to your project, theybecome schema objects known as logical tables in MicroStrategy. Logicaltables are representations of the tables that are avai lable in the datawarehouse, and are discussed in detai l in Appendix B, Logical Tables.



The database login you use must have read priv ileges so you are able to viewthe tables in the selected warehouse. Database instances and database loginsare MicroStrategy objects that determine the warehouse to which a projectconnects. To learn more about these objects, refer to the Instal lation andConfiguration Guide .

To add and remove tables to the project using the Warehouse Catalog

In the Project Creation Assistant, select Select tables from theWarehouse Catalog . The Warehouse Database Instance dialog box opens.

Select a database instance from the drop-down l ist and cl ick OK . Thedatabase instance selected in this dialog box determines which data sourceis accessed. The Warehouse Catalog opens.

If you have the MultiSource Option, you can add tables from multipledata sources into your project. For information on adding tables frommultiple data sources into your project wi th the Warehouse Catalog, seeAccessing multiple data sources in a project, page 353.

You can edit your database instance by click ing Edit.

The left side of the Warehouse Catalog l ists al l avai lable tables and thenumber of rows each table contains. The l ist on the right shows al l thetables currently being used in the project, i f any:





From the left side, select the tables you want to add to the WarehouseCatalog, and cl ick > to add the selected tables. Cl ick >> to add al l the l istedtables.

To remove tables from your project, select them from the right side and cl ick< to remove them. Cl ick << to remove al l the tables from your project.

Warehouse Catalog options

Right-cl icking any table provides you with addi tional Warehouse Catalogfunctional i ty.

For example you can view rows in a table, speci fy a table prefix, copy atable, or speci fy a database instance for a table. For more information onthese abi l i ties and how to use them, see Managing warehouse andproject tables, page 330.



To set advanced options, you can cl ick Options on the Warehouse Catalogtoolbar.

For example, you can change the database instance, customize howtables and columns are read from the database system catalog, displayextra table and row information, and decide whether schema objects aremapped automatical ly or manual ly. For more information on theseabi l i ties and how to use them, see Modifying data warehouse connectionand operation defaul ts, page 337.

In the toolbar, cl ick Save and Close to save your changes to theWarehouse Catalog. The table defini tions are wri tten to the metadata. Thisprocess can take some time to complete.

After exi ting the Project Creation Assistant, you can sti l l access theWarehouse Catalog to add addi tional tables. For steps to access theWarehouse Catalog to add tables to a project, see Adding and removingtables for a project, page 329.

The next step in the Project Creation Wizard involves creating schemaobjects: facts and attributes. Fol low the instructions outl ined in Creatingfacts and attributes, page 112 and Configuring addi tional schema-levelsettings, page 113 to learn how to create these schema objects andconfigure addi tional schema-level settings for those objects.

Creating a new project using ArchitectAs an al ternative to using the Project Creation Assistant that provides awizard-style process to create a project, you can use Archi tect to define al lthe required components of your project from a central ized interface.Archi tect also provides a visual representation of your project as you createi t, which helps to provide an intui tive workflow. For information on usingArchi tect to create a production project, see Creating projects usingArchi tect, page 118.



Enabling data internationalization for a projectMicroStrategy supports the international ization of your data into thelanguages required for your users. This al lows translated data from yourdata source to be integrated into a MicroStrategy project. This data canthen be displayed in the various languages that reflect a user's languagepreferences.

More speci fical ly, data international ization al lows attribute element data tobe displayed in various languages. For example, the Month of Year attributeelement data is suppl ied in both Engl ish and German, as shown in thereports below.

The attribute elements for the Month of Year attribute can be suppl ied inmultiple languages through data international ization. For example, theJanuary, February, and March attribute elements are displayed as Januar,Februar, and März for users that are defined to view data in German.

Data internationalization is different than metadata internationalization.Metadata internationalization allows various MicroStrategy metadata objectnames, descriptions, and other strings to be supplied in various languages.For example, in a project you can provide the names of attributes, metrics,folders, and other objects in multiple languages. For information on how toprovide translated strings for metadata objects such as attributes, metrics,folders and so on, see the System Administration Guide .

MicroStrategy supports data international ization through two techniques.You can provide translated data through:

the use of extra tables and columns

separate databases to store translated data

For a description of these two methods, see Supporting datainternational ization, page 64.

If you plan to use international ized data with your attributes, you shoulddefine how data international ization is enabled before creating attributes.




By defining how international ized data is represented in your data source,Archi tect, the Attribute Creation Wizard, and the Fact Creation Wizard canrecognize international ized data when automatical ly creating attributes.This can save you the time that would be required to go back and modi fyattributes to recognize and use the international ized data.

To support one of these data international ization methods, fol low one of theprocedures described below:

Enabl ing data international ization through SQL queries, page 107

Enabl ing data international ization through SQL queries, page 107

Enabling data internationalization through SQL queriesIf you have configured your data source to use tables and columns toidenti fy your international ized data, you can define your MicroStrategyproject to create SQL queries to return data in the required languages. TheSQL queries are automatical ly generated to return the information in auser's selected language based on the tables and columns you identi fy ascontaining translated data.

For information on configuring your data source to use tables and columnsto identi fy translated data, see International ization through tables andcolumns or databases, page 64.

To enable data international ization through SQL queries, you must definethe tables and columns used for your international ized data, as described inthe procedure below.

Prerequisites

A project has been created.

To enable data internationalization through SQL queries

In MicroStrategy Developer, log in to a project.



Right-cl ick the project and select Project Configuration . The ProjectConfiguration Edi tor opens.

In the Categories l ist, expand Languages, and then select Data.

Select the Enable data internationalization check box, and then select theSQL based option.

Select the check box next to a language to include i t as a language enabledfor translated data.

To add other languages to enable data international ization, perform thesteps below:

Cl ick Add . The Avai lable Languages dialog box opens.

Clear the Display metadata languages only check box.

Select the check box for languages to enable for data international izationand cl ick OK to return to the Project Configuration Edi tor.

For each language, include suffixes for the columns and tables that containyour translated data.

Cl ick ... in the Column Pattern for a language, to include suffixes forcolumns. Cl ick ... in the Table Pattern for a language, to includesuffixes for tables. For example, i f your data source includes Spanishdata in columns that end in _ES , type _ES in the Column Pattern.

The Column Pattern and Table Pattern options expect suffixes to identi fyyour international ized columns and tables. If you use prefixes or othernaming conventions, you can use the functions l isted below to identi fythe columns and tables that contain translated data:

LStrCut(string s, integer x) : Removes x characters from thebeginning of the character string s , and returns the remaining characterstring. For example, LStrCut("Apple",2) would return ple .



RStrCut(string s, integer x) : Removes x characters from the endof the character string s , and returns the remaining character string. Forexample, RStrCut("Apple",2) would return App .

Concat(string s1, string s2) : Appends the character string s2 tothe end of the character string s1 , and returns the resul ting character string.For example, Concat("App","le") would return Apple .

The functions l isted above can be used together to support variouscolumn and table naming conventions. You can use the parameter #0 topass the column or table name into the function. To support a prefixrather than a suffix you can use the syntax l isted below:

Concat("Prefix",#0)

For example, to use a prefix of ES_ to identi fy columns that containSpanish data, you can use the syntax l isted below:

Concat("ES_",#0)

Click OK to save your changes and close the Project Configuration Edi tor.

Enabling data internationalization through connection mappings

You can support data international ization in your database by usingseparate databases for each translation. A user can then be grantedaccess, through connection mappings, to the database that contains theirpreferred language.

For information on configuring your data source to use separate databasesand connection mappings to identi fy international ized data, seeInternational ization through tables and columns or databases, page 64.

To enable data international ization through separate databases andconnection mappings, you must define the databases used for eachlanguage, as described in the procedure below.



Prerequisites


To enable data internationalization through separate databases and

connection mappings



In the Categories l ist, expand Languages, and then select Data.

Select the Enable data internationalization check box, and then select theConnection mapping based option.

Select the check box next to a language to include i t as a language enabledfor translated data.

To add other languages to enable data international ization, perform thesteps below:

Cl ick Add . The Avai lable Languages dialog box opens.

Clear the Display metadata languages only check box.

Select the check box for languages to enable for data international izationand cl ick OK to return to the Project Configuration Edi tor.

For each language, from the Database Connection drop-down l ist, select adatabase connection to use for the language. The database connectiondetermines the data source that stores the translated data and the logininformation to connect to the data source. You can leave this drop-down l istblank to use the database connection for the defaul t database instance ofthe project.

Cl ick OK to save your changes and close the Project Configuration Edi tor.



Using read only or edit mode for schema editorsWhen opening a schema edi tor such as Archi tect, the Attribute Edi tor, theFact Edi tor, and so on, you can choose to open the edi tor in read only modeor edi t mode. These two modes al low some users to view the defini tion ofschema objects (read only mode), whi le one user can make changes to theschema objects (edi t mode).

To create and modi fy a project, you must be able to edi t the schema objectsof a project. If another user is edi ting a schema object, this can lock theschema from being edi ted by other users. This maintains the integri ty of theproject schema.

However, i f some users only want to use the various schema edi tors to viewthe defini tions of project schema objects to learn more information aboutthem, they can use read only mode. This al lows another user to modi fy theschema, whi le other users can view the schema objects wi thout making anymodi fications.

The mode can be chosen in the Read Only dialog box that opens whenopening any schema edi tor, which has the fol lowing options:

Read Only: Read only mode al lows you to view the schema objects wi thoutlocking the schema from other users. However, you cannot make anychanges to the schema object.

If you open a schema edi tor in read only mode, the enti re project isenabled to use read only mode. This means that every schema edi torautomatical ly opens in read only mode. However, from the Schemamenu in Developer, you can clear the Read Only option to switch to edi tmode. If you have a schema edi tor open, you must close and re-open theschema edi tor to swi tch to edi t mode for that schema edi tor.

If you are working in read only mode, you cannot access schema edi torsthat require the abi l i ty to make updates to the project, which includes theAttribute Creation Wizard, Fact Creation Wizard, Warehouse Catalog,MDX Cube Catalog, and the options to update the project schema.



Edit: Edi t mode provides the standard capabi l i ties of modi fying schemaobjects, and i t locks the schema from being modi fied by al l other users.Therefore, only one user can be using edi t mode for a project at a giventime.

If you open a schema edi tor in edi t mode, the enti re project is enabled touse edi t mode. This means that every schema edi tor automatical ly opensin edi t mode. However, from the Schema menu in Developer, you canselect the Read Only option to switch to read only mode. If you have aschema edi tor open, i t is also switched to read only mode automatical lyand you cannot make any changes to schema objects.

You must use edi t mode to access schema edi tors that require the abi l i tyto make updates to the project, which includes the Attribute CreationWizard, Fact Creation Wizard, Warehouse Catalog, MDX Cube Catalog,and the options to update the project schema.

If someone has already locked the schema for a project, a message isdisplayed and you can only open the schema edi tor in read only mode.

Remember my selection as a default preference for future sessions:When this option is selected, the mode you select is defined as the defaul tmode to use when opening any schema edi tor, and you are not promptedagain to choose the mode for any schema edi tors. If you clear this checkbox, the mode you select is used for al l schema edi tors only unti l you endthe user session and close Developer.

If you select this check box, this becomes the default mode for all schemaeditors and you cannot change the default mode. However, you can switchbetween read only mode and edit mode in Developer, from the Schema menu,by selecting or clearing the Read Only Mode option.

Creating facts and attributes

This step in the project creation process involves using the Project CreationAssistant or Archi tect to create two kinds of schema objects: facts and



attributes.

Before you create facts and attributes, however, i t is important tounderstand what facts and attributes are and the defining characteristics ofeach. This information is covered in Chapter 6, The Bui lding Blocks ofBusiness Data: Facts and Chapter 7, The Context of Your Business Data:Attributes.

Configuring addit ional schema-level sett ings

The final step in the project creation process involves configuringaddi tional schema-level settings to add more analytical depth to yourschema objects and optimize the project as a whole. These settingsinclude:

Fact definitions: The Fact Edi tor al lows you to create, edi t, and configurefacts one at a time. This is covered in Creating and modi fying simple andadvanced facts, page 212.

Archi tect also al lows you to create, edi t, and configure any and al l factsfor your project. This is covered in Creating and modi fying facts, page154.

Attribute definitions: The Attribute Edi tor al lows you to create and edi tattributes, attribute relationships, attribute forms, and attribute formexpressions for attributes one at a time. This is covered in Adding andmodi fying attributes, page 257.

Archi tect also al lows you to create and edi t any and al l attributes,attribute relationships, attribute forms, and attribute form expressions foryour project. This is covered in Creating and modi fying attributes, page168 and Defining attribute relationships, page 194.

User hierarchies: The Hierarchy Edi tor al lows you to create userhierarchies, which faci l i tate access to attribute and element browsing and



dri l l ing. This is covered in Chapter 9, Creating Hierarchies to Organize andBrowse Attributes.

Archi tect also al lows you to create any and al l user hierarchies for yourproject. This is covered in Creating and modi fying user hierarchies,page 202.

Advanced configurations: These objects include transformations,aggregate tables, and parti tioning and parti tion mappings:

The Transformation Edi tor al lows you to create transformations, which areschema objects used for time-series analysis. Transformations are coveredin Chapter 10, Creating Transformations to Define Time-Based and OtherComparisons.

The tools used to create aggregate tables and parti tions are the WarehouseCatalog, the Metadata Parti tion Mapping Edi tor, and the WarehouseParti tion Mapping Edi tor. This information is covered in Chapter 8,Optimizing and Maintaining Your Project.

Now that you have completed most of the key steps in creating a newproject, proceed to the chapters referenced above to complete the nextsteps in the project creation process.

Deploying your project and creating reports

After you create a project, you can deploy i t to your user community usingMicroStrategy Web. However, i f you completed only the steps in thischapter, the project you deploy wi l l contain only basic facts and attributes.Proceed to the chapters l isted above to add analytical depth and morefunctional i ty to your project.

Facts and attributes provide the backbone of the reports and documentscreated by report designers. Facts are used to create metrics, and metricsand attributes are essential components of reports.



Metrics, and other report objects such as fi l ters, custom groups, andprompts, are beyond the scope of this guide. For a complete discussion ofmetrics, fi l ters, reports, and other report objects, see the Basic ReportingGuideand the Advanced Reporting Guide.

To learn more about how to deploy your project using MicroStrategy Web,see the Instal lation and Configuration Guide.

You can also begin creating reports in MicroStrategy Developer andMicroStrategy Web. For information about creating reports in MicroStrategyDeveloper, see the Basic Reporting Guide; for creating reports inMicroStrategy Web, see the MicroStrategy Web Help.

MicroStrategy allows you to connect to your SAP BI, Microsoft AnalysisServices, and Hyperion Essbase data sources. For information aboutconnecting to MDX Cube sources, see the MDX Cube Reporting Guide .

For information on how to use your own customized SQL statements to createreports, refer to the Advanced Reporting Guide .











CREATING A PROJECTUSING ARCHITECT



MicroStrategy includes a project design tool known as Archi tect. Archi tectal lows you to define al l the required components of your project from acentral ized interface. Archi tect also provides a visual representation of yourproject as you create i t, which helps to provide an intui tive workflow.

Archi tect is provided in addi tion to the Project Creation Assistant, which isa wizard-style tool that steps you through the process of creating a project.Rather than providing a step-by-step process to create a project, Archi tectal lows you to see your project take shape as you create i t. For acomparison of Archi tect and the Project Creation Assistant, see Archi tectversus Project Creation Assistant, page 97.

Archi tect provides a wide range of project creation and modi fication tasks,which are covered in the sections of this chapter l isted below:

Creating and modi fying projects, page 117

Adding, removing, and administering tables, page 140

Creating and modi fying facts, page 154

Creating and modi fying attributes, page 168

Defining attribute relationships, page 194

Creating and modi fying user hierarchies, page 202

Creating and modifying projects

Archi tect al lows you to complete al l tasks related to ini tial project creationas wel l as modi fications required over the ful l l i fe cycle of a project, whichincludes:

Creating projects using Archi tect, page 118

Modi fying projects using Archi tect, page 122

Defining project creation and display options, page 124

Using the Archi tect toolbar, page 140



Creating projects using ArchitectRather than using the Project Creation Assistant that provides a step-by-step process to create a project, you can use Archi tect to visual ly performthe ini tial creation of a project. However, before you can begin usingArchi tect, you must fi rst create the project object wi th the Project CreationAssistant and define various Archi tect project creation options.

Prerequisi tes

Before creating a project, you must connect to a metadata reposi tory and toa data source, as described in the sections l isted below:

Connecting to the metadata reposi tory, page 94

Connecting to a data source, page 94

You should also review the information in Chapter 4, Creating andConfiguring a Project before creating a project using Archi tect.

To create a new project using Architect

Log in to a project source in MicroStrategy Developer.

To create a project source which connects to your data throughIntel l igence Server, see the Configuring and Connecting Intel l igenceServer chapter of the Instal lation and Configuration Guide.

From the Schema menu, select Create New Project. The Project CreationAssistant opens, as shown below:




Click Create project. The New Project page opens.

Define the project configuration settings l isted below:

Name: A name for the project. This name is used to identi fy a project wi thina project source.

Description : An optional description for the project. This description cangive a brief overview of the purpose of the project as compared to yourother projects.

Default document directory: The directory location to store al l HTMLdocuments. For more detai ls on how to set up HTML documents for aproject, see the Instal lation and Configuration Guide.

Enable the guest user account for this project: Select this check box toal low users to log in to a project wi thout any user credentials. Users canthen to connect to Intel l igence Server wi th a l imi ted set of privi leges andpermissions (defined by the Publ ic group).




Enable Change Journal for this project: Select this check box to enablethe Change Journal for the project. An entry is automatical ly included inthis journal when any object in a project is modi fied, al lowing you to keeptrack of any changes to your project. For information on the ChangeJournal , see the System Administration Guide.

Languages: Cl ick this button to define languages that are avai lable formetadata objects in this project. The languages that you select are alsolanguages that are avai lable for the international ization of your metadataobjects. If a language is avai lable for a project, you can provide objectnames, descriptions, and other information in various languages. Forexample, in a project you can provide the names of attributes, metrics,folders, and other objects in mul tiple languages. For information on how toprovide international ized data for metadata objects such as attributes,metrics, folders, and so on, see the System Administration Guide.

MicroStrategy provides international ized data for common metadata objectsin the avai lable, defaul t languages l isted. For example, data is avai lable forthe name and description of the Publ ic Objects folder as wel l as othercommon objects for each language l isted as avai lable by defaul t. If you addother languages, you must supply al l international ized data for commonmetadata objects.

When you create a new project, a language check ensures that the languagesettings of the user profile of the local machine (the CURRENT_USER registrykey), the language of the local machine (the LOCAL_MACHINE registry key),and the Project locale property match. If these properties do not match, it canlead to inconsistencies in the language display. The language check preventsthese inconsistencies and ensures that the language display is consistentacross the project.

These language options are not related to supporting the integration ofinternationalized data from your data source into MicroStrategy. Informationon defining your data source to support data internationalization is provided inSupporting data international ization, page 64 .





If you plan to use internationalized data from your data source with attributes ina project, you must define how data internationalization is enabled beforecreating attributes. Enabling data internationalization is described in Enabl ingdata international ization for a project, page 106 .

Click OK to create the project object.

Cl ick the arrow for Architect. The Warehouse Database Instance dialogbox opens.

To continue creating the project with the Project Creation Assistant, seeCreating a new project using the Project Creation Assistant, page 98 .

Select a database instance from the drop-down l ist. The database instanceselected in this dialog box determines which data source is accessed.

Cl ick OK . MicroStrategy Archi tect opens.

From the Architect Button , select Settings. The MicroStrategy Archi tectSettings dialog box opens.

Define the various options for how Archi tect displays data, automatical lycreates and maps schema objects, loads the Warehouse Catalog, andupdates the project's schema.

Reviewing and defining these options before using Archi tect can saveyou a lot of time when creating and modi fying projects. For informationon al l the options avai lable, see Creating and modi fying projects, page117.

Cl ick OK . You can now begin to add tables to your project, and createattributes, facts, user hierarchies, and so on. These tasks are l isted below:

Adding tables, page 143

Creating facts, page 155

Creating attributes, page 169




Creating user hierarchies, page 202

Modifying projects using ArchitectAfter creating your project, modi fications to schema objects can becompleted in separate edi tors including the Fact Edi tor, Attribute Edi tor,Hierarchy Edi tor, and so on. These edi tors provide al l of the simple andadvanced schema object features, al lowing you to create and modi fyschema objects one-by-one.

Archi tect provides a single integrated environment in which you can makeproject-wide changes as wel l as create or modi fy individual schemaobjects. Rather than creating or modi fying schema objects one-by-one, youcan create and modi fy mul tiple schema objects for your project. Archi tectalso al lows you to add tables to your project and create or modi fy attributes,facts, and user hierarchies al l from the same interface.

Modi fying your project using Archi tect also al lows you to lock the schema ofyour project, preventing users from encountering reporting issues orreturning outdated data during periods of scheduled project maintenance.

When opening a project with Architect, basic information is loaded for all theobjects in a project. These objects include attributes, facts, tables, and so on.Once the project is open and accessible in Architect, additional information forthe objects are loaded incrementally as well as on an as-needed basis. Thisallows Architect to load projects faster than if all information for a project wasloaded when first opening the project in Architect.

The procedure below provides steps to modi fy a project using Archi tect.

Prerequisi te


To modify a project using Architect




From the Schema menu, select Architect.

If a message is displayed asking i f you want to open Archi tect in read onlymode or edi t mode, select Edit and cl ick OK to open Archi tect in edi t modeso that you can make changes to the project. MicroStrategy Archi tect opens.

If you are only given the option of opening Architect in read only mode, thismeans another user is modify ing the project's schema. You cannot openArchitect in edit mode until the other user is finished with their changes and theschema is unlocked.

For information on how you can use read only mode and edit mode for variousschema editors, see Using read only or edi t mode for schema edi tors,page 111 .

From the Architect Button , select Settings. The MicroStrategy Archi tectSettings dialog box opens.

Define the various options for how Archi tect displays data, automatical lycreates and maps schema objects, loads the Warehouse Catalog, andupdates the project's schema.

Reviewing and defining these Archi tect options before using Archi tectcan save you a lot of time when creating and modi fying projects. Forinformation on al l the options avai lable, see Creating and modi fyingprojects, page 117.

Cl ick OK to return to Archi tect. You can now begin to add or remove tablesto your project and create and modi fy attributes, facts, user hierarchies, andso on:

Adding, removing, and administering tables, page 140







Defining project creation and display optionsArchi tect provides various options that determine how you can create andmodi fy projects. Reviewing and defining these options before usingArchi tect can save you time when creating and modi fying projects.

The options you can define determine how Archi tect displays data,automatical ly creates and maps schema objects, loads the WarehouseCatalog, and updates the project's schema. Some of these options areavai lable in the MicroStrategy Archi tect Settings dialog box. For steps toaccess this dialog box, see Accessing the Archi tect options, page 125. Theavai lable options are described in the sections l isted below:

Control l ing the view that is displayed when starting Archi tect, page 125

Disabl ing the abi l i ty to add tables, page 134

Automatical ly updating the project schema, page 134

Creating metrics based on the facts of a project, page 135

You can also access various Archi tect options from the Archi tect toolbar, asdescribed below:

From the Home tab:

In the View area, cl ick the arrow icon ( ) to access the fol lowing

configurations:

Displaying columns and attribute forms in tables, page 131

In the Auto Arrange area, cl ick the arrow icon ( ) to access the fol lowing

configurations:

Defining the layout of the Archi tect working area, page 138

From the Design tab:

In the Auto Recognize area, cl ick the arrow icon ( ) to access the fol lowing

configurations:

Automating the creation of facts and attributes, page 126



Automatical ly mapping columns to existing attribute forms and facts, page130

Automatical ly defining attribute relationships, page 136

In the Edi tors area, cl ick the Edit logical size of tables icon (shown below)to access the Logical Size Edi tor, which provides access to the fol lowingconfigurations:

Defining logical sizes for tables, page 139

Accessing the Architect options

You can access the MicroStrategy Archi tect Settings dialog box fromArchi tect. In Archi tect, from the Architect Button , select Settings. TheMicroStrategy Archi tect Settings dialog box opens.

Controlling the view that is displayed when starting Architect

Archi tect al lows you to choose whether the Project Tables View or theHierarchy View is displayed at startup. You can configure this behaviorusing the Choose the default open view drop-down l ist. This drop-downl ist is avai lable in the Configuration tab of the MicroStrategy Archi tectSettings dialog box. You can choose from the options l isted below todetermine what view is displayed when Archi tect opens:

Last Used : Select this option to display the view that was used last duringthe most recent use of Archi tect.

Project Tables View: Select this option to display the Project Tables View.

Hierarchy View: Select this option to display the Hierarchy View.



Automating the creation of facts and attributes

You can save time during the schema creation process of designing aproject by al lowing Archi tect to automatical ly create attributes and facts.Archi tect can create attributes and facts automatical ly when you add tablesto your project. The attributes and facts are created based on data types,database column names, primary and foreign keys, and other schemacreation heuristics.

You can define how attributes and facts are created when tables are addedto your project by defining the automatic column recogni tion rules. Toaccess the options l isted below, from the Design tab, in the AutoRecognize area, cl ick the arrow icon ( ):

Do not auto recognize: Select this option to disable the automatic creationof attributes and facts when tables are added to your project usingArchi tect.

This can be a good option to use i f you are updating a project in whichyou have already defined the bulk of the project schema. In thisscenario, i t prevents Archi tect from automatical ly defining attributes andfacts that might not be needed in the project. After adding extra tables toyour project you can create any required attributes and facts in a waythat fi ts your current project schema.

Auto recognize: Select this option to enable the automatic creation ofattributes and facts when tables are added to your project using Archi tect.

This option can save time during the schema creation process ofdesigning a project by al lowing Archi tect to automatical ly createattributes and facts.

When selecting this option, facts are created for database columns thatuse numeric data types and are not used for attribute forms. Attributesand attribute forms are created based on various schema creationheuristics and the rules that you define with the Advanced Optionsl isted below:



Separator: Type the character used as a separator in your databasecolumn names. For example, a database column name such as USER_ID

uses the underscore character (_ ) as a separator.

Attribute naming rule: Type database column name suffixes that identi fythat the column should be mapped to a new attribute as the identi ty form.For example, the suffix ID is commonly used for database columns that aremapped to attributes as an identi ty form.

Use a semicolon (; ) to separate suffixes that are to be mapped to newattributes.

You can also define how the attribute name is created. Use the vertical bar(| ) to define what the suffix is replaced with in the resul ting attribute name.The text to the left of the | character is the suffix, and the text to the right ofthe | character is what replaces the suffix in the attribute name that iscreated.

For example, including ID|; creates new attributes for any databasecolumns that use the suffix ID , and removes the ID suffix from the attributename. When a table that uses a column such as USER_ID is imported intothe project, a new attribute named User is created. Including DT|DATE;

creates new attributes for any database columns that use the suffix DT , andreplaces the DT suffix wi th DATE when creating an attribute name. When atable that uses a column such as YEAR_DT is imported into a project, a newattribute named Year Date is created.

Attribute form naming rule: Type database column name suffixes thatidenti fy that the column should be mapped to a new attribute form. Forexample, the suffix DESC is commonly used for database columns that aremapped to description attribute forms.

Use a semicolon (; ) to separate suffixes that are to be mapped to newattribute forms.

You can also define how the attribute form name is created. Use the verticalbar (| ) to define what the suffix is replaced with in the resul ting attribute



form name. The text to the left of the | character is the suffix, and the text tothe right of the | character is what replaces the suffix in the attribute formname that is created.

For example, including DSC|DESC; creates new attribute forms for anydatabase columns that use the suffix DSC , and replaces the DSC suffix wi thDESC when creating an attribute form name. When a table that uses acolumn such as PRODUCT_DSC is imported into a project, a new attributeform named Product Desc is created.

In addi tion to using these rules to define attributes and attribute forms,selecting the Auto recognize option also employs other schema creationheuristics:

The automatic column mapping rules described in Automatical ly mappingcolumns to existing attribute forms and facts, page 130, are employed tomap columns to existing attribute forms that use the columns in theirdefini tions.

An attribute is created for any column defined as a primary or foreign key,and the column name for the primary key is used to define the attributename. The column name for the primary key is used to define the attributename even i f the primary key column is not included in the project.

Every column must be mapped to ei ther a fact or an attribute. If none of theschema creation heuristics or the rules you define can determine whether tocreate a fact or attribute for the column, an attribute is created for thecolumn.

Auto recognize form format: Select this check box to define when attributeform formats are appl ied to newly created attribute forms. Attribute formformats control how the form is displayed and how fi l ters are defined. Forexample, speci fying a format type of Big Decimal al lows users to preserveprecision when qual i fying on a form with more than 15 digi ts. For moredetai led information on each form format type, see Format types, page 588.



You can define rules on when to apply attribute form formats by using theOptions l isted below:

Default form format: Select the form format to use for forms that do not fi tany of the other form format rules. The defaul t selection is Text. You cannotdefine the rules for when to use the defaul t form format, as i t is impl ici tlydefined to be used when al l other form format rules are not met.

Form format: Select a form format, and define the rules for applying theform format to newly created attribute forms. The rules for when to apply acertain form format are defined by the options l isted below. If you supplynei ther a column data type nor a column naming rule for a form format, theform format is never automatical ly appl ied to a newly created attribute form.

Column data type: Select the column data types relevant to a form format.Only columns with one of the selected data types are considered to bedefined as the associated form format. For example, the Number form formatis defined to be used for columns with decimal , double, float, integer,numeric, and real data types by defaul t. If you do not select relevant datatypes for a form format, only the column naming rules described below areused to determine when to apply the associated form format.

Naming rules: Type the column names relevant to a form format, separatedby a semicolon (; ). Only columns with one of the provided column namesare considered to be defined as the associated form format. For example,the Picture form format is defined to be used for columns with Picture,Image, Icon, Drawing, Figure, Photo, and Print column names by defaul t. Ifyou do not type relevant column names for a form format, only the columndata type rules described above are used to determine when to apply theassociated form format.

An attribute form can only have one form format. The rules for each formformat should be defined so that they are all mutually exclusive. If an attributeform meets the rule requirements of more than one form format, the first formformat in the Form format lis t is applied to the form.



Display message if objects are not recognized : If this check box isselected, which i t is selected by defaul t, a message is displayed during theautomatic creation of schema objects i f some of these objects are notcreated. By clearing this check box, this message is never displayed.

Automatically mapping columns to existing attribute forms andfacts

You can save time during the schema creation process of designing aproject by al lowing Archi tect to automatical ly map columns to attributeforms and facts already defined in your project. Archi tect can map columnsto existing attribute forms and facts automatical ly when you add tables toyour project.

You can enable the automatic mapping of columns to attribute forms andfacts in your project when tables are added to your project by selecting theUse automatic column mapping check box. To access this option, fromthe Design tab, in the Auto Recognize area, cl ick the arrow icon ( ).

When this option is enabled and tables are added to your project, thecolumn expressions included in the table are compared to the columnexpressions used in attribute forms and facts. If an attribute form or fact isfound that matches the column expression, then the column is mapped tothat attribute form or fact. For example, the MicroStrategy Tutorial projectmaps the Revenue fact to the column TOT_DOLLAR_SALES . If automaticcolumn mapping is enabled and you use Archi tect to add a table thatincludes the TOT_DOLLAR_SALES column to the project, the TOT_

DOLLAR_SALES column for the table is automatical ly mapped to theRevenue fact.

The Use automatic column mapping option is particularly helpful toautomatical ly map columns in newly added tables to existing facts andattributes, wi thout creating any new facts or attributes. To map columns innewly added tables to existing facts and attributes, as wel l as create newfacts and attributes based on various rules, you should enable the Auto



recognize option, as described in Automating the creation of facts andattributes, page 126.

Whi le enabl ing or disabl ing this option, you can also select or clear theDisplay message if objects are not recognized check box. If this checkbox is selected, which i t is selected by defaul t, a message is displayedduring the automatic creation of schema objects i f some of these objectsare not created. By clearing this check box, this message is neverdisplayed.

Displaying columns and attribute forms in tables

When you add tables to your project using Archi tect, you can view thevarious schema objects included in the table as wel l as the columns thatare used to define the schema objects.

The display of data avai lable in the tables included in your project can bedefined using the options l isted below.

To access the options lis ted below, from the Home tab, in the View area, c lickthe arrow icon ( ).

Physical Tables View area, page 131

Visible Links area, page 133

Physical Tables View area

Prior to selecting options in the Project Tables view area, you must chooseto display the data avai lable in tables in ei ther physical view or logicalview. This can be defined using the fol lowing Archi tect toolbar options:

Display table physical view: On the toolbar, select this option to

display the columns that are avai lable in the table. Columns are displayedin the form Column_Name : Column_Data_Type . For example, the YR_

CATEGORY_SLS table from the MicroStrategy Tutorial project shown belowis displayed in physical view:



If you display tables in physical view, the options in the Project TablesView area have no affect on the display of data within the tables inArchi tect.

Display table logical view: On the toolbar, select this option to display

the columns that are avai lable in the table and how they relate toMicroStrategy schema objects. The LU_YEAR and LU_REGION tables fromthe MicroStrategy Tutorial project shown below are used to i l lustrate thevarious logical view options avai lable for displaying columns and attributeforms in tables.

If you display tables in logical view, the options in the Project TablesView area can be used to modi fy the display of data within tables inArchi tect. These options are described below:

Display available columns on logical tables: Select this logical viewoption to display columns that are avai lable in the table but are not used inany schema objects in the project. Columns are displayed in the formColumn_Name : Column_Data_Type .

In the LU_YEAR table shown above, selecting this option displays thePREV_YEAR_ID : INTEGER column which has not been mapped to aschema object.

You can also display this information for an individual table by right-cl icking a table, pointing to Properties, then pointing to Logical View, andselecting Display Available Columns.

Selecting this option also al lows you to select the option described below:



Display columns used for data internationalization : Select this option todisplay columns that are avai lable in the table that used for datainternational ization. Columns are displayed in the form Column_Name :

Column_Data_Type .

In the LU_REGION table shown above, selecting this option displays thevarious REGION_NAME columns that are used to translate the name of aregion into various languages.

For information on supporting international ized data in a data source, seeSupporting data international ization, page 64.

Display attribute forms on logical tables: Select this option to displayattribute forms that are mapped to columns of the table. Attribute forms aredisplayed in the form Attribute_Form_Name : Attribute_Form_

Category (Column_Name ).

In the LU_YEAR table shown above, selecting this option displays the IDform and the Date form for the attribute Year.

You can also display this information for an individual table by right-cl icking a table, pointing to Properties, then pointing to Logical View, andselecting Display Attribute Forms.

Visible Links area

Maximum number of visible links per table row: Define the number of l inkl ines that are displayed when you select a column, fact, attribute, orattribute form in a table. When selecting one of these objects in a table, al ine is drawn to each occurrence of this object in other tables included inthe project. For example, selecting the Year attribute in the LU_YEAR tabledisplays a l ine that connects to every other occurrence of the Year attributein other tables.



Disabling the ability to add tables

By defaul t, Archi tect al lows you the flexibi l i ty to browse the WarehouseCatalog to add new tables to your project. However, i t can be beneficial todisable the abi l i ty to add tables to your project i f your project includes al lthe required tables. This prevents any unnecessary tables from beingadded to the project, which can trigger the creation of unnecessary schemaobjects. It also provides better performance whi le using Archi tect since al lthe tables in the Warehouse Catalog do not have to be made avai lable.

You can disable the abi l i ty to add new tables to your project using Archi tectby selecting the Disable loading warehouse catalog check box. Thisoption is avai lable in the Configuration tab of the MicroStrategy Archi tectSettings dialog box. Any tables not included in the project are hidden fromview in Archi tect.

Automatically updating the project schema

Changes made in Archi tect affect the schema of your project. By defaul t, theschema of your project is updated when you save your changes and exi tArchi tect. This ensures that your project is updated to reflect yourmodi fications.

Updating your project schema every time that you exi t Archi tect can bedisabled. The schema update process can require a substantial load onyour Intel l igence Server and require a considerable amount of time tocomplete. You may also have other project updates that you plan to performafter using Archi tect. In these scenarios, you can disable the projectschema update process, and instead execute a schema update manual ly atthe desired time. You can disable the project schema update process fromoccurring when closing Archi tect by clearing the Update schema afterclosing Architect check box. This option is avai lable in the Configurationtab of the MicroStrategy Archi tect Settings dialog box.



Creating metrics based on the facts of a project

Archi tect al lows you to create metrics based on the facts created for aproject. This can reduce the time i t takes to create the basic metrics for yourproject.

The options to create metrics based on the facts of your project areavai lable in the Metric Creation tab of the MicroStrategy Archi tect Settingsdialog box. On this tab, you can al low the automatic creation of metricsusing the aggregation functions l isted below:

Avg : To create metrics that perform an average calculation on the factexpression.

Sum: To create metrics that perform a summation calculation on the factexpression.

Count: To create metrics that perform a count calculation on the factexpression.

Min : To create metrics that perform a minimum calculation on the factexpression.

Max: To create metrics that perform a maximum calculation on the factexpression.

Var: To create metrics that perform a variance calculation on the factexpression.

Advanced Options: Cl ick Advanced Options to open the Advanced Optionsdialog box, which lets you define metric naming conventions. A metricnaming convention can be defined for each aggregation function l istedabove. When a metric is created for an aggregation function, the metricnaming convention for that aggregation function is used to define the namefor the metric. You can use the characters %1 to insert the name of the factinto the metric name. For example, you can create the fol lowing metricnaming convention for metrics created based on the Avg aggregationfunction.



Average %1

If you create a fact named Cost and select to create metrics wi th the Avgaggregation function, a metric wi th the name Average Cost is created bysubsti tuting the fact name for the %1 characters in the metric namingconvention.

When a fact is created for a project, metrics are created for the fact usingthe selected aggregation functions. A separate metric is created to supporteach aggregation of a fact. The metrics are created in thePublic Objects/Metrics folder of a MicroStrategy project.

Automatically defining attribute relationships

Archi tect al lows you to create attribute relationships based on the design ofthe data in your data source. This can help reduce the time required tocreate the relationships between the attributes within a project.

To access the options to automatical ly create attribute relationshipsbetween the attributes within a project option, from the Design tab, in theAuto Recognize area, cl ick the arrow icon ( ). You can select from the

fol lowing options to automatical ly create attribute relationships:

Do not automatically create relations: Attribute relationships are notautomatical ly created based on the design of the data in your data source.For information on manual ly defining attribute relationships with Archi tect,see Defining attribute relationships, page 194.

Automatically create relations in System Hierarchy: Attributerelationships are automatical ly created based on the design of the data inyour data source as you add tables to your project. These attributerelationships are created automatical ly the fi rst time you switch toHierarchy View after an appl icable attribute has been added to the project.To manual ly execute the action of automatical ly defining attributerelationships you can use the System Hierarchy dialog box, as described inAutomatical ly defining attribute relationships, page 199.



Attribute relationships are created based on the rules that you select inthe Advanced Options, as described below:

Based on Primary Keys/Foreign Keys: Creates attribute relationshipsbased on the primary keys and foreign keys defined on your tables. Eachattribute that acts as a foreign key of a table is defined as a parent attributeof each attribute that acts as a primary key of the same table. The attributerelationship is defined as a one-to-many relationship from the foreign keyattribute (parent attribute) to the primary key attribute (chi ld attribute).

Based on lookup tables: Creates attribute relationships based on lookuptables that do not include primary key or foreign key information. To definea table as a lookup table for an attribute, see Creating attributes, page 169.Each attribute that defines a table as i ts lookup table is defined as a chi ldattribute of al l other attributes in the same table, that do not define the tableas i ts lookup table. Each attribute relationship is defined as a one-to-manyrelationship from the parent attribute to the chi ld attribute.

Based on sample data from the table: Creates attribute relationships forattributes that share the same lookup table. To define a table as a lookuptable for an attribute, see Creating attributes, page 169.

Archi tect analyzes sample data for the table. The attributes with fewerdistinct values are defined as parents of the attributes with more distinctvalues, using a one-to-many relationship from the parent attribute to thechi ld attribute. For example, a lookup table includes four rows of data,which include data related to year and quarter. Each row includes the sameyear (for example, 2009), but the quarter changes for each row (Q1, Q2, Q3,Q4). In this case, the Year attribute is created as a parent of the Quarterattribute.

Show preview result: Displays the attribute relationships that can beautomatical ly created in a Resul ts Preview dialog box. From this dialogbox, you can select which attribute relationships should be created, andwhich attribute relationships should be excluded. This is the defaul tbehavior. If you clear the Show preview resul t check box, al l of the potential



attribute relationships are created automatical ly wi thout fi rst displayingthem in the Resul ts Preview dialog box.

After al l relationships are determined by the rules that you selected,Archi tect performs a final analysis on the attribute relationships that areto be created. Any attribute relationships that are found to be redundantare not created. This ensures that attribute relationships are created thatproperly reflect the design of the data in your data source. Forinformation on modi fying the attribute relationships that are created, seeDefining attribute relationships, page 194.

Display message if objects are not recognized : If this check box isselected, which i t is selected by defaul t, a message is displayed during theautomatic creation of attribute relationships i f some of these attributerelationships are not created. By clearing this check box, this message isnever displayed.

Defining the layout of the Architect working area

Archi tect al lows you to define the layout of the working area for the ProjectTables View and the Hierarchy View in Archi tect using the auto arrangeoptions on the Archi tect toolbar. You can also define the margins of thisworking area using the options l isted below:

To access the options lis ted below, from the Home tab, in the Auto Arrangearea, c lick the arrow icon ( ).

Margin to the left: Type the number of pixels to use as a margin for the leftside of the Archi tect working area. This provides whi te space at the leftmargin of the working area, which can provide visual separation betweenthe working area and the other panes and options avai lable on the Archi tectinterface.

Margin to the right: Type the number of pixels to use as a margin for theright side of the Archi tect working area. This provides whi te space at theright margin of the working area, which can provide visual separation



between the working area and the other panes and options avai lable on theArchi tect interface.

Defining logical sizes for tables

Archi tect al lows you to view and define the logical sizes for the tables in aproject using the Logical Size Edi tor. The logical table size determineswhich logical table to use to answer a query when multiple logical tableswould provide the same data. The table wi th the lowest logical table size isused, as a lower logical table size means the table has a higher level ofaggregation. The performance of accessing a table wi th a higher level ofaggregation is usual ly better than accessing a table wi th a lower level ofaggregation.

To access the options lis ted below, in the Editors area, c lick the Edit logicalsize of tables icon (shown below) to access the Logical Size Editor.

The Logical Size Edi tor displays several columns, as fol lows:

Size locked : Displays whether a table's size is locked (selected) orunlocked (cleared). Al l tables have their size unlocked by defaul t. When atable's logical size is locked the table is excluded from the logical tablesize calculation when a schema update is performed. This helps to retainany table sizes that are manual ly defined.

Table name: Displays the name of each table in the warehouse.

Size value: Displays the current size value for each table. Archi tect ini tial lyassigns logical table sizes based on an algori thm that takes into accountthe number of attribute columns and the various levels at which they exist intheir respective hierarchies. See Defining logical table sizes, page 507 fordetai ls on how table sizes are calculated.



You can cl ick in the Size value cel l for a table to manual ly define thelogical size for the table. You can then lock the table size for the table toensure that this manual value is retained.

Row count (optional): This column displays the number of rows in eachtable. Cl ick the Display each table row count in the edi tor icon ( ) to

display the Row count column.

Using the Architect toolbarArchi tect provides a set of toolbar icons, shown in the image below, tofaci l i tate the tasks of creating and modi fying a project.

The options that are avai lable on the toolbar are determined by whether youare in Project Tables View or Hierarchy View. To review detai ledinformation on each toolbar option, wi th Archi tect open, press F1 to openthe Archi tect Help and search for the topic Archi tect: Toolbar options.

Adding, removing, and administering tables

The warehouse tables for a project determine the set of data avai lable to beanalyzed in the project. You can use Archi tect to add, remove, update, andmanage tables for your project.

You can also use the Warehouse Catalog to add tables to and remove tablesfrom your project, as described in Creating a new project using the ProjectCreation Assistant, page 98 .

Archi tect displays al l of the avai lable data sources for the project in theWarehouse Tables pane, as shown below.



If the Warehouse Tables pane is not displayed in Architect, from the Hometab, in the Panels area, c lick Show the Warehouse tables section . TheWarehouse Tables pane is only available in the Project Tables View ofArchitect.

Within each data source is a l ist of al l the tables in the data source to whichyou are connected through a database instance. From this l ist, you selectthe lookup, fact, and relationship tables to use in your new project. Youshould also include al l other tables needed to complete your project,including transformation tables, aggregate tables, and parti tion mappingtables.

The database login you use must have read priv ileges so you are able to viewthe tables in the selected data source. Database instances and databaselogins are MicroStrategy objects that determine the data sources to which aproject connects. To learn more about these objects, refer to the Instal lationand Configuration Guide .

Using Archi tect, you can perform the fol lowing tasks to add, remove,update, and manage tables for your project:





Displaying data sources in Archi tect, page 142

Adding tables, page 143

Removing tables, page 145

Updating, modi fying, and administering tables, page 146

Organizing project tables: Layers, page 153

Displaying data sources in ArchitectYou can define which data sources in your system are displayed inArchi tect. Once displayed, you can begin to add tables from the data sourceinto your project.

Prerequisi tes

A database instance has been created for the data source. For informationon database instances and examples on how to create them, see theInstal lation and Configuration Guide.

You are creating or modi fying a project using Archi tect. For instructions,see Creating and modi fying projects, page 117.

To display data sources in Architect

With a project open in Archi tect, from the Architect Button , select SelectDatabase Instance. The Select Database Instance dialog box opens.

From the l ist of data sources, you can display or hide a data source:

Select a check box for a data source to display i t in Archi tect. Oncedisplayed, you can begin to add tables from the data source into yourproject.

Clear a check box for a data source to hide i t in Archi tect. You cannot hidea data source that is used in a project.

Cl ick OK to save your changes and return to Archi tect.




Adding tablesBefore you can begin creating attributes, facts, and hierarchies for yourproject, you must add tables to your project.

Along with making data avai lable in your project, adding tables to yourproject can also trigger the creation of attributes and facts, and the mappingof columns to attributes and facts. For information on defining howattributes and facts are created and mapped when adding tables to yourproject, see Defining project creation and display options, page 124 andDefining project creation and display options, page 124.

Once tables are selected from the data source and added to your project, theybecome schema objects known as logical tables in MicroStrategy. Logicaltables are representations of the tables that are available in the datawarehouse, and are discussed in detail in Appendix B, Logical Tables.

The procedure below provides steps to add tables to your project usingArchi tect.

Prerequisi tes


The abi l i ty to add tables using Archi tect is enabled. For information onenabl ing and disabl ing the abi l i ty to add tables using Archi tect, seeDefining project creation and display options, page 124.

If changes have been made to the tables within the tables' data source, youmust update the structure of the tables in MicroStrategy to ensure they canbe added to a project successful ly. For steps to update table structures, seeUpdating, modi fying, and administering tables, page 146.

To add tables to a project using Architect

With a project open in Archi tect, select the Project Tables View.



From the Warehouse Tables pane, expand a data source.

If you have the MultiSource Option, you can add tables from multipledata sources into your project. For information on adding tables frommultiple data sources into your project wi th the Warehouse Catalog orArchi tect, see Accessing multiple data sources in a project, page 353.

Right-cl ick a table, and then select Add Table to Project. The table isadded to the project and included in the Project Tables View of Archi tect.

To view a sample of the data within a table, right-c lick the table and selectShow Sample Data .

If you have selected to automatical ly create attributes, attribute forms, andfacts based on schema creation heuristics (see Defining project creationand display options, page 124 and Defining project creation and displayoptions, page 124), the Resul ts Preview dialog box opens.

Attributes, attribute forms, and facts that can be created based on thecolumns of the table added to the project are displayed. Select thecheck box for each object to create in the table when the table is addedto the project. If more than one attribute form is avai lable for creation foran attribute, you must select the ID form. Any other attribute forms forthat attribute are optional . Cl ick OK to complete the processes of addingthe table to the project and creating any selected attributes, attributeforms, and facts.

Once you have imported tables for your project, you can continue with otherproject design tasks, which include:







Removing tablesYou can remove tables from your project to keep your project frombecoming cluttered with tables that are no longer required for your project.You can remove a table from a project using Archi tect by accessing ProjectTables View, right-cl icking a table, and selecting Delete.

However, you cannot remove a table from a project i f schema objects in theproject are dependent on the table. For example, an attribute is dependenton the table that is set as the lookup table for the attribute.

When you attempt to remove a table that has dependent objects, you canview a l ist of dependent objects for the table. You must fi rst delete al ldependent objects from the project before you can delete the table.

Removing tables from a project that have been removed from adata source

When tables that are included in a project are removed from the data sourcethat they were avai lable in, you can use Archi tect to remove these tablesfrom the project. This al lows your project to display an accurate l ist oftables that are included in the project from the selected data source.

The steps below show you how to perform this task using Archi tect. Toremove these tables using the Warehouse Catalog, see Managingwarehouse and project tables, page 330.

If tables that were not included in a project are removed from the data source,these tables are automatically removed from the display of available tables inArchitect.

To remove tables from a project that have been removed from a data

source








If the Warehouse Tables pane is not displayed, from the Home tab, in thePanels area, cl ick Show the Warehouse tables section .

In the Warehouse Tables pane, expand the database instance for the datasource, which has had tables removed. The Warehouse Catalog dialog boxopens. If this dialog box does not open, there are no tables that need to beremoved from the project.

Select the check box for a table to remove i t from the project.

After you have selected al l the tables to delete, cl ick OK to remove thetables that were selected to be deleted and return to Archi tect.

If a message is returned that a table cannot be removed because objectsdepend on i t, you can cl ick Yes to review a l ist of dependent objects. Toremove the table from the project, al l dependent objects must be deleted.

From the Home tab, in the Save area, cl ick Save and Update Schema tosave your changes.

Updating, modifying, and administering tablesWith Archi tect, you can update and manage the tables in your project toensure that the data in your project is up to date and accurate, as describedin the sections l isted below:



Updating tables, page 147

Modi fying and viewing table defini tions, page 147

Modi fying data warehouse connection and operation defaul ts, page 151

Updating tables

With Archi tect, you can update individual tables or al l of the tables for adata source at once. This ensures that the data avai lable in your project isup to date with any changes made to the tables in the data source. Theprocedure below describes how to update tables using Archi tect.

Prerequisi te


To update tables using Architect


From the Warehouse Tables pane, you can update al l tables for a datasource or update individual tables as described below:

To update al l tables for a data source, right-cl ick a data source, and selectUpdate. Al l the tables for the data source are updated to reflect theirdefini tions in the data source.

To update an individual table, expand a data source, right-cl ick a table, andselect Update Structure. The table is updated to reflect i ts defini tion in thedata source.

Modifying and viewing table definitions

Once a table is added to a project, you can modi fy and view tabledefini tions using the Properties pane in Archi tect. To view the variousproperties and contents of a table in Archi tect, from the Tables tab of the



Properties pane, select the table from the drop-down l ist. The YR_

CATEGORY_SLS table of the MicroStrategy Tutorial project shown below isused as an example of how you can modi fy and view tables defini tionsusing Archi tect.

When you select a table in Archi tect, the Properties pane al lows you tomodi fy and view table defini tions as described below.

You can select a property in the Properties pane to view a description of theproperty. The description is displayed at the bottom of the Properties pane.

Defining and viewing table defini tions: Defini tion section, page 149

Modi fying attributes in a table: Mapped Attributes section, page 150

Modi fying facts in a table: Mapped Facts section, page 151

Modi fying column names and data types in a table: Member Columnssection, page 151



Defining and viewing table definitions: Definition section

When you select a table in Archi tect, the Defini tion section of the Propertiespane displays the various properties for the table. These properties andhow to use them are described below:

ID : The identi fier of the table. You cannot modi fy this value.

Name: The name of the table in a MicroStrategy project. By defaul t, thename is inheri ted from the table name in the data source.

Description : The description of the table. A description can help explainthe purpose of a table in a project.

Hidden : Speci fies whether the table is defined as hidden. Select the checkbox to set the value to True, which defines the table as hidden.

Objects that are hidden are not displayed to a user unless the user haschanged his or her Developer Preferences and selected the Displayhidden objects check box. Therefore, defining an object as hidden doesnot necessari ly prevent users from viewing or accessing an object. Thebest way to prevent users from viewing or accessing an object is torestrict the user permissions for i t.

Location : The location of a table in a project.

Database Name: The name of the table in the data source. If the name of atable has changed in the data source, you can type the new name for thetable in this property. This al lows a MicroStrategy project to locate a tableafter i ts name has changed in i ts data source.

Row Count: The number of rows in the table. To calculate a table's rowcount, right-cl ick the table and select Calculate Row Count.

The Calculate Row Count option is displayed only if the data source for thetable is expanded in the Warehouse Tables pane.



Table Name Space: The table name space for a table in a data source. Forinformation on table name spaces, see Modifying data warehouseconnection and operation defaul ts, page 337.

Logical Size: The logical size of a table, which is based on an algori thmthat takes into account the number of attribute columns in a table and thevarious levels at which they exist in their respective hierarchies. You canalso type a logical size to manual ly change the logical size of a table.Logical table sizes are a signi ficant part of how the MicroStrategy SQLEngine determines the tables to use in a query.

Logical size locked : Speci fies whether the logical size of a table can bemodi fied. Select the check box to set the value to True, which locks thetable's logical table size.

Primary DB Instance: The primary database instance of a table.

If your project supports mapping tables in a project to tables in multipledata sources, you can select Primary DB Instance and cl ick the ...(browse) button to open the Avai lable Database Instances dialog box.From this dialog box, you can view the table's data sources. You canalso change the database instance (which is associated with a datasource) that is used as the primary database instance for the table. Forinformation on adding tables from multiple data sources into your projectwi th the Warehouse Catalog or Archi tect, see Accessing multiple datasources in a project, page 353.

Modifying attributes in a table: Mapped Attributes section

When you select a table in Archi tect, the Mapped Attributes section of theProperties pane displays the attributes that are mapped to columns in thetable. From the Properties pane, you can select a column mapped to anattribute form and cl ick the ... button to open the Modi fy Form Expressiondialog box. From this dialog box, you can modi fy the attribute formexpression.



For information on creating and modi fying attribute forms in Archi tect, seeCreating and modi fying attributes, page 168. For information on attributeforms and how to create and modi fy them from the Attribute Edi tor, seeColumn data descriptions and identi fiers: Attribute forms, page 270.

Modifying facts in a table: Mapped Facts section

When you select a table in Archi tect, the Mapped Facts section of theProperties pane displays the facts that are mapped to columns in the table.From the Properties pane, you can select a column mapped to a fact andcl ick ... (the browse button) to open the Modi fy Fact Expression dialog box.From this dialog box, you can modi fy the fact expression.

For information on creating and modi fying facts in Archi tect, see Creatingand modi fying facts, page 154. For information on facts and how to createand modi fy them from the Fact Edi tor, see Chapter 6, The Bui lding Blocksof Business Data: Facts.

Modifying column names and data types in a table: Member Columns section

When you select a table in Archi tect, the Member Columns section of theProperties pane displays the columns that are avai lable in the table. Fromthe Properties pane, you can select a column and cl ick the ... button to openthe Column Edi tor dialog box. From this dialog box, you can modi fy thecolumn name and data type.

You can modi fy the column name and data type i f this information haschanged in the data source. This al lows a MicroStrategy project to be ableto locate a column after i t has been renamed in the data source.

Modifying data warehouse connection and operation defaults

You can speci fy various settings for data warehouse connection andoperation defaul ts using Archi tect. These settings are part of theWarehouse Catalog options described in Modifying data warehouseconnection and operation defaul ts, page 337.



The procedure below describes how to access a subset of the WarehouseCatalog options from Archi tect.

Prerequisi te


To modify data warehouse connection and operation defaults


From the Warehouse Tables pane, right-cl ick a data source and selectWarehouse Catalog Options. The Warehouse Catalog options dialog boxopens.

When accessed from Archi tect, only a subset of these Warehouse Catalogsettings are displayed, including:

Warehouse Connection : These options al low you to modi fy the databaseinstance and database login used to connect the data warehouse to aproject. For information on these options, see Modifying data warehouseconnection and operation defaul ts, page 337.

Read Settings: These options al low you to customize the SQL that readsthe Warehouse Catalog for every platform except Microsoft Access. Forinformation on these options, see Modifying data warehouse connectionand operation defaul ts, page 337.

Table Prefixes: These options al low you to speci fy whether table prefixesare displayed in table names and how prefixes are automatical ly defined fortables that are added to the project. For information on these options, seeModifying data warehouse connection and operation defaul ts, page 337.

Once you are finished defining Warehouse Catalog options, cl ick OK tosave your changes and return to Archi tect.



Organizing project tables: LayersYou can improve the organization and clari ty of your project in Archi tect bycreating groups of tables that can be easi ly accessed and focused on.These groups of tables are referred to as layers, and they can help organizeMicroStrategy projects that require a large number of tables.

In the Project Tables View of Archi tect, you can select one or more tablesand define the group of tables as a layer. This layer can be accessed fromthe Layers drop-down l ist to focus on only the tables included in the layer.Any modi fications performed whi le viewing a layer are appl ied to theproject as a whole.

For example, you can select al l of the fact tables in your project and createa new layer named Fact Tables. This al lows you to quickly focus on onlythe fact tables included in your project.

The Al l Project Tables layer is a defaul t layer that includes al l tablesincluded in a project. This layer cannot be deleted.

The procedure below describes how to create a layer in Archi tect.

To create a layer in Architect








From the Project Tables View, select al l the tables to include in a layer.

To remove a table from a layer, right-c lick the table, and select RemoveFrom Layer.

From the Home tab, in the Layer area cl ick the Create New Layer option. Adialog box to name the layer opens.

In the Please enter the layer name field, type a name for the layer andcl ick OK . You are returned to Archi tect and the new layer is displayed in theProject Tables View.

Use the Layers drop-down l ist to swi tch between layers.

Creating and modifying facts

Facts are one of the essential elements wi thin the business data model .They relate numeric data values from the data warehouse to theMicroStrategy reporting environment. Facts general ly represent the answersto the business questions on which users want to report. For conceptualinformation on facts, see Chapter 6, The Bui lding Blocks of Business Data:Facts.

This section describes how to use Archi tect to create and modi fy facts,which includes:

Creating facts, page 155

Creating and modi fying multiple facts, page 158

Before you create facts for your project, you can select the type of metrics thatare created automatically when a fact is created for a project. This can reducethe time it takes to create the basic metrics for your project. For information on



configuring Architect to automatically create these basic metrics, seeDefining project creation and display options, page 124 .

Creating factsWith Archi tect you can create facts as part of your ini tial project designeffort as wel l as throughout the enti re l i fe cycle of a project.

To save the time i t takes to create al l the facts required for your project, youcan al low Archi tect to automatical ly create facts when tables are added toyour project. When tables are added to the project using Archi tect, facts arecreated for columns in tables that use numeric data types and are not usedfor attribute forms. To enable this automatic fact creation, see Definingproject creation and display options, page 124.

The procedure below describes how to create a fact using Archi tect.

Prerequisi tes

The procedure below assumes you have already created a project objectand added tables to the project. For information on creating a project usingArchi tect, see Creating projects using Archi tect, page 118.

To create a fact using Architect




If you are only given the option of opening Architect in read only mode, thismeans another user is modify ing the project's schema. You cannot openArchitect in edit mode until the other user is finished with their changes and the



schema is unlocked.


From the Project Tables View, locate and select the table that includes acolumn or columns to use in a fact defini tion.

Right-cl ick the table and select Create Fact. A dialog box opens to namethe fact.

Rather than creating facts by manual ly creating a fact expression, youcan al low Archi tect to automatical ly create simple facts defined on onecolumn. To do this:

Right-cl ick the table, point to Recognize, and then select Facts. TheResul ts Preview dialog box opens.

If facts are displayed, these facts can be created as described below:

Facts can be created for columns in tables that use numeric data types andare not used for attribute forms, as described in Defining project creationand display options, page 124.

Facts can be created by automatical ly mapping columns to facts alreadydefined in your project, as described in Defining project creation anddisplay options, page 124.

Select the check box for a fact to create the fact.

Cl ick OK . The facts you selected for creation are created within the table. Ifyou use this option to create simple facts, you can then skip to To definefact expressions and column al iases, page 158.

Type a name for the fact, and cl ick OK . The Create New Form Expressiondialog box opens to create a fact expression.

From the Available columns pane, drag and drop a column into the Formexpression pane.



You can include multiple columns as wel l as use numeric constants andmathematical operators and functions to create a fact expression. Forinformation on creating various types of fact expressions, see Mappingphysical columns to facts: Fact expressions, page 220.

In the Mapping area, select Automatic or Manual:

Automatic mapping means that al l of the tables in the project wi th thecolumns used in the fact expression are selected as possible source tablesfor the fact. You can then remove any tables mapped automatical ly andselect other tables.

Manual mapping means that al l of the tables in the project wi th the columnsused in the fact expression are located but are not selected as possiblesource tables for the fact. You can then select which of those tables areused as source tables for the fact. Other scenarios in which you should usethe manual mapping method include:

If you are creating a constant expression that is not based on a physicalcolumn in a project table, you must select the tables to apply the constantexpression to.

If the same column name does not contain the same data across di fferenttables, manual ly select the appropriate source tables for each fact.

For example, suppose you have a column named Sales , which exists inboth the Fact_Sales table and the Fact_Discount table. In the Fact_

Sales table, the Sales column contains revenue data. However, in theFact_Discount table, the Sales column contains discount data. In otherwords, al though the column name is the same in both tables (Sales ), thecolumns contain di fferent fact data in each table. When creating theRevenue fact, you must select the Manual mapping method so you canselect the Fact_Sales table as a source table for the Revenue fact. Whencreating the Discount fact, you must select the Manual mapping method soyou can select the Fact_Discount table as a source table for theDiscount fact. If you use the Automatic mapping method in both cases, theMicroStrategy SQL Engine may use the incorrect column for the facts.



Click OK to close the Create New Form Expression dialog box and createthe fact. The fact is displayed in the table used to create the fact.

To define fact expressions and column al iases

You can continue to define the fact by right-cl icking the fact and selectingEdit. The Fact Edi tor opens. Use the tabs of the Fact Edi tor to define factexpressions and create column al iases as described below:

Definition : This tab al lows you to define fact expressions. Fact defini tionsare discussed in How facts are defined , page 219.

Column Alias: This tab al lows you to create a column al ias for the fact.Column al iases are discussed in Fact column names and data types:Column al iases, page 227.

For detailed information about the options on each tab within the Fact Editor,refer to the MicroStrategy Developer Help (formerly MicroStrategyDesktop Help).

You cannot create fact level extensions using Architect. For information onhow to create fact level extensions, see Modifying the levels at which factsare reported: Level extensions, page 229 .

When your changes are complete, cl ick OK to return to Archi tect.


Creating and modifying multiple factsWith Archi tect, you can create and modi fy mul tiple facts in your projectquickly from an integrated interface. Archi tect al lows you to create andmodi fy facts in most of the same ways as the Fact Edi tor.

You cannot create fact level extensions using Architect. For information onhow to create fact level extensions, see Modifying the levels at which factsare reported: Level extensions, page 229 .



For conceptual information on facts as wel l as detai led examples, seeChapter 6, The Bui lding Blocks of Business Data: Facts. Refer to the l istbelow for steps to perform various fact defini tions using Archi tect:

Modifying facts wi th the Properties pane, page 159

Creating fact expressions, page 162

Creating and modi fying fact column names and data types: Column al iases,page 167

Modifying facts with the Properties pane

Once facts are created, you can modi fy and view fact defini tions using theProperties pane in Archi tect. To view the various properties of a fact inArchi tect, from the Facts tab of the Properties pane, select the fact from thedrop-down l ist. The Cost fact of the MicroStrategy Tutorial project shownbelow is used as an example of how you can modi fy and view facts usingArchi tect.



When selecting a fact in Archi tect, the Properties pane al lows you to modi fyand view facts as described below.


Prerequisi tes, page 184


Defining and viewing fact definitions: Definition section

When you select a fact in Archi tect, the Defini tion section of the Propertiespane displays the various properties for the fact. These properties and howto use them are described below:

ID : The identi fier of the fact. You cannot modi fy this value.



Name: The name of the fact in the MicroStrategy project.

Description : The description of the fact. A description can help explain thepurpose of a fact in a project.

Hidden : Speci fies whether the fact is defined as hidden. Select the checkbox to set the value to True, which defines the table as hidden.


Location : The location of the fact in a project.

Modifying fact expressions: Fact Expressions section

When you select a fact in Archi tect, the Fact Expressions section of theProperties pane displays the tables that the fact is included in, as wel l asthe fact expression used for the fact in that table.

In the Cost fact example shown in Modifying facts wi th the Properties pane,page 159, TOT_COST is displayed as the fact expression for most of thetables. However, the Cost fact uses a derived fact expression in theORDER_DETAIL table (derived fact expressions are described in Creatingderived facts and fact expressions, page 162). The Cost fact also uses adi fferent column name in the ORDER_FACT table (heterogeneous columnnaming is described in Creating facts wi th varying column names:Heterogeneous column names, page 164).

From the Properties pane, you can select a column mapped to a fact andcl ick the ... (browse) button to open the Modi fy Fact Expression dialog box.From this dialog box, you can modi fy the fact expression.



Creating fact expressions

A fact expression represents a mapping to speci fic fact information in thedata source. For conceptual information on fact expressions, see Mappingphysical columns to facts: Fact expressions, page 220.

Fact expressions are commonly created by mapping a column to a fact, asdescribed in Creating facts, page 155. With Archi tect, you can also createand define facts as l isted below:

Creating derived facts and fact expressions, page 162

Creating facts wi th varying column names: Heterogeneous column names,page 164

Creating derived facts and fact expressions

A derived fact has i ts value determined by an expression that contains morethan just a column in a table. Any operation on a column such as adding aconstant, adding another column's values, or setting the expression to bean absolute value creates a derived fact. In other words, you are creating afact from information that is avai lable in the data warehouse.

For more information on derived facts and derived fact expressions, seeMapping physical columns to facts: Fact expressions, page 220. Theprocedure below describes how to create a derived fact using Archi tect, andfol lows the example scenario provided in Mapping physical columns tofacts: Fact expressions, page 220.

To create a derived fact using Architect


For the example scenario, log in to the MicroStrategy Tutorial project.







From the Project Tables View, locate and select a table that includes acolumn or columns to use in a fact defini tion.

For the example scenario, select the ORDER_DETAIL table.

Right-cl ick the table and select Create Fact. The Create New FormExpression dialog box opens.


For the example scenario, drag and drop the QTY_SOLD column to addi t to the Form expression pane.

To complete the derived fact expression

A derived fact expression includes a combination of columns, numericalconstants, and mathematical operators. The steps below continue theexample scenario to provide a guidel ine of how to create derived factexpressions.

With the cursor in the Form expression pane, cl ick * (the multipl icationoperator) to add i t to the expression.

From the Available columns pane, double-cl ick the UNIT_PRICE columnto add i t to the end of the fact expression.



Under Mapping method , select Automatic.

Cl ick Validate to check whether the syntax of the expression is correct. Theexpression should appear as shown below:

Cl ick OK . You are returned to Archi tect. The derived fact is given a defaul tname and is displayed in the ORDER_DETAIL table.

To change the default name of the fact, right-c lick the fact in the table andselect Rename . Type the new name in the dialog box that appears and clickOK to save and return to Architect.


Creating facts with varying column names: Heterogeneous column names

In your warehouse, the same fact can access columns with di fferent columnnames. MicroStrategy al lows you to identi fy heterogeneous fact columnnames for each fact. With heterogeneous column names, you can refer thesame fact to multiple columns with di fferent column names and fromdifferent tables that identi fy the same quanti tative value.

For more information on heterogeneous column names, see Mappingphysical columns to facts: Fact expressions, page 220. The procedurebelow describes how to use Archi tect to create a fact wi th heterogeneouscolumn names, and fol lows the example scenario provided in Mappingphysical columns to facts: Fact expressions, page 220.



To create a fact with heterogeneous column names using Architect







From the Project Tables View, locate and select a table that includes acolumn or columns to use in a fact defini tion.

For the example scenario, select the ORDER_FACT table. This is one ofthe tables in which a heterogeneous fact column for the Uni ts Sold factexists.

Right-cl ick the table and select Create Fact. The Create New FormExpression dialog box opens.


For the example scenario, drag and drop the QTY_SOLD column to addi t to the Form expression pane.

In the Mapping method area, select Automatic.



Click OK . You are returned to Archi tect and the derived fact appears in theORDER_FACT table.

Right-cl ick the new fact and select Edit. The Fact Edi tor opens and the factexpression you just created appears in the Expressions pane.

To add additional columns for heterogeneous facts

Now you must add the other heterogeneous fact column as separateexpression for the fact.

Cl ick New. The Create New Fact Expression dialog box opens.

From the Source table drop-down l ist, select the CITY_CTR_SALES table.This is the other table that contains a heterogeneous fact column for theUni ts Sold fact.

From the Available columns pane, double-cl ick the TOT_UNIT_SALEScolumn to add i t to the Fact expression pane on the right.


Cl ick OK . You are returned to the Fact Edi tor and the fact expression thatyou just created appears in the Expressions pane. Now the fact that you arecreating maps correctly to i ts heterogeneous fact columns.

Cl ick OK . You are returned to Archi tect. The fact is given a defaul t nameand is now displayed in the table.

To change the default name of the fact, right-c lick the fact in the table andselect Rename . Type the new name in the dialog box that appears and clickOK to save and return to Architect.




Creating and modifying fact column names and data types: Columnaliases

A column al ias speci fies both the name of the column to be used intemporary tables and the data type to be used for the fact. By defaul t, thedata type for a fact is inheri ted from the data type of the column on whichthe fact is defined in the data warehouse.

For information on column al iases, see Fact column names and data types:Column al iases, page 227. The procedure below describes how to create acolumn al ias using Archi tect.

Prerequisi tes

This procedure assumes you have already created a fact wi th a val id factexpression.

To create a column alias for a fact using Architect

In MicroStrategy Developer, log in to the project source that contains thefact to create a new column al ias for.





Right-cl ick the fact and select Edit. The Fact Edi tor opens.



Select the Column Alias tab.

In the Column alias area, cl ick Select. The Column Edi tor - ColumnSelection dialog box opens.

Select New to create a new column al ias. The Column Edi tor - Defini tiondialog box opens.

You can modi fy the fol lowing properties for the column al ias:

Column name: The name for the column al ias. This name is used in anySQL statements which include the fact column.

Data type: The data type for the fact. For a description of the di fferent datatypes supported by MicroStrategy, see Appendix C, Data Types.

Depending on the data type selected, you can speci fy the byte length, bi tlength, precision, scale, or time scale for your column al ias. For a detai leddescription on each of these properties, see the MicroStrategy DeveloperHelp (formerly the MicroStrategy Desktop Help).

Cl ick OK to save your changes and return to the Column Edi tor - ColumnSelection dialog box.

Cl ick OK . You are returned to the Fact Edi tor.

Cl ick OK . You are returned to Archi tect.


Creating and modifying attributes

Business data represented by facts can offer l i ttle insight wi thout thepresence of business concepts and context, which take the form ofattributes in MicroStrategy. Attributes provide the business model wi th acontext in which to report on and analyze facts. Whi le knowing yourcompany's total sales is useful , knowing where and when the sales tookplace provides the kind of analytical depth that users require on a dai ly



basis. For conceptual information on attributes, see Chapter 7, The Contextof Your Business Data: Attributes.

This section describes how to use Archi tect to create and modi fy attributes,which includes:

Creating attributes, page 169


These sections focus on creating attributes and attribute forms. To createand define attribute relationships with the Hierarchy View in Archi tect, seeDefining attribute relationships, page 194.

Creating attributesWith Archi tect you can create attributes as part of your ini tial project designeffort as wel l as throughout the enti re l i fe cycle of a project.

To save the time that i t takes to create al l the attributes required for yourproject, you can al low Archi tect to automatical ly create attributes whentables are added to your project. When tables are added to the projectusing Archi tect, attributes are created based on the automatic columnrecogni tion rules that you define in Archi tect. To enable and define thisautomatic attribute creation, see Defining project creation and displayoptions, page 124.

The procedure below describes how to create an attribute using Archi tect.

Prerequisi tes


To create an attribute using Architect








From the Project Tables View, locate and select a table that includes acolumn or columns to use in an attribute defini tion.

Right-cl ick the table and select Create Attribute. The Create New FormExpression dialog box appears.

Rather than creating attributes by manual ly creating an attributeexpression, you can al low Archi tect to automatical ly create simpleattributes defined on one column. To do this:

Right-cl ick the table, point to Recognize, and then select Attributes. TheResul ts Preview dialog box opens.

If attribute forms are displayed, these attribute forms can be created asdescribed below:

Attribute forms can be created based on these automatic columnrecogni tion rules that you define, as described in Defining project creationand display options, page 124.

Attribute forms can be created by automatical ly mapping columns toattribute forms already defined in your project, as described in Definingproject creation and display options, page 124.



Select the check box for an attribute form to create the attribute form. Ifmore than one attribute form is avai lable for creation for an attribute, youmust select the ID form. Any other attribute forms for that attribute areoptional . For example, to create an attribute description form you mustselect the description form along with the ID form for the attribute.

Cl ick OK . The attribute forms you selected for creation are created withinthe table. If you use this option to create simple attributes, you can thenskip to To define attribute lookup tables, form expressions, and columnal iases , page 172.

Create a form expression for the ID form of the new attribute being created,as described below:

To create a simple attribute form expression (Attribute form expressions,page 275), drag a column from the Avai lable columns pane to the Formexpression pane.

To create a more advanced attribute form expression, use a combination ofany of the fol lowing techniques:

Enter constants in double quotes.

To create a function using the Insert Function Wizard, cl ick f(x) in the Formexpression toolbar.

To insert an operator into the expression, cl ick any operator in the Formexpression toolbar.

Cl ick Validate to ensure that your expression is val id.

Under Mapping method , select Automatic or Manual:

Automatic mapping means that al l of the tables in the project wi th thecolumns used in the attribute form expression are selected as possiblesource tables for the attribute form. You can then clear any tables mappedautomatical ly or select other tables.



Manual mapping means that al l of the tables in the project wi th the columnsused in the attribute form expression are located but are not selected aspossible source tables for the attribute form. You can then select which ofthose tables are used as source tables for the attribute form.

The mapping method defaults to Automatic for the first attribute or attributeform expression you create. The system maps the expression to each of thesource tables. For subsequent attributes, the default is Manual.

An expression that uses only a constant value cannot use the automaticmapping method.

To use an attribute for meaningful analysis, you must verify that it inc ludes acolumn from a fact table in its definition, or is related to an attribute that does.For example, to use the Month attribute for analysis, you must create arelationship to the Day attribute, which must include the DAY column from thefact table in its definition. To create relationships between attributes, seeDefining attribute relationships, page 194 .

Click OK to close the Create New Form Expression dialog box and createthe attribute. The attribute is given a defaul t name and is displayed in thetable.

To change the default name of the attribute, right-c lick the attribute in the tableand select Rename . Type the new name in the dialog box that appears andclick OK to save and return to Architect.

To define attribute lookup tables, form expressions, and column al iases

You can continue to define the attribute by right-cl icking the ID form for theattribute and selecting Edit. The Modi fy Attribute Form dialog box opens.

From the Source tables pane, select a table and cl ick Set as Lookup toset i t as the lookup table for the attribute. A lookup table acts as the maintable which holds the information for an attribute. If you chose manualmapping, select the check boxes of the tables to map to the attribute form.



You can use the tabs of the Modi fy Attribute Form dialog box to defineattribute form expressions and create column al iases as described below:

Definition : This tab al lows you to define attribute form expressions.Attribute forms are discussed in Column data descriptions and identi fiers:Attribute forms, page 270.

Column Alias: This tab al lows you to create a column al ias for the fact.Column al iases are discussed in Modifying attribute data types: Columnal iases, page 286.

For detailed information about the options on each tab within the ModifyAttribute Form dialog box, refer to the MicroStrategy Developer Help(formerly MicroStrategy Desktop Help).

When your changes are complete, cl ick OK to return to Archi tect.


Creating and modifying multiple attributesWith Archi tect, you can create and modi fy mul tiple attributes in your projectquickly from an integrated interface. Archi tect al lows you to create andmodi fy attributes in most of the same ways as the Attribute Edi tor.

For conceptual information on attributes as wel l as detai led examples, seeChapter 7, The Context of Your Business Data: Attributes. Refer to the l istbelow for steps to perform various attribute defini tions using Archi tect:

Modifying attributes with the Properties pane, page 174

Creating attribute form expressions, page 179

Creating and modi fying attribute data types: Column al iases, page 183

Creating attributes with multiple ID columns: Compound attributes, page186

Modi fying how to use attributes to browse and report on data, page 188



Speci fying attribute roles: Attributes that use the same lookup, page 190

Supporting data international ization for attribute elements, page 192

Modifying attributes with the Properties pane

Once attributes are created, you can modi fy and view attribute defini tionsusing the Properties pane in Archi tect. To view the various properties of anattribute in Archi tect, from the Attributes tab of the Properties pane, selectthe attribute from the drop-down l ist. The Category attribute of theMicroStrategy Tutorial project shown below is used as an example of howyou can modi fy and view attributes using Archi tect.



When selecting an attribute in Archi tect, the Properties pane al lows you tomodi fy and view attributes as described below.


Defining and viewing attribute defini tions: Defini tion section, page 175

Modi fying attribute forms: Forms sections, page 177

Defining and viewing attribute definitions: Definition section

When you select an attribute in Archi tect, the Defini tion section of theProperties pane displays the various properties for the attribute. Theseproperties and how to use them are described below:

ID : The identi fier of the attribute. You cannot modi fy this value.

Name: The name of the attribute in a MicroStrategy project.

Description : The description of the attribute. A description can help explainthe purpose of an attribute in a project.

Hidden : Speci fies whether the attribute is defined as hidden. Select thecheck box to set the value to True, which defines the table as hidden.


Location : The location of the attribute in a project.

Lock Type: Speci fies how you can browse attribute elements wi thin theSystem Hierarchy in the Data Explorer. You have the fol lowing options:



Locked : No elements of the attribute are shown within the SystemHierarchy in the Data Explorer. For example, i f the attribute Year is locked,no elements for Year display in the Data Explorer when Year is expandedfrom the System Hierarchy.

Unlocked : Al l elements of the attribute are shown within the SystemHierarchy in the Data Explorer. For example, i f the attribute Year isunlocked, al l elements of Year (such as 2005, 2006, and 2007) display inthe Data Explorer when Year is expanded from the System Hierarchy.

Limit: Incremental ly retrieves the number of elements set for the attribute.For example, i f the l imi t for the attribute Year is set to one, the years 2005,2006, and 2007 are retrieved one-by-one as they are requested.

Lock Limit: If you choose the Limit lock type above, you can define thenumber of elements to incremental ly retrieve and display within the SystemHierarchy in the Data Explorer.

Apply Security Filters: Enables and disables the use of securi ty fi l ters inelement requests. This setting also appl ies to the use of securi ty fi l ters forcreating an element cache.

This setting covers si tuations where only certain attributes need thesecuri ty fi l ters for element requests. For example, i f you have anexternal-facing data warehouse for your suppl iers, securi ty fi l ters can beused on attributes in the product dimension so one suppl ier cannot seeanother suppl ier's products. However, since securi ty is not necessary onattributes in the Time dimension, securi ty fi l ters do not need to beappl ied and the element cache can be shared.

Enable Element Caching : Enables and disables element caching at theattribute level . By caching the elements of an attribute, the elements arereturned quickly from a cache when browsing the attribute elements. This isparticularly helpful for attributes that rarely or never have a modi fication tothe elements avai lable for the attribute. The volati l i ty of the elements wi thindi fferent attributes can fluctuate greatly. For example, the Order Numberattribute may have elements that change once a day (depending on the



warehouse load), whi le the Product Number attribute may only haveelements that change once a week or once a month.

Modifying attribute forms: Forms sections

When you select an attribute in Archi tect, the Forms sections of theProperties pane display information about the attribute forms for theattribute. The properties for attribute forms and how to use them aredescribed below:

Attribute form category: The fi rst property for an attribute form reflects thecategory used for the attribute form. In the example shown above inModifying attributes with the Properties pane, page 174, ID is displayed asthe fi rst property. You can select the attribute form property and cl ick the ...button to modi fy the attribute form.

If the attribute form uses a form group to combine multiple attribute forms, youcan modify the separate attribute forms that are included in the form group. Forinformation on creating form groups in Architect, see Creating attributes withmultiple ID columns: Compound attributes, page 186 .

Name: The name of the attribute form in a MicroStrategy project.

Geographical Role: Defines how the attribute form can be used asgeographical data with various MicroStrategy mapping features. Whenusing Data Import, this type of geographical information can beautomatical ly detected. For detai ls on how Data Import is able to assigngeographical roles to your data, see Strategies to include supplementaldata in a project, page 77.

Shape File: Defines the shapes used to display the attribute form onvarious MicroStrategy mapping features. For detai ls on using shape fi les todefine the display of attribute forms as part of the Image Layout widget,refer to the Dashboards and Widgets Creation Guide.

Category: The category used for the attribute form, which can help group oridenti fy attribute forms. From the drop-down l ist, select the category to use


https://www2.microstrategy.com/producthelp/2020/DashboardsWidgets/WebHelp/Lang_1033/index.htm


for the attribute form. For information on how the category helps groupattribute forms, see Attribute form expressions, page 275.

Format: The format of the attribute form, which controls how the form isdisplayed and how fi l ters are defined. From the drop-down l ist, select theformat to use for the attribute form. For information on the format of attributeforms, see Attribute form expressions, page 275.

Report Sort: Defines the defaul t sort order of the attribute form when i t isincluded in a report. From the drop-down l ist, you can choose fromAscending , Descending , or None. For information on how attribute formsare sorted when multiple attribute forms of a single attribute define a defaul tsort order, see Displaying forms: Attribute form properties, page 272.

Browse Sort: Defines the defaul t sort order of the attribute form when i t isviewed in the Data Explorer. From the drop-down l ist, you can choose fromAscending , Descending , or None. The Data Explorer is discussed inHierarchy browsing, page 402.

Use as Browse Form: Defines whether the attribute form can be displayedin the Data Explorer. To al low an attribute form to be displayed in the DataExplorer, select the check box to set the value to True. The Data Exploreris discussed in Hierarchy browsing, page 402.

Use as Report Form: Defines whether the attribute form is displayed onreports by defaul t. To define an attribute form to be displayed on reports bydefaul t, select the check box to set the value to True.

Supports Multiple Languages: Defines whether the attribute form'sinformation can be displayed in multiple languages using datainternational ization. To define an attribute form to al low data to bedisplayed in multiple languages, select True.

Enabl ing data international ization for an attribute form is described inSupporting data international ization for attribute elements, page 192.



The ID form of an attribute does not have this option as these forms are usedstric tly for identification purposes.

Column Alias: The column al ias of the attribute form, which al lows you todefine a new data type that you can use in place of the defaul t data type fora given attribute form. You can select the Column Al ias property and cl ickthe ... button to modi fy the attribute form's column al ias. For information oncolumn al iases for attribute forms, see Modifying attribute data types:Column al iases, page 286.

Attribute Expressions: The expressions used for the attribute form. Youcan select an attribute expression and cl ick the ... button to modi fy theattribute form expression.

Creating attribute form expressions

An attribute expression represents a mapping to speci fic attributeinformation in the data source. For conceptual information on attribute formsand attribute form expressions, see Column data descriptions andidenti fiers: Attribute forms, page 270 and Attribute form expressions, page275.

Attribute form expressions are commonly created by mapping a column toan attribute form, as described in Creating attributes, page 169. WithArchi tect, you can also create and define attributes as l isted below:

Creating derived attribute form expressions, page 179

Joining dissimi lar column names: Heterogeneous mappings, page 181

Creating derived attribute form expressions

Derived expressions are created using a combination of warehousecolumns, mathematical operators, functions, and constants. Whi le simpleexpressions have their value determined by just one column in awarehouse table, derived expressions are defined using one or morecolumns as wel l as other operators and values. Any operation on a column



(such as adding a constant, adding another column, or setting theexpression to be an absolute value) creates a derived expression.

For information on derived attribute form expressions, see Attribute formexpressions, page 275. The procedure below describes how to create aderived attribute form expression using Archi tect, and fol lows the examplescenario provided in Attribute form expressions, page 275.

To create an attribute form with a derived expression using Architect








For the example scenario, select the LU_CUSTOMER table.

Right-cl ick the Customer attribute and select New Attribute form. TheCreate New Form Expression dialog box opens.

Double-cl ick the CUST_LAST_NAME column to add i t to the Formexpression pane on the right.



In the Form expression pane, place the cursor to the right of [CUST_LAST_NAME] and type + ", " +.

Double-cl ick the CUST_FIRST_NAME column to add i t to the Formexpression pane on the right. Your expression should be defined as shownbelow.

Select Manual as the mapping method.

Cl ick OK to return to Archi tect. The new attribute form is displayed as partof the Customer attribute in the LU_CUSTOMER table.

In the Properties pane, locate the new attribute form.

In the Name field, type Last Name, First Name.

From the Category drop-down l ist, select None since Last Name, FirstName is nei ther the ID form of Customer nor the primary description form.

Because this is only an example, you can close Archi tect wi thout savingyour changes.

Joining dissimilar column names: Heterogeneous mappings

Heterogeneous mapping al lows Intel l igence Server to perform joins ondissimi lar column names. If you define more than one expression for agiven form, heterogeneous mapping automatical ly occurs when tables andcolumn names require i t.

For information on heterogeneous mappings for attributes, see Attributeform expressions, page 275. The procedure below describes how to createan attribute form with a heterogeneous column mapping using Archi tect,



and fol lows the example scenario provided in Attribute form expressions,page 275.

To create an attribute form with a heterogeneous column mapping

using Architect








For the example scenario, select the LU_DAY table.

Right-cl ick the Customer attribute and select New Attribute form. TheCreate New Form Expression dialog box opens.

Double-cl ick the DAY_DATE column to add i t to the Form expression paneon the right.

Select Automatic as the mapping method.



Click OK to return to Archi tect. The new attribute form is displayed as partof the Day attribute in the LU_DAY table.

Right-cl ick the new attribute form and select Edit. The Modi fy AttributeForm dialog box opens.

Cl ick New. The Create New Form Expression dialog box opens.

From the Source table drop-down l ist, select the ORDER_DETAIL table.

Double-cl ick the ORDER_DATE column to add i t to the Form expressionpane on the right.


Cl ick OK . The Create New Attribute Form dialog box opens.

Notice that there are now two expressions for the attribute formdefini tion, both of which use di fferent tables as the source of theirinformation. You can continue this process to add as manyheterogeneous columns as part of one attribute form as necessary.

Cl ick OK to return to Archi tect.


In the Name field, type Date Example.

From the Category drop-down l ist, select None since this is an examplescenario.


Creating and modifying attribute data types: Column aliases

A column al ias is a new data type that you can speci fy in place of thedefaul t data type for a given attribute form. Column al iases al low you tospeci fy a more appropriate data type that can help avoid errors in your SQL.



They can also help you take more advantage of the data in your datawarehouse.

For information on column al iases for attributes, see Modifying attributedata types: Column al iases, page 286. The procedure below describes howto create a column al ias using Archi tect, and fol lows the example scenarioprovided in Modifying attribute data types: Column al iases, page 286.

PrerequisitesThis procedure assumes you have already created an attribute wi th a val idattribute expression for which to create a new column al ias.

To create a column alias for an attribute using Architect









From the Project Tables View, locate and select a table that includes anattribute to create a column al ias for.

Right-cl ick the attribute form to create a column al ias for, and select Edit.The Modi fy Attribute Form dialog box opens.


In the Column alias area, cl ick Select. The Column Edi tor - ColumnSelection dialog box opens.



Column name: The name for the column al ias. This name is used in anySQL statements which include the fact column.


Depending on the data type selected, you can speci fy the byte length, bi tlength, precision, scale, or time scale for your column al ias. For a detai leddescription on each of these properties, see the MicroStrategy DeveloperHelp (formerly MicroStrategy Desktop Help).


Cl ick OK to save your changes and return to the Modi fy Attribute Formdialog box.





Creating attributes with multiple ID columns: Compound attributes

A compound attribute is an attribute wi th multiple columns speci fied as theID column. This impl ies that more than one ID column is needed to uniquelyidenti fy the elements of that attribute. General ly, you bui ld a compoundattribute when your logical data model reflects that a compound keyrelationship is present. In the relational database, a compound key is aprimary key that consists of more than one database column.

For information on compound attributes, see Attributes with multiple IDcolumns: Compound attributes, page 315. The procedure below describeshow to create a compound attribute using Archi tect, and fol lows theexample scenario provided in Example: Creating compound attributes, page316.

To create a compound attribute using Architect







From the Project Tables View, locate and select a table that includes thecolumns to use for a compound attribute.



For the example scenario, select the LU_DIST_CTR table.

Right-cl ick the table and select Create Attribute. The Create New FormExpression dialog box opens.

Double-cl ick the COUNTRY_ID column to add i t to the Form expressionpane on the right.

Select Automatic mapping method.

Cl ick OK to return to Archi tect. The new attribute is displayed in the LU_

DIST_CTR table.

To rename the attribute, right-c lick the attribute and select Rename .


In the Name field, type ID 1.

Right-cl ick the attribute and cl ick New Attribute form to create the otherattribute ID form. The Create New Form Expression dialog box opens.

Double-cl ick the DIST_CTR_ID column to add i t to the Form expressionpane on the right.

Select Automatic mapping method.

Cl ick OK to return to Archi tect. The new attribute form is displayed in theLU_DIST_CTR table.

You can change the default name of the fact by right-c lick ing it in the table andselecting Rename .


In the Name field, type ID 2.

In the Category drop-down l ist, select ID . A message about creating a formgroup is displayed.



You can also create a form group by dragging and dropping one attribute formonto another attribute form for the same attribute.

Click Yes to create a form group. The two attribute forms are included in aform group.

For more information on using form groups to create compound attributes, seeAttributes with multiple ID columns: Compound attributes, page 315 .

In the fi rst Name field for the attribute form, type ID .


Modifying how to use attributes to browse and report on data

Once attributes are bui l t, they are used in two primary ways—browsing andreporting. Users browse through attributes to locate an attribute to use on areport, and users place an attribute on a report to display detai ls about theparticular attribute and how it relates to fact data. Each attribute can bedisplayed in a variety of forms so you must speci fy the defaul t display ofeach of the attributes in the project. You can do this on a report-by-reportbasis, but you sti l l must speci fy the global , or project-wide, defaul t for eachattribute.

For information on modi fying the attribute forms used for reporting andbrowsing, see Using attributes to browse and report on data, page 318. Theprocedure below describes how to define attribute form display usingArchi tect. The steps below fol low the example scenario provided inDefining how attribute forms are displayed by defaul t, page 320.

To display an attribute form in reports and in the Data Explorer using

Architect









From the Project Tables View, locate and select a table that includes theattribute to define how its attribute forms are displayed by defaul t.

For the example scenario, select the LU_DIST_CTR table, whichincludes the attribute Distribution Center.

Select an attribute.

For the example scenario, select the Distribution Center attribute.

In the Properties pane, locate the attribute form.

For the example scenario, locate the ID 2 attribute form.

You can define the fol lowing display options:

Report Sort: Defines the defaul t sort order of the attribute form when i t isincluded in a report. From the drop-down l ist, you can choose fromAscending , Descending , or None. For information on how attribute formsare sorted when multiple attribute forms of a single attribute define a defaul tsort order, see Displaying forms: Attribute form properties, page 272.

Browse Sort: Defines the defaul t sort order of the attribute form when i t isviewed in the Data Explorer. From the drop-down l ist, you can choose from



Ascending , Descending , or None. The Data Explorer is discussed inHierarchy browsing, page 402.

Use as Browse Form: Defines whether the attribute form can be displayedin the Data Explorer. To al low an attribute form to be displayed in the DataExplorer, select the check box to set the value to True. The Data Exploreris discussed in Hierarchy browsing, page 402.

Use as Report Form: Defines whether the attribute form is displayed on reports bydefault. To define an attribute form to be displayed on reports by default, select the checkbox to set the value to True.

You can also define the defaul t sort order for attributes on reports and theData Explorer. For information on attribute form sorting options, seeDisplaying forms: Attribute form properties, page 272.


Specifying attribute roles: Attributes that use the same lookup

Attribute roles al low you to use the same data to define and support twoseparate attributes. If you identi fy that one of your attributes needs to playmultiple roles, you must create an attribute in the logical model for each ofthe roles. This ensures that a report wi th attributes playing multiple rolesreturns correct data.

For information on attribute roles, see Attributes that use the same lookuptable: Attribute roles, page 307. The procedure below describes how tospeci fy attribute roles using expl ici t table al iasing. The steps below fol lowthe example scenario provided in Speci fying attribute roles, page 309.

You can also define attribute roles using automatic role recognition, whichutilizes MicroStrategy VLDB properties and is described in Speci fyingattribute roles, page 309 .



To create attribute roles with explicit table aliasing using Architect

This procedure provides steps to re-create the example of expl ici t tableal iasing described in Speci fying attribute roles, page 309. The LU_STATE

table is not included in the MicroStrategy Tutorial project. However, youcan use the same high-level procedure and concepts as guidel ines tocreate attribute roles in your project setup.

In MicroStrategy Developer, log in to the project to create attribute roleswith expl ici t table al iasing.





From the Project Tables View, locate and select the LU_STATE table thatincludes the attribute to define attribute roles for.

Right-cl ick the LU_STATE table and select Create Table Alias. An LU_STATE(1) table is created.

Right-cl ick LU_STATE(1), select Rename, and type LU_STATE_STORE .


Right-cl ick LU_STATE(1), select Rename, and type LU_STATE_VENDOR .



Create the attributes

Right-cl ick the LU_STATE_STORE table and select Create Attribute. TheCreate New Form Expression dialog box opens.

In the Available columns pane, double-cl ick STATE_ID , which identi fiesthe attribute role.

Select Manual mapping and cl ick OK . You are returned to Archi tect and thenew attribute is created in the LU_STATE_STORE table.

Right-cl ick the new attribute, select Rename, and type State Store.

Right-cl ick the State Store attribute table and select New Attribute form.The Create New Form Expression dialog box opens.

Map any other columns to attribute forms for the State Store attribute. Youmust make sure to map any State Store attribute forms to columns from theLU_STATE_STORE table.

Cl ick OK and save the State Store attribute.

Create a Vendor State attribute wi th the same sub-procedure (Create theattributes, page 192) used to create State Store above, except you must usethe LU_STATE_VENDOR table instead of the LU_STATE_STORE table.

Supporting data internationalization for attribute elements

MicroStrategy supports the international ization of your data into thelanguages required for your users. This al lows attribute element data to bedisplayed in various languages that reflect the user's language preferences.

For information on enabl ing data international ization for attribute elementsand an example of i ts benefi ts, see Supporting data international ization forattribute elements, page 267. The procedure below describes how toenable data international ization for attribute elements using Archi tect.



Prerequisi tes

The international ized data must be stored in your data source, as describedin Supporting data international ization, page 64.

The project must enable data international ization, as described in Enabl ingdata international ization for a project, page 106.

An attribute has been created.

To enable or disable data internationalization for attribute forms using

Architect

In Developer, log in to a project.





From the Project Tables View, locate an attribute.

From the Properties pane, locate an attribute form.

Select the Support multiple languages check box to set the value to True,which enables data international ization for the attribute form. You can clearthe check box and set i t to False, which disables international ization for theattribute form.




From the Home tab, in the Save area, cl ick Save and Close to save yourchanges and close Archi tect.

Defining attribute relationships

After you have created attributes for your project, you can define attributerelationships to determine how the engine generates SQL, how tables andcolumns are joined and used, and which tables are related to other tables.

You l ink directly related attributes to each other by defining parent-chi ldrelationships. Attribute elements, or the actual data values for an attribute,dictate the relationships that you define between attributes.

The parent-child relationships that you create determine the system hierarchywithin the project.

The four types of di rect relationships that can exist between attributesinclude one-to-one, one-to-many, many-to-one, and many-to-many. Forinformation on these direct relationships and steps to define them with theAttribute Edi tor, see Attribute relationships, page 290.

You can also use Archi tect to define relationships between attributes.Archi tect can provide a more intui tive and helpful workflow that al lows youto view and modi fy mul tiple attributes as you define attribute relationships.

For example, in the MicroStrategy Tutorial project, the Time hierarchyincludes relationships between the attributes Year, Quarter, Month of Year,Month, and Day. With Archi tect, rather than defining parent and chi ldrelationships for one attribute at a time, you can define the relationshipsbetween these attributes at the same time in a visual environment.

The steps below show you how to manual ly define parent and chi ldrelationships between attributes, and also provides an example scenario of



creating the relationships between the attributes Year, Quarter, Month ofYear, Month, and Day in the MicroStrategy Tutorial project.

You can also al low Archi tect to automatical ly define attribute relationshipsbased on the design of your data, as described in Automatical ly definingattribute relationships, page 199.

Prerequisite

Attributes have been created for your project.

To define attribute relationships







From the Hierarchy View, on the Home tab, in the drop-down l ist on theHierarchy area of the toolbar, select System Hierarchy View. The systemhierarchy is displayed.

Prior to defining any relationships, you should gather the attributes that youwant to relate to each other in the same area within the Hierarchy View of



Archi tect. For example, the attributes Year, Quarter, Month of Year, Month,and Day in the MicroStrategy Tutorial project are gathered close together inthe Hierarchy View, as shown below.

To create an attribute relationship

Select an attribute that is to be a parent attribute in an attributerelationship. Drag from the middle of the attribute to an attribute that is tobe a chi ld of the parent attribute selected. A one-to-many relationship l ineis created between the two attributes.

For example, in the image below a relationship is created between theYear and Quarter attributes in which Year is a parent attribute ofQuarter.



In the example above, the Year attribute is the parent attribute ofQuarter.

Attribute relationships created in this way are created as one-to-manyrelationships by defaul t. To modi fy the relationship type, right-cl ick therelationship l ine and select from one of the relationship types l isted below:

One-to-one

One-to-many

Many-to-one

Many-to-many

For information on these relationship types, see Attribute relationships,page 290.

A table in which both attributes exist is chosen as the table to support theattribute relationship. To modi fy the relationship table, right-cl ick therelationship l ine, point to Relationship table, and select a table.

To define attribute relationships with other techniques

If you are finished defining attribute relationships, you can save yourchanges and close Archi tect. The rest of this procedure describes how todefine attribute relationships with other techniques and completes theexample scenario.



Right-cl ick the Quarter attribute, and select Edit Children Relations. TheChi ldren Relations dialog box opens and l ists attributes that can be relatedto the Quarter attribute.

For the Month attribute, in the Relationship type drop-down l ist, selectOne-to-many. You can select any of the avai lable relationship types fromthe Relationship type drop-down l ist to create the required relationship.

For the Month attribute, in the Relationship table drop-down l ist, keep thedefaul t of LU_MONTH .

Keep the Relationship type drop-down l ist at None for the other attributesl isted. Quarter is not di rectly related to any of these attributes.

Cl ick OK to close the Chi ldren Relations dialog box and create the attributerelationship between Quarter and Month.

Drag from the middle of the Month of Year attribute to the Month attribute. Aone-to-many relationship l ine is drawn between the two attributes.

Drag from the middle of the Month attribute to the Day attribute. A one-to-many relationship l ine is drawn between the two attributes.

This completes the defini tion of the required attribute relationships, asshown below.



Automatically defining attribute relationshipsIn addi tion to manual ly defining attribute relationships (see Definingattribute relationships, page 194) you can also al low Archi tect toautomatical ly define attribute relationships based on the design of yourdata in your data source.

The steps below show you how to automatical ly define attributerelationships based on the design of your data in your data source.

Prerequisi te

You have created attributes for your project (see Creating and modi fyingattributes, page 168).

To automatically define attribute relationships








From the Hierarchy View, on the Home tab, in the drop-down l ist on theHierarchy area of the toolbar, select System Hierarchy View. The systemhierarchy is displayed.

Right-cl ick wi thin the area that displays the attributes for your project, andselect Recognize Relationships. The System Hierarchy dialog box opens.

You can select from the fol lowing options to automatical ly define attributerelationships:

Based on Primary Keys/Foreign Keys: Creates attribute relationshipsbased on the primary keys and foreign keys defined on your tables. Eachattribute that acts as a foreign key of a table is defined as a parent attributeof each attribute that acts as a primary key of the same table. The attributerelationship is defined as a one-to-many relationship from the foreign keyattribute (parent attribute) to the primary key attribute (chi ld attribute).

Based on lookup tables: Creates attribute relationships based on lookuptables that do not include primary key or foreign key information. To definea table as a lookup table for an attribute, see Creating attributes, page 169.Each attribute that defines a table as i ts lookup table is defined as a chi ldattribute of al l other attributes in the same table, that do not define the tableas i ts lookup table. Each attribute relationship is defined as a one-to-manyrelationship from the parent attribute to the chi ld attribute.



Based on sample data from the table: Creates attribute relationships forattributes that share the same lookup table. To define a table as a lookuptable for an attribute, see Creating attributes, page 169.

Archi tect analyzes sample data for the table. The attributes with fewerdistinct values are defined as parents of the attributes with more distinctvalues, using a one-to-many relationship from the parent attribute to thechi ld attribute. For example, a lookup table includes four rows of data,which include data related to year and quarter. Each row includes the sameyear (for example, 2009), but the quarter changes for each row (Q1, Q2, Q3,Q4). In this case, the Year attribute is created as a parent of the Quarterattribute.

Once you have selected the appropriate options, cl ick OK .

If you selected the Show preview resul ts check box to preview the resul ts ofautomatical ly defining attribute relationships (see Defining project creationand display options, page 124) the Resul ts Preview dialog box isdisplayed. From this dialog box, you can select which attributerelationships should be created and which attribute relationships should beexcluded. After you have made al l your selections, cl ick OK to al lowArchi tect to automatical ly define attribute relationships.

If you cleared the Show preview resul ts check box (see Defining projectcreation and display options, page 124) Archi tect automatical ly creates al lpotential attribute relationships without fi rst displaying them in the Resul tsPreview dialog box.

After al l relationships are determined by the rules that you selected,Archi tect performs final analysis on the attribute relationships that are tobe created. Any attribute relationships that are found to be redundantare not created. This ensures that attribute relationships are created thatproperly reflect the design of the data in your data source. Forinformation on modi fying the attribute relationships that are created, seeDefining attribute relationships, page 194.



Creating and modifying user hierarchies

User hierarchies provide flexibi l i ty in element browsing and report dri l l ing.They are groups of attributes and their relationships to each other, arrangedin ways that make sense to a business organization. As the structure ofyour business intel l igence system evolves, you can modi fy the design of auser hierarchy to include addi tional attributes or to l imi t user access tocertain attributes.

For conceptual information on user hierarchies, see Chapter 9, CreatingHierarchies to Organize and Browse Attributes.

This section describes how to use Archi tect to create and modi fy userhierarchies.

Creating user hierarchiesWith Archi tect you can create hierarchies as part of your ini tial projectdesign effort as wel l as throughout the enti re l i fe cycle of a project.

This section discusses creating user hierarchies to support browsing anddrilling on an attribute. The system hierarchy is created according to therelationships defined between the attributes in your project. It is automaticallycreated based on the attribute relationships you define, as described inDefining attribute relationships, page 194 .

The fol lowing procedure describes how to create a user hierarchy usingArchi tect.

Prerequisi tes




To create a user hierarchy using Architect






From the Hierarchy View, select an attribute to include in the hierarchy,and then cl ick the New Hierarchy toolbar option. A dialog box to name thehierarchy opens.

In the Please enter the hierarchy name field, type a name for the hierarchyand cl ick OK . You are returned to Hierarchy View with the attribute youselected included in the hierarchy.

To add addi tional attributes to the hierarchy, right-cl ick wi thin theHierarchy View and select Add/Remove Attributes to Hierarchy. TheSelect Objects dialog box opens.

In the Available objects pane, select the attributes to use in the hierarchyand cl ick the arrow to add them to the Selected objects pane.

Cl ick OK to close the Select Attributes dialog box and return to Archi tect.The attributes you selected appear in Hierarchy View.



To create a browsing or dri l l ing relationship, locate an attribute that is to beable to browse to and/or dri l l to another attribute. Drag from the middle ofthe attribute to another attribute. A browsing and/or dri l l ing relationship iscreated between the two attributes.

To use the hierarchy as a dri l l hierarchy, right-cl ick wi thin the HierarchyView and select Use As a drill hierarchy. If you clear this check box, thehierarchy is only used for browsing.

A dri l l hierarchy can be used for browsing as wel l as dri l l ing. Dri l lhierarchies are discussed in Hierarchy browsing, page 402.

Each attribute in a user hierarchy has properties that affect how thatattribute is displayed and accessed in a hierarchy. You can right-cl ick anattribute and configure the properties l isted below:

Define Browse Attributes: Defines the attributes to which users canbrowse to and/or dri l l to from the selected attribute. These relationships canalso be defined by dragging and dropping from one attribute to another asis described earl ier in this procedure.

Define Attribute Filters: Speci fies whether the data retrieved anddisplayed when browsing the hierarchy should be complete or fi l tered byany speci fic cri teria. Only data satisfying the fi l ter cri teria is displayed whenbrowsing the hierarchy (see Fi l tering attributes in a hierarchy, page 398).

Set As Entry Point: Speci fies whether the user can begin browsing in thishierarchy using this attribute (see Entry point, page 400).

Element Display: Determines the elements a user can see. The elementdisplay may be Locked , Unlocked , or Limited (see Control l ing the displayof attribute elements, page 394).

From the Home tab, cl ick Save and Close to save your changes and closeArchi tect.

You can save user hierarchies in any folder. However, to make the userhierarchy avai lable for element browsing in the Data Explorer, you must



place i t in the Data Explorer sub-folder wi thin the Hierarchies folder. This isdiscussed in Hierarchy browsing, page 402.

From the Schema menu, select Update Schema.



THE BUILDING BLOCKSOF BUSINESS DATA:FACTS



Facts are one of the essential elements wi thin the business data model .They relate numeric data values from the data warehouse to theMicroStrategy reporting environment. Facts general ly represent the answersto the business questions on which users want to report.

In the MicroStrategy environment, facts are schema objects created by andshared between MicroStrategy users. The facts you create in MicroStrategyal low users to access data stored in the data warehouse. Facts form thebasis for metrics, which are used in the majori ty of analyses and reportsthat users can create with MicroStrategy.

Facts and attributes are necessary to define projects. In a MicroStrategyproject, facts are numeric data and attributes are contextual data for thefacts. For example, you want to analyze the amount of sales at a certainstore during January. In this case, the amount of sales represents the fact,and the store and month represent attributes. As the project designer, youmust create projects that contain facts and attributes. Users can then usethese facts and attributes as bui lding blocks for metrics and reports.



Facts are stored in the data warehouse in fact tables. These fact tables arecomposed of di fferent columns. Each cel l in the columns represents aspeci fic piece of information. When fact information is requested for a reportin MicroStrategy, that column is accessed to retrieve the necessary data.This data is used to create a metric (such as profi t) which is a businessmeasure.

Facts are based on physical columns within tables in the data warehouse,as shown below.

Like other schema objects such as attributes, facts are logicalMicroStrategy objects that correspond to physical columns and tables.Unl ike attributes, facts do not describe data. Facts are the actual datavalues stored at a speci fic fact level . A fact entry level is the lowest set ofattributes at which a fact is stored.

Whi le creating facts is a major step in the ini tial creation of a project, i t canoften be necessary to modi fy and create facts throughout the l i fe cycle of aproject. The procedures to perform these tasks are discussed in the fi rstsection (Creating facts, page 208) of this chapter. The later sectionsdiscuss conceptual information on facts, as wel l as highl ight someadvanced fact design techniques and procedures.

Creating facts

A fact has two common characteristics: i t is numeric and i t is aggregatable.Examples of facts include sales dol lars, uni ts sold, profi t, and cost.



Data warehouses contain di fferent types of facts depending on the purposeof the data. For example, facts such as Tenure and Compensation Costcould exist in a data warehouse that contains human resources data. Factssuch as Quanti ty and Item Cost could exist in a warehouse containing salesand distribution data.

It is important to understand how to define facts because facts are the basisfor almost al l metrics. Facts also al low you to create advanced metricscontaining data that is not stored in the warehouse but can be derived byextending facts.

This section provides steps to create facts at di fferent phases of the projectdesign process, using di fferent techniques and MicroStrategy interfaces:

Simul taneously creating multiple, simple facts, page 209 covers steps tocreate multiple, simple facts as part of the ini tial project design effort orlater in a project's l i fe cycle wi th the Fact Creation Wizard.

You can also create multiple simple or advanced facts as part of theini tial project design effort using Archi tect, as described in Creating andmodi fying simple and advanced facts, page 212.

Creating and modi fying simple and advanced facts, page 212 covers stepsto add and modi fy both simple and advanced facts for an existing project.

Simultaneously creating multiple, simple factsDuring your ini tial project design effort, you can create multiple simple factsusing the Project Creation Assistant, the Fact Creation Wizard, andArchi tect. However, fact creation and modi fication can be done throughoutthe enti re l i fe cycle of a project. Facts can be created and modi fied usingvarious techniques, uti l izing the fol lowing MicroStrategy tools:

The Fact Creation Wizard is a step-by-step interface that is typical ly usedwhen you fi rst create a project. It al lows you to create multiple facts in asingle creation process.



The Project Creation Assistant utilizes the Fact Creation Wizard to help youcreate the facts for your initial project creation effort. You can also access theFact Creation Wizard in MicroStrategy Developer from the Schema menu.

The Fact Edi tor, which is discussed in Creating and modi fying simple andadvanced facts, page 212, is used to add advanced features to facts thatal ready exist or to create new simple or advanced facts as your projectevolves.

Archi tect, which is discussed in Creating and modi fying simple andadvanced facts, page 212, is used to create and modi fy simple andadvanced facts in a visual ly integrated environment.

To create facts with the Fact Creation Wizard

This procedure is part of an ini tial project creation effort using the ProjectCreation Assistant, which launches the Fact Creation Wizard to completethe fact creation tasks. For steps to access the Project Creation Wizard, seeCreating a new project using the Project Creation Assistant, page 98. Youcan also access the Fact Creation Wizard in MicroStrategy Developer fromthe Schema menu.

In the Project Creation Assistant, select Create facts. The Fact CreationWizard opens, as shown below:



Click Define Rules to set some basic fact creation rules. The Fact CreationRules page opens.

Rules help automate and govern the fact creation process. If the namingconventions in your warehouse do not conform to the defaul ts in the FactCreation Rules page, you may need to change these rules.

The Column data type area al lows you to select the column data types thatare avai lable as possible fact ID columns. Select the check boxes for thedata types to be included when the wizard searches the data warehouse foravai lable fact columns.

For example, i f you select Character and Numeric and leave theremaining check boxes cleared, only columns whose data types arenumeric or character-based are displayed in the Fact Creation Wizard aspossible columns to use for your facts.

Unlike most attributes which can access multiple columns of descriptioninformation, a fact does not have description information. Therefore, you canonly select data types for the ID columns of your facts.

The Fact name area al lows you to determine how to create defaul t factnames, that is, whether to replace underscores in the fact name with spacesand whether the fi rst letter is capi tal ized. Select the appropriate checkboxes to create the desired defaul t fact names.

Cl ick OK to accept your rule changes and return to the Fact CreationWizard.

Fact column select ion

Click Next. The Column Selection page opens, wi th columns that are notcurrently being used in the project l isted in the Avai lable columns pane.

From the Avai lable columns pane, select the fact columns to use for yourfacts and cl ick > to add them to your project. Cl ick >> to add al l the l istedcolumns.



Note the following:

You can rename any fact to make its name more user-friendly by right-c lick ing the fact and selecting Rename .

The Fact Creation Wizard cannot handle columns that hold the sameinformation but have different column names (that is, heterogeneouscolumns). For more information about mapping facts to heterogeneouscolumns, see Mapping physical columns to facts: Fact expressions,page 220 .

To remove fact columns from your project, select them from the Facts paneand cl ick < to move them to the left side. Cl ick << to remove al l the columnsin your project.

Cl ick Next. The Finish page opens.

Review the summary information in the Finish page and cl ick Finish tocreate the facts.

The selected fact defini tions are stored in the metadata. To continuecreating a project wi th the Project Creation Assistant, see Simul taneouslycreating multiple attributes, page 252.

Creating and modifying simple and advanced factsAfter you have created a project, you can use ei ther the Fact CreationWizard, the Fact Edi tor, or Archi tect to create and modi fy facts in yourproject:

With Archi tect you can:

Create simple facts

Create multiple facts quickly

Add a large number of facts during project creation

Create simple and advanced facts

Edi t existing facts and configure addi tional schema-level settings



With Archi tect, you can support al l of the simple and advanced factfeatures that are avai lable in the Fact Edi tor. Rather than focusing onone fact at a time with the Fact Edi tor, you can use Archi tect to createand modi fy mul tiple facts for a project at one time. For information onhow to use Archi tect, see Creating and modi fying simple and advancedfacts using Archi tect, page 217.

With the Fact Creation Wizard you can:

Create simple facts

Create multiple facts quickly

Add a large number of facts during project creation

The Fact Creation Wizard can create multiple facts quickly and easi ly.However, i t l imi ts you to creating simple facts and does not al low you toedi t existing facts. Typical ly, you only use the Fact Creation Wizard aspart of the ini tial project creation, for creating most of the facts for theproject. For steps to use the Fact Creation Wizard, see Creating one ormore simple facts wi th the Fact Creation Wizard, page 214.

With the Fact Edi tor you can:

Create simple and advanced facts

Edi t existing facts and configure addi tional schema-level settings

You can use the Fact Edi tor to edi t existing facts and create factexpressions, column al iases, level extensions; map multiple orheterogeneous columns; and configure other settings. The Fact Edi toral lows you to modi fy one fact at a time, which can be helpful when onlya few facts in a project need to be modi fied. For steps to use the FactEdi tor, see Creating simple and advanced facts wi th the Fact Edi tor,page 214 and Modifying simple and advanced facts wi th the Fact Edi tor,page 217.



Creating one or more simple facts with the Fact Creation Wizard

Although the Fact Creation Wizard is primari ly used to create most of aproject's facts during ini tial project creation, you can use i t at any time tocreate one or more simple facts at the same time.

To create facts with the Fact Creation Wizard

In MicroStrategy Developer, log in to the project source that contains yourproject and expand your project.

You must use a login that has Architect priv ileges. For more information aboutpriv ileges, see the List of Privi leges chapter in the System AdministrationGuide .

From the Folder List in MicroStrategy Developer, select the project to whichto add addi tional facts.

From the Schema menu, select Fact Creation Wizard . The Fact CreationWizard opens.

To use the Fact Creation Wizard to add facts, fol low the proceduresoutl ined in Simul taneously creating multiple, simple facts, page 209.

Creating simple and advanced facts with the Fact Editor

As your project evolves, you can create addi tional facts and modi fy existingfacts wi th the Fact Edi tor. You can also use the Fact Edi tor to addextensions to those facts and configure addi tional settings within them tosupport various analytical requirements.

The fol lowing procedure describes how to use the Fact Edi tor to create asimple fact based on a single fact column in a table.





To create a simple fact with the Fact Editor


You must use a login that has Architect priv ileges. For more information aboutpriv ileges, see the List of Privi leges chapter in the System AdministrationGuide .

From the Folder List in MicroStrategy Developer, select the project to whichto add addi tional facts.

From the File menu, select New, and then Fact. The Fact Edi tor opens, wi ththe Create New Fact Expression dialog box displayed on top of i t.

From the Source table drop-down l ist, select the source table for the fact.

The source table is the table or logical v iew that contains the fact column onwhich you want to base a new fact.

From the Available columns pane, drag and drop a column into the Factexpression pane.

You can include multiple columns as wel l as use numeric constants andmathematical operators and functions to create a fact expression. Forinformation on creating various types of fact expressions, see Mappingphysical columns to facts: Fact expressions, page 220.

In the Mapping area, select Automatic or Manual:

Automatic mapping means that al l of the tables in the project wi th thecolumns used in the fact expression are selected as possible source tablesfor the fact. You can then remove any tables mapped automatical ly or selectother tables.

Manual mapping means that al l of the tables in the project wi th the columnsused in the fact expression are located but are not selected as possible





source tables for the fact. You can then select which of those tables areused as source tables for the fact. Other scenarios in which you should usethe manual mapping method include:

If you are creating a constant expression that is not based on a physicalcolumn in a project table, you must select the tables for which you wantyour constant expression to apply.

If the same column name does not contain the same data across di fferenttables, manual ly select the appropriate source tables for each fact.

For example, suppose you have a column named Sales , which exists inboth the Fact_Sales table and the Fact_Discount table. In the Fact_

Sales table, the Sales column contains revenue data. However, in theFact_Discount table, the Sales column contains discount data. In otherwords, al though the column name is the same in both tables (Sales ), thecolumns contain di fferent fact data in each table. When creating theRevenue fact, you must select the Manual mapping method so you canselect the Fact_Sales table as a source table for the Revenue fact. Whencreating the Discount fact, you must select the Manual mapping method soyou can select the Fact_Discount table as a source table for theDiscount fact. If you use the Automatic mapping method in both cases, theMicroStrategy SQL Engine may use the incorrect column for the facts.

Cl ick OK to close the Create New Fact Expression dialog box.

Use the tabs of the Fact Edi tor to define fact expressions, create columnal iases, and create extensions, as described below.

For detailed information about the options on each tab within the Fact Editor,refer to the MicroStrategy Developer Help (formerly MicroStrategyDesktop Help).

Definition : This tab al lows you to define fact expressions. Fact defini tionsare discussed in How facts are defined , page 219.



Column Alias: This tab al lows you to create a column al ias for the fact.Column al iases are discussed in Fact column names and data types:Column al iases, page 227.

Extensions: This tab al lows you to create fact level extensions. Factextensions are discussed in Modifying the levels at which facts arereported: Level extensions, page 229.

When your changes are complete, cl ick Save and Close.

In the Save As dialog box, navigate to the location in which to save the fact.Enter a name for the fact and cl ick Save. The fact is saved and the FactEdi tor closes.

From the Schema menu, select Update Schema to update the projectschema.

Modifying simple and advanced facts with the Fact Editor

To modify an existing fact with the Fact Editor

In MicroStrategy Developer, open the folder that contains the fact to modi fy.

Double-cl ick the fact to open the Fact Edi tor and edi t the fact.

You can learn how to create more advanced facts in the various sectionsbelow.

Creating and modifying simple and advanced facts using Architect

Archi tect can be used to create and modi fy simple and advanced facts in avisual ly integrated environment. Archi tect al lows you to view the tables,attributes, attribute relationships, facts, user hierarchies, and other projectobjects together as you design your project.

With Archi tect, you can support al l of the simple and advanced fact featuresthat are avai lable in the Fact Edi tor. Rather than focusing on one fact at a



time with the Fact Edi tor, you can use Archi tect to create and modi fymul tiple facts for a project at one time. Review the chapters and sectionsl isted below for information on Archi tect and steps to create and modi fyfacts using Archi tect:

Chapter 5, Creating a Project Using Archi tect



The structure of facts

As shown in the diagram below, facts are made up of the fol lowingcomponents:

The fact definition is composed of one or more fact expressions. Every factmust have at least one expression. Fact defini tions are discussed in detai lin How facts are defined , page 219.

The column alias stores the column name MicroStrategy uses to generateSQL statements when creating temporary tables related to the fact. Everyfact must have a column al ias. MicroStrategy selects a defaul t column al ias



depending on the type of fact, unless you create a new column al ias.Column al iases are discussed in detai l in Fact column names and datatypes: Column al iases, page 227.

Fact level extensions al low facts stored in the data warehouse at one levelto be reported at an unrelated level . Extensions can also prevent a fact frombeing reported at a certain level , even though i t is stored at that level . Levelextensions are very effective for advanced data model ing scenarios. Levelextensions are discussed in detai l in Modifying the levels at which facts arereported: Level extensions, page 229.

You create facts in MicroStrategy Developer using the Fact Creation Wizardand the Fact Edi tor. During project creation with the Fact Creation Wizard,when you select the numeric column used to represent the fact, both thefact defini tion and column al ias are automatical ly defined. Level extensionsare optional .

For a discussion of the tools used to created facts and procedures on howto use them, see Creating facts, page 208.

How facts are defined

A fact defini tion contains properties that define a fact and i ts components.The fact defini tion is composed of at least one fact expression and basicinformation about the fact, including the fact name, expression, and thesource tables i t uses.

The fol lowing table provides an example of a fact defini tion, which includesthe fact's name, expression, and source tables.

FactName

Expression Source Tables

UnitPrice

All_Sales

LU_ITEM

ORDER_DETAIL



In the example, the fact expression maps the fact to the All_Sales

columns in the LU_ITEM and ORDER_DETAIL tables in the warehouse. Thefact expression contained in the defini tion represents how the fact iscalculated by MicroStrategy. In this case, the fact expression is simply thename of the column which holds the fact data. However, some facts usemore advanced expressions to perform calculations on multiple columns ofdata to return a single fact.

Facts can be found in multiple tables in a warehouse schema, and oftenmust be calculated di fferently from one table to the next. Whi le the Uni tPrice fact only has one expression, mul tiple expressions can exist wi thin afact defini tion.

Each fact expression relates to one or more related tables that contain thefact.

For each of the tables, fact expressions define how the fact is calculated.

Mapping physical columns to facts: Fact expressionsA fact expression maps facts to physical columns in the warehouse. Theseexpressions can be as simple as a fact column name from the warehouse oras sophisticated as a formula containing multiple fact column names andnumeric constants. Regardless of how it is defined, a fact expressionrepresents a mapping to speci fic fact information in the warehouse. A factdefini tion must have one or more fact expressions.

The fol lowing image i l lustrates a column in the fact table and theassociated fact expressions:



Val id fact expressions are formulas constructed from fact columns with orwi thout numeric constants or mathematical operators. The mathematicaloperators that can be used in a fact expression are:

Addi tion (+)

Subtraction (-)

Mul tipl ication (*)

Division (/)

You can use the Fact Edi tor to create fact expressions. These steps arecovered in Creating and modi fying simple and advanced facts, page 212.

A fact can be defined using an ApplySimple function. Apply functions arediscussed in the Pass-Through Expressions appendix in the AdvancedReporting Guide .

Most facts represent physical columns in the data warehouse. However,some facts do not exist at al l in the warehouse and are defined in otherways, as explained in the fol lowing sections.

Implicit facts and implicit fact expressions

Impl ici t facts are virtual or constant facts that do not physical ly exist in thedatabase. An impl ici t fact indicates a fact table from which to retrieve data.The impl ici t fact can have i ts expression defined as a constant value,al though nothing is saved in a table column.

For example, you can use impl ici t fact expressions to create "temporarycolumns" in the database with a value of "1" for every row. These temporarycolumns al low you to keep track of how many rows are returned for acertain attribute. You may also find i t helpful to use impl ici t facts whenbui lding metrics, where you can sum the column holding the constant tocreate a COUNT. For example, i f you want to bui ld a metric defined as Sum(1), you can define a fact equal to the constant "1." For detai led informationabout metrics, see the Advanced Reporting Guide.






Derived facts and derived fact expressions

A derived fact has i ts value determined by an expression that contains morethan just a column in a table. Any operation on a column such as adding aconstant, adding another column's values, or setting the expression to bean absolute value, creates a derived fact. In other words, you are creating afact from information that is avai lable in the data warehouse. For example,a table in your data warehouse contains the fol lowing elements:

You can create a new fact, Sales, by creating the fol lowing derived fact:

Sales = Quantity_Sold * Price

One advantage of creating a derived fact is that a derived fact al lows oneconsistent fact to exist in the project in l ieu of having to retrieve multipleintermediary facts from multiple tables. Using a single fact saves storagespace and l imi ts the number of SQL passes used in queries.

Rather than creating a derived fact, you can create such analysis inMicroStrategy with the use of metrics. Metrics al low you to performcalculations and aggregations on your fact data. For more information onwhat metrics are and how to create them, see the Advanced ReportingGuide.

Example: creating derived facts

The Cost fact in the MicroStrategy Tutorial contains the derived factexpression Qty_Sold * Unit_Cost . This expression impl ies thatcolumns containing data about the quanti ty of i tems sold and the price ofthose uni ts can be multipl ied to produce a useful business calculation. In





this case, the columns are used to answer the business question, "Howmuch did i t cost the company to create the i tems purchased by customers?"

The fol lowing procedure describes how to create a derived fact that usesthe derived fact expression described above. You can also created derivedfacts that use derived fact expressions using Archi tect, which is describedin Creating and modi fying multiple facts, page 158.

To create a derived fact

In MicroStrategy Developer, log in to the MicroStrategy Tutorial project.

Navigate to the My Personal Objects folder, and open the My Objectsfolder.

From the File menu, point to New, and then select Fact. The Fact Edi toropens, wi th the Create New Fact Expression dialog box displayed on top ofi t.


From the Available columns pane, double-cl ick the QTY_SOLD column toadd i t to the Fact expression pane on the right.

To complete the derived fact expression

A derived fact expression includes a combination of columns, numericalconstants, and mathematical operators. The steps below continue theexample scenario to provide a guidel ine of how to create derived factexpressions.

With the cursor in the Fact expression pane, cl ick * (mul tipl ication operator)to add i t to the expression.

From the Available columns pane, double-cl ick the UNIT_PRICE columnto add i t to end of the fact expression.

Under Mapping method , select Automatic.



Click Validate to check whether the syntax of the expression is correct. Theexpression should appear as shown below:

Cl ick OK . The derived fact expression appears in the Fact expression panein the Fact Edi tor.

From the File menu, select Save As. The Save As dialog box opens.

Enter a name for the derived fact and cl ick Save.

When you create a fact for your project, at this point, you must update theproject schema. However, since this is only an example, i t is not necessaryto update the schema.

Facts with varying column names: Heterogeneous column names

In your warehouse, the same fact data can be included in columns withdi fferent column names. In the example below, two fact tables in awarehouse each contain columns for dol lar sales. Table 1 contains a factcal led Dollar_Sales . Table 2 includes a fact cal led Dollar_Sls . Thesetwo i tems represent the same information.

MicroStrategy al lows you to identi fy heterogeneous fact column names foreach fact. Withheterogeneous column names, you can refer the same fact tomultiple columns with di fferent column names and from different tables thatidenti fy the same quanti tative value.



In the example above, creating a heterogeneous fact column name fordol lar sales informs the system that the Dollar_Sales and Dollar_Sls

columns represent the same fact. When you cal l for the information in areport through the use of a metric, both fact columns are used in the SQL,resul ting in an accurate representation of the fact in the report.

Example: Mapping heterogeneous fact columns

The Units Sold fact in MicroStrategy Tutorial consists of two fact columns inthe warehouse, Qty_Sold and Tot_Unit_Sales . Al though these factcolumns have di fferent names and exist in di fferent fact tables, theyrepresent the same data and are therefore both mapped to the Uni t Soldfact.

You must map heterogeneous fact columns to their corresponding facts toensure that accurate and complete data is displayed on reports.

The fol lowing procedure describes how to create the Uni ts Sold fact thatal ready exists in MicroStrategy Tutorial . In the procedure, you create theUni ts Sold fact and map i ts corresponding heterogeneous fact columns to i t.You can also use Archi tect to create a fact wi th heterogeneous columnnames, which is described in Creating and modi fying multiple facts, page158.

To create a fact with heterogeneous column names

In MicroStrategy Developer, log in to the MicroStrategy Tutorial project.


From the File menu, point to New, and then select Fact. The Fact Edi toropens, wi th the Create New Fact Expression dialog box displayed on top ofi t.



From the Source table drop-down l ist, select the ORDER_FACT table. Thisis one of the tables in which a heterogeneous fact column for the Uni ts Soldfact exists.

From the Available columns pane, double-cl ick the QTY_SOLD column toadd i t to the Fact expression pane on the right.


Cl ick OK . The Fact Edi tor opens and the fact expression you just createdappears in the Fact expression pane.

Now you must add the other heterogeneous fact column as separateexpression for the Uni ts Sold fact.

Cl ick New. The Create New Fact Expression dialog box opens.

From the Source table drop-down l ist, select the CITY_CTR_SALES table.This is the other table in which a heterogeneous fact column for the Uni tsSold fact exists.

From the Available columns pane, double-cl ick the TOT_UNIT_SALEScolumn to add i t to the Fact expression pane on the right.


Cl ick OK . The Fact Edi tor opens and the fact expression you just createdappears in the Fact expression pane. Now the Uni ts Sold fact you arecreating maps correctly to i ts heterogeneous fact columns.

From the File menu, select Save As. The Save As dialog box opens.

Enter a name for the new fact and cl ick Save.

When you create a fact for your project, at this point, you must update theproject schema. However, since this is only an example, i t is not necessaryto update the schema.



Fact column names and data types: Column aliases

A column al ias speci fies both the name of the column to be used intemporary tables and the data type to be used for the fact.

By defaul t, the data type for a fact is inheri ted from the data type of thecolumn on which the fact is defined in the data warehouse. However, thereare cases where you may need to change this.

For example, you can define a fact to be the di fference between two datesto perform a calculation such as the average number of days between astart and an end date. You could create this fact using the fol lowingexpression:

ApplySimple("DateDiff(day,#0, #1)", [Start_Date_Id], [End_

Date_Id])

The expression syntax is specific to your database type. This syntax isspecific to Microsoft SQL Server. The SQL you create may be different.

The data type for this fact is automatical ly set to a Date data type becausethe Start_Date_ID and End_Date_ID have Date data types. However, the



resul t of the calculation, that is, the di fference between the two dates, is aninteger.

This is used when a temporary SQL table needs to be created for thecalculation. If you did not change the data type of the column al ias, then thesystem uses a Date data type and tries to insert integer data into thiscolumn. This can cause an error for some database platforms. To avoid thepossibi l i ty of an error due to confl icting data types, you should modi fy thecolumn al ias for the fact to change the defaul t Date data type to an Integerdata type.

The procedure below describes how to use the Fact Edi tor to create columnal iases. You can create column al iases using Archi tect, which is describedin Creating and modi fying multiple facts, page 158.

Prerequisite

This procedure assumes you have already created a fact wi th a val id factexpression for which to create a new column al ias.

To create a column alias for a fact

In MicroStrategy Developer, log in to the project source that contains thefact to create a new column al ias for.

Right-cl ick the fact and select Edit. If a message is displayed asking i f youwant to use read only mode or edi t mode, select Edit and cl ick OK to openthe Fact Edi tor in edi t mode so that you can make changes to the fact. TheFact Edi tor opens.

If you are only given the option of opening the Fact Editor in read only mode,this means another user is modify ing the project's schema. You cannot openthe Fact Editor in edit mode until the other user is finished with their changesand the schema is unlocked.





In the Column alias area, cl ick Modify. The Column Edi tor - ColumnSelection dialog box opens.



Column name: The name for the column al ias which is used in any SQLstatements which include the fact column.


Depending on the data type selected, you can speci fy the byte length, bi tlength, precision, scale, or time scale for your column al ias. For a detai leddescription on each of these properties, see the MicroStrategy DeveloperHelp.


Cl ick OK to save your changes and return to the Fact Edi tor.

Select Save and Close to save your changes.

Modifying the levels at which facts are reported: Levelextensions

Facts are stored at a particular business level in the warehouse. The levelof a fact is defined by the attribute IDs present in the table. For example,the fact table shown below contains several attribute IDs, including Item



and Quarter. These attribute IDs imply that the fact is reported at the i temand quarter levels by defaul t.

Level extensions are necessary when facts are stored in the datawarehouse at one level and reported at di fferent levels. Every fact is tied toa set of attributes that may or may not satisfy al l users' reportingrequirements. A fact extension is needed when a fact does not relatedirectly or indirectly to an attribute included on a report.

If the entry level of a fact is at the lowest level of a hierarchy, al l attributesat a higher logical level in the hierarchy are avai lable for use as wel l ,wi thout the use of level extensions. For example i f you have a cost fact atthe level of a date attribute in a time hierarchy, MicroStrategy canaggregate the cost fact data to the level of the year attribute because i t is inthe same hierarchy as the date attribute and at a higher level . However,facts require level extensions to be related to any attributes that are at a



lower logical level in the same hierarchy than the entry level for a fact (seeLowering the level of fact data: Fact degradations, page 240).

You can use level extensions to change a fact level and extend a fact levelto a level in a completely di fferent hierarchy. For example, you record aDiscount fact at the Item/Date level . That is, discounts apply to particulari tems on particular days. To see i f some cal l centers are sel l ingsigni ficantly more i tems at a discount than other cal l centers, you have toextend the level of the Discount fact to the Cal l Center level , which is anattribute from a di fferent hierarchy.

Level extensions define how facts can be extended, lowered, or disal lowedto other attributes across the schema. By creating a level extension, you areal lowing facts or attributes that have been captured at one level to beextended to other levels to meet reporting requirements.

Level extensions are not required l ike the fact defini tion and column al ias,and they tend to be used only in speci fic cases.

Before a metric containing a fact can be used with an attribute that is not inor related to the attribute's entry level , a level extension must be defined forthe fact. This is because i f a fact is stored at a level unrelated to anattribute on a report, a level extension must exist to relate the fact data tothe attribute. Otherwise, there is no way to make a connection between thefact data and the attribute.

You can create fact level extensions by using any of the fol lowing methods:

Defining a join on fact tables using table relations, page 232

Defining a join on fact tables using fact relations, page 237

Forcing facts to relate to attributes: Using cross product joins, page 238

Lowering the level of fact data: Fact degradations, page 240

Disal lowing the reporting of a fact at a certain level , page 244



You can find complete descriptions for each of these methods in the onl inehelp for the Level Extension Wizard in the Fact Edi tor.

You can use the Fact Edi tor to create level extensions.

Defining a join on fact tables using table relationsA table relation defines a join on tables. When you speci fy a table to joinwi th a fact, you are creating a table relation to extend a fact. A factextension can be used to relate a fact to an attribute using a fact table. Thejoin is important as the table contains an attribute in the entry level and theattribute to which to extend.

For example, the MicroStrategy Tutorial project includes a Freight metric.This metric has a table relation fact extension to the Item attribute. Sincethe ORDER_FACT table that defines Freight does not include the identi tycolumn for the Item attribute, the Freight fact cannot be reported at the Itemlevel . A fact extension is required to view freight values for each i temincluded in an order. In this example, the ORDER_DETAIL table is used tocreate the Freight fact extension to Item because:

The ORDER_FACT and ORDER_DETAIL tables both contain the Orderattribute's identi ty column to join the tables, and ORDER_DETAIL containsthe Item attribute's identi ty column to extend the fact to Item.

The Freight fact cannot simply be joined with a table containing Iteminformation to return a meaningful freight value for each i tem. An al locationexpression is required to extend Freight to the Item level . Notice that theORDER_FACT and ORDER_DETAIL tables include Order-level Uni ts Soldand Item-level Uni ts Sold columns respectively. These two columns areused to al locate the fact expression in the procedure below.

The fol lowing procedure steps through how to create the fact extension thathas been created for the Freight fact of the Tutorial project. The procedurealso describes general principles of creating fact extensions which you canuse to create fact extensions for the facts in your project.



To define a fact extension with a table relation

In Developer, log in to the MicroStrategy Tutorial project.

Browse to the Facts folder and double-cl ick the Freight fact to edi t i t. If amessage is displayed asking i f you want to use read only mode or edi tmode, select Edit and cl ick OK to open the Fact Edi tor in edi t mode so thatyou can make changes to the fact. The Fact Edi tor opens.



Click the Extensions tab.

Select Extension to Item and cl ick Modify. The Level Extension Wizardopens.

To create a new fact extension you would click New. However, this examplesteps through how the Freight fact extension Extension to Item was created.

Read the Welcome statement and cl ick Next. The General Information pageopens.

To lower, extend, or disal low the fact entry level

Enter a name and a description for your fact extension (already provided).Then select whether you want to:

Lower the fact entry level: define a fact degradation (see Lowering thelevel of fact data: Fact degradations, page 240)



Extend the fact entry level: define a fact extension on a table relation,dynamic fact relation, or a cross product join

Disallow partially or completely the fact entry level: define a factextension that does not al low a fact to be reported at a certain level (seeDisal lowing the reporting of a fact at a certain level , page 244)

For this example you are creating a fact extension on a table relation, soselect Extend the fact entry level, and cl ick Next. The ExtendedAttributes page opens.

To select attributes to extend the fact to

Select the attributes you want to extend the fact to, al lowing the fact to bereported at the new level . For this example Item is already selected. Cl ickNext. The Extension Type page opens.

To extend the fact so that it can be reported at any level in a hierarchy, choosethe lowest level attribute in that hierarchy.

To select the type of fact extension

Select how you want to extend the fact:

Specify the relationship table used to extend the fact: select arelationship table and join attributes.

Select the relationship table dynamically: select a fact and join attributes.This al lows the MicroStrategy Engine to select the table that includes thefact and join attributes you choose to create the fact extension (seeDefining a join on fact tables using fact relations, page 237).

Perform the extension through a cross product: select to apply a crossproduct join (see Forcing facts to relate to attributes: Using cross productjoins, page 238).



For this example select Specify the relationship table used to extendthe fact, and cl ick Next to continue defining your fact extension on atable relation. The Table Selection page opens.

To select the table, join attributes, and define the al location expression

Select the table used to extend the fact to the new level . For this example,the ORDER_DETAIL table is already selected. Cl ick Next. The Join Typepage opens.

Select whether to al low Intel l igence Server to dynamical ly select whatattributes to perform the join, or manual ly select the attributes. Since youknow that you want to join the ORDER_FACT and ORDER_DETAIL tablesusing the Order attribute, select Order and cl ick Next. The Join AttributesDirection page opens.

You can choose to join using the attribute, or join using the attribute and i tschi ldren. In this case Order has no chi ldren, so you do not have to cl ick theJoin against arrow to change the defaul t. Cl ick Next. The Al location pageopens.

Enter an al location expression that calculates the fact at the new level . Forthis example, the al location expression is already provided, ((Freight *

[Item-level Units Sold]) / [Order-level Units Sold]) .

Take a moment to review the allocation expression. Notice that the expressionreturns an average freight amount per item of an order. Therefore, theextension of Freight provides an estimate of the freight for each item of anorder, not an exact calculation. A more detailed description of why this occursfollows this procedure.

Click Finish to create the fact extension.

When the engine processes a report containing Order, Item, and Freight, i tjoins ORDER_FACT and ORDER_DETAIL and considers the resul ting tableas one logical fact table at the Item, Day, Order, Employee, Promotion level .



The SQL generated for the report containing Order, Item, and Freight(metric mapped to the Freight fact) is:

select a11.[ORDER_ID] AS ORDER_ID,

max(a11.[ORDER_DATE]) AS ORDER_DATE,

a12.[ITEM_ID] AS ITEM_ID,

max(a13.[ITEM_NAME]) AS ITEM_NAME,

sum(((a11.[FREIGHT] * a12.[QTY_SOLD]) /

a11.[QTY_SOLD])) AS WJXBFS1

from [ORDER_FACT] a11, [ORDER_DETAIL] a12,

[LU_ITEM] a13

where a11.[ORDER_ID] = a12.[ORDER_ID] and

a12.[ITEM_ID] = a13.[ITEM_ID]

group by a11.[ORDER_ID], a12.[ITEM_ID]

The SQL statement above is for an Access database. The SQL for yourreports may vary depending on the type of DBMS that you use.

To view how the fact extension is an estimation of freight values for eachi tem of an order, review the values of the fi rst order wi th an extra metric thatcalculates the number of each i tem type in an order shown below.

Notice that the Freight metric averages the amount of freight per i tem in anorder. The larger freight values occur because more than one of the i temtype was included in the order. This i l lustrates how fact extensions oftenprovide an estimation of values at a di fferent level rather than an exactcalculation. If you want to provide exact values of data at a certain level ,you most l ikely need to capture such data and store i t in your data source.



Defining a join on fact tables using fact relationsFact extensions can be defined by a fact relation instead of a table relation.With a fact relation, the table join is possible on any table that contains thefact. This al lows more flexibi l i ty in defining the relations, since theMicroStrategy Engine is responsible for choosing the appropriate table tojoin, rather than you having to select tables manual ly.

The fol lowing diagram shows the schema from the example in Defining ajoin on fact tables using table relations, page 232 after two summary tablesare added to i t.

To extend the entry level of the Freight fact to Customer, you can create afact relation using the Order Uni t Sales fact.

The MicroStrategy Engine tries to join a table containing Freight to a tablecontaining Order Uni t Sales. The engine can make the fol lowing joins,depending on the join attributes speci fied:

Table 1 and Table 2 on Distribution Center, and Order

Table 1 and Table 4 on Distribution Center





The joins described above demonstrate how the join attributes can beei ther Distribution Center and Order or just Distribution Center.

You can define the fact relation in the Level Extension Wizard which youcan access from the Fact Edi tor. Open the Order Uni t Sales fact and extendi t to ei ther Distribution Center and Order or just Distribution Center. Next,select the Select the relationship table dynamically option and speci fythe tables to use for the extension. This option is set in the stepimmediately after Defining a join on fact tables using table relations, page232 in the procedure above. The tables and attributes you speci fy in thewizard determine the di fferent types of joins that are created, as explainedabove.

The SQL generated for a report containing Distribution Center, Customer,and Freight is shown below, i f the only join attribute is Distribution Center.

select a1.DIST_CENTER, a2.CUSTOMER,

sum(a1.Freight)

from TABLE3 a1, TABLE4 a2

where a1.DIST_CENTER = a2.DIST_CENTER

group by a1.DIST_CENTER, a2.CUSTOMER

The SQL statement above is for an Access database. The SQL for yourreports may vary depending on the type of DBMS you use.

As with table relations, you can speci fy the best fi t as the join strategy sothat the engine calculates the joins. In a best fi t join, the set of joinattributes must contain the enti re key of the left-hand-side fact table (Table3 in the example SQL above).

Forcing facts to relate to attributes: Using cross product joinsYou can use a cross product join when a join does not exist and you needto force a fact to relate to an attribute by extending the fact. The crossproduct join is an extension that al lows a single fact value to relate to al lelements of an unrelated attribute. This method can produce incorrect databecause data can be repeated and counted twice in some cases.



Cross products should only be used when no other way to extend the factexists. When you specify a cross product join to relate a fact to an attribute,you are creating a Cartesian product of the lookup attribute. Since this methodcan be ineffic ient, MicroStrategy does not recommend using the cross productjoin.

For example, in the fol lowing schema, Distribution Center does not relate toDol lar Sales:

To report Dol lar Sales by Distribution Center, a cross product join must beused.

You can define this cross product join in the Level Extension Wizard in theFact Edi tor. Open the Dol lar Sales fact and extend i t to the DistributionCenter attribute. Next, select the Perform the extension through a crossproduct option. This option is set in the step immediately after Defining ajoin on fact tables using table relations, page 232 of the procedure above.For this example, you do not need to speci fy an al location expression.

Notice that no join attributes are speci fied. The MicroStrategy Enginealways cross-joins the lookup tables of the attributes in the extension.

The SQL generated for a report containing Customer, Distribution Center,and Dol lar Sales is:

select a1.DIST_CENTER, a2.CUSTOMER,

sum(a2.DOLLAR_SALES)

from TABLE1 a1, TABLE2 a2

group by a1.DIST_CENTER



The SQL statement above is for an Access database. The SQL for yourreports may vary depending on the type of DBMS you use.

Lowering the level of fact data: Fact degradationsDegradation, which lowers a fact level , is the logical opposi te ofaggregation. To view fact data at a lower logical level than the fact is storedat, you must degrade the fact to a lower level . This scenario may occurbecause you stored a fact at a level that is used most commonly in reports.However, you must support those users who wish to view and analyze thesame fact data at a lower logical level .

For example, the Human Resources Analysis Module includes a PlannedCompensation fact that is stored at the Department level , and has a factdegradation to the Employee level (the attributes, facts, and metrics used inthis example can al l be found in this Analytics Module). The fact extensiondoes not use an al location expression to degrade Planned Compensation tothe Employee level . This causes every employee to be l isted with the sameplanned compensation value as the employee's department, as shownbelow:



The analytical value of this fact degradation is not immediatelyrecognizable. However, now that Planned Compensation is avai lable at theEmployee level , you can create more meaningful analysis wi th other factdata that is stored at the Employee level . For example, the CompensationCost fact is stored at the Employee level . The metric Actual as % PlannedCompensation has been created to calculate the actual compensation of anemployee as a percentage of the planned compensation for the enti redepartment of the employee. The metric defini tion is ([Compensation

Cost]/[Planned Compensation]) , which performs a division ofmetrics defined from the Compensation Cost and Planned Compensationfacts, respectively. You can now view what percentage of your plannedcompensation per department has been spent per employee, as shownbelow:

Without using a degradation of Planned Compensation to Employee, youcould not include Department and Employee on a report wi th these metricsand return accurate values.

The fol lowing procedure steps through how to create the fact degradationthat has been created for the Planned Compensation fact of the HumanResources Analysis Module. The procedure also describes generalprinciples of creating fact degradations which you can use to create factdegradations for the facts in your project.



To define a fact degradation

In Developer, log in to the Human Resources Analysis Module.

Browse to the Facts / Compensation / Planning folder and double-cl ickthe Planned Compensation fact to edi t i t. If a message is displayed askingi f you want to use read only mode or edi t mode, select Edit and cl ick OK toopen the Fact Edi tor in edi t mode so that you can make changes to the fact.The Fact Edi tor opens.



Click the Extensions tab.

Select Degradation to Employee and cl ick Modify. The Level ExtensionWizard opens.

To create a new fact degradation you would click New. However, this examplesteps through how the Planned Compensation fact degradation Degradation toEmployee was created.

Read the Welcome statement and cl ick Next. The General Information pageopens.

Enter a name and a description for your fact extension (already provided).Then select whether you want to:

Lower the fact entry level: define a fact degradation

Extend the fact entry level: define a fact extension on a table relation,dynamic fact relation, or a cross product join (see Defining a join on fact



tables using table relations, page 232 and Defining a join on fact tablesusing fact relations, page 237)

Disallow partially or completely the fact entry level: define a factextension that does not al low a fact to be reported at a certain level (seeDisal lowing the reporting of a fact at a certain level , page 244)

For this example you are creating a fact degradation so select Lowerthe fact entry level, and cl ick Next. The Extended Attributes pageopens.

Select the attributes you want to degrade the fact to, al lowing the fact to bereported at the new level . For this example Employee is already selected.Cl ick Next. The Join Type page opens.

To extend the fact so that it can be reported at any level in a hierarchy, choosethe lowest level attribute in that hierarchy.

Select what attribute(s) to perform the join. For this example, theDepartment attribute is already selected. Cl ick Next. The Join AttributesDirection page opens.

You can choose to join using the attribute, or join using the attribute and i tschi ldren. For this example, the join is performed on the Department attributeand i ts chi ldren. Cl ick Next. The Al location page opens.

Enter an al location expression that calculates the fact at the new level . Forthis example, you do not need to include an al location expression. See Factdegradations with al location expressions, page 243 for an example of usingan al location expression for a fact degradation.

Cl ick Finish to create the fact degradation.

Fact degradations with allocation expressions

Not al l fact degradations can simply be lowered to a new level . Ordinari ly,you must add an al location expression, which al lows the distribution of



values according to a calculation you speci fy, to change the defini tion ofthe fact in a level extension.

This is similar in concept to choosing an aggregation function (Sum, Avg, andso on) when aggregating data to higher levels.

For example, i f your fact is stored at the yearly level and you want to reportthe data at the monthly level , you can create a degradation on the fact torelate i t to the monthly level . You select Month to be the attribute to whichto degrade. You then speci fy that the al location expression is fact/12 .

By creating al location expressions, you define how higher-level facts aredegraded to lower-level attributes. Al location expressions are defined byoperations you set on attributes and facts in the Level Extension Wizard inthe Fact Edi tor.

Fact degradations often produce data estimates rather than exact values forthe fact data at lower logical levels. For example, consider the al locationexpression fact/12 for a degradation from Year to Month. Using such anal location expression would spread a year's fact data evenly over the 12months of that year. Whi le i t is possible that the fact data would be thesame for every month of the year, this is often an unl ikely scenario. Suchfact degradations should be used only when fact data is not stored at alower logical level and there is no way to directly relate the fact data to thelower logical level .

Disallowing the reporting of a fact at a certain levelThe Disal low partial ly or completely the fact entry level setting within theFact Edi tor is l ike a lock which prevents a fact from being reported at aspeci fic level . The setting prevents unnecessary joins to lookup tables. Thefol lowing examples describe instances in which disal lowing a fact entrylevel can prove useful .

Disal lowing a fact to be extended to a level lower than the fact's entry leveldue to unnecessary complexi ty and the cost of analyzing fact data at such alevel is a common use for this feature. If a fact is stored at a level that is



counterproductive to a query, such as data that is stored at the Minute orSecond level , you can disal low the lower levels. For example, i f you havethree years' worth of data, querying at the Minute or Second level consumestoo many resources and returns extensive data. With a disal low in place, i fyou create a report and attempt to include the fact at the Minute or Secondlevel , an error is returned, indicating that the report cannot be run at thatlevel .

Consider a schema containing three dimensions: Geography, Time, andProduct. Suppose you create a fact cal led Sales at the Item level in theProduct dimension and a metric cal led Sales as the sum of the Sales fact.When you create a report containing the Month attribute and the Salesmetric, the Analytical Engine does a dynamic cross-join and evaluates thereport. To expl ici tly disal low an extension of the Sales fact to the Timedimension, you would use the Disallow partially or completely the factentry level setting and select the lowest attribute in the Time dimensionsuch as Day. This option is set in the step immediately after Defining a joinon fact tables using table relations, page 232 of the procedure to create afact extension above. After updating the schema and re-executing thereport, the report fai ls because the disal low setting now prevents the cross-joins between the lookup tables and fact tables. This setting, however, doesnot affect normal joins.

In the previous example, for the Sales fact, assume you specify an extensionto the Month attribute and also disallow extension to Year which is a parent ofthe extended attribute, Month. If you execute the report containing the Yearattribute and Sales metric, the report runs successfully . In this case, theengine sorts the extension conditions specified in some order and calculatesthe report based on the sorted order of extensions. This is not an expecteddesign condition, although the engine returns a valid SQL. It is advisable toavoid fact definitions that contain contradictory extension definitions.

The Disal low the fact entry level setting appl ies only to attributes that canbe considered as extended attributes. For example, you create a report thatcontains the attributes Subcategory and Item and the Revenue metric,



which is defined as sum of the Revenue fact. You now disal low anextension on the Revenue fact for the Item attribute and update the schema.If you re-execute the report, you can sti l l see Revenue by Item. This impl iesthat the fact extension has not been disal lowed. This is because Revenueexists at the same level as Item in the MicroStrategy Tutorial project. Soyou encounter only normal joins and no extensions. There must be a val idreason to disal low reporting a fact at a certain level . In this case,disal lowing the Revenue fact at the level i t is stored at in the datawarehouse does not make logical sense.



THE CONTEXT OF YOURBUSINESS DATA:ATTRIBUTES



Business data represented by facts can offer l i ttle insight wi thout thepresence of business concepts and context, which take the form ofattributes in MicroStrategy. Attributes provide the business model wi th acontext in which to report on and analyze facts. Whi le knowing yourcompany's total sales is useful , knowing where and when the sales tookplace provides the kind of analytical depth users require on a dai ly basis.

For example, you have a report wi th the Month, Year, and Region attributeson the template, as wel l as a Revenue metric based on the Revenue fact.When executed, the report displays your company's revenue at the region,month, and year levels. Because of the attributes on the report, asubstantial amount of information is avai lable, including which regionsproduced the least revenue and which years saw the highest growth inrevenue. If you remove the attributes from the report, you can only find outhow much revenue the company generated in total .

Overview of attributes

Creating attributes is an important step in the ini tial project design effort,which comes after creating facts when using the Project Creation Assistant.New user and appl ication requirements make attribute creation andmodi fication an important part of the enti re project l i fe cycle.



In the data warehouse, attributes are normal ly identi fied by a unique IDcolumn in a lookup table. In MicroStrategy reports, attributes are identi fiedby the column headers of the reports.

A report designer creates a report in part by determining these reportcolumn headers. Intel l igence Server, using this report defini tion, instructsthe engine how to bui ld the SQL for that report. The expressions ofattributes and facts in the report define the SELECT clause of the SQLcommand.

For example, consider the fol lowing:

Select Store_ID, Date, sum(Sales)From Store_Fact

Group By Store_ID, Date

In the SQL above, sales information wi l l be retrieved by store and date. Theattributes and metrics in the report tel l Intel l igence Server where to look inthe data warehouse for the information and how to create the SQL that wi l l



retrieve i t. Because of this process, report analyzers do not have to knowSQL to extract information from a data warehouse.

The lowest level attribute you include in a report, such as Day, is the lowestlevel of detai l reported. A high-level report, such as a report at the Yearlevel , includes the Year attribute but lacks the detai l of a simi lar reportwhich includes the lower level attributes Month and Week. It is important tounderstand the data is sti l l the same, i t is just not aggregated.

A discussion about metrics, filters, and reports is beyond the scope of thisguide and is covered in the Advanced Reporting Guide .

Attributes are defined by these properties:

Attribute form: contains an identi fier or descriptor of an attribute. Attributescan have multiple attribute forms. For example, for the Customer attribute,Customer Emai l , Customer First Name, and Customer Last Name areexamples of attribute forms. See Column data descriptions and identi fiers:Attribute forms, page 270.

Attribute expression : maps a MicroStrategy attribute form to one or morecolumns in the warehouse. See Attribute form expressions, page 275.

Attribute relationship : al lows interaction of data at di fferent conceptuallevels and shows how data is related within a project. See Attributerelationships, page 290.

The fol lowing diagram i l lustrates how the attribute properties l isted aboveare related:




While creating attributes is a major step in the ini tial creation of a project, i tis often necessary to modi fy and create attributes throughout the l i fe cycleof a project. The procedures to perform these tasks are discussed in thefi rst section (Creating attributes, page 251) of this chapter. The latersections discuss conceptual information on attributes, as wel l as highl ightsome advanced attribute design techniques and procedures.

Creating attributes

An attribute is primari ly used to group and aggregate fact data to addbusiness context to the fact data. The abi l i ty to report on and analyze datarequires data to have a business context; therefore, creating attributes is amajor step in any project design effort.



This section provides steps to create attributes at di fferent phases of theproject design process, using di fferent techniques and MicroStrategyinterfaces:

Simul taneously creating multiple attributes, page 252: Provides steps tocreate multiple attributes as part of the ini tial project design effort or later ina project's l i fe cycle wi th the Attribute Creation Wizard.

Adding and modi fying attributes, page 257: Provides steps to add andmodi fy attributes for an existing project. This includes adding advancedfeatures such as attribute forms to attributes that al ready exist or addingnew attributes as your project evolves.

You can also create and modi fy attributes at any phase of the projectdesign process using Archi tect. For information on creating and modi fyingattributes using Archi tect, see Adding and modi fying attributes, page 257.

Simultaneously creating multiple attributesDuring your ini tial project design effort or later in a project's l i fe cycle, youcan create multiple attributes using the Attribute Creation Wizard.

You can also create multiple attributes using Architect, which is described inChapter , Adding and modi fying attributes.

To create attributes using the Attribute Creation Wizard

This procedure is part of an ini tial project creation effort using the ProjectCreation Assistant, which launches the Attribute Creation Wizard tocomplete the attribute creation tasks. For steps to access the ProjectCreation Wizard, see Creating a new project using the Project CreationAssistant, page 98. You can also access the Attribute Creation Wizard atany time in the development of a project from the Schema menu inMicroStrategy Developer.

In the Project Creation Assistant, cl ick Create attributes. The AttributeCreation Wizard opens, as shown below.



Review the introduction page that is displayed.

Define attribute creation rules

These rules can make the process of choosing attribute columns andnaming your attributes considerably easier, especial ly i f you useconsistent naming conventions and data types in your data warehouse.The Attribute Creation Wizard uses these rules below to help automatethe attribute creation process. Change these rules i f the naming or datatype conventions in your warehouse do not conform to these defaul ts.

Cl ick Define Rules to set some basic attribute creation rules. The AttributeCreation Rules page opens.

The Column data type area al lows you to select the column data types to beavai lable as possible attribute ID columns. Select the check boxes for thedata types that should be included when the wizard searches the datawarehouse for avai lable attribute ID columns.

The Attribute name area al lows you to determine how to create defaul tattribute names. You can select the appropriate check boxes to set thefol lowing defaul t behaviors for creating attribute names:



Replace underscores in the attribute name with spaces.

Remove the word "ID" from the name.

Capi tal ize the fi rst letter.

The Warehouse search area determines naming conventions to help locateyour warehouse objects. The defaul ts are ID for identi fier columns, DESCfor description columns, and LOOKUP for lookup tables.

Cl ick OK to accept your rule changes and return to the Attribute CreationWizard.

Select the ID column

An ID column is a column or group of columns that uniquely identi fieseach element of an attribute.

Cl ick Next. The ID Column Selection page opens.

When choosing the ID column for an attribute, make sure that all values in thecolumn are unique and that it does not contain NULL values. You should neveruse a column that has NULL or repeated values as the ID column for anattribute. Doing so results in unexpected behavior and errors.

Only those columns with data types that match those chosen in the rulesyou defined above appear on the ID Selection page. The columns thatmatch the identi fier naming convention that you set in the warehousesearch rule above are automatical ly highl ighted.

From the Avai lable columns pane, select the columns to use for yourattribute IDs and cl ick > to add them to your project. Cl ick >> to add al l thel isted columns.

You can rename any attribute name to make it more user-friendly by right-c lick ing the attribute and selecting Rename .



To remove attribute ID columns from your project, select the attribute IDs inthe Attributes pane and click < to move them to the Available columns pane.

The Attribute Creation Wizard cannot handle columns that hold the sameinformation but have different column names (that is, heterogeneouscolumns). For more information about mapping attributes to heterogeneouscolumns, see Attribute form expressions, page 275 .

Create compound attributes

A compound attribute is defined as an attribute wi th more than onecolumn speci fied as the ID column. This impl ies that more than one IDcolumn is needed to uniquely identi fy the elements of that attribute (seeAttributes with multiple ID columns: Compound attributes, page 315).

To create a compound attribute, complete the fol lowing steps:

Cl ick Compound Attributes and then cl ick Add . The New CompoundAttribute dialog box opens.

Type a name for the attribute.

Select the columns that are required to uniquely identi fy the compoundattribute and cl ick OK . You are returned to the Attribute Creation Wizard.

Select the description column

Description columns provide the data which gives context and meaningto your attributes.

After adding al l your attribute ID columns, cl ick Next. The DescriptionColumn Selection page opens.

Select whether to use the ID or a di fferent column for the description of theattribute. The column that meets the description naming convention that youset in the warehouse search rule is automatical ly selected.

In general, you should use the default description column for each attribute. In



some cases, however, it may make sense to use the ID column as thedescription column, such as Year.

Other attribute forms need to be created through the Attribute Editor after youcomplete steps in the Project Creation Assistant. Refer to Adding andmodi fying attributes, page 257 , for more information about attribute forms.

Select the lookup table

Lookup tables are the physical representation of attributes; they providethe information for an attribute through data stored in their ID anddescription columns.

Cl ick Next when you are finished selecting description columns forattributes. The Lookup Table Selection page opens.

Select the lookup table for each attribute.

The table that fol lows the lookup naming convention that you set in thewarehouse search rule is automatical ly selected. In general , you shouldchoose the defaul t lookup table for each attribute.

Cl ick Next:

If you have created compound attributes, the Compound Attribute Defini tionpage opens. Speci fy the lookup table and description column for thecompound attributes and cl ick Next. The Relationship Defini tion pageopens.

If you have not created a compound attribute, the Relationship Defini tionpage opens.

Define the relationship

For each attribute, you speci fy the chi ldren and the type of relationship:one-to-one, one-to-many, or many-to-many. When you design a logicaldata model for your project (see Chapter 2, The Logical Data Model ), therelationships between attributes should become apparent. Relatedattributes such as City, State, or Region are often grouped in a common



hierarchy, l ike Location. In a logical data model , when attributes are inthe same hierarchy they must be related to each other, whereasattributes in di fferent hierarchies cannot be related.

For each attribute, define chi ld attributes:

In the Attributes pane, select an attribute and cl ick Add . The SelectChi ldren Attributes dialog box opens.

Select the chi ld attributes from the l ist of avai lable chi ld attributes and cl ickOK . You are returned to the Attribute Creation Wizard.

In the Chi ldren of: attribute name pane, select the relationship type for theattribute to i ts chi ld attribute. For more information on the di fferent attributerelationship types, see Attribute relationships, page 290.

When you have defined chi ldren for al l the attributes that need them, cl ickNext. The Finish page opens.

Review the summary information in the Finish page and cl ick Finish tocreate the attributes.

After you have completed the steps of the Attribute Creation Wizard, theattributes are created. This completes the ini tial creation of a project wi ththe Project Creation Assistant.

Adding and modifying attributesJust as you can add more facts to your project once you have created i t, youcan also create and add attributes as they become necessary. As acompany evolves, so does i ts reporting requirements; these requirementscan lead to changes to the data warehouse as wel l as to the schema withini ts MicroStrategy projects.

For example, a heal th care company, wi th offices only in the Uni ted States,decides to extend i ts operations into Europe and Asia. Before the shi ftoverseas, the company does not include lookup tables with informationabout di fferent countries in i ts data warehouse.



However, when the company opens i ts offices in Europe and Asia, i t mustadd lookup tables that contain data about i ts new offices to i ts warehouse.It must then add these tables to i ts MicroStrategy project, and create theappropriate attributes so report users can analyze business data for theirappropriate country.

You can use various techniques and interfaces to create and modi fyattributes for a project:

The Attribute Creation Wizard al lows you to:

Create simple attributes

Create multiple attributes quickly

Add a large number of attributes during project creation

The Attribute Creation Wizard works wel l for bui lding a large number ofattributes ini tial ly, but you cannot use i t to modi fy existing attributes orto define more advanced attributes. In general , you only use theAttribute Creation Wizard as part of the ini tial project creation to createmost of the attributes for the project. For steps to use the AttributeCreation Wizard, see Simul taneously creating multiple attributes, page252 and Adding attributes with the Attribute Creation Wizard, page 259.

The Attribute Edi tor al lows you to:

Create simple and advanced attributes

Edi t existing attributes and configure addi tional schema-level settings

You can use the Attribute Edi tor to edi t existing attributes and createaddi tional attribute forms, map heterogeneous column names, defineadvanced expressions, configure addi tional settings, and so on. TheAttribute Edi tor al lows you to modi fy one attribute at a time, which canbe helpful when only a few facts in a project need to be modi fied. Forsteps to use the Attribute Edi tor, see Adding attributes with the AttributeEdi tor, page 260 and Modifying attributes, page 263.

Archi tect al lows you to:



Create simple attributes

Create multiple attributes quickly

Add a large number of attributes during project creation

Create simple and advanced attributes

Edi t existing attributes and configure addi tional schema-level settings

With Archi tect, you can support al l of the simple and advanced attributefeatures that are avai lable in the Attribute Edi tor. Rather than focusingon one attribute at a time with the Attribute Edi tor, you can use Archi tectto create and modi fy mul tiple attributes for a project at once. Forinformation on how to use Archi tect, see Adding and modi fying simpleand advanced attributes using Archi tect, page 264.

Adding attributes with the Attribute Creation Wizard

Although the Attribute Creation Wizard is primari ly used to create most of aproject's attributes during ini tial project creation, you may sti l l find i t usefuli f you need to create multiple attributes from remaining lookup columns inyour warehouse.

Fol low the steps below to use the Attribute Creation Wizard to createsimple attributes in bulk.

To create simple attributes in bulk using the Attribute Creation Wizard


You must use a login that has Architect priv ileges. See the List of Privi legeschapter in the System Administration Guide for more information.

From the Folder List, select the project to which to add new attributes.




From the Schema menu, choose Attribute Creation Wizard . The AttributeCreation Wizard opens.

To create attributes with the Attribute Creation Wizard, fol low the stepsoutl ined in Simul taneously creating multiple attributes, page 252.

Adding attributes with the Attribute Editor

The Attribute Edi tor is used to add advanced features such as attributeforms to attributes that al ready exist. You can also use i t to add newattributes to your project.

To create an attribute using the Attribute Editor


From the File menu, select New, and then Attribute. The Attribute Edi toropens, wi th the Create New Form Expression dialog box displayed on topof i t.

From the Source table drop-down l ist, select a table which contains thecolumns of data for the attribute. Its columns are l isted in the Avai lableColumns pane.

Create a form expression for the ID form of the new attribute being created.

To create a simple attribute form expression (Attribute form expressions,page 275), drag a column from the Avai lable columns pane to the Formexpression pane.

To create a more advanced attribute form expression, use a combination ofany of the fol lowing techniques:

Enter constants in double quotes.

Cl ick f(x) in the Form expression toolbar to create a function using theInsert Function Wizard.



Click any operator in the Form expression toolbar to insert i t into theexpression.

Cl ick Validate to ensure that your expression is val id.

Under Mapping method , select Automatic or Manual:

Automatic mapping means that al l of the tables in the project wi th thecolumns used in the attribute form expression are selected as possiblesource tables for the attribute form. You can then clear any tables mappedautomatical ly or select other tables.

Manual mapping means that al l of the tables in the project wi th the columnsused in the attribute form expression are located but are not selected aspossible source tables for the attribute form. You can then select which ofthose tables are used as source tables for the attribute form.

The mapping method defaults to Automatic for the first attribute or attributeform expression you create. The system maps the expression to each of thesource tables. For subsequent attributes, the default is Manual.

An expression that uses only a constant value cannot use the automaticmapping method.

To use an attribute for meaningful analysis, you must verify that it inc ludes acolumn from a fact table in its definition, or is related to an attribute that does.For example, to use the Month attribute for analysis, you must create arelationship to the Day attribute, which must include the DAY column from thefact table in its definition. To create relationships between attributes, seeAttribute relationships, page 290 .

Click OK . The Create New Attribute Form dialog box opens, from which youcan create attribute forms for the attribute (Column data descriptions andidenti fiers: Attribute forms, page 270).

From the Source tables pane, select a table and cl ick Set as Lookup toset the lookup table for the attribute. A lookup table acts as the main table



which holds the information for an attribute. If you chose manual mapping,select the check boxes of the tables to map to the attribute form.

In the Form general information area, type a name and description in theassociated fields for the attribute form.

In the Category used drop-down l ist, do one of the fol lowing:

Select a form category from the drop-down l ist. For a description of formcategories, see Displaying forms: Attribute form properties, page 272.

Cl ick Modify to create a new form category.

Using a column with a non-numeric data type as an ID column of an attributecan result in SQL generation issues. Therefore, if you select a column with anon-numeric data type and set it as an ID column, a warning message appearsby default when you click OK in the Create New Attribute Form dialog box.

In the Form format area, select a display type and a defaul t sorting optionfrom the associated drop-down l ists.

Custom groups are sorted by the Default sort of the form that appears first inthe Report display forms. For more information on custom groups, refer to theAdvanced Reporting Guide .

If the attribute form should be capable of displaying information in multiplelanguages, select the Supports multiple languages check box. Forinformation on supporting the display of data in multiple languages, seeSupporting data international ization for attribute elements, page 267.

Cl ick OK . The Attribute Edi tor opens.

From the File menu, select Save As. The Save dialog box opens.

Navigate to the folder in which to save the attribute. Enter a name for theattribute. Cl ick Save.




From the Schema menu, select Update Schema to update the projectschema. This ensures that your project is updated to recognize the newattribute defini tion.

Modifying attributes

After creating an attribute, you can modi fy the attribute at any time using theAttribute Edi tor. You cannot use the Attribute Creation Wizard to modi fyattributes.

To modify an existing attribute

In MicroStrategy Developer, open the folder that contains the attribute tomodi fy.

Double-cl ick the attribute to edi t. If a message is displayed asking i f youwant to use read only mode or edi t mode, select Edit and cl ick OK to openthe Attribute Edi tor in edi t mode so that you can make changes to theattribute. The Attribute Edi tor opens.

If you are only given the option of opening the Attribute Editor in read onlymode, this means another user is modify ing the project's schema. You cannotopen the Attribute Editor in edit mode until the other user is finished with theirchanges and the schema is unlocked.


You can then modi fy al l the options avai lable when creating andattribute in the Attribute Edi tor, which is described in the previousprocedure To create an attribute using the Attribute Edi tor, page 260.

You can learn how to create more advanced attributes in the varioussections in this chapter.



Adding and modifying simple and advanced attributes usingArchitect

Archi tect can be used to create and modi fy simple and advanced attributesin a visual ly integrated environment. Archi tect al lows you to view thetables, attributes, attribute relationships, facts, user hierarchies, and otherproject objects together as you design your project.

With Archi tect, you can support al l of the simple and advanced attributefeatures that are avai lable in the Attribute Edi tor. Rather than focusing onone attribute at a time with the Attribute Edi tor, you can use Archi tect tocreate and modi fy mul tiple attributes for a project at one time. Review thechapters and sections l isted below for information on Archi tect and steps tocreate and modi fy attributes using Archi tect:




Unique sets of attribute information: Attributeelements

Attribute elements are the unique sets of information or values of anattribute. For example, in the fol lowing diagram, Customer is the attributeand New York NY, Bal timore BA, and Boston BN are elements of theattribute Ci ty:



The fol lowing example displays the physical warehouse table that storeselements and data for the Customer attribute. Each attribute element is arow in an attribute lookup table in your data warehouse, as shown below:

The Customer attribute is a good example to understand the components ofan attribute and the concept of an attribute element. With the Customerattribute, each attribute element is an individual customer. Each customer(attribute element) has i ts own set of information such as last name, fi rstname, emai l address, and so on which are defined by the attribute forms(see Column data descriptions and identi fiers: Attribute forms, page 270).

As shown above, an attribute element is a unique set of information definedby the attribute forms of an attribute. Attribute elements are identi fied bytheir browse forms, which should be forms that provide a generaldescription of the attribute element. For example, in the image above, the



First Name and Last Name forms are used to identi fy the attribute elements.Just as you would not refer to a customer by his or her street address, youwould not want to use the Address form to identi fy the Customer attributeelements. For more information on selecting the attribute forms used toidenti fy attribute elements, see Using attributes to browse and report ondata, page 318.

Attribute elements can be identi fied in logical data models. As shownbelow, the attribute Division has multiple attribute elements, such as Men'sClothing, Shoes, and Sporting Goods:



In MicroStrategy reports, attribute elements are displayed depending on thelocation of the attribute they are associated with. For example, the reportbelow has two attributes, Sales Organization and Year. Sales Organizationis on the rows of the report along with i ts attribute elements such as USACentral . Year is on the columns of the report along with i ts attributeelements such as 2005.

The display of attributes and their attribute elements is also affected by thelocation of the metrics on the report. The report above uses the commonpractice of putting the metrics (Sales Orders Quanti ty (Base Uni ts) and CostSales Orders) on the columns of the report.

Supporting data internationalization for attribute elementsMicroStrategy supports the international ization of your data into thelanguages required for your users. This al lows attribute element data to bedisplayed in various languages that can reflect the user's languagepreferences.

For example, consider the simple report below which displays profi ts foreach month of the year.



This is the data that is shown to a user running the report wi th their regionalsettings defined as Engl ish. By supporting international ized data, the samereport can return the data shown below to a user wi th their regional settingsdefined as German.

The attribute element data is displayed in the German language. Forexample, the January, February, and March attribute elements aredisplayed as Januar, Februar, and März.

Data international ization provides data from you data source translated invarious languages for the attribute element data. To provideinternational ized attribute names (such as Month of Year and Monat im Jahrin the reports above), descriptions, and other translated object information,you must use and configure metadata international ization. For information



on configuring metadata international ization, see the System AdministrationGuide.

Each attribute form can enable or disable the international ization of i tsattribute element data. The procedure described below provides the stepsto enable or disable international ization for attribute forms.

You can also use Archi tect to enable or disable the international ization ofattribute element data, as described in Prerequisi tes, page 184.

Prerequisi tes

The translated data has been stored in your data source, as described inSupporting data international ization, page 64.

The project has been enabled for data international ization, as described inEnabl ing data international ization for a project, page 106.

An attribute has been created.

To enable or disable data internationalization for attribute forms


Navigate to the Schema Objects folder, open the Attributes folder, andthen open a folder that contains attributes to enable or disable datainternational ization for.

Right-cl ick an attribute and select Edit. If a message is displayed asking i fyou want to use read only mode or edi t mode, select Edit and cl ick OK toopen the Attribute Edi tor in edi t mode so that you can make changes to theattribute. The Attribute Edi tor opens.







In the Attribute forms pane, select an attribute form and cl ick Modify. TheModi fy Attribute Form dialog box opens.

Select the Support multiple languages check box to enable datainternational ization for the attribute form. You can clear the check box todisable international ization for the attribute form.


Click OK to return to the Attribute Edi tor.

Cl ick Save and Close to save your changes and return to Developer.

Column data descriptions and identifiers: Attributeforms

Attribute forms are identi fiers or descriptors of an attribute, as explained inLogical data model ing conventions, page 36.

Every attribute must have at least one form, and most have at least two:

The ID form (required)



A description form

Every attribute must have an ID form (identi ty form). ID forms serve touniquely identi fy each attribute element from other elements for the sameattribute. For example, the Customer attribute's ID form is Customer_ID ,which is a column of unique numeric values to identi fy each customer. Todi fferentiate between two customers such as John Smith and Fred Black,each customer must have a di fferent value for their identi ty column. In thiscase John Smith can have a value of 1 in the Customer_ID column andFred Black can have a value of 2 in the Customer_ID column.

Attributes also have description forms. The Customer attribute in theMicroStrategy Tutorial has various forms, including the Customer Name andthe Address forms. These types of forms give context and information aboutthe Customer attribute.

Some attributes can have addi tional descriptive forms that do not serve asthe primary description form. For the Customer attribute, Emai l is includedas an addi tional descriptive form, as shown in the fol lowing diagram:

In the data warehouse, a lookup table wi th three columns holds thefol lowing separate forms, described below:



Customer_ID : A unique, identi fying number for each customer (ID form)

Customer_Full_Name : The ful l name of each customer (Description form)

EMAIL : The emai l address for the speci fic customer (Addi tional descriptionform)

In this example, the LU_CUSTOMER table records al l of the attribute formdata for the Customer attribute.

Attributes must contain at least one ID form, which uniquely identi fies theattribute. The forms you create must have a reference to a lookup table andcan include multiple expressions. Each table must have an ID form; the IDforms are used to join tables. When creating an attribute form, you canchoose a lookup table in the Attribute Edi tor from a l ist of tables existing inthe project. In the warehouse, two columns with di fferent names canrepresent the same information about an attribute. In such cases, you mustmap the appropriate columns to the same attribute to retrieve accurate andcomplete resul ts when using an attribute on a report. Heterogeneouscolumn names are discussed in Attribute form expressions, page 275.

For example, two tables exist, one with the forms Customer_ID , Name ,and SSN . The second lookup table contains Customer _ID and Email .The attribute wi l l have the Customer_ID , Name , SSN , and Email formsand the tables wi l l join together through the ID columns because that is thecolumn they have in common.

Displaying forms: Attribute form propertiesAttribute form properties are settings that affect the display of the forms.You must select properties for each form when you create forms in the



Attribute Edi tor or Archi tect in MicroStrategy Developer. In the AttributeEdi tor, these properties are avai lable when creating a new attribute form, orby modi fying an attribute form. In Archi tect, these properties can bemodi fied using the Properties pane, as described in Prerequisi tes, page184.

Attribute form properties include the fol lowing:

Categories: Help group the types of forms. The standard category optionsare ID, Desc, and None. You can create new form categories in the AttributeEdi tor.

When you have attributes that require multiple description forms, i t is agood practice to map the most commonly used or most importantdescription form to the Desc form of the attribute. Each attribute canhave only one Desc form; the other description forms must be mapped toNone forms. Whi le there is no di fference in how a Desc attribute formand None attribute form are used in MicroStrategy, mapping the mostcommonly used or most important description form can be helpful forproject designers to quickly distinguish this attribute form from the othersecondary forms.

Format types: Control how the form is displayed and how fi l ters aredefined. For example, speci fying a format type of Big Decimal al lows usersto preserve precision when qual i fying on a form with more than 15 digi ts.Big Decimal is discussed in detai l in Appendix C, Data Types.

Report Sort: Defines how the attribute form is sorted by defaul t whenincluded in a report. From the drop-down l ist, you can choose fromAscending, Descending, or None. For information on how attribute formsare sorted when multiple attribute forms of a single attribute define a defaul tsort order, see Defaul t sorting of mul tiple attribute forms on reports, page274 below.

Browse Sort: Defines how the attribute form is sorted by defaul t whenviewed in the Data Explorer. From the drop-down l ist, you can choose from



Ascending, Descending, or None. The Data Explorer is discussed inHierarchy browsing, page 402.

Additional examples on how you can use the Report Sort and Browse Sortoptions to display attribute information are provided in Using attributes tobrowse and report on data, page 318 .

Geographical Role: Defines how the attribute form can be used asgeographical data with various MicroStrategy mapping features. Whenusing Data Import, this type of geographical information can beautomatical ly detected. For detai ls on how Data Import is able to assigngeographical roles to your data, see Strategies to include supplementaldata in a project, page 77.

Shape File: Defines the shapes used to display the attribute form onvarious MicroStrategy mapping features. For detai ls on using shape fi les todefine the display of attribute forms as part of the Image Layout widget,refer to the Dashboards and Widgets Creation Guide.

Supports Multiple Languages: Defines whether the attribute form'sinformation can be displayed in multiple languages using datainternational ization. For information on defining attribute forms to al lowdata to be displayed in multiple languages, see Supporting datainternational ization for attribute elements, page 267.

Default sorting of multiple attribute forms on reports

When creating attribute forms, you can define the defaul t sort order for eachattribute form on a report by selecting a Report Sort option as described inDisplaying forms: Attribute form properties, page 272 above.

If you define multiple attribute forms of an attribute wi th ascending ordescending sort orders, the fi rst attribute form with a defaul t sort order isused to sort the attribute on the report. If the fi rst attribute form with adefaul t sort order is not included on a report, then the second attribute formwith a defaul t sort order is used for sorting, and so on.


https://www2.microstrategy.com/producthelp/2020/DashboardsWidgets/WebHelp/Lang_1033/index.htm


For example, the Customer attribute in the MicroStrategy Tutorial projecthas the five attribute forms shown below:

Of these five attribute forms, only Last Name has a defaul t report sort orderdefined. Modi fy the Address form so that i t has a descending report sortorder. If you include Customer on a report wi th both Last Name andAddress, customers are sorted by their Last Name in ascending order. Thisis because Last Name was created fi rst and therefore is considered forsorting before the Address form. If you remove the Last Name form from thereport, customers are sorted by their address in descending order.

This is the defaul t functional i ty for how attributes are sorted by theirattribute forms on reports. It is important to note that you can change howattribute forms are sorted from within a report. In a report you can useadvanced sorting to define how attribute forms, metrics, and other reportobjects are sorted. Sorting defined for a report takes precedence overdefaul t sorting defined for attribute forms. For more information onadvanced sorting, refer to the Advanced Reporting Guide.

Attribute form expressionsAttributes act l ike holders of information and provide context for fact data.For example, the Customer attribute holds information about the customersuch as Name and Address. These information uni ts are cal led attributeforms. An attribute form expression defines what columns in the warehouseare used to represent the attribute form in SQL. Each attribute form musthave at least one expression.

For example, the form expression for the Customer First Name attributeform is CUST_FIRST_NAME . The form expression for the Customer Last




Name attribute form is CUST_LAST_NAME . In this instance, the CUST_

FIRST_NAME and CUST_LAST_NAME columns in the warehouse provideinformation about fi rst and last names respectively.

Al though you can have multiple expressions in di fferent tables, a formcannot have two di fferent expressions in the same source table.

You can create expressions using attribute columns, constants, and/ormathematical operators, for example, +, -, /, *. Only impl ici t attributes do notinclude a column in the expression, since they only use the constants youdeclare.

You can also create a form expression using Apply functions. Thesefunctions are discussed in the Functions Reference.

The types of attribute form expressions are:

Simple expressions, page 276: Simple form expressions access datathrough columns in the data warehouse.

Derived expressions, page 278: Derived form expressions perform sometype of mathematical calculation on columns in the data warehouse tocreate an attribute form.

Joining dissimi lar column names: Heterogeneous mappings, page 281:Heterogeneous mappings al low you to use columns with di fferent names inthe data warehouse as the same attribute form.

Impl ici t expressions, page 284: Impl ici t form expressions do not relatedirectly to data stored in the data warehouse. These form expressionscreate virtual data by combining or using columns to generate the data.

Simple expressions

A simple expression is based on a single warehouse column. The defini tionof the simple expression includes the tables in which the column is found.

For example, Category is an attribute in the MicroStrategy Tutorial . It hastwo forms, ID and Description, both of which are defined by simple




expressions. The expression for the ID form is the CATEGORY_ID columnand the expression for the description form is the CATEGORY_DESC column.Both of these columns reside in the table LU_CATEGORY .

Example: creating an attribute form with a simple expression

A retai ler begins a promotion that offers customers 25% off of theirpurchases i f they fi l l out a feedback survey on the company websi te. Theretai ler intends to analyze the data gathered from the surveys to bettermarket their products in the future.

The retai ler's customers provide a variety of information on the surveys,including their dates of bi rth. Once gathered, the date of bi rth dataeventual ly becomes part of the retai ler's data warehouse and theappropriate lookup table is added to the retai ler's project in MicroStrategy.

At this point, the project designer must add the column containing thecustomer dates of bi rth as an addi tional attribute form of the Customerattribute. This wi l l enable report designers to display each customer's dateof bi rth alongside each customer's name on reports.

Fol low the procedure below to create Customer Birth Date as an attributeform in the Customer attribute.

You can also use Archi tect to create an attribute form with a simpleexpression, as described in Creating attributes, page 169.

To create an attribute form with a simple expression

In MicroStrategy Developer, log in to the project source that contains theMicroStrategy Tutorial project and then log in to MicroStrategy Tutorial .

Navigate to the Schema Objects folder, open the Attributes folder, andthen the Customers folder.

Double-cl ick the Customer attribute. If a message is displayed asking i fyou want to use read only mode or edi t mode, select Edit and cl ick OK to



open the Attribute Edi tor in edi t mode so that you can make changes to theattribute. The Attribute Edi tor opens.



Click New. The Create New Form Expression dialog box opens.

From the Source table drop-down l ist, select the LU_CUSTOMER table.This is the table that contains customers' dates of bi rth.

Double-cl ick the CUST_BIRTHDATE column to add i t to the Formexpression pane on the right. The mapping method is selected asAutomatic by defaul t.


In the Form general information area, in the Name field, type CustomerBirth Date.

From the Category used drop-down l ist, select DATE since Customer BirthDate is nei ther the ID form of Customer nor the primary description form.

Cl ick OK . The new Customer Birth Date attribute form is added to theAttribute form pane in the Attribute Edi tor.

Because this is only an example, close the Attribute Edi tor wi thout savingyour changes.

Derived expressions

Derived expressions are created using a combination of warehousecolumns, mathematical operators, functions, and constants. Whi le simple



expressions have their value determined by just one column in awarehouse table, derived expressions are defined using one or morecolumns as wel l as other operators and values. Any operation on a column(such as adding a constant, adding another column, or setting theexpression to be an absolute value) creates a derived expression.

For example, you can create a derived attribute to calculate age oranniversaries. By calculating the di fference between the columns Date ofBirth and Current Date, you can create an attribute to hold the age of acustomer or an employee that has been derived from the two columns. Bycreating an attribute to calculate age in this manner, the attribute's value isautomatical ly updated as the age changes. If you created an attribute forage in which you included a constant number, the attribute would need tobe updated every time a customer or an employee has a birthday.

Example: creating an attribute form with a derived expression

In your database, you store Customer names in two di fferent columns,CUST_FIRST_NAME and CUST_LAST_NAME . However, you want reports todisplay a customer's fi rst name and last name together as a single entry ona report. You can achieve this using a derived form expression Name,which consists of the two strings. Using the Customer attribute, the syntaxof the derived expression for Name reads:

CUST_FIRST_NAME + " " + CUST_LAST_NAME

On a report, this information is displayed as Mary Jones under the Namecolumn. As another example, you could create a derived expression forName in the format of Last Name, First Name using the fol lowing syntax:

CUST_LAST_NAME + ", " + CUST_FIRST_NAME

Using this expression, the information is displayed as Jones, Mary underthe Name column.

Calculations and functions used in a derived expression can assist in deriv ingdata from the database, but you must make sure you use expressions that



meet the requirements of your database-specific SQL syntax. If you usesyntax that is not supported by your database or other data source, the SQLquery and resulting report can fail.

You can also use Archi tect to create an attribute form with a derivedexpression, as described in Prerequisi tes, page 184.

To create an attribute form with a derived expression


Navigate to the Schema Objects folder, open the Attributes folder, andthen the Customers folder.

Double-cl ick the Customer attribute. If a message is displayed asking i fyou want to use read only mode or edi t mode, select Edit and cl ick OK toopen the Attribute Edi tor in edi t mode so that you can make changes to theattribute. The Attribute Edi tor opens.




From the Source table drop-down l ist, select the LU_CUSTOMER table.This is the table that contains customers' fi rst and last names.

Double-cl ick the CUST_LAST_NAME column to add i t to the Formexpression pane on the right.



In the Form expression pane, place the cursor to the right of [CUST_LAST_NAME] and type + ", " +.

Double-cl ick the CUST_FIRST_NAME column to add i t to the Formexpression pane on the right. Your expression should be defined as shownbelow.



In the Form general information area, in the Name field, type Last Name,First Name.

From the Category used drop-down l ist, select None since Last Name,First Name is nei ther the ID form of Customer nor the primary descriptionform.

Cl ick OK . The new attribute form is added to the Attribute form pane in theAttribute Edi tor.


Joining dissimilar column names: Heterogeneous mappings

Heterogeneous mappingal lows Intel l igence Server to perform joins ondissimi lar column names. If you define more than one expression for agiven form, heterogeneous mapping automatical ly occurs when tables andcolumn names require i t.



Because di fferent source systems may store information in various contexts,your company may have multiple columns in di fferent tables that al lrepresent the same business concept. For example, in the MicroStrategyTutorial , the ID form of the attribute Day contains two expressions. TheDay_Date column occurs in the LU_DATE table and the Order_Date

column occurs in the ORDER_DETAIL and ORDER_FACT tables.

In the above example, you can use heterogeneous mapping to map the Dayattribute to al l of the columns in the data warehouse that represent thesame concept of Day. You can map Order_Date and Day_Date to theDay attribute. This ensures that both columns are used when informationabout the Day attribute is displayed on a report.

Each expression is l inked to a set of source tables that contain the columnsused in the expression. Of al l the tables in which the columns exist, you canselect as many or as few as you want to be used as part of the attribute'sdefini tion.

In the Attribute Editor, you can view the chosen tables in the source Tablesarea to the right of the Form Expressions area.

The data types of columns used in a heterogeneous mapping for a givenattribute must be identical or s imilar enough for your particular RDBMS to jointhem properly. For example, most databases cannot join a data type of Text toa data type of Number. However, depending on your database platform, youmight be able to join columns with data types of Number and Integer.

You can also use Archi tect to create an attribute form with a heterogeneouscolumn mapping, as described in Prerequisi tes, page 184.

To create an attribute form with a heterogeneous column mapping




Navigate to the Schema Objects folder, open the Attributes folder, andthen the Time folder.

Double-cl ick the Day attribute. If a message is displayed asking i f you wantto use read only mode or edi t mode, select Edit and cl ick OK to open theAttribute Edi tor in edi t mode so that you can make changes to the attribute.The Attribute Edi tor opens.




From the Source table drop-down l ist, select the LU_DAY table.

Double-cl ick the DAY_DATE column to add i t to the Form expression paneon the right. The mapping method is selected as Automatic by defaul t.


Cl ick New. The Create New Form Expression dialog box opens.


Double-cl ick the ORDER_DATE column to add i t to the Form expressionpane on the right. The mapping method is selected as Automatic bydefaul t.


Notice that there are now two expressions for the attribute formdefini tion, both of which use di fferent tables as the source of theirinformation. You could continue this process to add as manyheterogeneous columns as part of one attribute form as necessary.



In the Form general information area, in the Name field, type DateExample.

From the Category used drop-down l ist, select None since this is simplyan example scenario.

Cl ick OK . The new Date Example attribute form is added to the Attributeform pane in the Attribute Edi tor.


Implicit expressions

While most attributes map directly to one or more physical columns in thewarehouse, an impl ici t attribute is a virtual or constant attribute that doesnot physical ly exist in the warehouse. Such an attribute has an impl ici texpression, which is a constant value, al though nothing is saved in anactual column. Impl ici t expressions are not defined by column names; theyare defined by constants that you speci fy. Any constant is acceptable, forexample, RushOrder="Yes". Some attribute defini tions can be impl ied bythe existence of a row in a certain table, rather than being defined in termsof columns. Impl ici t attributes are useful in analyzing and retrievingrelevant information.

Implic it attributes are not commonly used, but are useful in special cases suchas the scenario described below.

For example, the Rush Order attribute in MicroStrategy Tutorial is anexample of an impl ici t attribute. This attribute can be used to display whichorders are rush orders so you can better keep track of your shipments.

The Rush Order attribute is defined by the impl ici t expression "Y", whichstands for Yes. This impl ici t expression is based on an order's existence inthe RUSH_ORDER table, rather than being based on a column in a table.This is shown in the image below, which shows the RUSH_ORDER table and



the ORDER_FACT table, the latter being the lookup table for the Orderattribute.

The ORDER_FACT table includes more schema objects than are shownbelow, which are hidden as they are not important to this example.

In the RUSH_ORDER table shown above, the Order attribute and the RushCharge fact both display the table column that they use for theirexpressions. You can identi fy Rush Order as an impl ici t attribute because i thas no associated table column to define i ts impl ici t expression.

The Tutorial project also includes a Rush Orders by Cal l Center report,which displays the Rush Order attribute on a report. For each order that is arush order, a "Y" is displayed in the Rush Order column, as shown below.



In the report shown above, the Rush Charge is also displayed to showaddi tional shipping costs that were charged to send the order as a rushorder.

Modifying attribute data types: Column aliasesA column al ias is a new data type that you can speci fy in place of thedefaul t data type for a given attribute form. Column al iases al low you tospeci fy a more appropriate data type that can help avoid errors in your SQL.

They can also help you take more advantage of the data in your datawarehouse. For attributes, a column al ias performs the same function as i tdoes for facts. By defaul t, the data type for an attribute form is inheri tedfrom the data type of the column on which the form is defined. Thisinheri tance is governed by MicroStrategy, which attempts to use a data typeas simi lar as possible to the data type in your database or other data source(see Appendix C, Data Types for more information on how MicroStrategyselects a matching data type). However, there are cases where you mayneed to change the data type. The fol lowing are some examples of suchcases.



In your data warehouse you have a lookup table for an Accounts attributewhere the ID is Account Number and the ID is stored in the database asDECIMAL(18, 0). Because this column stores high-precision values, youmust modi fy the column al ias for the attribute form and map i t to a specialdata type, Big Decimal . By doing so, the precision can be preserved whenperforming fi l tering, dri l l ing, or page-by on the Account attribute.

Another example could be a case in which your warehouse does not have alookup table for year information, but you would l ike to create a Yearattribute. Many database platforms have functions that can extract parts of adate from a Date data type. For example, SQL Server has a Year functionthat extracts just the year from a date. In such a case, you can create aYear attribute using the fol lowing form expression:

ApplySimple("Year(#0)",[Date_Id])

The ApplySimple expression above is syntactically correct for SQLServer. However, depending on your database or data source type, you mayneed to use a different syntax.

The data type for this attribute is automatical ly set to a Date data type. Thisis because Date_ID is a Date data type. However, the resul t of theApplySimple calculation is an integer value that represents a given year,such as 2011.

When a temporary SQL table is created, i f you do not change the data typeof the column al ias, the system uses a Date data type and tries to insertinteger data into this column. Whi le this does not create a problem in al ldatabase platforms, some databases wi l l return an error. To avoid thepossibi l i ty of an error due to confl icting data types, modi fy the column al iasfor the attribute form and change the defaul t Date data type to an Integerdata type.

In addi tion to speci fying the data type to be used for an attribute form, thecolumn al ias also lets you speci fy the column al ias name to be used in theSQL generated by MicroStrategy. When you create a form expression using



a custom expression or mul tiple columns (as discussed in Attribute formexpressions, page 275), the column al ias for the attribute form defaul ts toCustCol (or CustCol_1 , CustCol_2 , and so on). The fol lowing piece ofSQL shows, in bold, where the column al ias name is used:

SELECT Year(a12.Date_Id) CustCol_1,

sum(a11.Tot_Dollar_Sales) WJXBFS1

FROM YR_CATEGORY_SLS a11

cross join TRANS_DATE_LW_LY a12

GROUP BY Year(a12.Date_Id)

While the column al ias name does not affect the actual resul ts or yourreport, you can change the column al ias name to be more meaningful . Theabove example is a simple one, but this can be useful for troubleshootingthe SQL for a particularly complex report.

You can use the Attribute Edi tor to create column al iases. You can also useArchi tect to create column al iases, as described in Prerequisi tes, page 184.

Prerequisi te

This procedure assumes you have already created an attribute wi th a val idattribute expression for which to create a new column al ias.

To create a column alias for an attribute

In MicroStrategy Developer, log in to the project source that contains theattribute to create a new column al ias for.

Right-cl ick the attribute and select Edit. If a message is displayed asking i fyou want to use read only mode or edi t mode, select Edit and cl ick OK toopen the Attribute Edi tor in edi t mode so that you can make changes to theattribute. The Attribute Edi tor opens.

If you are only given the option of opening the Attribute Editor in read onlymode, this means another user is modify ing the project's schema. You cannotopen the Attribute Editor in edit mode until the other user is finished with their



changes and the schema is unlocked.


Select an attribute form and cl ick Modify. The Modi fy Attribute Form dialogbox opens.


In the Column al ias area, cl ick Modify. The Column Edi tor - ColumnSelection dialog box opens.



Column name: The name for the column al ias which is used in any SQLstatements which include the attribute form column.

Data type: The data type for the attribute form. For a description of thedi fferent data types supported by MicroStrategy, see Appendix C, DataTypes.

Depending on the data type selected, you can speci fy the byte length, bi tlength, precision, scale, or time scale for your column al ias.


Cl ick OK to save your changes and return to the Attribute Edi tor.

Select Save and Close to save your changes.

Attribute forms versus separate attributesAttribute forms can be considered as addi tional descriptions for anattribute, whereas attributes themselves can be considered as reportelements or group-by elements that have a one-to-many or a many-to-many



relationship wi th other attributes. The data that you map to attributes can berepresented as separate attributes or as an attribute form of an attribute.

In general , you should map data to an attribute form rather than a separateattribute i f:

There is a one-to-one relationship between an attribute and the data.

You do not group by the data.

The decision to model data as an attribute form for a given attribute or as aseparate attribute is usual ly determined during the logical data model ingphase of project design. For more information on whether to model data asan attribute form or as a separate attribute, see Attribute forms, page 39.

Attribute relationships

After you have created attributes for your project, you can define attributerelationships to define how the engine generates SQL, how tables andcolumns are joined and used, and which tables are related to other tables.

You l ink directly related attributes to each other by defining parent-chi ldrelationships, as explained in Attribute relationships, page 27. Attributeelements, or the actual data values for an attribute, dictate the relationshipsthat you define between attributes.

The parent-child relationships you create determine the system hierarchywithin the project.

The impl ications of whether attributes are related become clear when youbegin bui lding reports. You can run a report wi th two attributes that arerelated without any problems. For example, i t is easy to include Countryand City, on a report together. A report wi th two unrelated attributes,however, must include a metric based on a fact that is on or below the levelof the two attributes, or else a Cartesian join occurs, which is general ly



undesirable. A Cartesian join, or cross join, is very database intensive asevery row in one table is joined to every row in the other table.

In MicroStrategy Developer, you can define relationships for the attributesin your project. This step is covered in Simul taneously creating multipleattributes, page 252, as part of the ini tial project design effort and inViewing and edi ting the parents and chi ldren of attributes, page 293, after aproject has already been created.

Attributes can be ei ther related or unrelated to one another:

Related : A parent-chi ld relationship is defined between two or more relatedattributes. The relationship is defined through the attribute's lookup table ora relationship table.

Four types of di rect relationships can exist between related attributes,and these relationships are defined by the attribute elements that existin the related attributes. Each type is described below:

One-to-one: Each element in the parent attribute corresponds to one andonly one element in the chi ld attribute, and each chi ld attribute correspondsto one and only one element in the parent attribute. A common example of aone-to-one relationship is ci tizen and taxpayer ID. A ci tizen can have onlyone taxpayer ID and a taxpayer ID can be assigned to only one ci tizen.

One-to-many: Each element in the parent attribute corresponds to one ormore elements in the chi ld attribute, and each chi ld attribute corresponds toone and only one element in the parent attribute. These are the mostcommon types of attribute relationships. Year has a one-to-manyrelationship to quarter. One year has many quarters, but a speci fic quartercan be in one year only. This assumes that quarters are defined with anaccompanying year such as Q4 2006, Q1 2007, and so on.

Many-to-one: Each element in the parent attribute corresponds to one andonly one element in the chi ld attribute, and each chi ld attribute correspondsto one or more elements in the parent attribute. Many-to-one relationshipsare the same type of relationship as a one-to-many, but i t is defined from a



di fferent perspective. For example, year is described above as having aone-to-many relationship to quarter. This means that quarter has a many-to-one relationship to year.

Many-to-many: Each element in the parent attribute can have multiplechi ldren and each chi ld element in the chi ld attribute can have multipleparents. In banking, customers and accounts are an example of a many-to-many relationship. One customer may have many accounts, and eachaccount may be associated with many customers, such as in the case of ajoint checking account.

Attributes can also be related to other attributes through a chain ofattribute relationships. Attributes of this type are often in the samehierarchy. For example, a Geography hierarchy contains the attributesCustomer Region, Customer State, and Customer Ci ty:

In this scenario, Customer Region and Customer State are directlyrelated to each other and Customer State and Customer Ci ty also have adirect relationship. Whi le Customer Ci ty is not di rectly related toCustomer Region, these two attributes are related through CustomerState. This al lows you to include Customer Region and Customer Ci tyon a report and view the di fferent customer ci ties for each customerregion.

Unrelated : No parent-chi ld relationship has been defined and the attributesare not related through a chain of attribute relationships. No relationship ispresent in the lookup tables or relationship tables for these attributes.Unrelated attributes can exist together in fact tables, giving context to thefact. For example, the Customer and Day attributes have no relationship toone another. A particular customer and a particular day only make sensetogether i f a fact is associated with that combination. For example, a certaincustomer, Don Addison, spent $2,500 on January 5, 2003 on behal f of the



heal th care company in which he works. In this case, care must be takenwhen using unrelated attributes on a single report. In general , however,these attributes are relatively straightforward to deal wi th from a projectdesign perspective.

Viewing and editing the parents and children of attributesThe relationships that exist between attributes rely on the parent-chi ldspeci fications that you assign to attributes. How attributes relate to oneanother and the types of relationships they share define the systemhierarchy which is used to generate SQL. This SQL, in turn, determines theoutput of a report.

Parent-chi ld relationships were designated when attributes were selectedfor the new project. However, you can continue to make changes to therelationships between attributes even after creating your project.

For example, the Distribution Center attribute is the parent of the Cal lCenter attribute. A one-to-one relationship exists between DistributionCenter and Cal l Center. This means that only one cal l center exists in eachdistribution center. Country, in turn, is the parent of Distribution Center andmultiple distribution centers exist in each country. So these two attributeshave a one-to-many relationship.

Assigning parent-chi ld relationships to attributes al lows you to connectattributes to one another in user hierarchies, as discussed in CreatingHierarchies to Organize and Browse Attributes, page 385. Also, when areport generates inaccurate SQL and resul ts, viewing and changing parent-chi ld relationships may be a necessary troubleshooting method.

Fol low the procedure below to view and edi t the parents and chi ldren of theDistribution Center attribute.

You can also use Archi tect to define relationships between attributes.Archi tect can provide a more intui tive and helpful workflow that al lows youto view and modi fy mul tiple attributes as you define attribute relationships,as described in Defining attribute relationships, page 194.



To view and edit the parents and children of an attribute


Navigate to the Schema Objects folder, open the Attributes folder, andthen the Geography folder.

Double-cl ick the Distribution Center attribute. If a message is displayedasking i f you want to use read only mode or edi t mode, select Edit and cl ickOK to open the Attribute Edi tor in edi t mode so that you can make changesto the attribute. The Attribute Edi tor opens.



Click the Children tab. The Cal l Center attribute is l isted, along with therelationship type i t shares with Distribution Center, and the relationshiptable in which the relationship exists.

Consider a scenario in which multiple cal l centers now exist in the samedistribution center so they no longer have a one-to-one relationship; inthis case, you must change the relationship type between Cal l Centerand Distribution Center.

To change the relationship type, select One to Many from the Relationshiptype drop-down l ist.

You also want the relationship between the two attributes to be defined inthe LU_Employee table instead of the LU_Call_Ctr table in which i t is



defined now. To change the relationship table, select the LU_Employeetable from the Relationship table drop-down l ist.

Cl ick the Parents tab. The Country attribute is l isted, along with therelationship type i t shares with Distribution Center, and the relationshiptable in which the relationship exists.

From this Parents tab, you can view or modi fy the existing parentattribute relationships, as wel l as create or delete new parent attributerelationships.

Because this is only an example, close the Distribution Center attributewi thout saving your changes.

Supporting many-to-many and joint child relationshipsTwo forms of attribute relationships, many-to-many relationships and jointchi ld relationships, can introduce addi tional complexi ty to the schema andwarehouse design process. The fol lowing sections discuss theconsiderations you must make to ensure an effective warehouse design inl ight of the unique nature of these relationships.

Whi le the topics are largely related to logical model design, a workingknowledge of physical schemas is helpful when deal ing with the chal lengesinvolved with these topics.

Before reading this section, you should know what logical data models andphysical warehouse schemas are, and how to read and interpret them.Logical data models and physical warehouse schemas are discussed inChapter 2, The Logical Data Model and Chapter 3, Warehouse Structure forYour Logical Data Model respectively. These chapters discuss how to planand create a conceptual framework for your business intel l igence data.

Many-to-many relationships

The presence of many-to-many relationships introduces complexi ty duringthe warehouse design process. With the presence of many-to-many



relationships, you must make addi tional considerations to effectively planyour design.

Below are some real-l i fe examples of many-to-many relationships whichmust be careful ly handled in the data model and schema:

In a certain organization, each salesperson can work in more than onecal l ing center. Likewise, each cal l ing center has many salespeople.

In a car manufacturing plant, many models of cars are produced, and eachcomes in several colors. That is, there are many colors for a single type ofcar, and many types of cars can be associated with the same color.

The fol lowing sections use the example of i tems and colors to demonstratea many-to-many relationship and the options you have for deal ing withthem. One i tem can come in many colors, such as red hats, blue hats, andgreen hats, and one color can be associated with many i tems, such as reddress, red hat, red shoes, and red socks.

Potential problems with many-to-many relationships usual ly come in thefol lowing forms, both of which can be avoided by correctly model ing therelationship:

Loss of analytical capabi l i ty, page 296

Multiple counting, page 298

Loss of analytical capability

With the color and i tem many-to-many relationship, there are usual ly twobusiness questions for which users want answers:

In what colors are certain i tems avai lable?

How much of a particular i tem/color combination was sold?

Answering the fi rst question requires a table that contains a l ist of al lpossible i tem/color combinations. Recal l that one-to-many relationships areusual ly in the chi ld's lookup table.



In many-to-many relationships this is not feasible. Rather, a distinctrelationship table needs to be present in your warehouse. The fol lowingdiagram shows the lookup and relationship tables for i tem and color:

The Rel_Color_Item table provides a row for every possible i tem/colorcombination.

Answering the second question requires a fact table that has salesinformation as wel l as color and i tem information. The fol lowing diagramshows the same scenario as before, but in addi tion i t shows a simple facttable containing sales data keyed by i tem, color, and date.

The fact table in the above diagram alone is not suffic ient to answer the firstquestion. Only item and color combinations that were actually sold, andtherefore have sales recorded, can be retrieved from this table. If you haveitem and color combinations that are available but that have never been sold,



this fact table cannot provide a complete lis t of item and color combinations toanswer question one.

In summary, to prevent any loss of analytical flexibi l i ty when deal ing with amany-to-many attribute relationship, the fol lowing requirements must bemet:

A distinct relationship table to identi fy al l the possible combinations ofattribute elements between attributes

Both the attribute ID columns in the fact table

You can implement the above points in several di fferent ways, which arediscussed in Working with many-to-many relationships, page 300.

Multiple counting

When deal ing with many-to-many relationships, loss of analytical capabi l i tyis only one chal lenge. Another equal ly signi ficant issue is mul tiplecounting. Mul tiple counting occurs when al l of the fol lowing takes place:

You attempt to aggregate data to the level of one of the attributes in themany-to-many relationship, or a higher level than one of the attributes inthe many-to-many relationship.

The relationship exists in a distinct relationship table.

Al l of the attributes in the many-to-many relationship are not in the facttable.

Recal l the example from above, but make the fol lowing change: removecolor from the fact table.



Assume that there are three i tems, including hats, dresses, and socks.These i tems come in three colors, including red, blue, and green, wi th theexception of socks, which come in only green and blue. The fol lowingdiagram shows this data in the lookup tables as wel l as some simple salesdata:

The risk of mul tiple counting occurs when you run a query requesting thesales by color, effectively aggregating to the i tem attribute level in themany-to-many relationship. This query would require both the fact table,which has the sales information by i tem, and the relationship table, sincecolor is not recorded in the fact table.



The di fficul ty l ies in the fact that color is not in the fact table. There is noway to directly relate the sales of an i tem in the fact table to the color of thatparticular i tem. For example, instead of calculating the sales of red i tems,the query aggregates sales for al l i tems that come in red according to therelationship table. The sum includes al l hats and al l dresses, including blueones and green ones. This obviously leads to numbers that are higher thanthe true sales for red i tems.

For example, using the given data, the fol lowing questions cannot al l beanswered accurately:

What are the total sales for hats?

The answer is $35, which can be calculated directly from the fact table.

What are the total sales for red i tems?

You cannot determine an accurate answer. The answer you get is $85,which is the total for al l hats and dresses, since socks do not come inred. It is enti rely possible that al l the dresses sold are green; however,you cannot confi rm this since color is not recorded in the fact table.

What are the total sales for red dresses?

Again, you cannot determine an accurate answer. If al l the dresses soldare indeed green, the correct answer is $0, but the answer you wi l l getbased on the data in the fact table is $50.

The fol lowing section describes several ways to prevent mul tiple countingwhen deal ing with many-to-many relationships.

Working with many-to-many relationships

As you can see, seemingly simple questions can require you to take anumber of steps to answer them when many-to-many relationships areinvolved.

You can use one of three techniques to provide physical support to answerthe types of questions that cannot be answered accurately when using



many-to-many relationships. The three techniques al l have di ffering levelsof flexibi l i ty, and flexibi l i ty is always a trade-off wi th complexi ty. In al lcases, the two fundamental components remain in place in one form oranother:

A relationship table to define the attribute relationship

Both the attribute's ID columns in the fact table

MicroStrategy builds the rules that MicroStrategy SQL Engine uses togenerate SQL when a report request is made. If you make both of the abovephysical implementations, the SQL Engine uses the related table when nometric is included on the report. When a metric is included, the fact table isused to answer the query.

All of the following methods require additional data in the fact table. Thismeans that you must capture the additional data in the source system. Forexample, you need to have data in the source system as to what the color is ofeach item sold. If this additional data was never captured in the sourcesystem, you cannot fully resolve the many-to-many relationship to calculatethe amount of sales for items of a certain color.

Method 1

This method is the most straightforward way to effectively manage many-to-many relationships.

Method 1 requires you to create a separate relationship table (in this case,Rel_Color_Item ) and add both attribute IDs to the fact table as shown inthe fol lowing diagram.



Method 2

Method 2 el iminates the many-to-many relationship and the need for adistinct relationship table.

Here the many-to-many relationship is converted into a compound attributerelationship. You treat one attribute as a chi ld of the other and have acompound key for the lower level attribute. Also, you add both attribute IDs,in this case Item_ID and Color_ID , to the fact table as shown in thefol lowing diagram.

Whi le this method el iminates the need for a separate relationship table, youlose the abi l i ty to view i tems independent of color, or vice versa.

Method 3

Method 3 is the most versati le solution and has the fol lowingcharacteristics:



Further simpl i fies the compound attribute relationship from Method 2 into asimple attribute relationship

Provides the abi l i ty to view i tem and color together or independently

Requires only one attribute column in the fact table for complete flexibi l i ty,rather than two

Here you must create a new attribute, lower in level than ei ther Color orItem. This attribute is essential ly a concatenation of Color and Item, whichgives i t a one-to-many relationship between i tsel f and each of i ts parentattributes. This is the SKU attribute, particularly common in retai l datamodels or si tuations.

Final ly, rather than including Color and Item in the fact table, you only needto include this new chi ld attribute SKU, as shown in the fol lowing diagram.

This method is actual ly qui te simi lar to Method 1. The major di fference isthat the distinct relationship table from Method 1 has an addi tional column,SKU, which extends the relationship of each i tem and color combinationinto a single value. Consequently, you can use this single value in the facttable.

The major disadvantage of Method 3 l ies in creating the new attribute i fyour business model does not al ready use a simi lar structure, as wel l aspossibly adding complexi ty to the ETL process.



Joint child relationshipsSome attributes exist at the intersection of other indirectly relatedattributes. Such attributes are cal led joint chi ldren.

Joint chi ld relationships connect special attributes that are sometimescal led cross-dimensional attributes, text facts, or qual i ties. They do not fi tneatly into the model ing schemes you have learned about thus far. Theserelationships can be modeled and conceptual ized l ike tradi tional attributesbut, l ike facts, they exist at the intersection of mul tiple attribute levels.

Many source systems refer to these special attributes as flags. Therefore, ifflags are referenced in your source system documentation, these are likelycandidates for joint child relationships.

Joint chi ld relationships are real ly another type of many-to-manyrelationship where one attribute has a many-to-many relationship to twootherwise unrelated attributes. For example, consider the relationshipbetween three attributes: Promotion, Item, and Quarter. In this case,Promotion has a many-to-many relationship to both Item and Quarter, asshown in the fol lowing diagram.

An example of a promotion might be a "Red Sale" where al l red i tems areon sale. A business might run this promotion around Valentine's Day andagain at Christmas time.



Supporting joint child relationships

One way to resolve a many-to-many relationship is to have a relationshiptable for the attributes involved in the many-to-many relationships. In thiscase, you might create two relationship tables, one to relate Promotion andItem. The second relates Promotion and Quarter as shown in the fol lowingdiagram.

These two tables are sufficient to answer questions such as:

What i tems have been in what promotions?

What quarters have had what promotions?

However, these tables are not sufficient to answer the fol lowing moredetai led and insightful questions:

What i tems were in what promotions in a given quarter?

In what quarters was a certain i tem involved in a certain type of promotion?

To answer these questions, you must combine the two relationship tables,creating one table to relate al l three attributes.

The relationship in the distinct relationship table must exist for a joint childrelationship to be properly defined. However, it does not necessarily have tobe in its own, distinct relationship table. Defining the relationship directly in the



lookup table for the parent of the joint child—in this case, Promotion—would befine. Alternatively, you can build the relationship directly into the fact table.

In these examples, i t is important to notice the relationship between thethree attributes. The Promotion attribute is related to a particular Item-Quarter pair, as opposed to i t being related to Item and Quarter separately.This is the essence of a joint chi ld relationship and is shown in thefol lowing diagram.

Notice that a joint child relationship can be one-to-many or many-to-many. Theissues with many-to-many relationships, including loss of analytical capabilityand multiple counting, also apply to many-to-many joint child relationships.

If you have a joint chi ld relationship in your data, i t is important for you todefine i t in MicroStrategy so that you get the correct data for reports thatuse the parent attribute in a joint chi ld attribute. This ensures that when youneed to join the fact table to the parent attribute of a joint chi ld relationship(for example, to see sales by promotion) the join wi l l always use both jointchi ldren rather than just one or the other.



Attributes that use the same lookup table: Attributeroles

Attribute roles al low you to use the same data to define and support twoseparate attributes. Suppose you define two attributes that have the samedata defini tion but play di fferent roles in your business model . For example,in the fol lowing image, notice that the attributes Origin Airport andDestination Airport are defined using the same lookup table, LU_AIRPORT ,and column, AIRPORT_ID .

Al though i t makes sense to see JFK as ei ther an origin or destinationairport on a report, i t is understood that destination airport data di ffers fromorigin airport data. You need to support the logical concepts of an originairport and a destination airport, but you do not want to create two separatelookup tables with identical data. Creating two separate lookup tableswould create redundancy, and thus take up more storage space and beharder to maintain.



When multiple attributes are defined using the same lookup table andcolumn, the attributes are essential ly playing di fferent attribute roles. Howan attribute plays multiple roles depends on the speci fic attribute.

The Origin Airport and Destination Airport attributes share the sameattribute forms, or various aspects about them, such as description,location, and so on. In the fact table, however, a separate column exists foreach of their roles; the fact columns are ORIGIN_AIRPORT_ID andDESTINATION_AIRPORT_ID , as shown below.

If a report designer places both the Origin Airport and Destination Airportattributes on a report to obtain the number of fl ights that originated from MIAand arrived at LGA, an empty resul t set is returned. This occurs becausethe SQL statement tries to obtain the description of an airport that is bothMIA and LGA at the same time (Airport_ID = "MIA" AND Airport_ID ="LGA").

If you identi fy that one of your attributes needs to play multiple roles, youmust create an attribute in the logical model for each of the roles, asexplained in Speci fying attribute roles, page 309. This ensures that a reportwi th attributes playing multiple roles returns correct data.

In the fol lowing diagram, State is another example of an attribute that canhave two roles since i t relates to both the Vendor and Store attributes. Inone case, i t refers to the location of a vendor. In the other, i t refers to the



location of a store. The State attribute is therefore said to be playing tworoles.

In an OLTP system, roles are most often implemented as a single table, asshown in the above diagram. In the data warehouse, a query involving bothVendor State and Store State needs to use the State table twice in thesame query. For example, a report is created to display vendors fromArkansas who sold to New York stores. The resul ts may be blank i f the datawarehouse structure was set up incorrectly. The SQL statement tries toobtain the description of a state that is both Arkansas and New Yorksimul taneously, generating the empty resul t set.

Specifying attribute rolesTo see both roles on the same report, you must treat them as di fferentattributes. That is, they must have di fferent attribute names. To createunique attributes, you have the fol lowing options:

Automatic attribute role recognition , where you create multiple attributesthat have the same lookup table and al low MicroStrategy to automatical lydetect the multiple roles. Automatic recogni tion is enabled by the VLDBproperty Engine Attribute Role Options at the database instance level . Formore information on VLDB properties, refer to the Supplemental Referencefor System Administration.



Explicit table aliasing , where you create multiple logical tables pointing tothe same physical table and define those two logical tables as the lookuptables for the two attributes.

In a MicroStrategy project in which automatic attribute role recognition isenabled (meaning that the database instance-level VLDB property, EngineAttribute Role Options, is enabled), you can have a maximum of 99 attributesdefined on the same column of the same lookup table. If you create more thanthis number of attributes, you encounter an error, and are unable to update theproject schema or restart Intelligence Server.

Table al iasing provides advanced users wi th more control . If you areupgrading or have a very complex schema, i t may be the better al ternative.If you are new to MicroStrategy, however, i t is easier to use automaticattribute role recogni tion. MicroStrategy recommends that you takeadvantage of automatic role recogni tion i f you do not know the detai ls of themodel ing logic or the database.

Automatic recognition does not work if the attributes are in the same hierarchy,meaning that a child attribute is shared. For example, in the State exampleprovided above, the two State attributes do not have a common child attribute.

In summary, i f you identi fy that any one of your attributes needs to playmultiple roles, an attribute must be created in the logical model for each ofthe roles. Remember this rule to help you identi fy attribute roles: If you wantto see the same attribute multiple times on one report, as Ship Month andOrder Month, for example, the attribute has multiple roles. In this example,Month is the attribute that has multiple roles. You can use ei ther automaticattribute role recogni tion or expl ici t table al iasing to create the attributeroles.

Using automatic attribute role recognition

In the data warehouse, a query involving both Vendor State and Store Stateneeds to use the State table twice in the same query to get correct resul ts.



You can set up two attributes, Store State and Vendor State, both of whichuse the same lookup table. The resul ting SQL code contains a sel f-join wi ththe LU_State table. The logical model would look l ike the fol lowing:

Note that both roles for the State attribute are included in the logical modelso that "State" can be considered from two di fferent perspectives. Since thestate in which a vendor resides and the state in which one of the stores islocated are two di fferent things, the logical model must reflect that.Automatic recogni tion al lows these two attributes, Vendor State and StoreState, to access the same lookup table, using di fferent attribute names forthe same expression.

Automatic role recognition works only when the attributes use exactly thesame expression, which in most cases simply represents a column orcolumns in a lookup table.

Consider the fol lowing sample desired report:

In this case, the request is, "Show me total sales by Store State for al l myvendors in Arkansas (Store State ID = 15)." The same lookup table, LU_State , can be used for both attributes, Store State and Vendor State, i f



attribute roles are used. The two attributes refer to the same columns of thattable.

To use automatic attribute role recogni tion, you must select the EngineAttribute Role Options, found in the database instance-level VLDBProperties under Query Optimization. See the MicroStrategy DeveloperHelp (formerly the MicroStrategy Desktop Help) or the SystemAdministration Guide for steps to set this VLDB property.

Explicitly aliasing tables to specify attribute roles

Expl ici t table al iasing provides more robust functional i ty than automaticrecogni tion, so advanced users are encouraged to take advantage of thissolution.

An attribute such as State can play more than one role in the datawarehouse; i t can represent the Vendor State or the Store State. In thiscase, the State attribute is said to play two roles: i t refers to both thelocation of a vendor as wel l as the location of a store.

When you use expl ici t table al iasing to designate attributes that havemultiple roles, both roles for the State attribute are included in the logicalmodel so that State can be considered from two di fferent perspectives. Thelogical model would look l ike the fol lowing, just as i t would i f you usedautomatic recogni tion:





The di fference between automatic recogni tion and expl ici t table al iasing isthat when you use expl ici t table al iasing, you create separate lookup tablesin the schema, but point them each to the same physical table.

If you use expl ici t table al iasing for the Store attribute, one table (LU_STATE_STORE ) contains the attribute Store State whi le the other (LU_STATE_VENDOR ) contains Vendor State, as shown in the fol lowing diagram.

Consider the fol lowing sample desired report that should provide dataabout the total sales by Store State for al l vendors in Arkansas (Store StateID = 15):

When expl ici t table al iasing is used, the two lookup tables LU_STATE_

STORE and LU_STATE_VENDOR are used. Since they are just di fferentnames for the same physical table, the report accesses the same physicaltable, LU_STATE , for both state names, as shown by this sample SQL:

SELECT a12.State_Desc as State_Desc

SELECT a13.State_Desc as State_Desc

FROM LU_STATE a12

LU_STATE a13



When you create a table al ias, the selected table is copied, al lowing you torename a copy of the same table. When you are ready to create newattributes—as in the example discussed above—you can map theappropriate table to each attribute. In the case above, you would select theLU_STATE_STORE table for the Store State attribute and LU_STATE_

VENDOR for Vendor State.

Table aliases are one kind of logical table. For information about logical tables,refer to Appendix B, Logical Tables.

You can also use Archi tect to create attribute roles with expl ici t tableal iasing, as described in Prerequisi tes, page 184.

To create attribute roles with explicit table aliasing

This procedure provides steps to re-create the example of expl ici t tableal iasing described in this section. The LU_STATE table is not included inthe MicroStrategy Tutorial project. However, you can use the same high-level procedure and concepts as guidel ines to create attribute roles in yourproject setup.

In MicroStrategy Developer, log in to the project to create attribute roleswith expl ici t table al iasing.

Navigate to the Schema Objects folder, and then select the Tables folder.


Right-cl ick LU_STATE(1), select Rename, and rename the table as LU_STATE_STORE .


Right-cl ick LU_STATE(1), select Rename, and rename the table as LU_STATE_VENDOR .



Create the attributes

Select the Attributes folder.

From the File menu, select New, and then Attribute. The Create New FormExpression dialog box opens.

From the Source table drop-down l ist, select LU_STATE_STORE .

In the Available columns pane, double-cl ick STATE_ID , which identi fiesthe attribute role.

Select Manual mapping and cl ick OK . The Create New Attribute Formdialog box opens.

From the Source table drop-down l ist, select the same LU_STATE_STORE

table.

Cl ick OK . The Attribute Edi tor opens.

Cl ick New to create any other required attribute forms for the State Storeattribute, such as a description attribute form. You must make sure to mapany State Store attribute forms to columns from the LU_STATE_STORE

table.

Save the State Store attribute once you are finished mapping attribute formsto columns of the LU_STATE_STORE table.

Create a Vendor State attribute wi th the same sub-procedure (Create theattributes, page 315) used to create State Store above, except you must usethe LU_STATE_VENDOR table instead of the LU_STATE_STORE table.

Attributes with multiple ID columns: Compoundattributes

A compound attribute is an attribute wi th multiple columns speci fied as theID column. This impl ies that more than one ID column is needed to uniquelyidenti fy the elements of that attribute. General ly, you create a compound



attribute when your logical data model reflects that a compound keyrelationship is present. In the relational database, a compound key is aprimary key that consists of more than one database column.

For example, a retai l project has two attributes, Class and Item. Class is theparent of Item and has a one-to-many relationship wi th i t. The values in theItem_ID column do not uniquely identi fy an i tem. The i tem shirt has anItem_ID of 1. However, there are di fferent shirts, depending on the class,which includes men's, women's, and chi ldren's. Therefore, to uniquelyidenti fy a man's shirt, Item_ID and Class_ID must be grouped together,creating a compound attribute.

All of the ID forms of the compound attribute should be within the same lookuptable.

Example: Creating compound attributesYou must create a compound attributes when an attribute requires two ormore columns to uniquely identi fy i ts elements. In the MicroStrategyTutorial project, Distribution Center is an example of a compound attribute.To uniquely identi fy a distribution center, one must know two detai ls aboutthe distribution center: the ID of the distribution center and the country inwhich i t exists. This data is represented by the Dist_Ctr_ID andCountry_ID columns respectively. The same Distribution Centeridenti fication numbers can exist for di fferent distribution centers, but in thesame country, each distribution center has a unique identi fication number.

Therefore, both the Country_ID and Dist_Ctr_ID columns must begrouped together for the Distribution Center attribute. This ensures thatdata about distribution centers is displayed correctly and completely on areport. To support this functional i ty, a form group must be created. A formgroup is a grouping of attribute forms to create a compound attribute.

Fol low the procedure below to create the Distribution Center compoundattribute.



You can also use Archi tect to create compound attributes, as described inPrerequisi tes, page 184.

To create the Distribution Center compound attribute

In MicroStrategy Developer, log in to the project source that contains theMicroStrategy Tutorial project and then log into MicroStrategy Tutorial .


From the File menu, select New, and then Attribute. The Attribute Edi toropens, wi th the Create New Form Expression dialog box displayed on topof i t.

From the Source table drop-down l ist, select the LU_DIST_CTR table. Thisis the table in which the two ID columns of Distribution Center reside.

Double-cl ick the COUNTRY_ID column to add i t to the Form expressionpane on the right.

Select Automatic mapping and cl ick OK . The Create New Attribute Formdialog box opens.

In the Form general information area, in the Name field, type Country ID .

Keep al l other defaul ts, and cl ick OK .

In the Attribute Edi tor, cl ick New to create the other attribute ID form. Thisattribute form maps to the distribution center ID column necessary tocomplete the defini tion of the Distribution Center attribute.

Double-cl ick the DIST_CTR_ID column to add i t to the Form expressionpane on the right.

Select Automatic mapping and cl ick OK . The Create New Attribute Formdialog box opens.



In the Form general information area, in the Name field, type DistributionCenter ID .

In the Form category section, from the Category used drop-down l ist,select ID . Cl ick OK .

You must designate this attribute form as an ID column so that i t can becombined with the Country_ID form to create one unique identi fier IDfor the Distribution Center attribute.

Create a form group

A dialog box noti fies you that another form (in this case, COUNTRY_ID ) isal ready using the ID form category and that you must create a form group tocombine the two ID columns. Cl ick Yes. The Create New Attribute Formdialog box opens.

In the Name field, type Distribution Center and cl ick OK . The AttributeEdi tor opens, wi th the form group you created in the Attribute forms pane.

Because this is only an example, close the Distribution Center attributewi thout saving your changes.

If you create a compound attribute, you must update the schema to seeyour changes in the project. Close al l edi tors. Then, from the Schemamenu, select Update Schema.

Using attributes to browse and report on data

Once attributes are bui l t, they are used in two primary ways, browsing andreporting. Users browse through attributes to locate an attribute to use on areport, and users place an attribute on a report to display detai ls about theparticular attribute and how it relates to fact data. Each attribute can bedisplayed in a variety of forms so you must speci fy the defaul t display ofeach of the attributes in the project. You can do this on a report-by-reportbasis, but you sti l l must speci fy the global , or project-wide, defaul t for eachattribute.



You must choose a defaul t attribute display for browsing and another forreporting. Report display forms are the attribute forms that appear ascolumns in a completed report. Browse forms are the attribute forms thatappear as a user browses through the element l ist of an attribute in theData Explorer in a project. Therefore, browse forms identi fy attributeelements. This separation al lows for greater attribute display flexibi l i tydepending on the appl ication.

The browse forms of the attribute are also used to display the attributeelements in the prompt detai ls auto text code of a Report Servicesdocument. For information on creating Report Services documents, see theDocument Creation Guide.

When creating attributes, all forms are included as report display forms andbrowse forms by default. The only exception is if you create multiple attributeforms, the first form you create is not included as a report display or browseform.

An attribute's report display forms determine which attribute forms aredisplayed by defaul t when the report is executed. By selecting di fferentforms for the attribute, you select a di fferent set of values for display. Forexample, a report includes Region as an attribute. If ID is selected as theattribute form, the display could be a number such as four. If Description isselected as the attribute form, the display could be a name, such asNorthwest. If a report l ists the ci ties in which you have stores, then youmight choose to display the Long Description form, such as Chicago,instead of the URL attribute form, that is, www.chicago.com.

You can also select which attribute forms are retrieved with the reportresul ts but not displayed on the grid. These browse forms are found in theReport Objects pane. In Grid view, you can add the attribute forms in ReportObjects to the report wi thout re-executing the report. For example you caninclude a ci ties URL attribute form as a browse attribute form so that yourusers can choose to display the form on a report.

To modi fy the attribute forms displayed, you can:


https://www2.microstrategy.com/producthelp/2020/DocCreationGuide/WebHelp/Lang_1033/index.htm


Right-cl ick an attribute on a report or template and select the desiredattribute forms

From the Data menu, select Attribute Display to open the Attribute Displaydialog box

For steps to display attribute forms on a report or template, see the onl inehelp and the section below.

Defining how attribute forms are displayed by defaultYou can general ly display attribute forms in a number of ways. Forexample, the Distribution Center attribute in the MicroStrategy Tutorialconsists of an ID form group and a Description form. The ID form group ismade up of two separate ID columns, Country_ID and Dist_Ctr_ID .

Displayed on a report, the Dist_Ctr_ID form shows the identi ficationnumbers of speci fic distribution centers in the data warehouse. TheDescription form of Distribution Center, however, displays the actual nameof the Distribution Center such as "San Diego."

You can use the Attribute Edi tor to determine how the attribute forms aredisplayed on a report. In the case of the Distribution Center attribute, youcan speci fy whether the identi fication number of each distribution center,the distribution center names, or both are displayed. You can alsodetermine which attribute forms are displayed when browsing a project wi ththe Data Explorer.

Fol low the example procedure below to set one of the Distribution Centerattribute's forms to be displayed in reports and whi le browsing theMicroStrategy Tutorial project.

You can also use Archi tect to define how attribute forms are displayed inreports, as described in Prerequisi tes, page 184.



To display an attribute form in reports and in the Data Explorer

In the MicroStrategy Tutorial , navigate to the Schema Objects folder, openthe Attributes folder, and then the Geography folder.

Double-cl ick the Distribution Center attribute. If a message is displayedasking i f you want to use read only mode or edi t mode, select Edit and cl ickOK to open the Attribute Edi tor in edi t mode so that you can make changesto the attribute. The Attribute Edi tor opens.



Click the Display tab.

On the right, in the Report display forms pane, the description form ofthe Distribution Center is set as the only display form. This means that,when the Distribution Center attribute is used on a report, the actualnames of the distribution centers are displayed. The ID 2 form in theAvai lable forms pane represents the distribution centers' identi ficationnumbers.

You can set the ID 2 form to be displayed in the fol lowing ways:

To set the ID 2 form as a form that is displayed on a report by defaul t:Select ID 2 from the Avai lable forms pane and cl ick the top > button to addthe form to the Report display forms pane on the right.

To set the ID 2 form so i t is displayed in the Data Explorer when a userbrowses the Distribution Center attribute: Select ID 2 from the Avai lable



forms pane and cl ick the bottom > button to add the form to the Browseforms pane on the right.

The Data Explorer makes hierarchies avai lable for users to faci l i tateplacing objects on reports. The Data Explorer is discussed in Hierarchybrowsing, page 402.

You can also define the defaul t sort order for attributes on reports and theData Explorer. For information on attribute form sorting options, seeDisplaying forms: Attribute form properties, page 272.


You can also determine how attributes are displayed whi le users areedi ting and viewing reports. See the Basic Reporting Guide for detai ls.




OPTIMIZING ANDMAINTAINING YOURPROJECT



Once your MicroStrategy project is set up and populated with schemaobjects, you are ready to start thinking about ways to better maintain theproject and optimize i t for both the short and long term.

This chapter introduces you to maintenance and optimization concepts suchas tuning the interaction between your data warehouse and your project,creating aggregate tables, and using parti tion mapping, and explains howto use these methods to enhance your project. You can find this informationin the sections l isted below:

Updating your MicroStrategy project schema, page 325—As you continue toenhance the design and functional i ty of your project, you wi l l need to makevarious schema changes. To see any enhancements and changes to yourproject schema, you must update your project schema.

Data warehouse and project interaction: Warehouse Catalog, page 326—Asyour data warehouse changes to meet new data logging requirements, yourproject must reflect these changes. This can include adding new tables toyour project or removing tables that are no longer used. You can also tunethe interaction between your data warehouse and your MicroStrategyproject to bring your data into MicroStrategy in a way that meets yourrequirements.

Accessing multiple data sources in a project, page 353— With theMultiSource Option in Intel l igence Server, you can connect a project tomul tiple relational data sources. This al lows you to integrate al l yourinformation from various databases and other relational data sources into asingle MicroStrategy project for reporting and analysis purpose.

Improving database insert performance: parameterized queries, page 368—MicroStrategy's support for parameterized queries can improve performancein scenarios that require the insert of information into a database.

Using summary tables to store data: Aggregate tables, page 370—Aggregate tables store data at higher levels than the data was original lycol lected in the data warehouse. These summary tables provide quickeraccess to frequently-used data, reduce input/output and other resource



requirements, and minimize the amount of data that must be aggregatedand sorted at run time.

Dividing tables to increase performance: Parti tion mapping, page 378—Parti tion mapping involves the division of large logical tables into smal lerphysical tables. Parti tions improve query performance by minimizing thenumber of tables and records within a table that must be read to satisfyqueries issued against the warehouse.

Updating your MicroStrategy project schema

Al l of the schema objects—facts, attributes, hierarchies, transformations,and so on—in your project come together to form your project's schema.

Al though the concepts are related, the project schema is not the same asthe physical warehouse schema. Rather, the project schema refers to aninternal map that MicroStrategy uses to keep track of attribute relationships,fact levels, table sizes, and so on within the project.

Whenever you make any changes to a schema object you must indicate toMicroStrategy that new schema object defini tions have been included andthat these defini tions need to be loaded into memory.

You can do any of the fol lowing to update your project schema:

Stop and restart MicroStrategy Intel l igence Server, i f in server-connected(3-tier) mode.

Disconnect and reconnect to the project or the project source, i f in di rect (2-tier) mode.

Manual ly update the schema.

Manually updating the schema allows you to determine which specificelements of the schema are updated.



To manually update the schema

In MicroStrategy Developer, from the Schema menu, select UpdateSchema.

In the Schema Update dialog box, select or clear the fol lowing check boxes:

Update schema logical information : Use this option i f you added,modi fied, or deleted a schema object.

Recalculate table keys and fact entry levels: Use this option i f youchanged the key structure of a table or i f you changed the level at which afact is stored.

Recalculate table logical sizes: Use this option to use MicroStrategyDeveloper's algori thm to recalculate logical table sizes and override anymodi fications that you have made to logical table sizes.

Logical table sizes are a significant part of how the MicroStrategy SQL Enginedetermines the tables to use in a query.

Recalculate project client object cache size: Use this option to updatethe object cache size for the project.

Cl ick Update.

You can also update the schema with the last saved settings by click ing theUpdate Schema icon in the toolbar.

Data warehouse and project interaction: WarehouseCatalog

This section discusses how the Warehouse Catalog can control theinteraction between the data warehouse and the database instance for aproject. The Warehouse Catalog queries the data warehouse and l ists thetables and columns that exist in i t. From this l ist, you can select the tables



to add to your project. Every project can have a unique set of warehousetables.

You can add warehouse tables to your project wi th the Warehouse Catalogor Archi tect. The Warehouse Catalog is wel l -equipped at maintaining thewarehouse tables used for an existing project. For information on Archi tect,see Chapter 5, Creating a Project Using Archi tect.

This section also discusses customizing catalog SQL statements, thestructure of the SQL catalogs, and the defaul t SQL statements used for eachdatabase.

This section covers the fol lowing topics:

Before you begin using the Warehouse Catalog, page 328

Accessing the Warehouse Catalog, page 328

Adding and removing tables for a project, page 329

Managing warehouse and project tables, page 330

Modi fying data warehouse connection and operation defaul ts, page 337

Customizing catalog SQL statements, page 345

Troubleshooting table and column messages, page 351

You can also add tables to a project using MicroStrategy Query Builder. Formore information on Query Builder, see the MicroStrategy AdvancedReporting Guide .

You can connect to MDX Cube sources such as SAP BI, Hyperion Essbase,and Microsoft Analysis Services instead of a relational database. In this case,the MDX Cube Catalog handles tasks similar to the Warehouse Catalog. Formore information, refer to the MicroStrategy MDX Cube Reporting Guide .



Before you begin using the Warehouse CatalogBefore you begin using the Warehouse Catalog, you need to be fami l iarwi th:

Your schema, so you know how the information in your data warehouseshould be brought into MicroStrategy

How to create a project

Accessing the Warehouse Catalog

To access the Warehouse Catalog

On the Windows Start menu, point to Programs, then to MicroStrategyProducts, and then select Developer.

Log in to the project source that contains your project in MicroStrategyDeveloper, and expand the project source to select your project.

You must use a login that has Architect priv ileges. For more information aboutpriv ileges see the List of Privi leges chapter of the System AdministrationGuide .

If you are using read only mode for the project, from the Schema menu,clear the Read Only Mode option to switch to edi t mode.

Only one user can be edi ting a project at a given time. Therefore, i fsomeone else is modi fying the project, you cannot use the WarehouseCatalog. For more information on read only mode and edi t mode, seeUsing read only or edi t mode for schema edi tors, page 111.

From the Schema menu, select Warehouse Catalog . The WarehouseCatalog opens after i t retrieves the table information from the warehousedatabase.





Adding and removing tables for a projectAs you become aware of the addi tional needs of report designers andusers, i t may become necessary to add addi tional tables from the datawarehouse to your project. Also, as your project matures, you may need toremove tables from your project that are no longer used and are taking upspace in the metadata.

You can access the Warehouse Catalog at any time to add addi tional tablesfrom your data warehouse to your project and remove tables from yourproject.

For information on removing tables from a project that were removed from adata source, see Managing warehouse and project tables, page 330.

To add or remove tables after creating a project

Access the Warehouse Catalog for your project as described in Accessingthe Warehouse Catalog, page 328. Log in to the project source thatcontains your project in MicroStrategy Developer, and expand your project.

The left side of the Warehouse Catalog l ists al l avai lable tables and thenumber of rows each table contains. The l ist on the right shows al l thetables already being used in the project:

To add tables: From the left side, select the tables you want to add to theWarehouse Catalog, and cl ick > to add the selected tables. Cl ick >> to addal l the l isted tables.

To remove tables: From the right side, select the tables you want toremove from the Warehouse Catalog, and cl ick < to remove the selectedtables. Cl ick << to remove al l the l isted tables.

If you have the MultiSource Option, you can add tables from multiple datasources into your project. For information on adding tables from multipledata sources into your project wi th the Warehouse Catalog, see Accessingmultiple data sources in a project, page 353.



In the toolbar, cl ick Save and Close to save your changes to theWarehouse Catalog. The table defini tions are wri tten to the metadata. Thisprocess can take some time to complete.

Update the project schema from the Schema menu, by selecting UpdateSchema.

Managing warehouse and project tablesThe Warehouse Catalog al lows you to view tables that have been includedin the project, as wel l as those tables that are avai lable in the warehousebut have not been included in the project. To access the WarehouseCatalog for a project, see Accessing the Warehouse Catalog, page 328.

As you make changes to the tables in the warehouse, you need toperiodical ly load the updates into the Warehouse Catalog. You can updatei t by selecting Read the Warehouse Catalog from the Actions menu.

The Warehouse Catalog has the fol lowing sections:

Select current database instance: From the drop-down l ist, select thedatabase instance for the data source to view tables for. This option isavai lable as part of the MultiSource Option, which al lows you to accessmultiple data sources in a project, as described in Accessing multiple datasources in a project, page 353.

Tables available in the database instance: Displays tables that arelocated in the data source for the selected database instance, but have notbeen included in the project. You can add tables to the project by double-cl icking the tables or by selecting the tables and then cl icking >.

Tables being used in the project: Displays tables that have been selectedto be part of the project. You can remove tables from the project by double-cl icking the tables or by selecting the tables and then cl icking <.

You can add or remove all the tables from one section to the other by click ing<< and >> buttons.

Warehouse Catalog has the fol lowing menu options.



Menu Description

File

• Save Saves the current set t ings and status of the Warehouse Catalog.

• Exit Exits the Warehouse Catalog.

Tools

• ViewPart it ions

Displays the list of tables referred to by the selected part it ion mappingtable in the Table Part it ions dialog box. This opt ion is enabled when apart it ion mapping table is selected.

• TableStructure

Displays the structure of a table selected in the Warehouse Catalog.

• CalculateTable RowCount

Calculates the number of rows in the selected tables.

• TablePref ix

Allows you to add or remove a table pref ix for the selected table.

• TableDatabaseInstances

This opt ion allows you to support one of the following:

• MicroStrategy allows you to specify a secondary database instance for atable, which is used to support database gateways. For informat ion onsupport ing database gateways, see Specify ing a secondary database tosupport database gateways, page 336.

• I f you have the Mult iSource Opt ion, you can add tables from mult ipledata sources into your project . For informat ion on adding tables frommult iple data sources into your project with the Warehouse Catalog, seeAccessing mult iple data sources in a project, page 353.

• ImportPref ix

Allows you to import the pref ixes from the warehouse table name space.

• Opt ionsAllows you to specify various set t ings for the Warehouse Catalog such aschanging the database instance, changing or assigning default tablepref ixes and structures, automat ic mapping, row calculat ion, and so on.



Menu Description

Act ions

• Read theWarehouseCatalog

Allows you to update and ref lect the changes done to tables in thewarehouse.

Help Displays MicroStrategy help opt ions

Some of these options are also avai lable through toolbar buttons andthrough right-cl ick menus for quick access.

Viewing table structure

To view the table structure of a table, right-cl ick any table in the WarehouseCatalog (see Accessing the Warehouse Catalog, page 328) and chooseTable Structure from the shortcut menu. You can also select TableStructure from the Tools menu. The table structure of the selected table isdisplayed in the dialog box.

The dialog box displays the columns avai lable in the selected table and thedata type of each column. You can also cl ick Update Structure to reflectany recent changes done to that table (see Updating table structure, page333).

When the data type of one or more columns is modi fied, you get a warningmessage of this change, which provides the fol lowing options:

Cl ick OK to apply the change to this column in al l the tables i t appears.

Cl ick Cancel to undo al l data type changes. This action resul ts in nochanges being appl ied to any tables or columns.

The warning message appears only if you have selected the Display awarning if the columns data types are modified when updating the



table structure option in the Warehouse Catalog Options dialog box. Thisoption is selected by default.

Updating table structure

Whenever the structure of the warehouse table changes you have to updatethe table structure in the Warehouse Catalog for the changes to reflect inthe MicroStrategy system. Some examples of these type of changes arewhen you add, delete, or rename a column in a table associated with aproject.

To update the structure of a table

Access the Warehouse Catalog for your project (see Accessing theWarehouse Catalog, page 328). The Warehouse Catalog opens.

In the Tables being used in the project l ist, right-cl ick the table that haschanged and select Update Structure.

If the data type of one or more columns is modi fied, you receive amessage warning of this change. Veri fy the changes from the informationdialog box that opens and cl ick OK to apply the change in this column toal l the tables in which i t appears.

Cl ick Save and Close to close the Warehouse Catalog dialog box.

If no object defini tions have changed, the warehouse structure gets updatedcompletely wi th the Update Structure command. For example, this wouldapply i f you rename a column in the table and the column is not being usedin any fact expression.

If any of the object defini tions have changed, the table structure is onlypartial ly updated with the Update Structure command. Then, you have tomanual ly update the schema objects that depend on the outdated structure.



For example, i f you rename a column in a table, you have to manual lyupdate the facts that use this column. The procedure for manual ly updatingthe fact is as fol lows:

Right-cl ick the fact and select Edit. The Fact Edi tor opens.

Select the fact expression and cl ick Modify. The Modi fy Fact Expressiondialog box opens.

From the l ist of source tables select the source table from which the facthas been created. Edi t the fact expression and cl ick OK . You are returnedto the Fact Edi tor.

Cl ick Save and Close to save the changes and close the Fact Edi tor.

From the Schema menu, select Update Schema. The Schema Updatedialog box opens.

Cl ick Update.

Repeat the fi rst two steps of this procedure to open the Warehouse Catalogand update the table structure.

Cl ick Save and Close to save the changes and close the WarehouseCatalog dialog box.

Viewing sample data

To view sample data from a table, right-cl ick a table in the WarehouseCatalog (see Accessing the Warehouse Catalog, page 328) and chooseShow Sample Data from the shortcut menu. You can also select ShowSample Data from the Tools menu. The fi rst 100 rows of the table arereturned as sample data in the Values dialog box.

To refresh the table data, cl ick Reload table values.



Removing tables from the Warehouse Catalog that have beenremoved from their data source

When tables that are included in a project are removed from the data sourcethat they were avai lable in, you can use the Warehouse Catalog to removethese tables from the l ist of tables included in the project. This al lows youto view an accurate l ist of tables that are included in the project from theselected data source.

The steps below show you how to perform this task using the WarehouseCatalog. To remove these tables using MicroStrategy Archi tect, seeRemoving tables, page 145.

If tables that were not included in a project are removed from the data source,these tables are automatically removed from the display of available tables inthe Warehouse Catalog.

To remove the display of project tables that have been removed from

the data source


From the Schema menu, select Warehouse Catalog . The WarehouseCatalog opens.

From the Warehouse Catalog toolbar, cl ick Check for deleted catalogtables. The Deleted Catalog Tables dialog box opens.

Select the Delete check box for a table to remove i t from the Tables beingused in the project pane.

After you have selected al l the tables to delete, cl ick OK to return to theWarehouse Catalog.

From the Action menu, select Read the Warehouse Catalog . Al l tablesthat were selected to be deleted in the Deleted Catalog Tables dialog boxare removed from the Tables being used in the project pane.



Click Save and Close to save your changes and close the WarehouseCatalog.

Specifying a secondary database to support database gateways

MicroStrategy al lows you to speci fy a secondary database instance for atable, which is used to support database gateways. For example, in yourenvironment you might have a gateway between two databases such as anOracle database and a DB2 database. One of them is the primary databaseand the other is the secondary database. The primary database receives al lSQL requests and passes them to the correct database. From theperspective of MicroStrategy products in this environment, you need todefine two database instances, one for the primary database and anotherfor the secondary database. The defaul t database instance for the project isset to be the primary database. In the Warehouse Catalog, you must set thesecondary database instance for any tables that are found in the secondarydatabase. This way, MicroStrategy products know how to generate SQL foreach table.

If you use database gateway support, you cannot use the MultiSourceOption feature to add tables from multiple data sources into your project.For information on adding tables from multiple data sources into yourproject wi th the Warehouse Catalog, see Accessing multiple data sourcesin a project, page 353.

To specify a secondary database for a table


Right-cl ick a table being used in the project, (in the pane on the right side)and select Table Database Instances. The Avai lable Database Instancesdialog box opens.

In the Primary Database Instance drop-down l ist, select the primarydatabase instance for the table.



Select one or more Secondary Database Instances.

You cannot select the primary database instance as a secondary databaseinstance.

Click OK to accept your changes and return to the Warehouse Catalog.

From the toolbar, select Save and Close to save your changes and closethe Warehouse Catalog.

Modifying data warehouse connection and operation defaultsYou can speci fy various settings for data warehouse connection andoperation defaul ts using the Warehouse Catalog. Example settings includechanging the database instance, changing or assigning defaul t tableprefixes and structures, automatic mapping, row calculation, and so on. Thesettings are avai lable from the Warehouse Catalog, by choosing Optionsfrom the Tools menu (see Accessing the Warehouse Catalog, page 328 forsteps to access the Warehouse Catalog). The Warehouse Catalog Optionsdialog box opens, which al lows you to perform the fol lowing tasks:

Data warehouse connection and read operations, page 337

Displaying table prefixes, row counts, and name spaces, page 342

Mapping schema objects and calculating logical sizes for tables, page 343

Data warehouse connection and read operations

You can modi fy the database instance and database login used to connectthe data warehouse to a project, as wel l as change how the databasecatalog tables are read. You can make these type of modi fication from theCatalog category, which is divided into the fol lowing subcategories:

Warehouse Connection: Select the desired database instance to use forthe project as wel l as the custom database login.

Database Instance: You can select the primary database instance for theWarehouse Catalog from the drop-down l ist.



The primary database instance acts as the main source of data for a projectand is used as the defaul t database instance for tables added to the project.Non-database related VLDB property settings are also inheri ted from theprimary database instance.

If the desired database instance does not appear in the Database Instancebox, or i f i t does but needs to be modi fied, you can select from thefol lowing:

Cl ick Edit to modi fy the selected database instance. The General tab of theDatabase Instances dialog box opens.

Cl ick New to create a new database instance. The Database InstanceWizard opens.

Refer to the System Administration Guide for more information on either ofthese dialog boxes.

Custom Database Login : You can ei ther select the database login or clearthe login to use no database login.

For more information on the database login, see the MicroStrategyDeveloper Help (formerly the MicroStrategy Desktop Help).

Read Settings: You can define how database catalog tables are retrieved:

Use standard ODBC calls to obtain the database catalog : This option isavai lable i f you connect to a database type that supports ODBC cal ls toretrieve the database catalog tables. If you select this option, standardODBC cal ls are used to retrieve the database catalog tables. If you use aMicrosoft Access database, ODBC cal ls are automatical ly used. If youselect this option and the resul ts are not retrieving the database catalogtables correctly, you can select the SQL statement option l isted below tocustomize how the database catalog tables are retrieved.

Use one or more SQL statements that query directly the databasecatalog tables: This option is avai lable i f you connect to a database type




that supports ODBC cal ls to retrieve the database catalog tables.Otherwise, this is option is not shown and only the Settings button isdisplayed. If you select this option, SQL statements are used to retrieve thedatabase catalog tables.

You can customize the SQL to read the Warehouse Catalog for everyplatform (except Microsoft Access), by cl icking Settings. This al lows you todirectly edi t the catalog SQL statements that are used to retrieve the l ist ofavai lable tables from the Warehouse Catalog and the columns for theselected tables. The defaul t catalog SQL retrieves a DISTINCT l ist of tablesand columns from al l users. You could restrict the information returned, forexample, by speci fying certain condi tions and table owners (seeCustomizing catalog SQL statements, page 345).

You can also choose from the fol lowing options to read the databasecatalog tables:

Read the table Primary and Foreign Keys: Select this option to display, inMicroStrategy, which columns are defined as primary keys or foreign keysin the data source. Primary keys and foreign keys can help faci l i tate joiningtables to create Query Bui lder reports, as described in the AdvancedReporting Guide.

Displaying primary key or foreign key information in MicroStrategy can alsohelp users designing a project to determine which columns of data may besui table to serve as the identi fication columns of attributes. For informationon defining the primary key for tables included in a MicroStrategy project,see Defining the primary key for a table, page 511.

Count the number of rows for all tables when reading the databasecatalog: Select this option i f you want to control whether the WarehouseCatalog should get the number of rows each table has when loading fromthe data warehouse. This option is helpful when you want to identi fy facttables and aggregation tables. If performance is more important thanobtaining the row count, do not select this option as i t wi l l have a negative





effect on performance. By defaul t this option is selected when you open theWarehouse Catalog for the fi rst time.

Ignore current table name space when reading from the databasecatalog and update using new table name space: This option al lows youto switch between warehouses found in di fferent database name spaces.For more information, see Ignoring table name spaces when migratingtables, page 344 of this appendix. By defaul t this option is selected.

Display a warning if the column data types are modified when updatingthe table structure: Select this option i f you want to be warned when thedata type for a column stored in the project is di fferent from the one readfrom the data warehouse. The check for the data type change is onlyperformed when updating a table's structure. By defaul t this option isselected.

Automatically update information for all Partition Mapping tables whenreading the database catalog: Select this option to read the latestinformation for the parti tion mapping tables (PMTs) currently present in theproject. This setting should be cleared when the number of PMTs in theproject is so large that reading their structure is causing performanceproblems when opening the Warehouse Catalog. By defaul t this option isselected.

Column Merging Options: When you add a new table to your datawarehouse, i t may redefine the data type for a column included in theproject. For example, your project includes a table named Table1 that hascolumn C1 of data type char(1). Then a new table named Table2 is addedto the project, but i t has column C1 set to data type char(4). This example isused to i l lustrate the options described below. When you update the tablestructure, the column data types are modi fied to maintain a consistentschema in one of three ways, depending on the option you select.

The options below do not handle the merge if the data type has changed to anincompatible data type. For example, a column is changed from data type char



to data type integer. If the data type has changed to an incompatible data type,a warning is displayed and you are asked if you want to use the new data type.

Use most recent data type: This option updates the column data type touse the most recent column defini tion. In the example above, the columndata type for C1 would be changed to char(4) since Table2 was added afterTable1.

Use maximum denominator data type: This option updates the columndata type to use the data type with the largest precision or scale. In theexample above, the column data type for C1 would be changed to char(4),as defined in Table2. This is because char(4) has a higher precision thanchar(1) defined in Table1. If the data type has been changed to a di fferentcompatible data type, the data type with the largest precision or scale isused, as i l lustrated in the image below.

Do not merge: This option renames the column in the newly added table,which al lows the columns to have di fferent data types. From the exampleabove, column C1 uses the char(1) data type for Table1. Column C1 inTable2 is defined as a separate copy of C1 and uses the char(4) data type.This option can cause unwanted schema changes and should be used onlywhen necessary.

Read Mode: The Warehouse Catalog can be automatical ly read uponopening the Warehouse Catalog, or restricted to only be read when a readis manual ly requested:



Automatic: This option sets the Warehouse Catalog tables to be read assoon as the catalog browser is loaded.

Manual: This option sets the Warehouse Catalog tables to be read onlywhen the read catalog action is selected.

Displaying table prefixes, row counts, and name spaces

You can choose to show or hide table prefixes, row counts, and namespaces, by using the View category. This category is divided into thefol lowing subcategories:

Table Prefixes: You can speci fy whether table prefixes are displayed intable names and how prefixes are automatical ly defined for tables that areadded to the project. You have the fol lowing options:

Display table prefixes in the main dialog: Select this option to display al lprefixes in table names, including new tables added to the project. Bydefaul t this option is selected.

Automatically define prefixes for all tables that are added to thisproject: This setting enables/disables the fol lowing options:

Set a prefix based on the warehouse table name space or owner(import prefix): When this option is selected, the Warehouse Catalog readsthe name space for each table being added, creates a prefix having thesame text as the name space, and associates i t wi th the table being added.

Set a default prefix: Select this to add a prefix to tables when they areadded to a project. This option is only active when the database supportsprefixes. You can select the defaul t prefix from the Defaul t prefix box drop-down l ist or create a new table prefix by cl icking Modify prefix list.

Modify prefix list: You can create a new tables prefix or delete an existingprefix by selecting this option. The Table Prefixes dialog box opens. Formore information on modi fying the prefix l ist, see the onl ine help.



Table Row Counts: You can show or hide the number of rows per table,using the check box:

Display the number of rows per table: You can show or hide the valuescalculated for the number of rows for the tables. By defaul t, this option isselected and the number of rows are shown.

Table Name Spaces: You can show or hide the name space for each table,using the check box:

Display the name space for each table (if applicable): You can show orhide the owner or table name space where the table is located in thewarehouse. By defaul t, this option is selected and table name spaces areshown.

Mapping schema objects and calculating logical sizes for tables

The Schema category is divided into the fol lowing subcategories:

Automatic Mapping : When you add new tables to the Warehouse Catalog,you can determine whether existing schema objects in the project aremapped to these new tables automatical ly, using the fol lowing options:

Map schema objects to new tables automatically: Existing objects in theschema automatical ly map to tables you add to the project.

Do not map schema objects to the new tables: Objects in the schema arenot automatical ly mapped to tables you add to the project.

These automatic mapping methods are only appl ied to existing schemaobjects when tables are added to the Warehouse Catalog. For example,the attribute Year wi th an attribute form mapped to YEAR_ID is includedin a project. Then a new table which includes a YEAR_ID column isadded to the Warehouse Catalog. With the Map schema objects to newtables automatical ly option selected, the Year attribute is automatical lymapped when the new table is added.



If the table was added to the Warehouse Catalog first and then the attributewas created, the Warehouse Catalog automatic mapping settings do notdetermine whether the attribute and table are automatically mapped.Automatically mapping tables to schema objects when adding attributes orfacts to a project is controlled by the Attribute Editor and Fact Editor,respectively.

Table Logical Sizes: You can select whether the Warehouse Catalogcalculates logical sizes for new tables using one of the fol lowing options:

Calculate the logical table sizes automatically: Logical sizes areautomatical ly calculated for tables you add to the project.

Do not calculate table logical sizes: Logical sizes are not calculated forthe tables you add to the project.

Ignoring table name spaces when migrating tables

It is a common practice to establ ish a secondary warehouse with lessinformation than the primary warehouse for development and testing. Beforegoing into production, you change the project to point to the primarywarehouse.

Most database management systems (Oracle, DB2, and others) support theconcept of a table name space, which is a way of organizing databasetables into di fferent storage spaces. This method al lows you to repeat thesame table name in di fferent table name spaces. For instance, you canhave LU_STORE in a table name space cal led dbo and another table LU_

STORE in another table name space cal led admin . You now have twotables dbo.LU_STORE and admin.LU_STORE . The table name spaceprovides an extra piece of information that uniquely identi fies the table.

When you add tables to a project, the Warehouse Catalog savesinformation to the appropriate table name space. This can cause a problemwhen you migrate from a warehouse that resides in a certain table namespace to another warehouse in a di fferent table name space. The



Warehouse Catalog interprets the table as already in the project and notfound in the new warehouse. This is because the Warehouse Catalog islooking for a table named dbo.LU_STORE , and the table is actual ly storedas admin.LU_STORE in the new production warehouse.

To solve this problem, select the Ignore current table name space whenreading from the database catalog and update using new table namespace check box. You can find this option in the Warehouse CatalogOptions dialog box under the Catalog - Read Settings options subcategory.If you select this option, the Warehouse Catalog ignores the current tablename space when i t reads the catalog information. Thus, the WarehouseCatalog recognizes the two tables as the same table and saves the newtable name space information. This setting al lows you to migrate muchmore easi ly between warehouses. If the check box is cleared, theWarehouse Catalog defaul ts to identi fying the table by both table namespace and table name.

Customizing catalog SQL statementsIn al l supported warehouse platforms other than Microsoft Access,MicroStrategy uses SQL statements to query the relational databasemanagement system (RDBMS) catalog tables to obtain warehouse cataloginformation. This information includes catalog tables, columns, and theirdata types.

These catalog SQL statements vary from platform to platform and can becustomized according to the characteristics of the speci fic warehouse.

Microsoft Access does not have catalog tables, so an ODBC call must be usedto retrieve information about tables and columns in Access. By default, asimilar ODBC call is used for the Generic DBMS database type, but you canchoose to use custom catalog SQL for the generic type if you want.

The MicroStrategy Warehouse Catalog can be configured to read thecatalog information in one- or two-pass SQL mode. In two-pass SQL mode,i t fi rst reads only the tables from the database. The structure of individual



tables is read only when the table is selected. This is the recommendedoption for interactive warehouse catalog bui lding because no unnecessarycatalog information is read from the database, which increases processingspeed. One-pass SQL mode, on the other hand, reads al l the tables andcolumns in one SQL statement. This option is recommended only i f thecatalog SQL is wel l customized to l imi t the amount of data returned by i t.

The two retrieval options use di fferent catalog SQL, but both can becustomized in the Warehouse Catalog Options dialog box. In the fol lowingsections, the name Catalog Table SQL refers to the catalog SQL to retrievethe tables in the warehouse; that is, the fi rst SQL used in a two-passcatalog retrieval .

The name Ful l Catalog SQL refers to the SQL used to read al l the tablesand columns in one pass.

To customize a catalog SQL, you must understand several importantconcepts and procedures:

The table name space, page 346

SQL placeholder strings and incomplete catalog SQL, page 347

Structure of Catalog Table SQL, page 347

Structure of Ful l Catalog SQL, page 348

Modi fying catalog SQL, page 349

Defaul t catalog SQL, page 350

The table name space

In a typical RDBMS platform, a table name does not uniquely identi fy i t in aparticular database instal lation. A table name space is a parti tion of thedatabase instal lation in which table names are unique. Depending on thetype of RDBMS, this name space can be the name of the database, theowner of the table, or a combination of both database and owner. In boththe Catalog Table SQL and Ful l Catalog SQL, a name space gives each



table a unique name. This helps you to avoid confusing tables that sharethe same table name.

The table name space is optional . A customized catalog SQL can omit thename space i f dupl icate table names do not present a problem in thewarehouse database.

SQL placeholder strings and incomplete catalog SQL

The defaul t system catalog SQL can contain certain placeholder strings thatcan be resolved at run time or must be completed manual ly by the user.These placeholders are:

#LOGIN_NAME#—This placeholder is automatical ly replaced at run timewith the login name used to connect to the database. You can leave thistemplate in the customized SQL if you want the catalog SQL to yielddi fferent resul ts depending on the warehouse login used. Otherwise, thistemplate is replaced with the name of the database user who owns thewarehouse tables of interest.

#?Database_Name?# , #?Schema_Name?#—This catalog SQLplaceholder is an incomplete SQL string that must be completed by the userbefore i t can be executed. The string starts wi th #? and ends with ?# . Thecommand #?Database_Name?# , used with Teradata, must be replacedwith the name of the database containing the database tables. #?Schema_Name?# , used with DB2 AS/400 and MySQL, must be replaced with thename of the schema in which the database tables for the project reside.

Structure of Catalog Table SQL

Catalog Table SQL is expected to return two columns, one identi fying thename space of the table and the other the name of the table. If a namespace is not provided, only the table name column is required. Each row ofthe SQL resul t must uniquely identi fy a table. Dupl icates are not al lowed.The column that identi fies the table name space uses the SQL column al iasNAME_SPACE . The column that identi fies the table name has the al ias TAB_



NAME . The fol lowing example is the defaul t Catalog Table SQL for Oracle8.0:

SELECT DISTINCT OWNER NAME_SPACE, TABLE_NAME TAB_NAME

FROM ALL_TAB_COLUMNS

WHERE OWNER = '#LOGIN_NAME#'

Structure of Full Catalog SQL

Ful l Catalog SQL is expected to return between five and seven columns,depending on the RDBMS platform and the customization.

The fol lowing al iases identi fy each column returned:

NAME_SPACE (optional): the table name space

TAB_NAME (required): name of the table

COL_NAME (required): name of the column

DATA_TYPE (required): a string or a number that identi fies the major datatype of the column

DATA_LEN (required): a number that describes the length or size of thecolumn data

DATA_PREC (optional): a number that describes the precision of the columndata

DATA_SCALE (optional): a number that describes the scale of a floatingpoint column data

Ful l Catalog SQL must return i ts rows ordered fi rst by NAME_SPACE , i favai lable, and then by TAB_NAME .

The fol lowing example is the defaul t Ful l Catalog SQL for Microsoft SQLServer 7.0:

SELECT U.name NAME_SPACE, T.name TAB_NAME, C.name COL_NAME,

C.type DATA_TYPE, C.length DATA_LEN, C.prec DATA_PREC,



C.scale DATA_SCALE

FROM sysobjects T, syscolumns C, sysusers

WHERE T.id = C.id and T.type in ('U', 'V')

AND T.uid = U.uid

ORDER BY 1, 2

Modifying catalog SQL

You can customize and modi fy the catalog SQL that is run against yourdatabase for each project. The catalog SQL can be modi fied in theWarehouse Catalog options for your project.

To modify the catalog SQL for your project


From the Tools menu, select Options. The Warehouse Catalog Optionsdialog box opens.

Expand the Catalog Category, and select Read Settings. The Catalog -Read Settings options are displayed.

Cl ick the Settings button, the catalog SQL options are displayed as shownbelow.

The catalog SQL settings are unavailable if your project is connected to aMicrosoft Access database.



The top pane controls the Catalog Table SQL and the bottom pane controlsthe Ful l Catalog SQL.

Default catalog SQL

When customizing the catalog SQL that is executed on your database, i t isrecommended you consul t the defaul t catalog SQL that MicroStrategy usesto support di fferent database platforms. You can generate the defaul tcatalog SQL in MicroStrategy for the database platform your projectconnects to.

To generate and view the default catalog SQL

Access the catalog SQL options for your project (see Modifying catalogSQL, page 349). A dialog box for the catalog SQL options is displayed.

The top pane controls the Catalog Table SQL, which retrieves a l ist ofavai lable tables in the Warehouse Catalog.



The bottom pane controls the Ful l Catalog SQL, which retrieves columninformation for the selected tables.

Before performing the next step, cut and paste the SQL statements in the twopanes into any text editor. This allows you to save any modifications you havemade previously to the catalog SQL statements, and then compare them to thedefault statements you are about to generate.

Generate and view the defaul t catalog SQL for your database platform. Anytext in the panes is overwri tten with the defaul t catalog SQL statements:

To generate and view the defaul t Catalog Table SQL for your databaseplatform, cl ick the upper-most Use Default button.

To generate and view the defaul t Ful l Catalog SQL for your databaseplatform, cl ick the bottom-most Use Default button.

You can use the defaul t catalog SQL statements or compare and combinethem with your own customized catalog SQL statements.

Troubleshooting table and column messagesYou may encounter the fol lowing messages whi le using the WarehouseCatalog:

Tables missing, page 351

Column's data type changed, page 352

Columns missing, page 352

Tables missing

This happens when one or more tables already in the project are removedfrom the data warehouse. Two cases can be seen:

When the Warehouse Catalog is starting and retrieving the tableinformation from the data warehouse and i t detects that one or more tables



already in the project are missing, i t displays an error message which givesyou the fol lowing options:

Leave the table in the project: This leaves everything as is in the projectmetadata. However the defini tion in the project may be inconsistent wi th thereal physical structure in the warehouse. This can resul t in SQL errorswhen running reports that need data from a "missing" table.

Remove the table from the project. In this case, the Warehouse Catalogdoes not check for any dependencies unti l you save the changes. If thereare any dependencies, they are presented to you, and you have the optionto proceed or cancel the operation.

When the Warehouse Catalog tries to update the structure of a table that ismissing in the warehouse, a message is shown which explains that thetable structure update cannot proceed because the table was not found inthe warehouse. In this case, no changes occur and the original tablestructure remains intact.

Column's data type changed

When the table structure is updated for one or more tables in which thecolumn data types have been changed, you get a warning messageshowing the table name, column name, original data type, and new datatype. You can cl ick Cancel at any time to undo al l data type changes. Thisresul ts in no changes being appl ied to the tables and columns.

Columns missing

Missing columns are detected when Update Structure is performed. If thishappens, the Warehouse Catalog checks for the fol lowing:

Column is not mapped to any schema object: If this is the case, then noerror message is shown.

Column is mapped to a schema object: If this is the case, then a messageis displayed that gives detai ls on objects, which are mapped to the missing



column and the update structure operation is canceled. You are asked toremove the mapping before continuing with the update structure andoriginal table structure is restored.

Accessing multiple data sources in a project

MicroStrategy provides an extension to Intel l igence Server referred to asMultiSource Option. With the MultiSource Option feature, you can connect aproject to mul tiple relational data sources. This lets you integrate al l of yourinformation from various databases and other relational data sources into asingle MicroStrategy project for reporting and analysis purposes. Al l datasources included by using the MultiSource Option are integrated as part ofthe same relational schema for a project.

Accessing multiple relational data sources in a single project can providemany benefi ts and reporting solutions. There is the obvious benefi t of beingable to integrate information from various data sources into a single project.Along with accessing data in data sources provided from a central izedserver, you can also access personal relational data sources.

For example, a sales manager wants to include forecast data avai lable in aspreadsheet stored on a sales representative's local machine. Byconnecting to the spreadsheet as a relational data source, this forecast datacan be viewed along with actual sales data from the central ized database.

Mul tiSource Option also al lows you to use Freeform SQL, Query Bui lder,and MDX cube reports, that access secondary data sources, as fi l ters onstandard reports. For information on Freeform SQL and Query Bui lderreports, see the Advanced Reporting Guide. For information on MDX cubereports, see the MDX Cube Reporting Guide.

If you have the MultiSource Option, you can access multiple data sources ina project as described below:

Connecting data sources to a project, page 354

Adding data into a project, page 358





You can create logical views on data sources other than the data source forthe primary database instance. This technique along with steps to createlogical views are described in Creating logical views, page 512.

You can support fact tables that are parti tioned across multiple databases.Using metadata parti tioning is described in Metadata parti tion mapping,page 380.

You can include MDX cube data in regular reports, which lets you includeMDX cube data along with data from your relational project as wel l as MDXcube data from other MDX cubes. For examples of this capabi l i ty and stepsto create these types of reports, refer to the MDX Cube Reporting Guide.

Connecting data sources to a projectYou can connect a project to a data source through a database instance. Adatabase instance speci fies warehouse connection information, such as thedata source name, login ID and password, and other data source speci ficinformation. For information on creating a database instance, see theInstal lation and Configuration Guide.

Once database instances have been created for your data sources, you canconnect them to your project. However, keep in mind that i f you includemultiple data sources in a project, the data sources should al l fi t into thesame logical data model and warehouse structure planned for your project.For information on planning a logical data model and a physical warehousestructure, see Chapter 2, The Logical Data Model and Chapter 3,Warehouse Structure for Your Logical Data Model .

The procedure below describes how to include multiple data sources in aproject.

Prerequisi tes


Database instances have been created for the data sources to include in aproject.





You must have the MultiSource Option to connect mul tiple data sources to aproject.

To include multiple data sources in a project



From the Categories l ist, expand Database Instances, and then selectSQL Data Warehouses.

In the Database Instance pane, select the check box next to the databaseinstances for the data sources to include in a project.

Selecting a check box for a database instance also makes i ts datasource avai lable for use with Query Bui lder and Freeform SQL. Theavai labi l i ty of mul tiple data sources through Query Bui lder or FreeformSQL does not require the MultiSource Option. However, only one datasource can be used at a time in a Query Bui lder or Freeform SQL report.For information on Query Bui lder and Freeform SQL, see the AdvancedReporting Guide.

In the drop-down l ist near the top, select a database instance to act as theprimary database instance.

The primary database instance acts as the main source of data for aproject and is used as the defaul t database instance for tables added tothe project. Non-database related VLDB property settings are alsoinheri ted from the primary database instance.

To determine the order of data source access

You can define the order in which data sources are used to provide dataas part of the MultiSource Option, when the same data can be retrievedfrom multiple data sources.





From the Categories l ist, expand Report definition , and then select SQLgeneration .

In the Database Instance Ordering area, you can define the order in whichdata sources are used to provide data as part of the MultiSource Option, asdescribed below:

To define a priori ty in which each data source is used to access data aspart of the MultiSource Option, cl ick Modify. The Select Objects dialog boxopens.

Move any appl icable database instances for the project to the Selectedobjects pane.

You can then use the up and down arrows to change the priori ty of eachdatabase instance, wi th the database instance at the top of the l ist havingthe highest priori ty. Highest priori ty means that the database instance isused fi rst i f i t is one of the database instances that can be used to retrievethe requested data. In addi tion to using this order for a project, you canenable or disable the use of this ordering for individual reports, asdescribed in the Developer Help (formerly the MicroStrategy Desktop Help).

You have the fol lowing options to determine the order in which datasources are selected for the project:

Use MultiSource Option default ordering (defaul t): If data is avai lable inmultiple data sources through MultiSource Option, the primary databaseinstance is used i f i t has the necessary data. If the data is only avai lable inother secondary data sources, one of the secondary data sources thatincludes the data is used to retrieve the necessary data using some basicinternal logic. Any data source priori ty that you defined using DatabaseInstance Ordering is ignored.

By selecting this option, this Mul tiSource Option defaul t ordering is used foral l reports in a project by defaul t. You can enable or disable the use of thisordering for individual reports, as described in the Developer Help (formerlythe MicroStrategy Desktop Help).



Use project level database instance ordering : If data is avai lable inmultiple data sources through MultiSource Option, the data source used toretrieve the data is based on the priori ty that you defined using DatabaseInstance Ordering. If data is only avai lable in a data source that is notincluded in the priori ty l ist, then an appl icable data source is chosen usingthe standard MultiSource Option logic.

By selecting this option, the data source priori ty l ist that you defined for theproject is used for al l reports in a project by defaul t. You can enable ordisable the use of this ordering for individual reports, as described in theDeveloper Help (formerly the MicroStrategy Desktop Help).

To save your changes and complete the configuration

Click OK to save your changes and close the Project Configuration Edi tor.

MicroStrategy includes addi tional techniques that can help to improve theperformance of Mul tiSource Option in certain scenarios, including:

If the data source you use with MultiSource Option supports parameterizedqueries, you can enable the use of parameterized queries to improve theperformance of Mul tiSource Option. For information on enabl ing the use ofparameterized queries, see Improving database insert performance:parameterized queries, page 368.

Using MultiSource Option means that mul tiple passes of SQL are executedto return the resul t from more than one data source. You can execute thesemultiple passes of SQL at the same time by using paral lel SQL execution.For detai ls on how paral lel SQL execution works and how it can be enabledusing the Paral lel SQL Execution VLDB property, refer to the SystemAdministration Guide.

The data sources you included in the project can now be accessed from theWarehouse Catalog and Archi tect to import tables into the project, asdescribed in Adding data into a project, page 358 below.





Adding data into a projectOnce data sources are connected to a project, you can add data from thesedata sources into the project. This can be done by importing tables fromyour data sources into the project.

Tables can be imported into a project using the Warehouse Catalog orArchi tect. In the Warehouse Catalog, you can use the Select currentdatabase instance drop-down l ist shown below to switch between the datasources you are importing tables for.

In Archi tect, you can use the Warehouse Tables pane shown below toswitch between the data sources you are importing tables for.

If the tables that you import from various sources al l use di fferent tablenames, the tables are imported exactly as they are when only a single data



source is used. You can also import tables with the same name fromdifferent data sources, and is described in Supporting dupl icate tables inmultiple data sources , page 359 below.

Supporting duplicate tables in multiple data sources

You can support the integration of dupl icate tables in multiple data sourcesthrough the use of Mul tiSource Option. The MicroStrategy SQL Engine canthen obtain any required attribute information from the data source thatstores that information. This process can return this information to reportsand documents wi thout any extra considerations or tasks for a report ordocument designer.

Including dupl icate copies of tables from different data sources al lowsMicroStrategy to execute within a single data source for certain types ofqueries.

For example, you have two data sources. One data source stores historicaldata for your company. The other data source stores forecast data for thesame business sectors. Each data source includes dupl icate copies oftables that store attribute information, which describe the context of data.The data sources di ffer in the avai labi l i ty of historical data versus forecastdata, which is integrated into your MicroStrategy project through the use offacts and metrics.

In this scenario, including each copy of the tables that include attributeinformation from both data sources al lows some queries to be processedwithin a single data source. By including these dupl icate copies, users thatonly need to view historical data can have their query resolved within asingle data source. Simi larly, users that only need to view forecast data canhave their query resolved completely wi thin the other data source. Thisreduces the time and system resources required for these types of queriessince working within a single data source is more efficient than queryingacross multiple data sources.



Including both historical and forecast data on the same report from thesedifferent data sources is also possible in this scenario through the use ofMultiSource Option. However, s ince the historical and forecast data are onlyavailable in separate data sources, this query must include both data sources.

To import mul tiple copies of the same table from different data sources intoa project, the requirements l isted below must be met:

The table name and column names must be exactly the same.

One of the copies of the table must act as the primary table used in theproject. Al l of the columns in this table must also be present in the othercopies of the table from other data sources. The other copies of the tablethat are used as secondary tables can include addi tional columns ofinformation. However, these addi tional columns are not included in theproject when the table is added.

When you import mul tiple copies of a table from multiple data sources,import the table that is to act as the primary table fi rst. Once you import theprimary table, you can begin importing secondary tables from the other datasources.

If you do not import the primary table fi rst, you may have to remove sometables and then add them back into the project after the primary table isimported. This workflow may be required to update existing projects thatdid not previously use MultiSource Option.

The data types of matching columns must be compatible. Compatibi l i ty ofcolumn data types is described below:

A Decimal data type with a scale of zero is compatible wi th the Integer datatype.

A Numeric data type with a scale of zero is compatible wi th the Integer datatype.

A Decimal data type is compatible wi th a Numeric data type.

Double, Float, and Real data types are al l compatible wi th each other.



A Date data type is compatible wi th a Timestamp data type.

A Time data type is compatible wi th a Timestamp data type.

A Char data type is compatible wi th a VarChar data type.

Any other data types are only compatible wi th an identical data type.

Be aware that a Date data type is not compatible wi th a Time data type, andNVarChar and NChar data types are not compatible wi th VarChar and Chardata types.

The procedures below describe how to import mul tiple copies of the sametable into MicroStrategy using the Warehouse Catalog or Archi tect:

Importing tables from multiple data sources in a project using theWarehouse Catalog, page 361

Importing tables from multiple data sources in a project using Archi tect,page 363

Importing tables from multiple data sources in a project using the WarehouseCatalog

Prerequisi te

You must have MultiSource Option to connect mul tiple data sources to aproject.

To import tables from multiple data sources in a project using the

Warehouse Catalog



From the Select current database instance drop-down l ist, select thedatabase instance for one of the data sources the table resides in. The fi rst



data source you use to import a table should be the one you plan to use asthe primary data source for the table.

Importing a table from the primary database instance for a project or anon-primary database instance has an effect on how the table is updatedwhen the primary database instance for a project is changed, asdescribed in Importing tables as part of the project's primary databaseinstance, page 365.

In the Tables available in the database instance pane, select the table toadd to the project and cl ick the > button. The fi rst copy of the table is addedto the project and is displayed in the Tables being Used in the Projectpane.

To add copies of a table from other database instances

From the Select current database instance drop-down l ist, select thedatabase instance for a di fferent data source that also includes the table.

In the Tables available in the database instance pane, select the table toadd to the project and cl ick the > button.

If al l of the required condi tions to import mul tiple copies of the table(l isted in Supporting dupl icate tables in multiple data sources , page359) are met, a Warehouse Catalog Browser dialog box opens. Toinclude a copy of the table in the project, select Indicate that TABLE_NAME is also available from the current DB instance, and cl ick OK .The copy of the table is added to the project and is displayed in theTables being Used in the Project pane.

Review any messages displayed when attempting to import a copy of atable from a di fferent data source.

To add additional tables and configure the tables included in the project

To add tables from addi tional data sources, repeat the steps in To addcopies of a table from other database instances, page 362 above.



In the Tables being used in the project pane, right-cl ick the table andselect Table Database Instances. The Avai lable Database Instancesdialog box opens.

From the Primary Database Instance drop-down l ist, select a databaseinstance for the data source that stores the primary table for the project. Al lof the columns in this primary table must also be present in the other copiesof the table from other data sources. Any addi tional columns avai lable inother copies of the table that are used as secondary tables are not includedin the MicroStrategy project.

The Secondary Database Instances pane l ists the other data sources thatthe table is avai lable from for the project. You can clear the check box nextto a data source to remove that copy of the table from the project.

Cl ick OK . You are returned to the Warehouse Catalog.

Cl ick Save and Close to save your changes and close the WarehouseCatalog.

Importing tables from multiple data sources in a project using Architect

Prerequisi tes

You must have the MultiSource Option to connect mul tiple data sources to aproject.

To import tables from multiple data sources in a project using

Architect


From the Schema menu, select Architect. MicroStrategy Archi tect opens.

From the Project Tables View, in the Warehouse Tables pane, expand thedatabase instance for one of the data sources the table resides in. The fi rst



data source you use to import a table should be the one you plan to use asthe primary data source for the table.

Importing a table from the primary database instance for a project or anon-primary database instance has an effect on how the table is updatedwhen the primary database instance for a project is changed, asdescribed in Importing tables as part of the project's primary databaseinstance, page 365.

From the Warehouse Tables pane, right-cl ick the table to add to the projectand select Add Table to Project. The fi rst copy of the table is added to theproject and is displayed in the Project Tables View of Archi tect.

To add copies of a table from other database instances

From the Warehouse Tables pane, expand the database instance for adi fferent data source that also includes the table.

From the Warehouse Tables pane, right-cl ick the table to add to the projectand select Add Table to Project.

If al l of the required condi tions to import mul tiple copies of the table(l isted in Supporting dupl icate tables in multiple data sources , page359) are met, an Options dialog box opens. To include a copy of thetable in the project, select Indicate that TABLE_NAME is also availablefrom the current DB instance, and cl ick OK . The copy of the table isadded to the project and is displayed in the Project Tables View ofArchi tect.

Review any messages displayed when attempting to import a copy of atable from a di fferent data source.

To add additional tables and configure the tables included in the project

To add tables from addi tional data sources, repeat the steps in To addcopies of a table from other database instances, page 364 above.



From the Project Tables View, select the table. Information on the table isdisplayed in the Properties pane.

From the Properties pane, select the Primary DB Instance option, and thencl ick ... (Browse). The Avai lable Database Instances dialog box opens.

From the Primary Database Instance drop-down l ist, select a databaseinstance for the data source that stores the primary table for the project. Al lof the columns in this primary table must also be present in the other copiesof the table from other data sources. Any addi tional columns avai lable inother copies of the table that are used as secondary tables are not includedin the MicroStrategy project.

The Secondary Database Instances pane l ists the other data sources thatthe table is avai lable from for the project. You can clear the check box nextto a data source to remove that copy of the table from the project.

Cl ick OK . You are returned to Archi tect.

Cl ick Save and Close to save your changes and close the WarehouseCatalog.

Importing tables as part of the project's primary database instance

Importing a table from the primary database instance for a project or a non-primary database instance has an effect on how the table is updated whenthe primary database instance for a project is changed:

If you import a table from the primary database instance for a project, thetable's primary data source is updated when the primary database instancefor the project is changed. This supports scenarios such as moving from atesting environment to a production environment where di fferent databaseinstances are used for each environment.

For example, tables are imported into a project from the primarydatabase instance of a project. The primary database instance is fortesting purposes. When the system is switched into production, a newproduction database instance is defined as the new primary database



instance for the project. During the switch of primary databaseinstances, al l tables that were imported with the original (testing)primary database instance are modi fied to use the new (production)primary database instance. This example scenario is shown below,which i l lustrates that the tables remain connected to the new primarydatabase instance.

If you import a table from a non-primary database instance for a project, thedatabase instance used for the ini tial import remains as the primary datasource for the table. This supports scenarios in which a table is onlyprovided in secondary data sources that are not the primary data source forthe project.

You can modi fy a table to always use the primary database instance asi ts primary data source. Steps on how to switch the database instancefor a table are provided below.

To switch primary database instances for a table





In the Tables being used in the project area, right-cl ick a table and selectTable Database Instances. The Avai lable Database Instances dialog boxopens.

From the Primary Database Instance drop-down l ist, select the databaseinstance to act as the primary database instance for the table:

The database instance that is used as the primary database instance for aproject is l isted twice in the drop-down l ist. An example of this is shownbelow:

If you select the database instance that is l isted as the project's primarydatabase instance, the table's primary data source is updated when theprimary database instance for the project is changed.

If you select the database instance that is l isted without the project primarydatabase instance distinction, this database instance remains as theprimary data source for the table even i f a new project primary databaseinstance is selected.

The other database instances l isted that are not the project's primarydatabase instance can also be selected. If selected, the database instanceremains as the primary data source for the table.

Cl ick OK . If any warnings are displayed, read the information and take anyrequired action.

In the Warehouse Catalog, cl ick Save and Close to save your changes.



Improving database insert performance:parameterized queries

MicroStrategy's support for parameterized queries can improve performancein scenarios that require the insertion of information into a database. Thescenarios that can benefi t from the use of parameterized queries include:

Reports that combine data from multiple data sources using MicroStrategyMultiSource Option. For information on MultiSource Option, see Accessingmultiple data sources in a project, page 353.

MicroStrategy data marts that are stored in a database other than thedatabase used for the main data warehouse. For information on creatingand using data marts, refer to the Advanced Reporting Guide.

Metrics that use functions that are evaluated by the Analytical Engine. Forinformation on functions, refer to the Functions Reference.

Custom groups that use banding qual i fications that are evaluated as normalcalculations. For information on custom groups, refer to the AdvancedReporting Guide.

Parameterized queries are SQL queries that can use placeholders for data.Using placeholders al lows these queries to be re-used. A commonappl ication of this re-usabi l i ty is to combine multiple inserts of data into adatabase as a single query. The fol lowing is an example of a parameterizedquery:

INSERT INTO DMTABLE (Customer_ID, Customer_Name) VALUES (?, ?)

Combining multiple INSERT statements into a single query can improve theperformance of inserting data into the database. The steps below show youhow to enable the use of parameterized queries in MicroStrategy.

If you enable parameterized queries for a Netezza database that includes datathat uses the WCHAR data type, this can cause some characters to bereturned incorrectly as question mark (? ) characters. If you encounter this







type of data inconsistency, you can configure the Use Column Type Hint forParameterized Query VLDB property to return the WCHAR data accurately.For information on configuring this VLDB property, see the SystemAdministration Guide .

Prerequisites

Parameterized queries are only supported by certain databases. Refer toyour thi rd-party database documentation to ensure that your database cansupport parameterized queries.

A database instance has been created. This database instance mustconnect to the database to enable support for parameterized queries.

To enable the use of parameterized queries

In MicroStrategy Developer, log in to a project source with a user accountthat has administrative privi leges.

From the Folder List, expand Administration , then expand ConfigurationManagers, and then select Database Instances. Database instances forthe project source are displayed.

Right-cl ick a database instance and select Edit. The Database InstancesEdi tor opens.

To the right of the Database connection area, cl ick Modify. The DatabaseConnections dialog box opens.

On the Advanced tab, select the Use parameterized queries check box.

If you are enabl ing parameterized queries for one of the databases l istedbelow, you must also include the fol lowing parameters:

To enable parameterized queries for Oracle 10g, Oracle 10gR2, Oracle 11g,Oracle 9i , Sybase Adaptive Server 12.x, or Sybase ASE 15.x, type thefol lowing parameter in the Additional connection string parameters field:

EnableDescribeParam=1





To enable parameterized queries for Teradata 12.0 or Teradata V2R6.2,type the fol lowing parameter in the Additional connection stringparameters field:

EnableExtendedStmtInfo=Yes

Click OK to accept your changes and close the Database Connectionsdialog box.

Cl ick OK to close the Database Instances Edi tor.

Using summary tables to store data: Aggregate tables

Aggregate tables are summary tables that store data at higher levels than i twas stored when the data was ini tial ly captured and saved. Aggregatetables provide quicker access to frequently requested information, whi leretaining the tradi tional power of ROLAP to directly query the database toanswer any questions. This section describes how and why aggregatetables are used.

MicroStrategy creates aggregates only on fact tables since lookup tablesand relationship tables are usual ly signi ficantly smal ler. To understandaggregate tables, you should be fami l iar wi th fact tables in the context ofdata model ing and data warehousing. For more information on these topics,see Chapter 2, The Logical Data Model , Chapter 3, Warehouse Structure forYour Logical Data Model , and Chapter 6, The Bui lding Blocks of BusinessData: Facts.

When to use aggregate tablesMicroStrategy uses optimized SQL to query the relational database directlyto answer users' questions. Users can ask any question that is supported bythe data in their warehouse and then analyze the resul ts unti l they find aprecise answer.

The disadvantage to this relational OLAP (ROLAP) methodology is thataccessing huge fact tables can be potential ly time-consuming.



Multidimensional OLAP (MOLAP) is sometimes considered by some to bethe answer to this problem. However, MOLAP is not scalable for largeprojects because of the di fficul ty of maintaining every possible combinationof aggregates as the number of attributes and the amount of data increases.MicroStrategy's solution is the use of aggregate tables to provide quickeraccess to frequently-accessed data whi le sti l l retaining the power to answerany user query.

Aggregate tables are advantageous because they:

Reduce input/output, CPU, RAM, and swapping requirements

El iminate the need to perform dynamic calculations

Decrease the number of physical disk reads and the number of records thatmust be read to satisfy a query

Minimize the amount of data that must be aggregated and sorted at run time

Move time-intensive calculations with compl icated logic or signi ficantcomputations into a batch routine from dynamic SQL executed at report runtime

In summary, the MicroStrategy SQL Engine, in combination with aggregatetables and caching, can produce resul ts at about the same speed asMOLAP. This combined solution al lows questions to be answered on the flyand is also scalable for large databases.

Aggregation versus pre-aggregation

Whenever the display level of data on a report must di ffer from the level atwhich the data is ini tial ly captured, aggregation, that is, the rol l ing up ofdata, must occur. By defaul t, aggregation occurs dynamical ly wi th a SQLstatement at report run-time.

For example, sales data is stored by day in a fact table. A report requestingmonth-level data is executed. The dai ly values from the fact table areselected, sorted, and added to produce the monthly totals, as shown below.



Aggregation can also be completed before reports are executed; the resul tsof the aggregation are stored in an aggregate table. This process is cal ledpre-aggregation. You can bui ld these pre-aggregated—or aggregate—tables as part of the ETL process. If sales data is frequently requested atthe month level , as in the previous example, an aggregate table wi th thesales data rol led up to the month level is useful .

Pre-aggregation el iminates the reading, sorting, and calculation of datafrom many database rows in a large, lower-level fact table at run time, asshown in the fol lowing example.



If the dai ly sales fact table is the lowest-level fact table and containsatomic-level data, i t is referred to as a base table. In these terms, anaggregate table is any fact table whose data is derived by aggregating datafrom an existing base table.

Degree of aggregation

While MOLAP can provide fast performance when i t answers a question, i trequires a completely aggregated schema to answer most questions. Thatis, every possible combination of aggregate associations must begenerated when the multidimensional cube is bui l t. This ensures that al lpossible questions can be answered. This scenario becomes very di fficul tto maintain as the number of attributes and the amount of data increase,and therefore is not very scalable.



In a ROLAP environment, the degree of aggregation can be as dense or assparse as is appropriate for your users. A densely aggregated warehousehas a large number of aggregate tables whi le a sparsely aggregatedwarehouse has fewer. Sparse aggregation refers to the fact that a givenproject only requires as many aggregate fact tables as is useful to i ts users.

ROLAP, therefore, provides much greater flexibi l i ty than MOLAP. Only theaggregate combinations that you determine are beneficial must be created.That is, i f the aggregate table is useful in answering frequently-askedqueries, i ts presence provides a response as fast as a MOLAP system canprovide. However, i f a certain aggregate combination is rarely or neverused, the space in the RDBMS does not need to be consumed and theresources to bui ld that table during the batch process do not need to beused.

Not every attribute level or hierarchy intersection is sui table for pre-aggregation. Bui ld aggregate tables only i f they can benefi t users, since thecreation and maintenance of aggregate tables requires addi tional work bythe database administrator. Also, do not waste database space for tablesthat wi l l not be used.

Consider the fol lowing factors when deciding whether to create aggregatetables:

The frequency of queries at that level—Determining the frequency ofqueries at a speci fic level , page 374

The relationship between the parent and chi ld—Considering any relatedparent-chi ld relationships, page 375

The compression ratio—Compression ratio, page 376

Determining the frequency of queries at a specific levelBui ld aggregate tables only i f they can be useful to your users. If aggregatetables are never accessed, they consume disk space and imposeunnecessary burdens on the extraction, translation, and loading process, aswel l as the database backup routines.



However, usefulness is not always easy to quanti fy. For example, considerthe fol lowing hierarchy:

A summary of data at the department level seems to be a good candidatefor an aggregate table. However, i f users frequently want to excludeinactive i tems, the query must use i tem-level data and summarize thedepartment data dynamical ly. Therefore, the department aggregate tableswould not be used in this si tuation.

Once your warehouse is in production, trace the usage of any aggregatetables to determine how frequently they are used in a day-to-day businessenvironment. If any table is not used, el iminate i t from the warehouse.

MicroStrategy Enterprise Manager al lows you to easi ly track table usage.For more information on Enterprise Manager, see the System AdministrationGuide.

Considering any related parent-child relationshipsWhen an aggregate table is created, the chi ld records are usual lysummarized into the parent record, based on the key combinations in arelationship table. In any hierarchical relationship, when the parent-chi ldrelationship is al tered, al l tables that hold that relationship or data relevantto i t must be updated. Whether these relationships are dynamic or staticchange how they are aggregated into tables.

Dynamic relationships

When the relationship between parent and chi ld elements change, therelationship is cal led dynamic. These changes often occur because of





organizational restructuring; geographical real ignment; or the addi tion,reclassi fication, or discontinuation of i tems or services. For example, astore can decide to reclassi fy the department to which i tems belong.

Aggregate tables that contain dynamic relationships must be recalculatedevery time a change is made. If the tables are large, this process can taketime, consume resources, and compl icate the batch process. Frequentchanges can mean aggregate tables are not optimal for this si tuation.Consider the frequency of the changes, the table size, and the impact onthe batch process, and then balance the disadvantages against theadvantages of having an aggregate table.

Also, rol l ing up an enti re hierarchy can avoid many problems withrelationship changes. For example, a table contains one value for the sumof al l stores. It is not affected by a reorganization within the geographyhierarchy.

Static relationships

When elements rarely or never change relationships, they are a part ofstatic relationships. In these cases, maintaining aggregate tables is veryeasy. For example, time hierarchies are seldom dynamic—days do notmigrate into di fferent weeks, and fiscal weeks do not move into di fferentmonths.

Compression ratioThe process of data aggregation appl ies an aggregate function, such assum or average, to a set of chi ld records to produce a single parent record.The average number of chi ld records combined to calculate one parentrecord is cal led the compression ratio. One measure of effectiveness of anaggregate table can be estimated from this number, since i t represents thedecrease in records that must be read to respond to a query at that level .

Recal l that some of the reasons to bui ld aggregate tables include thereduction of disk I/O and the number of records that must be dynamical ly



sorted and aggregated. Therefore, pre-aggregating data is effective only i fthe compression ratio is signi ficant. For example, i f the compression ratio is3:2, the aggregate table requires 2/3 of the base table's storage space butyields only a 1/3 reduction in the number of records. In contrast, i f thecompression ratio is 4:1, the aggregate table reduces the number of recordsby 3/4 and uses only 1/4 of the storage space.

When the number of elements di ffers signi ficantly between two attributes inthe same hierarchy, the compression ratio suggests that an aggregate tablecan provide more efficient queries. Also, for smal ler base tables, theresource demands placed on the database server by dynamic aggregationsdecrease and therefore so does the effectiveness of pre-aggregation. Todetermine when pre-aggregation is worthwhi le for your system, you mustbalance the importance of speed of query response time and the avai labi l i tyof disk space and resources to maintain the schema.

For more information on ratios, refer to Another enhancement to the logicaldata model is the addi tion of cardinal i ties and ratios for each attribute.Cardinal i ty is the number of unique elements for an attribute and ratios arethe ratios between the cardinal i ties of related attributes., page 38.

Creating aggregate tablesYou can integrate aggregate tables in your project using the WarehouseCatalog in MicroStrategy Developer, as outl ined in the fol lowing procedure.

To use an aggregate table in an existing project

Using the Warehouse Catalog, add the table to the project. For steps to addtables using the Warehouse Catalog, see Adding and removing tables for aproject, page 329.

Use the new table in the desired fact expressions and attribute formexpressions.

If your aggregate table structure is consistent wi th your base fact tablestructure, Archi tect automatical ly adds i t to the defini tions of your existing



attributes and facts. In other words, Archi tect is aggregate-aware. How doesArchi tect know to use the aggregate table rather than the base fact table,when ei ther could provide the answer to a query? The answer is logicaltable size.

The size of tables in a project: Logical table sizeMicroStrategy Developer assigns a size to every table in the project whenyou fi rst add them to the project. These size assignments are stored in themetadata and are calculated based on the table columns and theircorresponding attributes. Because Developer uses the conceptual or logicalattribute defini tions when assigning sizes, this measurement is known asthe logical table size.

When you run a report, the Analytical Engine chooses the smal lest of al ltables, based on logical table size, that contains enough data to answer thequery. The ini tial logical table size is based on the number of attributecolumns and the various levels at which they exist in their respectivehierarchies. For information on defining the logical table size of a table, seeDefining logical table sizes, page 507.

Dividing tables to increase performance: Partit ionmapping

Parti tion mapping involves the division of large logical tables into smal lerphysical tables; this division is based on a definable data level , such asmonth or department. Parti tions improve query performance by minimizingthe number of tables and records within a table that must be read to satisfyqueries issued against the warehouse. By distributing usage acrossmultiple tables, parti tions improve the speed and efficiency of databasequeries.

Time is the most common category for parti tioning databases. Parti tioningby time l imi ts growth of the database tables and increases stabi l i ty.



Server versus application partitioningParti tioning can be managed by ei ther the database server or theMicroStrategy appl ication. Ei ther way, tables are parti tioned at thedatabase level . The terms "appl ication" and "server" refer to what managesthe parti tioned tables, not where the tables are spl i t.

Server-level partitioning

The database server, rather than MicroStrategy, manages the parti tionedtables in RDBMS server-level parti tioning. The original fact table is notphysical ly broken into smal ler tables. Instead, the database server logical lyparti tions the table according to parameters speci fied by the databaseadministrator. You do not need to take any action in MicroStrategy tosupport the parti tioning.

Since only the logical table is displayed to the end user, the parti tioning istransparent to MicroStrategy. In contrast, in appl ication-level parti tioningthe relational database is unaware of the parti tioned tables.

Refer to your database documentation for detai ls on server parti tioning foryour particular platform.

Application-level partitioning

In appl ication-level parti tioning the appl ication, rather than the RDBMSserver, manages the parti tion tables. A parti tion base table (PBT) is awarehouse table that contains one part of a larger set of data. Parti tiontables are usual ly divided along logical l ines, such as time or geography.MicroStrategy supports two types of parti tioning:

Metadata parti tion mapping, page 380—stores the mapping information inthe project metadata

Warehouse parti tion mapping, page 382—uses a special ized warehousetable to determine which table to access



Metadata partition mappingMetadata parti tion mapping is the mapping of parti tions where the mappingof parti tions is performed and maintained in the project metadata by theappl ication, in this case, MicroStrategy. MicroStrategy manages themapping between the logical table and the physical tables. This approachmakes i t easier for you to speci fy a flexible parti tioning schema.

In metadata parti tion mapping, you speci fy one or more parti tioningattributes in the Metadata Parti tion Mapping Edi tor. Next you define whatattribute elements wi thin those attributes should point to which PBT. Youcreate al l of the rules for choosing the appropriate PBT here and the rulesare stored in the MicroStrategy metadata.

If you have the MultiSource Option (see Accessing multiple data sources ina project, page 353) you can also support fact tables that are parti tionedacross multiple databases.

For steps to create a metadata parti tion mapping, refer to the MicroStrategyDeveloper Help.

Homogenous and heterogeneous partitions

Metadata parti tions can be homogenous or heterogeneous. Withheterogeneous parti tioning, the PBTs can have di fferent amounts of datastored in them at di fferent levels. For example, one table can contain sixmonths of sales data, whi le another stores an enti re year. The PBT level , orkey, refers to how the data is stored. For example, sales data for the currentyear can be stored at the dai ly level , whi le historical sales data is saved bymonth only. Heterogeneous parti tions can therefore require addi tional long-term maintenance and organization because the data contained in them isstored at various levels throughout the parti tion.

MicroStrategy stores one PBT level for each parti tion. If al l the PBTs withina parti tion are not stored at the same level , the highest PBT level is usedas the PBT level of the parti tion. For instance, i f al l the sales data in the



previous example is stored in one parti tion, you cannot access currentsales at the day level . This is because the PBT level for the parti tion ismonth, which is higher than day. If you save current data in a parti tion atthe dai ly level and the historical data in another parti tion at the month level ,you are able to ful ly access the data.

In contrast, homogenous parti tions must have the same amount of datastored at the same PBT level . The logical structure of the PBTs must be thesame, that is, they must have the same facts and attributes defined. Tocontinue with the previous examples, each table must store one year ofdata at the month level . Homogeneous parti tions work wel l for frequently-accessed data such as information about the previous year.

When you define the particular PBT to which an attribute is l inked inMicroStrategy, you do not need to speci fy whether the PBT is homogeneousor heterogeneous. MicroStrategy makes the distinction automatical lydepending, in part, on how the data is stored in the PBT.

Data slices

After PBTs are created, you define a data sl ice. The data sl ice acts as afi l ter that describes what portions of data are placed in the parti tion table.Based on this data sl ice, the MicroStrategy engine knows which table to getdata from when generating the SQL.

A data sl ice holds the parameters that a parti tion is based upon, forexample, Month=January. Instead of retrieving data for al l months, theserver knows to access a particular table that contains the data for Januaryonly. By creating a data sl ice with the parti tion, you can retrieve speci ficdata quickly wi thout time-consuming joins and searches.

It is important to create a reasonable and val id data sl ice becauseMicroStrategy cannot veri fy i ts accuracy or relevance. The data sl ice mustmake sense for the data. A poorly crafted data sl ice can lead to errors fromgenerating incorrect SQL and retrieving the wrong data.



Data sl icing displays and can be modi fied only for the metadataparti tioning. Each parti tion mapping table must include at least one datasl ice. In a heterogeneous mapping, data sl ices can exist at di fferent levelsand can be composed of di fferent keys.

Attribute qualifications

To create data sl ices, you use attribute qual i fications. Attributequal i fications are types of fi l ters that are appl ied to attribute forms. Thesequal i fications al low you to l imi t the type and amount of data that is returnedfor a report. For example, i f you create a report that contains the attributeCountry but you want to return only the data for France, you can create aqual i fication on the attribute Country and select France as the element thatappears on the report.

For steps to create a data sl ice, refer to the MicroStrategy Developer Help.

Warehouse partition mappingWarehouse parti tion mapping is the mapping of parti tions, where themapping is performed by and maintained in the data warehouse. You candefine a warehouse parti tion by using the MicroStrategy WarehouseCatalog to add a table wi th a special structure. This table contains the mapfor the parti tion, and is stored in the warehouse. Warehouse parti tionsdivide tables physical ly along any number of attributes, al though this is notvisible to the user.

Warehouse parti tions must be homogenous, unl ike metadata parti tions, sothat the same amount of data is stored at the same PBT level and the samefacts and attributes are defined. Homogenous parti tioning divides data ofequal levels, l ike January and February. A sample fact table andwarehouse parti tioning table are shown below for months. Note how thedata exists at equal levels, for example, di fferent months of the same year.



The original fact table, which contains al l of the data, is not brought into theproject. Rather, the database administrator creates multiple smal lerphysical tables in the data warehouse. Each table contains a subset of thedata in the original fact table. The database administrator is responsible forkeeping the parti tions consistent and up-to-date. He or she must also createand maintain a parti tion mapping table (PMT), which is used to identi fy andkeep track of the parti tioned base tables as part of a logical whole.

After the PMT is created, when you run a report in Developer or Web thatrequires information from one of the PBTs, the Query Engine fi rst runs apre-query to the PMT to determine which PBT to access to bring the databack for the report. The pre-query requests the PBT names associated withthe attribute IDs from the fi l tering cri teria. When i t finds the name of thePBT, i t cal ls the SQL Engine to wri te the appropriate SQL for thewarehouse.

When using warehouse partition mapping, it is usually not necessary to bringin the indiv idual PBT tables into the project. Doing so can cause errors if suchtables are mistakenly mapped directly to schema objects. You should onlyinclude the PMT table in the project. With this strategy you can map all relatedschema objects to the PMT, which then accesses the correct PBT in thewarehouse.

There are no data slices in a warehouse partition.



MicroStrategy supports warehouse partitions on both upgraded and newlycreated projects. These are added using the Warehouse Catalog Browser. Forsteps to add warehouse partitions, refer to the MicroStrategy DeveloperHelp (formerly the MicroStrategy Desktop Help).

Metadata versus warehouse partition mappingMetadata parti tion mapping does not require any addi tional tables in thewarehouse. Metadata parti tion mapping is general ly recommended overwarehouse parti tion mapping in MicroStrategy. However, i f you alreadyhave warehouse parti tion tables set up and are migrating to a newerversion of MicroStrategy, you can continue to use the warehouse parti tions.If you are creating parti tions for the fi rst time, however, i t is recommendedyou implement metadata parti tion mapping.

Metadata parti tion mapping is recommended because you create the rulesin MicroStrategy that the Query Engine uses to generate the SQL to runreports. Because you create the parti tions directly in the metadata, i t iseasier to maintain.

Metadata parti tion mapping also al lows both heterogeneous andhomogenous parti tions, unl ike warehouse parti tion mapping. Withheterogeneous parti tions, the PBTs can have di fferent amounts of datastored in them at di fferent levels. Only homogenous parti tions can be usedin warehouse parti tion mapping. For steps to map parti tions, refer to theMicroStrategy Developer Help (formerly the MicroStrategy Desktop Help).



CREATING H IERARCHIESTO ORGANIZE ANDBROWSE ATTRIBUTES



Hierarchies are groupings of attributes that can be displayed, ei ther orderedor unordered, to reflect the relationships that exist between the attributes ina project.

In Chapter 2, The Logical Data Model , you learned how to use hierarchiesto group related attributes in practical business areas. For example, youcan include a Time hierarchy in your model that consists of Day, Week,Month, and Year attributes.

This chapter discusses hierarchies as they exist in the MicroStrategyenvironment and provides information on the two di fferent types ofhierarchies in MicroStrategy. These types of hierarchies include the systemhierarchy and the user hierarchy. The system hierarchy is automatical lycreated when you create a project and is maintained by the relationshipsthat exist among the project's schema objects. The user hierarchy is ahierarchy which you create speci fical ly for your report designers.



This chapter explores how to create and configure user hierarchies inMicroStrategy and provides addi tional information about hierarchyfunctional i ty in MicroStrategy Developer.

Creating user hierarchies

In MicroStrategy Developer, you create user hierarchies using theHierarchy Edi tor or Archi tect. For an introduction to user hierarchies andsystem hierarchies, see Types of hierarchies, page 389.

Fol low the procedure below to create a user hierarchy with the HierarchyEdi tor. For information on how to use Archi tect, see Creating userhierarchies using Archi tect, page 389.

To create a new user hierarchy

In MicroStrategy Developer, log into the project source that contains yourproject and open the project.

In the Folder List, navigate to and open the Schema Objects folder.

Open the Hierarchies folder, and then the Data Explorer folder.

From the File menu, select New, and then Hierarchy. The Hierarchy Edi toropens, fol lowed immediately by the Select Attributes dialog box.

In the Avai lable objects pane, select the attributes to use in the hierarchyand cl ick the arrow to add them to the Selected objects pane. Cl ick OK toclose the Select Attributes dialog box. The attributes you selected appear inthe Hierarchy Viewer.

The arrows that connect certain attributes denote a relationship betweenthe connected attributes. You can use these relationships as the browsingor dri l l ing relationships for your hierarchy, or you can create your own.

To create a browsing or dri l l ing relationship, select in the middle of anattribute that is to be enabled to browse to and/or dri l l down to another



attribute. Drag from the middle of the attribute to the related attribute. Abrowsing and/or dri l l ing relationship is created between the twoattributes.

To use the hierarchy as a dri l l hierarchy, select the Use as a drillhierarchy check box at the bottom of the Hierarchy Edi tor. If you clear thischeck box, the hierarchy is only used for browsing.

A dri l l hierarchy can be used for browsing as wel l as dri l l ing. Dri l lhierarchies are discussed in Hierarchy browsing, page 402.

Each attribute in a user hierarchy has properties that affect how thatattribute is displayed and accessed in a hierarchy. You can right-cl ick anattribute and configure the properties l isted below:

Define Browse Attributes: Defines the attributes to which users canbrowse to and/or dri l l to from the selected attribute. These relationships canalso be defined by dragging-and-dropping from one attribute to another asdescribed earl ier in this procedure.

Define Attribute Filters: Speci fies whether the data retrieved anddisplayed should be complete or fi l tered by any speci fic cri teria. A fi l ter ona hierarchy acts l ike a fi l ter in a report. Only data satisfying the fi l ter cri teriais displayed (see Fi l tering attributes in a hierarchy, page 398).

Set As Entry Point: Speci fies whether the user can begin browsing in thishierarchy using this attribute (see Entry point, page 400).

Element Display: Determines the elements a user can see. The elementdisplay may be Locked , Unlocked , or Limited (see Control l ing the displayof attribute elements, page 394).

Cl ick Save and Close. The Save As dialog box opens.

Type a name for the hierarchy. Then navigate to the location in which youwant to save the hierarchy.

You can save user hierarchies in any folder. However, to make the userhierarchy avai lable for element browsing in the Data Explorer, you must



place i t in the Data Explorer sub-folder wi thin the Hierarchies folder.This is discussed in Hierarchy browsing, page 402.


Creating user hierarchies using ArchitectArchi tect can be used to create and modi fy user hierarchies in a visual lyintegrated environment. Archi tect al lows you to view the tables, attributes,attribute relationships, facts, user hierarchies, and other project objectstogether as you design your project.

With Archi tect, you can support al l of the features that are avai lable in theHierarchy Edi tor. Rather than focusing on one hierarchy at a time with theHierarchy Edi tor, you can use Archi tect to create and modi fy mul tiplehierarchies for a project at one time. Review the chapters and sectionsl isted below for information on Archi tect and steps to create and modi fyuser hierarchies using Archi tect:




Types of hierarchies

The two types of hierarchies that exist in MicroStrategy include:

System hierarchy: The system hierarchy is created according to therelationships defined between the attributes in your project. You do notneed to create the system hierarchy; i t is automatical ly created inDeveloper when you create a project. Al though the system hierarchyspeci fies an ordered set of al l attributes in the project, i t does not defineordering or grouping among attributes. The ordering and grouping ofattributes, among other configurations, is defined in user hierarchies.



User hierarchy: User hierarchies are groups of attributes and theirrelationships to each other, arranged in ways that make sense to abusiness organization. They are user-defined and do not need to fol low thelogical data model . As the structure of your business intel l igence systemevolves, you can modi fy the design of a user hierarchy to include addi tionalattributes or l imi t user access to certain attributes. This type of hierarchy iscreated to provide flexibi l i ty in element browsing and report dri l l ing. Stepsto create user hierarchies are discussed in:

Creating user hierarchies, page 387, which describes creating userhierarchies with the Hierarchy Edi tor.

Creating and modi fying user hierarchies, page 202, which describescreating user hierarchies using Archi tect.

System hierarchy: Project schema definitionThe system hierarchy is the defaul t hierarchy that MicroStrategy sets up foryou each time you create a project. It contains al l of the attributes in theproject and is actual ly part of the schema defini tion. When you fi rst create aproject, the only hierarchy i t contains is the system hierarchy.

The system hierarchy holds information on the relationships betweenattributes in the project. The system hierarchy cannot be edi ted but isupdated every time you add or remove attribute chi ldren or parents in theAttribute Editor , or when you define attribute chi ldren in the ProjectCreation Assistant .

The system hierarchy is useful in determining relationships between al lobjects in the project. Attributes from the system hierarchy do not need tobe part of an expl ici tly-defined user hierarchy. Any attributes that are notassigned to a user hierarchy remain avai lable to the system as reportobjects, fi l ter condi tions, and components of consol idations. These reportobjects are discussed in detai l in the Advanced Reporting Guide.

You can view the system hierarchy in the Data Explorer or in the HierarchyViewer, but not the Hierarchy Edi tor. You can access the Hierarchy Viewer




from Graphical View in the Schema menu. The Hierarchy Viewer isdiscussed in detai l in Using the Hierarchy Viewer, page 408.

User hierarchies: Logical business relationshipsUser hierarchies are sets of attributes and their relationships, arranged inspeci fic sequences for a logical business organization. You create userhierarchies to define the browse and dri l l relationships between attributes.For example, you can create a Time hierarchy that contains the Year,Quarter, Month, and Day attributes. When you browse the attributes in theData Explorer, you can double-cl ick Year to get to Quarter and double-cl ickQuarter to get to Month, and so on.

Whereas browsing occurs through the Data Explorer, in dri l l ing the useractual ly chooses to move to higher or lower levels on a report or moveacross to levels wi thin di fferent hierarchies. For example, i f the user dri l lson the Quarter attribute in a report, he or she can dri l l down to Month, up toYear, or across to an attribute wi thin another hierarchy.

You can create user hierarchies in the Hierarchy Edi tor using one or moreattributes from the system hierarchy.

A user hierarchy is the only type of hierarchy you can define, and you cancreate any number of user hierarchies for each project. You should defineuser hierarchies that correspond to speci fic areas of your companybusiness model and data warehouse schema.

Hierarchy organization

The best design for a user hierarchy is to organize or group attributes intological business areas. This al lows users to more easi ly locate attributes ina project and navigate from one attribute to another. For example, you canplace related attributes into hierarchies by their level .

The example below demonstrates the Location and Customer hierarchies.Within the Location hierarchy, State, Ci ty, and Store are organized



according to their relationships to each other. The Customer hierarchy alsogroups together the attributes Company, Contact, and Customer.

When creating user hierarchies, keep in mind that hierarchies do not haveto be separate from one another or necessari ly fol low the dimensionalstructure of your logical data model .

Hierarchy structureWhile both a system hierarchy and user hierarchy al low you to navigateattributes in your project, only the user hierarchy al lows you to logical lydefine and order groups of attributes.

The rest of this chapter discusses user hierarchies and how to create andconfigure them in your project.

When you group attributes together into user hierarchies, you aredeveloping a working design of the display and browse functions of theattributes. In the example below, there are two instances of the Regionhierarchy. One hierarchy demonstrates Region having multiple States andthe States having multiple Stores.

This hierarchy al lows you to create dri l l ing and browsing options to thelower levels to view Region, State, and Store on a report. However, i f youonly include Store in the Region hierarchy, as in the second example, thenthe only options for dri l l ing or browsing are the Region and Store levels.



Viewing hierarchies: Hierarchy ViewerThe Hierarchy Viewer graphical ly represents user hierarchies and thesystem hierarchy. In the system hierarchy, the connections between theattributes represent the parent-chi ld relationships. In user hierarchies, theconnections show the browse paths between the attributes. The Aerialperspective provides an overview of hierarchies; i ts decreased scale al lowsyou to navigate through the enti re project.

The Hierarchy Viewer is accessed from the Graphical View option in theSchema menu. The Hierarchy Viewer is discussed in further detai l in Usingthe Hierarchy Viewer, page 408.

Configuring hierarchy display options

Each attribute in a user hierarchy has properties that affect how thatattribute is displayed and accessed in a hierarchy. You can use theHierarchy Edi tor to configure each of these properties, as shown in thefol lowing procedures:

Element Display: Determines the elements a user can see. The elementdisplay may be locked, unlocked, or l imi ted (see Control l ing the display ofattribute elements, page 394).

Attribute Fi l ters: Speci fies whether the data retrieved and displayed shouldbe complete or fi l tered by any speci fic cri teria. A fi l ter on a hierarchy acts



l ike a fi l ter in a report. Only data satisfying the fi l ter cri teria is displayed(see Fi l tering attributes in a hierarchy, page 398).

Entry Point/Not an Entry Point: Speci fies whether the user can beginbrowsing in this hierarchy using this attribute (see Entry point, page 400).

Browse Attributes: Shows the attributes to which users can browse from agiven attribute. Represented by l ines that connect one attribute to others(see Hierarchy browsing, page 402).

The fol lowing sections explain these properties and how to use theHierarchy Edi tor to configure each.

Controlling the display of attribute elementsThe sections l isted below describe various techniques to control the displayof attribute elements:

Locked/Unlocked attribute elements, page 394

Limited attribute elements, page 396

Locked/Unlocked attribute elements

Locking a hierarchy prevents a user from viewing al l elements of thespeci fic attribute and any lower level attributes in the hierarchy. A hierarchyis referred to as locked when at least one attribute wi thin that hierarchy hasthe Element Display option set to Locked. Anything higher in the hierarchyis sti l l visible.

You can lock the hierarchy to restrict the user from viewing elements andlower level attributes for securi ty reasons or to better manage lengthyhierarchies. By restricting the view of attribute elements and lower levelattributes in the Data Explorer, you can prevent the expansion of longattribute element l ists that can consume system resources. When you setthe element display to locked, a padlock icon appears next to the attributename.



For example, the attribute Order is locked in the Data Explorer sampleshown below.

Whi le the user can view the attribute elements of Customer Region andCustomer Ci ty, he or she cannot view information about each customer'sorder. The Order attribute may be locked in order to prevent unauthorizedusers from accessing sensi tive information about customer orders.

Prerequisi tes

A hierarchy has been created.

To lock or unlock an attribute in a hierarchy

In MicroStrategy Developer, open a hierarchy using ei ther the HierarchyEdi tor or Archi tect, as described below:

Locate a hierarchy in the Folder List, right-cl ick the hierarchy, and selectEdit. The Hierarchy Edi tor opens.


From the Hierarchy View, in the Hierarchies drop-down l ist, select ahierarchy.

If a message is displayed asking i f you want to use read only mode oredi t mode, select Edit and cl ick OK to open the schema edi tor in edi tmode so that you can make changes to the hierarchy.



If you are only given the option of using read only mode, this means anotheruser is modify ing the project's schema. You cannot use edit mode until theother user is finished with their changes and the schema is unlocked.


Lock or unlock an attribute using the options l isted below:

To lock an attribute, right-cl ick an attribute, point to Element Display, andthen select Locked . A padlock icon appears next to the locked attribute,and users can no longer view elements of this attribute.

To unlock a locked attribute, right-cl ick an attribute, point to ElementDisplay, and then select Unlocked . The padlock icon is removed from theattribute, and users can now view the elements of this attribute.

In the Hierarchy Edi tor or Archi tect, cl ick Save and Close to save yourchanges and return to Developer.


You can also lock and unlock attributes when you edi t them in the Displaytab of the Attribute Edi tor. However, this locks and unlocks the attributeswithin the system hierarchy, not any user hierarchies that contain theattributes. For example, i f the attribute Year is locked in the Attribute Edi tor,no elements for Year display in the Data Explorer when Year is expanded.

Limited attribute elements

Another way to restrict users from viewing attribute elements in the DataExplorer is to l imi t the number of elements that appear at one time. Thismethod is useful when there are extensive attribute elements in a hierarchy.Instead of loading al l attribute elements at once, you can set the l imi t to fiveor ten at a time. Also, retrieving a large number of elements at once can



negatively impact system performance. The user can then cl ick the arrowsto see the next set of elements for that attribute.

For example, the Chocolate subcategory, shown below, contains manyi tems. Rather than displaying al l of them at once and overwhelming theuser, a l imi t of five i tems has been set. The fol lowing graphic displays thisview in the Data Explorer.

Prerequisi tes


To limit the display of attributes in a hierarchy






If you are only given the option of using read only mode, this means another



user is modify ing the project's schema. You cannot use edit mode until theother user is finished with their changes and the schema is unlocked.


Right-cl ick the attribute to l imi t, point to Element Display, and then selectLimit. The Limit dialog box opens.

Type the number of elements to display at one time and cl ick OK .



Filtering attributes in a hierarchyBefore reading this section, refer to the Fi l ters chapter in the AdvancedReporting Guideto understand what fi l ters are and how to create them inMicroStrategy.

You can add fi l ters to a hierarchy to control how data is retrieved anddisplayed. With a fi l ter you can choose exactly which attribute elements todisplay in a hierarchy. For example, you can fi l ter a hierarchy so that datafor only one quarter is displayed, or data for only a few days of one quarter.Fi l ters make data retrieval faster by only al lowing speci fic data to bedisplayed.

You cannot use a prompt-based filter to filter a hierarchy.

Each attribute in the hierarchy can have multiple fi l ters appl ied to i t. Whenfi l tering attributes in a hierarchy, you are l imi ting the elements of the datareturned when you browse the Data Explorer. Creating a l imi ted hierarchyreduces the number of elements displayed at one time. Fi l ters, however,l imi t the elements a user is al lowed to see and therefore, perform a type ofsecuri ty.





Fi l ters increase efficiency when retrieving data because you can l imi t useraccess to parts of a hierarchy when you apply fi l ters to attributes. The fi l tersal low the Data Explorer to display only the cri teria you select, and the useris unable to see addi tional data in the hierarchy.

For example, you want to view only those customers who are younger than30 years old. First, create a fi l ter on Customer Age less than 30. In theHierarchy Edi tor, add the fi l ter to the Customer attribute. Update the projectschema, and view the Customer hierarchy in the Data Explorer. Only thosecustomers younger than 30 years old are displayed.

When adding filters to an attribute in a hierarchy, you need to make sure thateach filter is relevant to the attribute's information. MicroStrategy does notvalidate that the associated filter makes sense on that attribute.

Prerequisi tes

A fi l ter has been created.


To apply a filter to an attribute in a hierarchy










Right-cl ick the attribute to fi l ter and select Define Attribute Filters .

If a tip about fi l tering opens, cl ick OK . The Select Objects dialog boxopens.

In the Avai lable objects pane, select the fi l ters to apply and cl ick > to addthem to the Selected objects pane.

Cl ick OK to close the Select Objects dialog box. The attribute to which youappl ied the fi l ter appears in the hierarchy with a fi l ter icon.


Entry pointAn entry point is a shortcut to an attribute in the Data Explorer. Creating anentry point grants users faster access to the attribute wi thout having tobrowse through multiple attributes to reach di fferent levels in a hierarchy.This is especial ly useful when accessing frequently-used attributes.

When you create a user hierarchy, the hierarchy, the attributes, and theirelements appear in the Data Explorer. When you set an attribute to be anentry point, you are creating a shorter route to access that attribute. Forexample, a typical hierarchy is Time. When you cl ick on Time, elements foreach Year, such as 2007, 2006, and 2005, open. When you cl ick on 2006,an element for each Quarter, such as Q1, Q2, Q3, and Q4, opens. If you areseeking Week 24, you need to open several levels of attributes to reach thecorrect data level , which is Week. If you set the attribute Week as an entrypoint, the attribute Week appears in the Data Explorer at the same level as



Year. If an attribute is not set to be an entry point, i t appears in i ts normalposi tion within the hierarchy structure.

If you set a locked attribute as an entry point, i t sti l l appears in thehierarchy but wi th a padlock icon. You can see the locked attribute, but areunable to access elements or attributes below that level .

Prerequisi tes


To create entry points in a hierarchy










Right-cl ick the attribute to set as an entry point, and select Set As EntryPoint. The attribute is marked with a green check mark to denote that i t isan entry point.

To remove an entry point from an attribute, right-cl ick an attribute andselect Remove Entry Point.



Hierarchy browsingOnce you choose which attributes to place in a hierarchy, you can definethe relationships between them. These relationships determine how userscan browse the attributes from the Hierarchies folder.

For example, i f Catalog, Category, Subcategory, and Item are the attributesthat comprise the user hierarchy Catalog Items, the hierarchy resembles theexample below, showing the parent/chi ld relationships between theattributes. For example, in the hierarchy below, Catalog is a parent attributeof Category and Category is the chi ld attribute of Catalog.

A user hierarchy does not need to have these direct relationships defined. Itcan simply be a collection of attributes.



Attributes in a hierarchy can have both browsing and dri l l ing relationshipsbetween them. Browse attributes are attributes you speci fy a user candirectly browse to from a given attribute in the user hierarchy. When youapply browse attributes to attributes in a hierarchy, you are speci fying whatlevels of detai l are visible when browsing the Data Explorer. Includinghierarchies in the Data Explorer makes the hierarchies avai lable for reportsand to users in the project. For more information on including hierarchies inthe Data Explorer, see Enabl ing hierarchy browsing in reports: DataExplorer, page 404.

For each attribute in a hierarchy, you can assign one or more browseattributes to i t. Using the example above, some of these attributes havebeen assigned a browse attribute. Speci fical ly:

Hierarchy Attr ibute Browse Attr ibute(s)

Catalog Category, Subcategory

Category Subcategory

Subcategory Catalog, I tem

Item

The addi tion of these browse attributes al lows users to see the Subcategoryelements directly from the Catalog attribute, wi thout having to fi rst browsedown through the Category attributes to get to Subcategory. The abi l i ty tobrowse more directly through the hierarchy can be represented as shownbelow.



In the Data Explorer, the hierarchy described above resembles the examplebelow.

Users can now view the subcategories in the catalog without fi rst having tobrowse through the categories.

Enabling hierarchy browsing in reports: Data Explorer

You can make hierarchies avai lable for browsing and including in reportsby storing the hierarchies in the Data Explorer. Moving hierarchies to andfrom this folder also al lows you to keep some hierarchies visible to userswhi le hiding others. The Data Explorer is a tool in the Object Browser that



holds the system hierarchy and the user hierarchies. When you create anew project, the system hierarchy for that project is automatical ly placed inthe Data Explorer.

You can save user hierarchies in any folder. However, to make a userhierarchy avai lable for browsing in the Data Explorer you must place i t inthe Data Explorer folder—a subfolder of the Hierarchies folder, which islocated in the Schema Objects folder.

Drilling using hierarchies

Dri l l ing is a function in MicroStrategy reports that al lows users to browsedi fferent levels of attributes along speci fied paths. Depending on the levelof the attributes included in the dri l l ing speci fication, reports can al lowusers to dri l l down, up, and across to di fferent levels of detai l .

When a user selects a dri l l ing path in a report, the report refreshes todisplay the selected level of detai l . For example, on a report wi th the Yearattribute and Revenue metric, the user can dri l l down on the Year attributeto a lower level attribute such as the Month attribute. A new report isautomatical ly executed; on the new report, Revenue data is reported at theMonth level .

You can make user hierarchies avai lable for dri l l ing. This option enablesyou to determine, at a project level , the attributes to which users can dri l lfrom other attributes. In the example of the Year and Month attributes,dri l l ing is enabled in the Time hierarchy, which contains the two attributes.This al lows a user to dri l l down from Year to Month and, i f they need to, dri l lback up from Month to Year.

To enable a user hierarchy as a dri l l path, you must enable the userhierarchy to be used as a dri l l hierarchy in the Hierarchy Editor . If a userhierarchy is not enabled, the defaul t dri l l path is defined by the SystemHierarchy.

Therefore, you can think of browsing paths in a user hierarchy as potentialdri l l ing paths. For example, in the fol lowing hierarchy, Subcategory is a



browse attribute of Catalog, which means that you can access the elementsof Subcategory wi thout having to necessari ly access the elements ofCatalog in Data Explorer. If you enable dri l l ing in this hierarchy, you candri l l from Catalog down to Subcategory—and any other browse attributes ofCatalog—on a report.

A dri l l hierarchy can be used for browsing as wel l as dri l l ing. However, theway in which you browse attributes may not be the same way in which youdri l l on attributes in reports. If your dri l l ing and browsing paths betweenattributes are di fferent, you should create separate dri l l ing and browsinghierarchies.

Prerequisi te


To define a user hierarchy as a drill hierarchy

In MicroStrategy Developer, open a hierarchy using ei ther the HierarchyEdi tor or Archi tect, as described below.







If you are only given the option of using read only mode, this means anotheruser is modi fying the project's schema. You cannot use edi t mode unti l theother user is finished with their changes and the schema is unlocked.

For information on how you can use read only mode and edi t mode forvarious schema edi tors, see Using read only or edi t mode for schemaedi tors, page 111.

To define a user hierarchy as a dri l l hierarchy:

With the Hierarchy Edi tor, select the Use as a drill hierarchy check boxlocated at the bottom of the Hierarchy Edi tor.

With Archi tect, right-cl ick wi thin the Hierarchy View and select Use As adrill hierarchy.



After a user hierarchy is enabled for dri l l ing, the hierarchy contributes to thedri l l ing path of any attributes in i t. Addi tional information on dri l l ing isavai lable in the Advanced Reporting Guide.

Using the Hierarchy Viewer and Table Viewer

Through the Hierarchy Viewer, MicroStrategy Archi tect gives you the abi l i tyto view the system hierarchy as wel l as al l of your user hierarchies in asingle place. The Table Viewer is another tool wi thin MicroStrategyArchi tect that provides you with a bird's eye view of some of the information




within your project. It is used to view al l of the tables in your projectgraphical ly.

Using the Hierarchy ViewerThe Hierarchy Viewer al lows you to select the hierarchy you want toexamine, and also al lows you direct access to the attributes that comprisei t. You can use the Hierarchy Viewer to view ei ther the system hierarchy orany of your user hierarchies.

When you view the system hierarchy, you can see the actual relationshipsbetween attributes, as defined by the system when the project was created.

When you view a user hierarchy, you do not see true attribute relationships,but rather the structure of the user hierarchy as defined by a projectdesigner, to faci l i tate user browsing and report development.

The Aerial perspective provides an overview of the hierarchies in yourproject. Its decreased scale al lows you to navigate through the enti reproject.

The Hierarchy Viewer gives you flexibi l i ty over how much of a givenhierarchy you choose to view at once. You can see al l of the entry pointsinto a hierarchy at once, or you may select only one at a time. For detai lson entry points, see Entry point, page 400.

The Hierarchy Viewer also gives you direct access to any of the attributesin the hierarchy you choose to view. When you access a hierarchy'sattributes directly, you can define them as entry points. See Entry point,page 400 for more detai ls on creating entry points.

To view the system hierarchy in the Hierarchy Viewer

In MicroStrategy Developer, from the Schema menu, point to GraphicalView.

Select Hierarchies.



To view a user hierarchy in the Hierarchy Viewer

In the Hierarchy Viewer, from the Hierarchy menu, select the hierarchy toview.

Attributes that have a green check mark next to them are entry points. SeeEntry point, page 400 for more detai ls on creating entry points.

To edit an attribute from the Hierarchy Viewer

In the Hierarchy Viewer, right-cl ick the attribute to edi t.

Select Edit.

To access Aerial perspective mode in the Hierarchy Viewer

In the Hierarchy Viewer, from the View menu, select Aerial perspective. Anaerial view of the hierarchy you are currently viewing is displayed. Thegreen squares indicate attributes that are entry points.

The hierarchy in the Hierarchy Viewer shi fts according to where younavigate in the aerial view. Cl ick a section of the aerial view display to shi ftyour view of a hierarchy to that particular section.

Using the Table ViewerThe Table Viewer al lows you to view al l of the tables in your project as wel las the joins and/or relationships between those tables and the names of theindividual columns in each table.

The tables that are displayed here are logical tables. They represent andindicate how Archi tect sees the tables that were brought into the projectwhen i t was created.

If you make changes to the actual tables in the data warehouse, you will needto update the logical table structure. See The size of tables in a project:



Logical table size, page 378 for information on updating logical tablestructures.

You can also view al l of this information using Archi tect, which is describedin Chapter 5, Creating a Project Using Archi tect.

To view your project's tables in the Table Viewer

In MicroStrategy Developer, from the Schema menu, point to GraphicalView.

Select Tables.

To view more or less information about each table in the project

Open the Table Viewer, as described above.

In the Table Viewer, select Options.

From the Options menu, select or clear the options for any of the fol lowing,depending on what you want to see in the Table Viewer:

Show joins

Use circular joins

Show relationships

Show relationship types

Show columns



CREATINGTRANSFORMATIONS TODEFINE T IME-BASED ANDOTHER COMPARISONS



Suppose you want to compare how much revenue your company grew lastyear to how much i t grew this year. This type of analysis, cal led a TY/LYcomparison (This Year versus Last Year), is a commonly used form of time-series analysis and is relevant to many di fferent industries, including retai l ,banking, and telecommunications.

Transformations—schema objects you can create using attributes in yourproject—are one of the many MicroStrategy techniques used to performtime-series analysis.

To calculate a variance or a growth percentage such as last year's revenueversus this year's revenue, i t is very convenient to use a transformation.Transformations are often the most generic approach and can be reusedand appl ied to other time-series analyses. To use a transformation, a reportdesigner creates a metric and appl ies the transformation to i t.

Transformation-style analysis can also be supported using the Lag andLead functions provided with MicroStrategy. These functions can be usedto define metrics that compare values from different time periods without theuse of transformations. For information on using these functions to supporttransformation-style analysis, see the Functions Reference.

This chapter discusses the di fferent types of transformations and how tocreate them. It is assumed that you have some understanding of whatmetrics are, as transformation metrics are discussed in this chapter. Forinformation on metrics and using transformations in metrics and reports, seethe Metrics chapter of the Advanced Reporting Guide.

Creating transformations

A transformation is a schema object that typically maps a specified time period toanother time period, applying an offset value, such as current month minus one month.

Usual ly defined by a project designer, transformations are used in thedefini tion of a metric to al ter the behavior of that metric. Such a metric isreferred to as a transformation metric. For example, time-related





transformations are commonly used in metrics to compare values atdi fferent times, such as this year versus last year or current date versusmonth-to-date. Any transformation can be included as part of the defini tionof a metric and multiple transformations can be appl ied to the same metric.Transformation metrics are beyond the scope of this guide; for informationabout transformation metrics, see the Advanced Reporting Guide.

Recal l the example used in the introduction, the TY/LY comparison. Tocalculate this year's revenue, you can use the Revenue metric inconjunction with a fi l ter for this year. Simi larly, to calculate last year'srevenue, you can use the Revenue metric in conjunction with a fi l ter for lastyear. However, a more flexible al ternative is to use a previously createdLast Year transformation in the defini tion of a new metric, last year'srevenue. With a single fi l ter, on 2003 for example, the two metrics Revenueand Last Year Revenue give you resul ts for 2003 and 2002, respectively.

Since a transformation represents a rule, i t can describe the effect of thatrule for di fferent levels. For instance, the Last Year transformationintui tively describes how a speci fic year relates to the year before. It can inaddi tion express how each month of a year corresponds to a month of theprior year. In the same way, the transformation can describe how each dayof a year maps to a day of the year before. This information defines thetransformation and abstracts al l cases into a generic concept. That is, youcan use a single metric wi th a last year transformation regardless of thetime attribute contained on the report.

Whi le transformations are most often used for discovering and analyzingtime-based trends in your data, not al l transformations have to be time-based. An example of a non-time-based transformation is This Catalog/LastCatalog, which might use Catalog_ID-1 to perform the transformation.

Expression-based versus table-based transformationsThe defini tion of the association between an original value and atransformed one can be represented in an expression that uses columns ofthe warehouse, constants, ari thmetic operators, and mathematical




functions. This is known as an expression-based transformation. However,i t is sometimes desirable to precalculate these values and store them in atable designed for the transformation. This method is sometimes referred toas a table-based transformation.

The advantage of a table-based transformation is the possible use ofindexing to speed query times. Another advantage is that table-basedtransformations provide addi tional flexibi l i ty beyond what formulaexpressions can produce. The drawback of this kind of transformation isthat i t requires the creation and management of an addi tional table in thewarehouse. However, once the table is created, i t usual ly signi ficantlydecreases the query time. Returning to the TY/LY example, you have theoption of using a simple formula such as Year_ID - 1 in the defini tion ofthe transformation or precalculating the data and storing i t in a column in atable.

A table-based transformation is required when a many-to-many transformationis performed. An example is a year-to-date calculation.

A signi ficant advantage to the dynamic calculation of an expression-basedtransformation is that the database administrator does not have to createand maintain a transformation table. The drawback is that the system mustperform the calculation every time.

A single transformation can use a combination of table-based andexpression-based transformations. For example, you can create a last yeartransformation based on Year and Month. The ID of the Year attribute is inthe format YYYY, so the transformation can use the expression Year_ID -

1 . The ID for the Month attribute is in the format 'MonthName,' so youcannot easi ly use a mathematical expression. You must use a table instead.

The fol lowing sections walk you through creating both a table-basedtransformation and an expression-based one.



Building a table-based transformationThe fol lowing example shows how to create a last year transformationbased on a lookup table in MicroStrategy Tutorial , which pairs each yearwi th the previous year. This transformation is used in the report displayedbelow, which compares revenue for this year and last year.

Creating the transformation metric and the report are discussed in theTransformation metrics section in the Metrics chapter of the AdvancedReporting Guide .

To create a last year transformation based on a table

Log in to the project source that contains your project in MicroStrategyDeveloper and expand your project.

From the File menu, point to New, and select Transformation . TheTransformation Edi tor opens with the Select a Member Attribute dialog boxdisplayed.

Double-cl ick Time to open the folder, then double-cl ick Year. The Year -Define a new member attribute expression dialog box opens.

Select the LU_Year table from the Table drop-down l ist. The table'scolumns appear in the Avai lable columns l ist. Notice that this table containsa previous year column, which maps this year to last year.





Double-cl ick the PREV_YEAR_ID column to place i t in the expression box.

Cl ick OK .

Cl ick Save and Close on the toolbar. Name the transformation Last Year(Table).

You have now created the transformation. A report designer can now usethe transformation in a revenue metric to calculate last year's revenue, thencreate a report using that transformation metric to obtain last year'srevenue.

Building an expression-based transformationThis example shows how to create a last year transformation using anexpression rather than a table. The Year_ID is in the format YYYY, so theprevious year is simply Year_ID minus one. For example, one subtractedfrom the year 2005 resul ts in the previous year, 2004.

This transformation is added to the report shown in the table-basedtransformation example above. The resul ting report is displayed below.

Creating the transformation metric and the report are discussed in theTransformation metrics section in the Metrics chapter of the AdvancedReporting Guide .

The performance of reports that use expression-based transformations can beimproved in certain scenarios using the Transformation Optimization VLDB





property. For information on this VLDB property and how it can improve reportperformance, see the System Administration Guide .

To create a last year transformation based on an expression

In MicroStrategy Developer, from the File menu, point to New, and selectTransformation . The Transformation Edi tor opens with the Select aMember Attribute dialog box displayed.

Double-cl ick Time to open the folder, then double-cl ick Year. The Year -Define a new member attribute expression dialog box opens.

Select the LU_Year table from the Table drop-down l ist. The table'scolumns appear in the Avai lable columns l ist.

Double-cl ick the YEAR_ID column to place i t in the expression box.

Type -1 in the expression box. The transformation wi l l subtract one from theYear ID to calculate last year's ID.

Cl ick Validate. The message "Val id expression" appears wi th a greencheck mark.

Cl ick OK .

Cl ick Save and Close on the toolbar. Name the transformation Last Year(Expression).

You have now created the last year transformation. A report designer cannow use the transformation in a revenue metric to calculate last year'srevenue, then add i t to the report created in the previous example.

Transformation components

Al l transformations have the fol lowing components:

Member attributes: This component contains the attributes to which thetransformation appl ies, that is, the di fferent levels to which the rule appl ies.




For example, in the Last Year transformation in the MicroStrategyTutorial , the member attributes are Year, Quarter, Month, and Day.

Member tables: These tables store the data for the member attributes.

For an expression-based transformation, each member expression is basedon a speci fic table, general ly the lookup table corresponding to the attributebeing transformed.

For a table-based transformation, this is the transformation table definingthe relationship. For example, in the Last Year transformation, the membertables are LU_YEAR, LU_QUARTER, LU_MONTH, and LU_DAY, for themember attributes Year, Quarter, Month, and Day, respectively.

Member expressions: Each member attribute has a correspondingexpression.

For an expression-based transformation, this is a mathematical expression.In the most generic case, this expression uses constants, ari thmeticoperators, mathematical functions, and columns from the warehouse,typical ly the attribute ID column.

For example, you can create a Last Year transformation using Year_ID-1 asthe expression. However, many cases can exist where the data is notconducive to such calculation. For instance, i f you store Month as 200001(January 2000), you cannot subtract one and receive December 1999 as theresul t.

For a table-based transformation, this is simply a column from a speci ficwarehouse table speci fical ly populated with data supporting thetransformation. The rule is then not encapsulated in an expression butdi rectly in the data of the column. Since the data defines the rule, thisapproach provides considerable flexibi l i ty in the transformation defini tion. Itis particularly effective when no straightforward formula can express therule. In fact, in the case of a many-to-many transformation, a separate tableis required.



For example, in the Last Year transformation, the member expressions areLY_DAY_DATE, LY_MONTH_ID, LY_QUARTER_ID, and PREV_YEAR_ID.These are al l columns from the lookup tables set in the Member tables field.

Mapping type: This component determines how the transformation iscreated based on the nature of the data. The mapping can be one of thefol lowing:

One-to-one: A typical one-to-one relationship is " last year to this year." Oneday or month this year maps exactly to one day or month from last year.

Many-to-many: A typical many-to-many relationship is year-to-date. For onedate, many other dates are included in the year-to-date calculation.

Many-to-many transformations can lead to double-counting scenarios. Forexample, consider YearToDate defined as a many-to-many transformation andRevenue (YTD) as a transformation metric. Suppose this metric is used on areport that does not include the Day attribute, which is the member attribute onthe template. In the report, a range of dates is specified in the filter. In thisinstance, the Revenue (YTD) metric will double count.

Transformation metrics and joint child attributes

Review the discussion of joint child attributes and relationships in Joint chi ldrelationships, page 304 before proceeding in this section.

In a report, a transformation metric displays the current attribute wi thtransformed data, that is, the values for the transformation. For example, areport contains Quarter and the transformation metric Last Year's Revenue.Each quarter is displayed, wi th the previous year's revenue, as shownbelow:



When a joint chi ld attribute, which is an attribute that exists at theintersection of other indirectly related attributes, is added, this affects howthe attribute elements and transformation values are displayed.

For example, the joint chi ld attribute Promotion is added to the previousreport. The report displays the quarter, the promotion associated with agiven quarter, and the revenue data from the date-promotion combination,minus one year. To demonstrate the effect this has on the display of data onthe report, the report below shows the revenue for al l quarters in 2009 and2010, wi thout any transformations:

The highl ighted data in the report shown above indicates that in the fourthquarter of 2009, there was $52,529 of revenue related to the MemphisSpecial Sale promotion. You can also see in this report that the MemphisSpecial Sale promotion was not held in the fourth quarter of 2010. The



report below shows how this data is displayed when a transformation of thedata is used:

In the report shown above, notice that the Memphis Special Sale isdisplayed with the fourth quarter of 2010, and the fourth quarter of 2009 hasno l isting of this promotion. This can seem contradictory as compared to theprevious report that did not include a transformation on the data. However,this is due to the fact that the Last Year's Revenue metric is displaying datafor the previous year for each attribute element. Since the joint chi ldattribute is dependent on time, the attribute elements also must change toreflect the transformation of data. This resul ts in a report that displays theMemphis Special Sale data for the fourth quarter of 2010, because this wasthe revenue that was generated for this quarter during the previous year.



DESIGNING A PROJECTFOR F INANCIALREPORTING



Financial reporting and analysis is important to every business. This caninclude standard reporting such as profi t and loss reporting that providesanalysis of a company's profi ts compared to i ts losses. An example profi tand loss report is shown below:

Whi le financial reporting is an important aspect of any company, i t can bedi fficul t to support and achieve through a standard relational database. Thisis partly due to the addi tional context and hierarchical structure that isrequired for the data.

In MicroStrategy, data such as Revenue and Gross Revenue is normal lymapped to metrics. However, the addi tional context and organizationrequired for this data is better sui ted to attributes in a MicroStrategy system.Since MicroStrategy provides the flexibi l i ty to integrate data from yourrelational database as ei ther metrics or attributes, this al lows you tosupport financial reporting and analysis requirements.



Prerequisites

The best practices l isted in this chapter can help you design a financialreporting project in MicroStrategy. To create this type of financial reportingproject in MicroStrategy, you should also have knowledge of the fol lowing:

Understanding of how to store and maintain data in a database. The bestpractices provided to support a financial reporting project in MicroStrategyrequire a speci fic physical warehouse design.

Expertise in the fol lowing MicroStrategy techniques and features:

Project design

Metric and report creation

Knowledge of your financial data, including:

Logical data model for your financial data, such as whether your financialdata requires addi tional context including account, vendor, customer, andtime. The best practices provided include a high-level discussion ofcreating context for your financial data, but i t is assumed that you have adefined logical data model for your financial data.

The calculations required to create your financial data. Some examples offinancial calculations are provided, but i t is assumed that you know thecalculations required to return the financial data relevant to your financialreporting requirements.

Physical warehouse requirements

Since financial reporting often requires data that would normal ly beintegrated as metrics in MicroStrategy to act more l ike attributes inMicroStrategy, the physical warehouse needs to be able to support thisdi fference.



Creating tables to provide hierarchical organizationAs shown in the example financial report below, the metric data ispresented in a hierarchical organization simi lar to that of attributes inMicroStrategy:

To create this structure, you store each element in lookup tables, and thendefine the hierarchical relationship between the elements using arelationship table.

Creating the lookup tables

The lookup tables define the hierarchical structure of your financial data fordisplay on financial reports.

To i l lustrate these techniques, below are examples of the Level 1, Level 2,and Level 3 tables that would need to be created for the example financialreport provided in Designing a Project for Financial Reporting, page 422.



Level1_ID Level1_DESC

1 Revenue

2 Gross Prof it

3 Operat ing Income

4 EBITDA

5 Net Income


1 Cost of Revenues

2 Gross Prof it Margin

3 Operat ing Expense

4 Deprecat ion Expense

5 Operat ing Margin

6 EBIT

7 Interest Income

8 Interest Expense

9 Taxes

-1 null

-2 null

-3 null

-4 null

-5 null




1 Other Income

2 Interest Coverage Rat io

-1 null

-2 null

-3 null

-4 null

-5 null

-6 null

-7 null

-8 null

-9 null

-10 null

-11 null

-12 null

-13 null

-14 null

To create the lookup tables

Gather the fol lowing information:

What is the deepest level of elements for financial reporting? In otherwords, what is the maximum number of levels that are used to represent anygiven element in your financial report?



In the example financial report, the elements Other Income and InterestCoverage Ratio are both at the deepest level for the financial report, whichuses three levels.

The number of levels needed is the number of lookup tables that need to becreated to represent this organization in your physical warehouse.

How many elements are included in each level?

In the example financial report, Level 1 has five i tems, Level 2 has ninei tems, and Level 3 has two i tems.

The number of i tems in each level is used to determine how many elementsare needed in each lookup table.

With this information, you can create a lookup table for each level ,starting with Level 1, the highest level .

To create the fi rst lookup table, create an ID column to uniquely identi fy thei tem, and a description column that provides the name of the element whendisplayed on financial reports. It is recommended that you use a simplesequential l ist of posi tive numbers for the ID values. This lookup tabledefines the elements for the Level 1 attribute. The table contains al l of theelements that are displayed at the highest level . An example of a Level 1table is provided in Creating the lookup tables, page 425.

Create a lookup table for each addi tional level of elements that is required.In addi tion to sharing al l of the requirements for the fi rst lookup table, eachsuccessive table must also meet the fol lowing requirements:

In addi tion to storing each element at the associated level , nul l or dummyelements must also be included. These elements are required to ensurethat the hierarchical structure can be supported in MicroStrategy reports.When creating dummy elements, use the fol lowing guidel ines:

Include the regular elements as the fi rst elements in the table, using thesame standard of sequential ID values and description information.



Include dummy rows equal to the total number of elements in the nexthighest level lookup table, including both regular elements and dummyelements.

For example, i f you are creating the Level 2 table, you need to create anumber of dummy elements equal to the total number of elements in theLevel 1 table. If you are creating the Level 3 table, you need to create anumber of dummy elements equal to the total number of elements in theLevel 2 table.

For each dummy element, i t is recommended that you use sequential ,negative values for the ID value. For example, the fi rst dummy element of atable should have -1 as i ts ID value, the second dummy element should use-2, and so on.

Leave the description column blank for any dummy elements, so that i t hasa nul l or empty value.

An example of a Level 2 and Level 3 tables is provided in Creating thelookup tables, page 425. In these example tables, notice that the Level 2table has five dummy elements. This is because the Level 1 table hasfive total elements. The Level 3 table has 14 dummy elements. This isbecause the Level 2 table has 14 total elements when counting both theregular and dummy elements. The dummy elements for each table alsouse sequential , negative values for the ID values of the dummyelements.

Creating a relationship table

Once you have the lookup tables created, you must create a relationshiptable to define the hierarchical organization of the level attributes.

To create a relationship table

To determine how to assign matching elements between the lookup tables,you need to combine al l of the regular elements from al l tables together,



mimicking the hierarchical organization required for the final report. Forexample, using the three lookup tables described above, the regularelements and their ID values would be combined as fol lows:

Level1_ID

Level1_DESCLevel2_ID


Level3_DESC

1Revenue

1 1 Cost of Revenues

2

Gross Prof it

2 2Gross Prof itMargin

2 3Operat ingExpense

2 4Deprecat ionExpense

3

Operat ingIncome

3 5Operat ing Margin

3 5 1 Other Income

3 6 EBIT

4

EBITDA

4 7 Interest Income

4 8

Interest Expense4 8 2

Interest CoverageRat io

4 9 Taxes

5 Net Income



This mimics the organization of the final required report, and provides arelationship between al l of the regular elements for the three levellookup tables.

Assign the dummy elements to fi l l out the structure. It is recommended toassign these elements in reverse order. For example, the fi rst element,Revenue, is assigned the lowest dummy element value for the Level 2table. Using this strategy, the table is defined as fol lows:

Level1_ID



Level3_DESC

1Revenue

-5 -14

1 1 Cost of Revenues -13

2

Gross Prof it

-4 -12

2 2Gross Prof itMargin

-11

2 3Operat ingExpense

-10

2 4Deprecat ionExpense

-9

3

Operat ingIncome

-3 -8

3 5Operat ing Margin

-7

3 5 1 Other Income

3 6 EBIT -6



Level1_ID



Level3_DESC

4

EBITDA

-2 -5

4 7 Interest Income -4

4 8

Interest Expense

-3

4 8 2Interest CoverageRat io

4 9 Taxes -2

5 Net Income -1 -1

Since the relationship table is only needed to create a relationship betweenthe level attributes, you can exclude al l description information from thetable. This leaves you with the fol lowing relationship table, which definesthe hierarchical organization of the level attributes in the example above:

Level1_ID

Level2_ID

Level3_ID

1 -5 -14

1 1 -13

2 -4 -12

2 2 -11

2 3 -10

2 4 -9

3 -3 -8

3 5 -7

3 5 1

3 6 -6



Level1_ID

Level2_ID

Level3_ID

4 -2 -5

4 7 -4

4 8 -3

4 8 2

4 9 -2

5 -1 -1

Notice the ID column for the lowest level attribute in this table, in theexample above, Level3_ID . There is a unique value in this ID column foreach entry, which means that this column can be used as the primary key ofthe table. Addi tional ly, this single ID column can be used to uniquelyidenti fy each financial l ine i tem. This value is used later to identi fy eachfinancial l ine i tem.

This table data is used to create attributes to represent your financial l inei tems in financial reports. Information on creating these attributes isincluded in Creating attributes for financial l ine i tems, page 436.

Storing financial dataAfter you create the lookup tables and relationship table to create thehierarchical structure of your financial data, you must store and categorizethe financial data i tsel f. This data includes al l of the various financialaccounts that you plan to include in your financial report. For example,recal l the fol lowing example financial report:



Each separate l ine i tem on the report is an account, and this data needs tobe stored so that i t can be retrieved by MicroStrategy for financial reporting.

There are various ways in which you can store data in a database. Tofaci l i tate financial reporting in MicroStrategy, i t is recommended to store al lof the data for al l financial accounts in a single column, at the lowestlogical level . This resul ts in a table wi th multiple columns that wi l l bemodeled as attributes in MicroStrategy, and a single column that stores al lfinancial data. For example, the table would have a structure simi lar to thefol lowing:

Day Other Attr ibutes Financia l Account Data

1/1/2012Account , Vendor, Customer,etc.

-14 (Revenue) 300


-13 (Cost ofRevenue)

500


-12 (Gross Prof it ) 125



Day Other Attr ibutes Financia l Account Data

. . . . . . . . . . . .


-14 (Revenue) 480


-13 (Cost ofRevenue)

320


-12 (Gross Prof it ) 95

. . . . . . . . . . . .

When storing your data in a table wi th this structure:

Include a column for each category that gives context to the financial data.For example, you might need to know the account, vendor, or customer for agiven piece of financial data, as wel l as the day when the transactionoccurred. This should include al l aspects of the financial data at the lowestlogical level of data. This concept is discussed more in detai l in Facttables: Fact data and levels of aggregation, page 48.

The concepts related to ful ly categorizing your data are discussed inChapter 2, The Logical Data Model . Be aware that each categoryrequired needs to be ful ly defined in your database. This means youmust create lookup tables to provide the necessary, descriptiveinformation to describe these categories. For addi tional detai ls onlookup table design, see Lookup tables: Attribute storage, page 45.

Include a column that identi fies which financial l ine i tem the data isassociated with. These identi fication numbers must match the ID column ofthe lowest level lookup table you created to define the hierarchicalorganization of the final financial report (see Creating tables to providehierarchical organization, page 425). In the example scenario, the Revenuel ine i tem is associated with the value -14 in the lowest level lookup table,



which is LU_LEVEL3 . So any entry of Revenue data must use the value of -14 in this Financial Account column to identi fy i t as Revenue data.

Include a column that stores al l of the financial data for each separatefinancial l ine i tem. This data is entered for each l ine i tem for every recordthat is appl icable.

Do not include data for any financial l ine i tems that are percentages.This includes financial l ine i tems such as margins and ratios. Forexample, data such as Gross Profi t Margin should not be included in thistable. This data is created later in MicroStrategy with the use of metrics.

The resul ting table has more rows than columns. This is because, ratherthan storing the financial data in their own separate columns, each entry isstored in a single column.

Designing the financial reporting project

With your financial data stored in a database as described in Physicalwarehouse requirements, page 424, you are ready to integrate the data intoMicroStrategy. This is accompl ished by adding your tables intoMicroStrategy and creating attributes, facts, and the other schema objectsrequired to support the financial information.

Creating attributes for financial line itemsOnce you have created the lookup tables and relationship table in yourdatabase (see Creating tables to provide hierarchical organization, page425) you can include them in your MicroStrategy project for financialreporting. With the tables included in a MicroStrategy project, you can thenassign the values to attributes. You can use MicroStrategy Archi tect toperform the tasks outl ined below. Detai ls on how to use Archi tect areprovided in Chapter 5, Creating a Project Using Archi tect.

For your financial reporting project, each lookup table is represented inMicroStrategy as a single attribute representing that level of elements, wi th



the attribute ID form representing the ID values in the table, and theattribute description form representing the description values in the table.The image below shows the three lookup tables and the one relationshiptable, from the examples above, included in a project.

To create attributes for financial line items

Create attributes for each level , and map the attribute forms to thecorresponding columns of data in the level lookup tables.

Create the relationships between the level attributes you created, torepresent the hierarchical structure of the financial information. Therelationships can be simple one-to-many relationships, wi th the highestlevel attribute being directly related to the second highest level attribute,the second highest level attribute being directly related to the thi rd highestrelated attribute, and so on. An example of this is shown below forattributes Level1, Level2, and Level3.



Create a hierarchy that represents these attributes as a single, logicalgroup. This hierarchy is used later when creating metrics for the project, asdescribed in Returning financial data with metrics, page 443. Forbackground information on hierarchies, see Chapter 9, Creating Hierarchiesto Organize and Browse Attributes. For a guided set of steps to create anew hierarchy for these attributes, see Creating user hierarchies, page 387.

Displaying financial line item attributes in exported results

As part of defining the attributes for your financial l ine i tems, you canensure that these attributes are displayed correctly when your financialreports are exported to Microsoft Excel or as a PDF using MicroStrategyWeb.

When a report that includes these financial l ine i tem attributes is exportedto Excel or as a PDF using MicroStrategy Web, al l rows of data areexported. Since these financial l ine i tem attributes include empty elementsto support the hierarchical structure of the financial data, this causes someof the rows of the exported report to also be empty.

To prevent this, you can identi fy which of the financial l ine i tem attributesinclude empty elements. These elements are then ignored when reportsincluding those attributes are exported using MicroStrategy Web.



To display financial line item attributes in exported results

Determine the ID values for the attribute objects:

In MicroStrategy Developer, navigate to the attribute, right-cl ick theattribute, and select Properties. The Properties dialog box opens.

Make a note of the alphanumeric string of characters l isted as the ID value.You must determine this ID value for each attribute that includes emptyelements. In the example described in Creating attributes for financial l inei tems, page 436, this would be Level2 and Level3.

Right-cl ick the project that stores your financial data and select ProjectConfiguration . The Project Configuration Edi tor opens.

On the left, expand Project definition , and then select Advanced .

In the Project-Level VLDB settings area, cl ick Configure. The VLDBProperties Edi tor opens.

From the Tools menu, ensure that Show Advanced Settings is selected.

In the VLDB Settings pane, expand Export Engine, then select the GUID ofattributes in profit and loss hierarchy (separated by ':') that has dummyrows to be removed VLDB property.

Clear the Use default inherited value check box.

In the text field, type each ID value for al l financial l ine i tem attributes thatinclude empty elements. Use a colon (: ) to separate each attribute IDvalue.

Cl ick Save and Close to save your changes and close the VLDB PropertiesEdi tor.

When you use MicroStrategy Web to export a report that includes financiall ine i tem attributes, the empty elements wi l l not be shown in the exporteddata.



Creating schema objects for financial dataThe instructions in Storing financial data , page 433 show you how toinclude your financial data in your database, in a MicroStrategy fact table.With this data stored in a fact table, you are ready to create schema objectsto integrate the financial data into a MicroStrategy project.

Your fact table should include a single column that stores the financial datafor al l of the financial accounts.

To create schema objects for financial data

Using MicroStrategy Archi tect, you must create a fact to integrate the datainto the project. This can be a simple fact that points directly to the columnin your database that stores the financial data. For steps to create facts,see Creating and modi fying facts, page 154.

Each category used to define the level of data in this fact table must beincluded in MicroStrategy as an attribute. In addi tion to the fact table, youmay have addi tional lookup tables that provide the descriptive data forthese categories. Within the fact table, the ID column of each categoryshould be included. The image below shows an example of what the facttable might look l ike in MicroStrategy, wi th a single fact column (Data) offinancial data, and addi tional attributes to categorize the financial data.



Notice that a Level3 attribute is included in the fact table above. This isthe lowest level attribute included as part of creating the financial l inei tems, as described in Creating attributes for financial l ine i tems, page436. It is important to include this column of data and associatedattribute in this fact column because i t identi fies which financial l inei tem is associated with each value in the Data column. Without thiscolumn, you cannot accurately identi fy the values for the Data fact thatintegrates this data into MicroStrategy.

For addi tional detai ls on how to create the other attributes required tocategorize your financial data, see Chapter 7, The Context of YourBusiness Data: Attributes.

Creating reporting objects for financial data

Now that you have a basic project designed to integrate your financial datainto MicroStrategy, you can create the remaining objects required to reporton your financial data. This includes bui lding blocks such as fi l ters andmetrics, along with the reports themselves.

Determining financial line items using filtersAs described in Storing financial data , page 433, al l financial data isrepresented with a single fact column. In MicroStrategy, a fi l ter is requiredto determine how data is related to each financial l ine i tem displayed in thereport.

This can be achieved by creating a fi l ter for each financial l ine i tem. Eachfi l ter is defined as an attribute qual i fication, wi th the fol lowing defini tion:

LevelN (ID) Exactly Value

In the defini tion provided above:

LevelN is the lowest level attribute used to define the hierarchicalorganization of the financial l ine i tems, as described in Creating tables toprovide hierarchical organization, page 425.



Value is the value that corresponds to the financial l ine i tem, as defined inthe relationship table created in Creating tables to provide hierarchicalorganization, page 425.

For example, in Creating tables to provide hierarchical organization, page425, level attributes and a relationship table were created to bui ld theorganization of the report shown below.

Revenue is displayed in the report along with other financial l ine i tems. Inthe relationship table for this example, the value for the ID column of thelowest level attribute (Level3) that is associated with the Revenue financiall ine i tem is -14. So the fi l ter defini tion for this l ine i tem is as fol lows:

Level3 (ID) Exactly -14

You can use the relationship table you created in Creating tables to providehierarchical organization, page 425 to determine the value for eachfinancial l ine i tem, and then use this information to create a fi l ter for eachfinancial l ine i tem. For detai ls to create fi l ters, see the Basic ReportingGuide and the Advanced Reporting Guide.






Returning financial data with metricsMetrics al low you to further integrate your data into MicroStrategy anddisplay this data on reports. To support this financial reporting project, youneed to create some speci fic metrics.

Retrieving financial data from the database

Since you modeled your data to store al l financial data in a single factcolumn, you need to create a metric that returns al l of the data that is storedin the database. The defini tion for this metric is as fol lows:

Sum(Fact) {~+, <[Level]+}


Fact is the single fact you created for your financial data, as described inCreating schema objects for financial data, page 440. In the exampleprovided, the fact is named Data.

Level is the hierarchy created for the attributes used to define thehierarchical organization of the financial l ine i tems, as described inCreating tables to provide hierarchical organization, page 425. In theexample provided, the hierarchy is named Level .

The level of this metric is defined as {~+, <[Level]+} , whichindicates that this metric is not aggregated over the Level attributes thatdefine the hierarchical structure of the financial l ine i tems. This ensuresthat subtotals are calculated correctly.

For example, the defini tion for this metric can be as fol lows:

Sum(Data) {~+, <[Level]+}

You can use any name for this metric; for this example the metric is namedStoredData.



Metrics for financial line items with percentage values

Al l financial l ine i tems that are percentages, margins, ratios, and so on arenot stored in the database, as described in Storing financial data , page433. These instead need to be created as metrics in MicroStrategy.

For example, in the report shown below, the financial l ine i tems that are notstored in the database include Gross Profi t Margin, Operating Margin, andInterest Coverage Ratio.

Determine the general calculation for each of these metrics. In the example,these metrics would have the fol lowing general calculations:

Gross Profi t Margin can be defined as Gross Profi t / Revenue.

Operating Margin can be defined as Operating Income / Revenue.

Interest Coverage Ratio can be defined as Operating Income / InterestExpense.

With these general defini tions, you need to define the metrics so that theyrepresent these values. Since each of these metrics rel ies on otherfinancial l ine i tems, you need to determine how to return the values for each



financial l ine i tem. This can be done with a defini tion with the fol lowingsyntax:

Sum(Fact) {~+, !Level+} <[FinancialLineItemFilter]; @2; ->


Fact is the single fact you created for your financial data, as described inCreating schema objects for financial data, page 440. In the exampleprovided, the fact is named Data.


The level of this metric is defined as {~+, !Level+} , which indicatesthat this metric does not include a group-by on the Level attributes thatdefine the hierarchical structure of the financial l ine i tems. This ensuresthat the division calculation can be performed accurately.

FinancialLineItemFilter is the fi l ter used to determine the data forthe speci fic financial l ine i tem. Creating these fi l ters is described inDetermining financial l ine i tems using fi l ters, page 441.

The metric defini tion parameters @2; and - define how the fi l ter is appl iedto the metric.

In this example, this defini tion can be used to create the two valuesrequired for Gross Profi t Margin:

Gross Profi t = Sum(Data) {~+, !Level+} <[GrossProfit]; @2; -

>

Revenue = Sum(Data) {~+, !Level+} <[Revenue]; @2; ->

To create the metric for Gross Profi t Margin, you include these twodefini tions of financial l ine i tems in one metric defini tion for Gross Profi tMargin:



Sum(Data) {~+, !Level+} <[GrossProfit]; @2; -> / Sum(Data)

{~+, !Level+} <[Revenue]; @2; ->

Al l metrics for financial l ine i tems can be created with this same format; forthis example, you would create the fol lowing metric defini tions:

Operating Margin = Sum(Data) {~+, !Level+} <

[OperatingIncome]; @2; -> / Sum(Data) {~+, !Level+} <

[Revenue]; @2; ->

Interest Coverage Ratio = Sum(Data) {~+, !Level+} <

[OperatingIncome]; @2; -> / Sum(Data) {~+, !Level+} <

[InterestExpense]; @2; ->

Notice that the only di fference between these metrics is the fi l ters used toidenti fy the required financial l ine i tems.

You must define each of these metrics as a smart metric. When creating themetric in the Metric Edi tor, on the Subtotals/Aggregation tab, select theAllow Smart Metric check box. This ensures that the division is calculatedcorrectly. For best practices in using smart metrics, refer to the AdvancedReporting Guide.

Financial data metric

When displaying reports of your financial data, the values are al l displayedusing a single metric. This metric combines the values stored in yourdatabase with the values of the metrics that calculate the percentagefinancial l ine i tems into a single metric.

To create the financial data metric

To create the metric that combines al l of the data for your financial l inei tems into a single metric, you need to create the fol lowing metrics:



A metric that retrieves al l of the financial data that is stored in the database.Creating this metric is described in Retrieving financial data from thedatabase, page 443.

A metric that calculates the financial l ine i tems that are not stored in thedatabase, and instead are created within MicroStrategy. Creating thesemetrics is described in Metrics for financial l ine i tems with percentagevalues, page 444.

A metric that helps to determine whether the data for a financial l ine i tem isretrieved from the database, or from a metric in MicroStrategy. The syntaxfor this metric is:

Min([LevelN]@ID) {<Level+}


LevelN is the lowest level attribute created to help define the hierarchicalorganization of the financial l ine i tems, as described in Creating tables toprovide hierarchical organization, page 425. In the example provided, theattribute is named Level3.


Based on the example, the defini tion for this metric is as fol lows:

Min([Level3]@ID) {<Level+}

In addi tion to this metric defini tion, you must define the subtotal function forthis metric to be Minimum. When creating the metric in the Metric Edi tor, onthe Subtotals/Aggregation tab, in the Total subtotal function drop-down l ist,select Minimum.

You can use any name for this metric; for this example, the metric is namedLevels.



With these metrics, you are ready to bui ld the single metric that combinesal l of your financial l ine i tem data into one metric. The syntax for this metricis:

Case(([Levels] = Value1), [PercentageMetric1], ... ,

([Levels] = ValueN), [PercentageMetricN], [StoredData])


Levels is the metric you created above to determine whether the data for afinancial l ine i tem is retrieved from the database, or from a metric inMicroStrategy.

([Levels] = Value1), [PercentageMetric1], ... ,

([Levels] = ValueN), [PercentageMetricN] is the part of themetric defini tion that retrieves the values for al l financial l ine i tems that arecreated using metrics in MicroStrategy, as described in Metrics for financiall ine i tems with percentage values, page 444.

Value1 through ValueN refer to the values that correspond to the financiall ine i tem. You can use the relationship table you created in Creating tablesto provide hierarchical organization, page 425 to determine the value foreach financial l ine i tem.

PercentageMetric1 through PercentageMetricN refer to the metricsyou created for the financial l ine i tems created as metrics to supportpercentages.

StoredData is the metric that retrieves al l of the financial data that isstored in the database. Creating this metric is described in Retrievingfinancial data from the database, page 443.

In this example, the metric needs to determine whether to use one offour di fferent metrics as the source of data for the financial l ine i tem.This includes the metrics for Gross Profi t Margin, Operating Margin,Interest Coverage Ratio, and the StoredData metric that retrieves al l thefinancial data that is stored in the database. The metric defini tion toselect between these metrics is as fol lows:



Case(([Levels] = -11), [GrossProfitMargin], ([Levels] = -

7), [OperatinMargin], ([Levels] = 2),

[InterestCoverageRatio], [StoredData])

This metric selects data from the correct source for each financial l inei tem. You can use any name for this metric; for this example, the metricis named Values. This Values metric is the metric that is includeddirectly on reports for your financial reporting project.

To ensure that the Values metric is displayed correctly, you must alsoperform the fol lowing configurations for this metric.

Open the metric in the Metric Edi tor and switch to theSubtotals/Aggregation tab.

From the Total subtotal function drop-down l ist, select Default.

Select the Allow Smart Metric check box near the bottom of the interface.

From the Tools menu, select Metric Join Type. The Metric Join Typedialog box opens.

Clear the Use default inherited value check box.

Select the Outer option, and cl ick OK to return to the Metric Edi tor.

Cl ick Save and Close to save your changes and close the Metric Edi tor.

Creating reports for your financial dataOnce you have created al l of the metrics, fi l ters, and other supportingobjects for you financial project, you are ready to begin creating reports onyour financial data.

When you create these reports, include the fol lowing objects on the reports.

To create reports for your financial data

Include the attributes used to create the hierarchical organization of thefinancial l ine i tems. Creating these attributes is described in Creating



attributes for financial l ine i tems, page 436. As highl ighted in the reportbelow, these attributes provide the names of the financial l ine i tems as wel las their overal l structure:

Include the single metric that returns al l the data for your financial l inei tems. Creating this metric is described in Returning financial data withmetrics, page 443. This single metric is highl ighted in the report below:



Create thresholds that apply any required metric formatting for the di fferentfinancial l ine i tems. For example, some of the financial l ine i tems can beformatted as percentages. For any financial l ine i tems that should beformatted as percentages, you must create thresholds to apply thisformatting. For example, the report shown below has two financial l inei tems at Level2 and one financial l ine i tem at Level3 that need to bedisplayed as percentages.



You create thresholds for the financial i tems at each level . For example,the thresholds below define the percentage formatting for the financiall ine i tems shown in the report above:

In addi tion to these percentage formatting thresholds, you must ensure thatthe percentage formatting is not appl ied to any financial l ine i temsincorrectly.



For example, by applying the percentage format to the Operating Marginfinancial l ine i tem, this also appl ies the percentage formatting to theOther Income financial l ine i tem. This is because Other Income is wi thinthe Operating Margin group. To prevent the Other Income financial l inei tem from using the percentage formatting, you can apply an addi tionalthreshold for this financial l ine i tem with i ts required formatting. Thisthreshold should also be included above the threshold for OperatingMargin, which ensures that the Operating Margin threshold is performedfi rst, and then the Other Income threshold overrides that threshold.These thresholds are displayed below.

Notice that these thresholds are appl ied to both the metric values andthe subtotal values, as indicated by the selection of the metric andsubtotal icon on the far right of the toolbar.

In addi tion to these required objects, you can also include any otherattributes required to provide addi tional context to the financial data.

As you create these ini tial reports for your financial reporting project,you can take advantage of the other reporting and analysis capabi l i tiesavai lable in MicroStrategy. Refer to the Basic Reporting Guide and the




Advanced Reporting Guide for addi tional steps, examples, and bestpractices for reporting and analysis in MicroStrategy.

Once the reports for your financial data are created, they can be viewed andanalyzed using MicroStrategy Web. Features such as outl ine mode,graphing, and other analysis features can be used in MicroStrategy Web tofurther the reporting and analysis capabi l i ties of your financial data.




M ICROSTRATEGYTUTORIAL



This appendix provides information on the MicroStrategy Tutorial , includingthe data model and physical warehouse schema.

What is the MicroStrategy Tutorial?

The MicroStrategy Tutorial is a MicroStrategy project, which includes awarehouse, and a set of demonstration appl ications designed to i l lustratethe platform's rich functional i ty. The MicroStrategy Tutorial Reportingmetadata is provided as part of the MicroStrategy Analytics Modulemetadata.

A project is the highest-level of intersection of a data warehouse, metadatareposi tory, and user community. Conceptual ly, the project is theenvironment in which al l related reporting is done. A typical projectcontains reports, fi l ters, metrics, and functions. You create projects thatusers access to run reports.

The theme of the MicroStrategy Tutorial project is a retai l store for the time2009 to 2012 that sel ls electronics, books, movies, and music. The keyfeatures of the MicroStrategy Tutorial project include the fol lowing:

Hierarchies, including Customer, Geography, Products, and Time. Eachhierarchy can be viewed graphical ly through MicroStrategy Developer andMicroStrategy Web.

Numerous customers and purchased i tems.

Reporting areas: Customer Analysis, Enterprise Performance Management,Human Resources Analysis, Inventory and Supply Chain Analysis, Salesand Profi tabi l i ty Analysis, and Suppl ier Analysis.

Options to create reports from MicroStrategy Developer and MicroStrategyWeb focusing on a particular analysis area, such as Customer, Inventory,Time, Products, Category, Employee, or Cal l Center.



MicroStrategy Tutorial reporting areasMicroStrategy Tutorial reports and documents are grouped into variousfolders wi thin the Public Objects\Reports folder of the MicroStrategyTutorial project. These reports and documents are grouped into thefol lowing folders:

Business Roles: This folder contains subfolders that reflect di fferent typesof business intel l igence users wi thin an organization, including Bi l l ingManagers, Brand Managers, Category Managers, Company Executives,District Sales Managers, Operations Managers, Regional Sales Managers,and Suppl iers.

Each subfolder contains reports that would be of interest to the type ofbusiness user for which the subfolder is named. For instance, theBilling Managers folder contains an Invoice report and a customer-level transaction detai l report. The Supplier folder contains a Suppl ierSales report, and the Brand Managers subfolder contains a report cal ledBrand Performance by Region.

Dashboards and Scorecards: This folder contains various examples ofdi fferent types of scorecards and dashboards. Using of MicroStrategyReport Services documents, you can create scorecards and dashboards. AReport Services document of this type is a visual ly intui tive display of datathat summarizes key business indicators for a quick status check.Dashboards usual ly provide interactive features that let users change howthey view the dashboard's data. For information on using dashboards,scorecards, and other Reporting Services documents, see the Documentand Dashboard Analysis Guide.

Enterprise Reporting Documents: This folder contains examples ofdi fferent types of standard enterprise reporting documents, such asscorecards and dashboards, managed metrics reports, production andoperational reports, invoices and statements, and business reports. Theyare a sample of the types of reporting documents that can be bui l t usingMicroStrategy Report Services.


https://www2.microstrategy.com/producthelp/2020/manuals/en/DocumentAnalysis.pdf

https://www2.microstrategy.com/producthelp/2020/manuals/en/DocumentAnalysis.pdf


MicroStrategy Platform Capabilities: This folder contains examples ofmany of the sophisticated capabi l i ties wi thin the MicroStrategy platform.Evaluators of the software, as wel l as customers, can use the examples toget a better feel for many of the platform's capabi l i ties. Customers can usethe examples to guide the development of there own MicroStrategyappl ications.

The subfolders under these folders are named according to thecapabi l i ties that their reports exempl i fy. For example, the Graph

Styles folder contains examples of most of the graph types that can becreated in MicroStrategy, the MicroStrategy Data Mining

Services folder contains examples of Linear Regression models andother data mining models bui l t wi thin MicroStrategy, and theMicroStrategy Mobile folder contains examples of reports anddocuments that can be viewed on a mobi le device through the use ofMicroStrategy Mobi le.

Subject Areas: This folder contains reports that are categorized further bytopic. Topics covered include Customer Analysis, Enterprise PerformanceManagement, Human Resource Analysis, Inventory and Supply ChainAnalysis, Sales and Profi tabi l i ty Analysis, and Suppl ier Analysis.

Customer Analysis: Reports analyzing the customer base, studying areassuch as Customer Income, Customer Counts, Revenue per Customer, andRevenue Growth.

Daily Analysis: Dashboards and reports containing information aboutsales, cost, revenue, revenue forecast, profi t, and profi t margins that areused to analyze the typical workflow of a company. The dashboards andreports are useful for a standard MicroStrategy demonstration.

Enterprise Performance Management: Reports containing information onrevenue amounts, trends and forecasts, profi ts, profi t margins, and profi tforecasts. These reports make i t easy for an executive at any level of thecompany to understand how the company is performing as a whole or at theregion, category, and subcategory levels.



Human Resource Analysis: Reports containing information on employees,including headcount, bi rthdays, length of employment, and the top fiveemployees by revenue. These reports are based on employees, time,geography, and sales. The Human Resources Analysis reports provideinsight into human capi tal so that managers can boost the efficiency andeffectiveness of their employees. Human Resource Representatives canhighl ight under-performing employees and misal located headcount.Managers at al l levels can focus on the performance of their employees,dri l l down to an individual employee detai l level , view trends, and extractintel l igence not otherwise evident.

Inventory and Supply Chain Analysis: Reports containing informationbased on suppl ier, product, cost, revenue and profi t, such as Inventory andUni t Sales, or Inventory Received from Suppl iers by Quarter. The Inventoryreports track inventory information within the company and through tosuppl iers. Essential ly, these reports show how many uni ts of an i tem are onhand, how many are expected from a particular suppl ier, and how manyuni ts have been sold. Inventory reports are used to ensure that the supplychain is as efficient as possible. Using these reports, employees cananalyze trends and detai ls, quickly adjust inventory and distribution, andunderstand underlying supply chain costs and inefficiencies.

Sales and Profitability Analysis: Reports analyzing revenue and profi tfrom multiple perspectives. Examples include Sales by Region, Revenueover Time, and Brand Performance by Region. The Product Sales reportsal low managers and analysts to moni tor and analyze sales trends, trackcorporate revenue goals, compare store-to-store performance, and respondmore quickly and accurately to feedback from the marketplace. In turn,executives can analyze sales trends and detai ls, quickly adjust pricing andpromotions, identi fy product affini ties and key profi t centers, andunderstand costs and revenue trends.

Supplier Analysis: Reports containing suppl ier, sales, profi t, and revenueinformation, such as Brand Sales by Suppl ier, Suppl ier Sel l -ThroughPercentage, and Uni ts Sold and Profi t by Suppl ier. The Suppl ier reports



al low managers and analysts to moni tor and analyze vendor performanceso that they can quickly identi fy performance problems. These reports trackbrands and i tems sold that came from a particular vendor. They alsocorrelate profi t and revenue information with particular suppl iers so thatrelationships with key vendors can be strengthened.

You can deploy the out-of-the-box documents to your project by reconci l ingthe documents' content to your own project objects. For example, you canuse any of the Tutorial documents or dashboards mentioned above, or anyof the documents and dashboards in the Human Resource Analytic Module,in your own project. To do this, you use the portable documents feature. Aportable document contains al l the design of the document wi thout the data,al lowing you to copy documents between projects, even when the projectsdo not have the same metadata. When you import the document into thereplacement project, you map the document to the new project (referred toas reconci l ing the document). For instructions on creating and reconci l ingportable documents, see the Advanced Documents chapter of the DocumentCreation Guide.

MicroStrategy Tutorial data model

A logical data model graphical ly depicts the flow and structure of data in abusiness environment. It provides a way of organizing facts so that they canbe analyzed from different business perspectives. For example, a simplelogical data model for a retai l company can organize al l necessary facts bystore, product, and time, which are the three common business perspectivestypical ly associated with retai l business.

For detai led information about data model ing, see Chapter 2, The LogicalData Model .

For MicroStrategy Tutorial , the areas of analysis discussed earl ier,Customer Analysis, Human Resources Analysis, and so on, are organizedinto the fol lowing hierarchical groupings:

Geography hierarchy, page 461





Products hierarchy, page 464

Customers hierarchy, page 465

Time hierarchy, page 469

Data modeling notationsThe fol lowing notations are used in graphical depictions of hierarchies.

Symbol Indicates Definition

entry point

An entry point is a shortcut to an at t ribute element in the DataExplorer. Creat ing an entry point grants you faster access to theat t ribute without having to browse through mult iple at t ributes toreach dif ferent levels of the hierarchy.

at t ribute

A data level def ined by the system architect and associated with oneor more columns in the data warehouse lookup table. At t ributesinclude data classif icat ions like Region, Order, Customer, Age, I tem,City, and Year. They provide a handle for aggregat ing and f i l tering ata given level.

one-to-manyrelat ionship

An at t ribute relat ionship in which every element of a parent at t ributerelates to mult iple elements of a child at t ribute, while every elementof the child at t ribute relates to only one element of the parent . Theone-to-many at t ribute relat ionship is the most common in datamodels.

Geography hierarchyThe Geography hierarchy contains attributes such as Country and Region,as wel l as Distribution Center, Cal l Center, and employee-speci ficattributes. It is easy to understand why Country and Region are in theGeography hierarchy, but what about Distribution Center, Cal l Center, andthe employee-related attributes?

The data used in MicroStrategy Tutorial is based upon a ficti tious companythat sel ls electronics, movies, music, and books. The company does nothave physical stores, but instead does i ts business from catalog and Web



sales. Customers review the products in a printed or onl ine catalog and cal lin their order over the phone. The order is then processed by an employeelocated at one of the cal l centers. The order is then ful fi l led by a distributioncenter that holds the correct i tem and sends i t through one of the shippers.

The Geography hierarchy contains the fol lowing attributes.

Attr ibute Description Example

Call CenterWhere product phone-in orders are taken. Each call centeris located in a dif ferent city.

At lanta,Boston,Charleston.

CountryCountries where the company does or hopes to dobusiness in the future. Also refers to countries whereemployees work.

USA, Spain,France.

Dist ribut ionCenter

The locat ion where product orders are sent out tocustomers. Current ly, each is located in the same city asthe call center it services.

Miami, NewOrleans,Fargo.

EmployeeThe lowest level in the Geography hierarchy, represent ingthe individual responsible for each order placed.

Jennifer Lee,Laura Kelly.

EmployeeAge

The age of each employee. 29, 36, 52.

EmployeeBirth Date

The date each employee was born. 5/6/66, 1/1/77.

EmployeeExperience

The number of years an employee has worked for theorganizat ion.

3, 5, 6.

EmployeeFTE Flag

Indicates whether the employee's status is full-t ime. Yes, No.

Hire Date The date on which a part icular employee was hired.2/16/97,3/15/99.

Manager Person responsible for a specif ic call center.Peter Rose,Alice Cooper.




MicroStrategyUser

Login ID of the MicroStrategy user. This at t ribute is usedfor implement ing data security using system prompts.

Administ rator,BusinessUser, User.

Region Each country is split into regions.Central,Northeast ,Southwest .

Salary The amount of money an employee makes per year.24,000,35,000.

The attributes l isted in the table above are some of the most commonlyused attributes that are included in the logical defini tion of the Geographyhierarchy. Refer to the fol lowing image for a complete understanding of thelogical relationships of al l attributes for the Geography hierarchy.



Products hierarchyThe products hierarchy contains attributes such as Category, Brand,Catalog, and Suppl ier.

The Products hierarchy contains the fol lowing attributes.


Brand The manufacturer or art ist for a part icular product .Ayn Rand,3Com, Sony.

Catalog The medium used to sell products.Spring 2006, Fall2007.

CategoryProducts are organized into categories at the highestlevel.

Electronics,Music.

Discont inuedCode

0 = discont inued product , 1 = non-discont inued product . 0, 1.

I tem The individual product sold.The GreatGatsby, SonyDiscman.

SubcategoryUsed to further dif ferent iate a subset of products within acategory.

Business,Cameras,Drama.

Supplier The dist ributor for a set of brands.McGraw Hil l ,Disney Studios.

WarrantyThe t ime period in months during which a manufacturerrepairs a broken item (specif ic to Narrowcast Server).

3, 5.

The attributes l isted in the table above are some of the most commonlyused attributes that are included in the logical defini tion of the Productshierarchy. Refer to the fol lowing image for a complete understanding of thelogical relationships of al l attributes for the Products hierarchy.



Customers hierarchyThe Customers hierarchy contains customer demographic and purchaseinformation, such as Customer Age, Income Bracket, Payment Method, andShip Date.

The Customers hierarchy contains the fol lowing attributes.


Age RangeThe segregat ion of customers between acertain age group.

24 and under, 28 andabove.

Customer The name of the individual customer. Selene Allen, Chad Laurie.

CustomerAddress

The postal address of the customer.1717 Mcknight Ln, 1734Benson St.

Customer AgeThe age of a part icular customer at acurrent point in t ime.

26, 38, 59.

Customer BirthDate

The date on which the Customer was born. 8/4/50, 4/30/72.




Customer City The city where the customer resides. Albany, Chicago, Memphis.

CustomerCountry

The country where the customer resides. USA, Spain, France.

Customer Email The email address of the [email protected],[email protected].

CustomerGender

The gender of the customer. Male, Female.

Customer Region The region where the customer resides. Northeast , South, France.

Customer State The state where the customer resides. Maine, North Dakota.

Days to ShipThe number of days remaining for theorder to be shipped from the Dist ribut ionCenter.

1, 5, 6.

Educat ion LevelThe highest level of educat ion of thecustomer.

High School,Undergraduate, Graduate.

First Order DateThe date of the f irst order placed by thecustomer.

2/14/2007.

Household CountThe number of houses owned by thecustomer.

2, 4, over 6.

Housing TypeThe type of housing owned by thecustomer.

Renter, Owner, Dependent .

Income BracketThe salary range reported by thecustomer.

$31,000 - 40,000, $61,000- 70,000.

Last Order DateThe date of the last order placed by thecustomer.

2/28/2009.

Marital Status The marital status of the customer. Married, Single.

OrderThe tracking number associated with apart icular group of items purchased.

167, 2635.




Payment Method The way a customer pays for an order. Amex, Check.

Phone PlanThe type of phone plan purchased by thecustomer.

Student , Single, Double,Family Small.

Phone UsageThe current phone usage of the customerthat includes the t ime, date, and bil l ingdetails of the call.

Act ive Months: 24,Average Minutes Off -peak:412.60294, AverageMinutes On-peak:91.54584, Expire Date:12/14/2009 12:00:00 am.

Promot ionDate range for a part icular discount periodunder which an item is purchased (SalesDate).

9/1/06 - 9/4/06, 2/16/07 -2/19/07.

Promot ion TypeType of discount period of fered (Saletype).

Holiday Sale, Back-to-School Sale.

Rush OrderIndicates whether a customer chose toexpedite delivery of an order.

1 (rush order), 0 (not a rushorder).

Ship DateThe date on which an order is shippedfrom the dist ribut ion center.

9/15/06, 3/26/07.

ShipperThe vendor used to send products to thecustomer.

Pronto Packages, MailFast .

StatusThe current account status of thecustomer.

New, Act ive.

StoreA retail store with locat ion informat ion thatsupports ident if icat ion through the use ofmobile devices.

New Design Export ,General AssociatesEnterprise, Good's GoodGoods

Store City The city that a store resides in.Council Bluf fs, Elk River,Liverpool

Store Country The country that a store resides in. Canada, Germany, USA




Store State The state that a store resides in. AB, PA, TX

Store Zipcode The postal zip code for a store. 00682, 22043

Zip CodeThe zip code of the area where thecustomer resides.

07026, 36303.

The attributes l isted in the table above are some of the most commonlyused attributes that are included in the logical defini tion of the Customershierarchy. Refer to the fol lowing image for a complete understanding of thelogical relationships of al l attributes for the Customers hierarchy.



Time hierarchyThe Time hierarchy contains time-speci fic attributes such as Year, Quarter,Month, and Day.

The Time hierarchy contains the fol lowing attributes.




Day Calendar date of purchase. 5/14/09, 12/26/12.

Month Month of purchase. Jul 10, Aug 12.

Month of Year Calendar month of purchase. January, November.

Quarter Calendar quarter of purchase. Q2 10, Q3 12.

Year Calendar year of purchase. 2009, 2010, 2011.

Refer to the fol lowing image for an understanding of the logicalrelationships of al l attributes for the Time hierarchy.

Viewing the MicroStrategy Tutorial data modelAlthough the MicroStrategy Tutorial data model is displayed in the previouspages, you can also view i t di rectly using MicroStrategy Archi tect.



To view the MicroStrategy Tutorial data model using Architect

If you are not al ready using the MicroStrategy Tutorial , log in to the projectsource containing the MicroStrategy Tutorial and expand the MicroStrategyTutorial project. You must log in as a user wi th administrative privi leges.

By default, the MicroStrategy Tutorial project is provided as part of theMicroStrategy Analytics Modules project source.

Right-cl ick the MicroStrategy Tutorial project and select Architect.MicroStrategy Archi tect opens.

From the Hierarchy View, in the Hierarchies drop-down l ist, select SystemHierarchy. The system hierarchy is displayed.

A project's system hierarchy defines the relationships between al l theattributes in a project. Attribute relationships determine how the enginegenerates SQL, how tables and columns are joined and used, and whichtables are related to other tables. For information on defining attributerelationships using Archi tect, see Defining attribute relationships, page194.

From the hierarchies drop-down l ist you can select a di fferent hierarchysuch as Customers, Geography, Products, and Time. These are userhierarchies that define browsing and dri l l ing functional i ty betweenattributes. For information on creating user hierarchies using Archi tect, seeCreating and modi fying user hierarchies, page 202.

To save the layout display of a hierarchy, from the File menu, select ExportImage. Type a name and select an image type to save the image as, andcl ick Save.

MicroStrategy Tutorial schema

A schema is a logical and physical defini tion of warehouse data elements,physical characteristics, and relationships, derived from the logical data



model .

The logical data model provides a picture of al l the pieces of informationnecessary to understand your data and how it relates to your business. It isa graphic-intensive technique that resul ts in a data model representing thedefini tion, characteristics, and relationships of data in a business,technical , or conceptual environment.

The physical warehouse schema is based on the logical data model , suchas Day, Item, Store, or Account. Several physical warehouse schemas canbe derived from the same logical data model . Whi le the logical data modeltel ls you what facts and attributes to create, the physical warehouseschema tel ls you where the underlying data for those objects is stored. Thephysical warehouse schema describes how your data is stored in the datawarehouse.

Exploring the MicroStrategy Tutorial schemaMicroStrategy Archi tect provides an intui tive way to explore theMicroStrategy Tutorial schema. Before you begin exploring the Tutorialschema using Archi tect, there are a few conventions and fact informationthat can help you understand the overal l Tutorial schema.

The fol lowing prefixes and suffixes are used to identi fy di fferent types oftables.


LU_a lookuptable

A database table used to uniquely ident ify at t ribute elements. Theytypically consist of descript ions of dimensions. Lookup tables areusually joined to fact tables to group the numeric facts in the facttable by dimensional at t ributes in the lookup tables.

REL_arelat ionshiptable

While lookup tables store informat ion about one or more at t ributes,relat ionship tables store informat ion about the relat ionship betweentwo at t ributes. Relat ionship tables contain the ID columns of two ormore at t ributes, thus def ining associat ions between them.




_SLSa tablewith salesinformat ion

A database table used to store sales data (revenue, prof it , cost , andso on) at dif ferent logical levels. These tables include a combinat ionof at t ribute and fact def init ions. For example, the YR_CATEGORY_

SLS table includes the at t ributes Year and Category, along withfacts such as Revenue, Cost , Prof it , and so on. Storing these factsin this table makes their data available at the Year and Categorylevel.

Many tables include a combination of attributes and facts. Some of thebasic facts from which metrics in the MicroStrategy Tutorial were createdfrom are l isted below.

Fact Description

Begin onhand

The number of individual items available at the beginning of each month.

Churn The trends and prof i les of the acquired, retained, and lost customers.

Cost The total amount charged by the supplier to the company.

CustomerId

The unique ident if icat ion number allocated to the customer by the company.

Discount A monetary reduct ion made from a regular price.

End onhand

The number of individual items remaining at the close of each month.

Freight The compensat ion paid for the transportat ion of goods.

GrossRevenue

The total income received from the company's product sales before deduct ing theexpenses.

I teminventory

The month level item inventories used for End on hand and Begin on hand typeinventory calculat ions. This fact also supports year-to-date and month-to-dateanalysis.



Fact Description

On OrderQuant ity

The quant ity ordered by the customer.

Prof it The excess of the sell ing price of goods over their cost .

Recency The number of days elapsed since the last purchase was made by the customer.

RevenueThe total income produced by a given source account ing for all product salesdeduct ing discounts.

RushCharge

The amount of money charged to expedite delivery service.

TargetQuant ity

The target set for the product units sold.

Tenure The durat ion an employee is employed by the company.

Unit CostThe amount of money charged by the supplier to the company per individual itempurchased.

UnitPrice

The amount of money charged by the company to the customer per individualitem sold.

UnitProf it

Unit price - Unit cost .

UnitsReceived

The number of individual items acquired from a supplier.

UnitsSold

The number of individual items bought by customers.

The steps below show you how to explore the MicroStrategy Tutorialschema using Archi tect.

To explore the MicroStrategy Tutorial schema using Architect

If you are not al ready using the MicroStrategy Tutorial , log in to the projectsource containing the MicroStrategy Tutorial and expand the MicroStrategy



Tutorial project. You must log in as a user wi th administrative privi leges.

By default, the MicroStrategy Tutorial project is provided as part of theMicroStrategy Analytics Modules project source.

Right-cl ick the MicroStrategy Tutorial project and select Architect.MicroStrategy Archi tect opens.

Select the Project Tables View. Al l the tables included in theMicroStrategy Tutorial project are displayed.

To view the physical columns for each table:

From the Options menu, select Settings. The MicroStrategy Archi tectSettings dialog box opens.

On the Display settings tab, select Display table physical view.


Tables are displayed to show the columns within each table, including thecolumn name and data type.

To view the physical columns for each table, along with the MicroStrategyschema object they define:

From the Options menu, select Settings. The MicroStrategy Archi tectSettings dialog box opens.

On the Display settings tab, select Display table logical view.

Cl ick Advanced Options.

Select al l the check boxes for the Display table logical view option. For adescription of each option, see Defining project creation and displayoptions, page 124.

Cl ick OK .




Tables are displayed to show the schema objects and the columns used todefine the schema objects.

To view attribute relationships in the Project Tables View, from the Viewmenu, select Show relationships.

From the Properties pane, you can use the Attribute, Facts, and Tablestabs to browse the various tables and schema objects for the Tutorialproject.

To organize tables for further insight into the Tutorial project, you cancreate layers. For information on creating layers using Archi tect, seeOrganizing project tables: Layers, page 153.

To save the layout display of the Tutorial project schema, from the Filemenu, select Export Image. Type a name and select an image type to savethe image as, and cl ick Save.

Table column informationThis section describes each physical table column used in the Tutorialproject.

Column Name Data Type Description

Table: CITY_CTR_SLS

Fact table that stores sales data at the City and Call Center logical level.

CALL_CTR_ID Integer(2) Unique ident if ier of call center values.

CUST_CITY_ID Integer(2) Unique ident if ier of customer city values.

TOT_COST DoubleThe total amount charged by the supplier to thecompany.

GROSS_DOLLAR_SALES

DoubleThe total income received from the company'sproduct sales before deduct ing the expenses.

TOT_DOLLAR_SALES DoubleThe total income produced by a given sourceaccount ing for all product sales deduct ing




discounts.

TOT_UNIT_SALES DoubleThe number of individual items bought by acustomer.

Table: CITY_MNTH_SLS

Fact table that stores sales data at the City and Month logical level.


MONTH_ID Integer(4) Unique ident if ier of a month.


GROSS_DOLLAR_SALES


TOT_DOLLAR_SALES DoubleThe total income produced by a given sourceaccount ing for all product sales deduct ingdiscounts.

TOT_UNIT_SALES DoubleThe number of individual items bought bycustomers.

Table: CITY_SUBCATEG_SLS

Fact table that stores sales data at the City and Subcategory logical level.


SUBCAT_ID Integer(2) Unique ident if ier for the subcategory of an item.



TOT_COST DoubleThe total amount charged by supplier to thecompany.




GROSS_DOLLAR_SALES


Table: CUSTOMER_SLS

Fact table that shows sales data at the Customer logical level.

CUSTOMER_ID Integer(4)The unique ident if icat ion number allocated tothe customer by the company.



TOT_COST DoubleThe number of individual items bought by acustomer.

GROSS_DOLLAR_SALES


Table: DAY_CTR_SLS

Fact table that shows sales data at the Day and Call Center logical level.

DAY_DATE TimeStampThe day and date on which the transact ion tookplace.


TOT_DOLLAR_SALES DoubleThe total income produced by a given sourceaccount ing for all product sales af ter deduct ingdiscounts.






GROSS_DOLLAR_SALES


Table: INVENTORY_CURR

Fact table that shows data for the current Inventory logical level.

ITEM_ID Integer(2) Unique ident if ier of an item.

TARGET_QTY Double The target set for the product units sold.

EOH_QTY DoubleThe number of individual items remaining at theclose of each month.

ON_ORDER_QTY Double The quant ity ordered by the customer.

UNIT_COST DoubleThe amount of money charged by the supplier tothe company per individual item purchased.

Table: INVENTORY_ORDERS

Fact table that shows data for the Inventory and Order logical level.


UNITS_RECEIVED DoubleThe number of individual items acquired from asupplier.


MONTH_DURATION DoubleDurat ion in months for which the inventory iscalculated.

Table: ITEM_CCTR_MNTH_SLS

Fact table that shows sales data at the I tem, Call Center, and Month logical level.




TOT_DOLLAR_SALES Double The total income produced by a given source




account ing for all product sales af ter deduct ingdiscounts.



GROSS_DOLLAR_SALES


Table: ITEM_EMP_SLS

Fact table that shows sales data at the I tem and Employee logical level.


EMP_ID Integer(2) Unique ident if ier of an employee.

TOT_DOLLAR_SALES DoubleThe total income produced by a given sourceaccount ing for all product sales af ter deduct ingdiscounts.



GROSS_DOLLAR_SALES


Table: ITEM_MNTH_SLS

Fact table that shows sales data at the I tem and Month logical level.



TOT_DOLLAR_SALES DoubleThe total income produced by a given sourceaccount ing for all product sales af ter deduct ing




discounts.



GROSS_DOLLAR_SALES


Table: LU_AGERANGE

Lookup table for Customer Demographic: Age Range.

AGERANGE_ID Integer(4) Unique ident if ier for the age range.

AGERANGE _DESCNVarChar(20)

Descript ion of the age range.

Table: LU_BRAND

Lookup table for Brand data, which lists the manufacturer or art ist for a part icular product .

BRAND_ID Integer(2) Unique ident if ier for the brand.

BRAND_DESCNVarChar(50)

Descript ion of the brand.

Table: LU_CALL_CTR

Lookup table for the Call Center data, which lists the Call Center details where productphone-in orders are taken.


CENTER_NAMENVarChar(50)

Name of the call center.

COUNTRY_ID Integer(2) Unique ident if ier of country values.

REGION_ID Integer(2) Unique ident if ier of region values.




DIST_CTR_ID Integer(2) Unique ident if ier of dist ribut ion center values.

MANAGER_ID Integer(2) Unique ident if ier for managers.

Table: LU_CATALOG

Lookup table for the Catalog data, which lists the products available in the catalog.

CAT_ID Integer(2) Unique ident if ier of catalog values.

CAT_DESCNVarChar(50)

Descript ion of the catalog values.

Table: LU_CATEGORY

Lookup table for Category data, which lists the products categorized at the highest levels.

CATEGORY_ID Integer(2) Unique ident if ier of the category values.

CATEGORY_DESCNVarChar(50)

Descript ion for the category values.

Table: LU_COUNTRY

Lookup table for Country data, which represents countries where the company does or hopesto do business in the future. Also includes countries where employees work.


COUNTRY_NAMENVarChar(50)

Name of the country.

Table: LU_CUST_CITY

Lookup table for customer geographic informat ion: City.


CUST_CITY_NAMENVarChar(50)

Name of the city in which the customer stays.

CUST_STATE_ID Integer(2) Unique ident if ier of customer state values.

Table: LU_CUST_REGION




Lookup table for customer geographic informat ion: Region.

CUST_REGION_ID Integer(2) Unique ident if ier of customer region values.

CUST_REGION_NAMENVarChar(50)

Name of the region in which the customer stays.

CUST_COUNTRY_ID Integer(2) Unique ident if ier of customer country values.

Table: LU_CUST_STATE

Lookup table for customer geographic informat ion: State.

CUST_STATE_ID Integer(2) Unique ident if ier of customer state.

CUST_STATE_NAMENVarChar(50)

Name of the state in which the customer stays.

CUST_REGION_ID Integer(2) Unique ident if ier of customer region.

Table: LU_CUSTOMER

Lookup table for Customer data. This table targets a customer as a consumer rather than abusiness.

CUSTOMER_ID Integer(4)Unique ident if icat ion number allocated to thecustomer by the company.

CUST_FIRST_NAMENVarChar(255)

First name of the customer.

CUST_LAST_NAMENVarChar(255)

Last name of the customer.

CUST_BIRTHDATE TimeStamp Birth date of the customer.

ADDRESSNVarChar(255)

Address of the customer.

INCOME_ID Integer(2) Unique ident if ier of the customer's income.

EMAILNVarChar(50)

Email ID of the customer.





ZIPCODENVarChar(255)

The zip code of the address where the customerresides.

GENDER_ID Integer(4) Unique ident if ier of the customer's gender.

AGE_YERS Real Age in years of a customer.

AGERANGE_ID Integer(4)Unique ident if ier of segregat ion of customersbetween a certain age group.

MARITALSTATUS_ID Integer(4)Unique ident if ier of marital status of thecustomer.

EDUCATION_ID Integer(4)Unique ident if ier of level of educat ion of thecustomer.

HOUSINGTYPE_ID Integer(4)Unique ident if ier of type of housing owned bythe customer.

HOUSEHOLDCOUNT_ID Integer(4)Unique ident if ier of number of houses owned bythe customer.

FIRST_ORDER TimeStamp The date of f irst order placed by the customer.

LAST_ORDER TimeStamp The date of last order placed by the customer.

STATUS_ID Integer(4)Unique ident if ier of the current account status ofthe customer.

TENURE RealThe durat ion an employee is employed by thecompany.

RECENCY RealThe number of days elapsed since the lastpurchase was made by the customer.

Table: LU_CUSTOMER_TELCO

Lookup table for Customer Telephone data, which lists the telephone plan details of thecustomer.

CUSTOMER_ID Integer(4) Unique ident if icat ion number allocated to the




customer by the company.

PLAN_ID Integer(2)Unique ident if ier of the telephone planpurchased by the customer.

AVG_MIN_PEAK DoubleAverage calls made by the customer in minutesduring peak t ime.

AVG_MIN_OFFPEAK DoubleAverage calls made by the customer in minutesduring of f -peak t ime.

MONTHLY_PROFIT DoubleThe monthly excess of the sell ing price of goodsover their cost .

HELPDESK_CALLS Integer(2) Calls made by the customer to the Helpdesk.

DROPPED_CALLS Integer(2)Number of calls made by the customer that weredropped or disconnected unexpectedly.

ACTIVE_MONTHS Double

The total number of months the customer hashad a telephone plan. This includes the numberof months into the current two-year contract , andall months for any previous contracts.

CURRENT_MONTHS DoubleThe number of months into the current two-yearcontract .

LIFETIME_VALUE DoubleA customer score that ident if ies the customersmost l ikely to be prof itable to a company over aperiod of t ime.

NET_PRESENT_VALUE Double Net present value of the telephone plan.

REMAINING_VALUE Double The remaining value of the telephone plan.

START_DATE TimeStamp Start date of the customer telephone plan.

EXPIRE_DATE TimeStamp Expiry date of the customer telephone plan.

RENEWALS Integer(2) Renewals made by the customer.

CANCEL_DATE TimeStamp Date on which the customer canceled the




telephone plan.

CHURN Integer(2)The trends and prof i les of the acquired,retained, and lost customers.

LIFETIMEVALUESCORENVarChar(50)

Lifet ime value score of the customer.

CREDITRISKSCORENVarChar(50)

Credit risk score of the customer.

CREDITRISKVALUENVarChar(50)

Credit risk value of the customer.

Table: LU_CUSTSTATUS

Lookup table for Customer Statuses.

STATUS_ID Integer(4) Unique ident if ier of customer status.

STATUS_DESCNVarChar(20)

Descript ion of customer status.

Table: LU_DAY

Lookup table for Day data, which lists the calendar dates for customer transact ions.

DAY_DATE TimeStamp Day and date.

MONTH_ID Integer(4) Month of the date.

QUARTER_ID Integer(2) Quarter of the date.

YEAR_ID Integer(2) Year of the date.

Table: LU_DIST_CTR

Lookup table for Dist ribut ion Center data, which lists the locat ion where product orders aresent out to customers.

DIST_CTR_ID Integer(2) Unique ident if ier of dist ribut ion center.

DIST_CTR_NAMENVarChar(50)

Dist ribut ion center name.




COUNTRY_ID Integer(2) Unique ident if ier of a country.

Table: LU_EDUCATION

Lookup table for Customer Psychographics: Level of Educat ion.

EDUCATION_ID Integer(4)Unique ident if ier of educat ion level of thecustomer.

EDUCATION_DESCNVarChar(20)

Descript ion of educat ion level of the customer.

Table: LU_EMPLOYEE

Lookup table for Employee data, which lists the details of individuals working for thecompany who receive salary and benef its in return.


EMP_LAST_NAMENVarChar(50)

Last name of the employee.

EMP_FIRST_NAMENVarChar(50)

First name of the employee.

EMP_SSNNVarChar(50)

Social security number of the employee.


DIST_CTR_ID Integer(2) Unique ident if ier of dist ribut ion center values.


MANAGER_ID Integer(2) Unique ident if ier of a manager.

SALARY Integer(4)The amount of money an employee makes peryear.

BIRTH_DATE TimeStamp The birth date of each employee.

HIRE_DATE TimeStampThe date on which a part icular employee washired.




FTE_FLAGNVarChar(50)

Indicates whether the employee's status is full-t ime.

Table: LU_GENDER

Lookup table for Customer Gender data, which lists the gender of the customer.

GENDER_ID Integer(4) Unique ident if ier of the customer's gender.

GENDER_DESCNVarChar(20)

Descript ion of the customer's gender.

Table: LU_HOUSEHOLDCOUNT

Lookup table for Household Count data, which lists the details of the number of housesowned by the customer.

HOUSEHOLDCOUNT_ID Integer(4)Unique ident if ier of the household count of thecustomer.

HOUSEHOLDCOUNT_DESC

NVarChar(20)

Descript ion of the number of houses owned bythe customer.

Table: LU_HOUSINGTYPE

Lookup table for Housing Type data, which lists the details of type of house owned by thecustomer.

HOUSINGTYPE_ID Integer(4)Unique ident if ier of the housing type of thecustomer.

HOUSINGTYPE_DESCNVarChar(20)

Descript ion of the type of house owned by thecustomer.

Table: LU_INCOME

Lookup table for the Customer Income data, which lists the salary range reported by thecustomer.

INCOME_ID Integer(2) Unique ident if ier of the customer's income.

BRACKET_DESCNVarChar(50)

Descript ion for customer's income.




Table: LU_ITEM

Lookup table for the I tem data, which lists the details of the individual products sold.


ITEM_NAMENVarChar(255)

Name of the product sold.

SUPPLIER_ID Integer(2)Unique ident if ier of the supplier that supplies theproduct .

ITEM_FOREIGN_NAMENVarChar(50)

Name given to the item by other suppliers.

SUBCAT_ID Integer(2)Unique ident if ier of the subcategory to which theitem belongs.

DISC_CD DoubleUnique code that ident if ies items as eitheravailable or discont inued.

ITEM_LONG_DESCNVarChar(255)

Detailed descript ion of the item.

WARRANTYNVarChar(50)

The t ime period in months during which amanufacturer repairs a broken item.

UNIT_PRICE DoubleThe amount of money charged by the company tothe customer per individual item sold.

BRAND_ID Integer(2)Unique ident if ier of manufacturer or art ist for apart icular product .


Table: LU_MANAGER

Lookup table for Manager data, which lists the details of the person responsible for a specif iccall center.

MANAGER_ID Integer(2) Unique ident if ier of the person responsible for a




specif ic call center.

MGR_LAST_NAMENVarChar(50)

Last name of the person responsible for aspecif ic call center.

MGR_FIRST_NAMENVarChar(50)

First name of the person responsible for aspecif ic call center.

EMAILNVarChar(50)

Email ID of the person responsible for a specif iccall center.

ADDRESS_DISPLAYNVarChar(50)

Manager's name displayed in Last Name, FirstName format.

DEVICE_IDNVarChar(50)

Unique ident if ier of the device.

MSTR_USERNVarChar(50)

Login ID of the MicroStrategy user. Thisat t ribute is used for implement ing data securityusing system prompts.

Table: LU_MARITALSTATUS

Lookup table for customer Marital Status, which lists the marital details of the customer.

MARITALSTATUS_ID Integer(4)Unique ident if ier for the marital status of thecustomer.

MARITALSTATUS_DESC

NVarChar(20)

Descript ion of the marital status of thecustomer.

Table: LU_MONTH

Lookup table for Month data, which lists the month of the customer transact ion.

MONTH_ID Integer(4) Unique ident if ier of month of the date.

MONTH_DESCNVarChar(50)

Descript ion of the month.

MONTH_OF_YEAR Integer(2) Calendar month of purchase.




QUARTER_ID Integer(2) Unique ident if ier of the quarters.

YEAR_ID Integer(2) Unique ident if ier of year of the date.

MONTH_DATE TimeStamp Calendar day of purchase.

MONTH_DURATION Double Durat ion in months.

Table: LU_MONTH_OF_YEAR

Lookup table for Month of Year data, which lists the calendar month of purchase.

MONTH_OF_YEAR Integer(2) Calendar month of purchase.

MONTH_OF_YEAR_NAME

NVarChar(50)

Name of the calendar month of purchase.

Table: LU_PROMO_TYPE

Lookup table for Promot ion Type data, which lists the type of discount of fered on the saleproduct .

PROMO_TYPE_ID Integer(2)Unique ident if ier of the type of discount periodof fered on the product .

PROMO_TYPE_DESCNVarChar(50)

Descript ion of the type of discount periodof fered on the product .

Table: LU_PROMOTION

Lookup table for Promot ion data, which lists the discount being of fered on the sale item.

PROMOTION_ID Integer(4)Unique ident if ier of the date range for apart icular discount period under which an item ispurchased.

PROMOTION_DESCNVarChar(50)

Descript ion of the discount period under whichan item is purchased.

PROMOTION_DISCOUNT

Integer(4)Monetary reduct ion made from a regular pricefor a part icular discount period under which anitem is purchased.




PROMO_TYPE_ID Integer(2)Unique ident if ier of the type of discount periodof fered on the product .

Table: LU_PYMT_TYPE

Lookup table for Payment Type data, which lists the payment mode used by a customer topay for an order.

PYMT_TYPE Integer(2)The mode used by a customer to pay for anorder.

PYMT_DESCNVarChar(50)

Descript ion of the way in which a customer paysfor an order.

Table: LU_QUARTER

Lookup table for Quarter data, which list the details of the calendar quarter of purchase.

QUARTER_ID Integer(2)Unique ident if ier of the calendar quarter ofpurchase.

QUARTER_DESCNVarChar(50)

Descript ion of the calendar quarter of purchase.

YEAR_ID Integer(2)Unique ident if ier of the calendar year ofpurchase.

QUARTER_DATE TimeStamp Calendar date from which the quarter starts.

QUARTER_DURATION Integer(2) Durat ion of quarter.

Table: LU_REGION

Lookup table for Region data, which lists the regions into which a country is split .


REGION_NAMENVarChar(50)

Name given to a region, which is part of acountry.


Table: LU_SHIPPER




Lookup table for Shipper data, which lists the details of the vendor used to send products tothe customer.

SHIPPER_ID Integer(2)Unique ident if ier of the vendor used to sendproducts to the customer.

SHIPPER_DESCNVarChar(50)

Descript ion of the vendor used to send productsto the customer.

Table: LU_STORE

Lookup table for Store data, which lists the details of a retail store including the locat ioninformat ion.

STORE_ID Integer(4) Unique ident if ier for store values.

STORE_NAMENVarChar(100)

Name given to a store.


STORE_ADDRESSNVarChar(255)

Address where the store is located.

STORE_ZIPCODENVarChar(10)

The postal zip code for a store.

STORE_STATENVarChar(50)

The state that a store resides in.

STORE_CITYNVarChar(100)

The city that a store resides in.

STORE_PHONENVarChar(50)

Telephone number of the store.

STORE_EMAILNVarChar(100)

Email address of the store.

STORE_USER_RATING Integer(2) Rat ing given by customers to the store.




STORE_WIFI Integer(4) Indicates whether Wi-Fi is available at the store.

STORE_DRIVE_THRU Integer(4)Indicates whether a drive-through facil i ty isavailable at the store.

STORE_SERVICE_CENTER

Integer(4)Indicates whether a service center facil i ty isavailable at the store.

STORE_SUPER Integer(4) Indicates whether the store is a super store.

STORE_LATITUDE Double Lat itude coordinates of the store locat ion.

STORE_LONGITUDE Double Longitude coordinates of the store locat ion.

STORE_WEBSITENVarChar(100)

URL of the store website.

STORE_SPECIALITY Integer(4) Indicates whether the store is a specialty store.

STORE_STATE_DESCNVarChar(255)

Full name of the state in which the store islocated.

STORE_COUNTRYNVarChar(50)

The country that a store resides in.

Table: LU_SUBCATEG

Lookup table for Subcategory data, which further dif ferent iates a subset of products within acategory.

SUBCAT_ID Integer(2)Unique ident if ier of the subcategory of aproduct .

SUBCAT_DESCNVarChar(50)

Descript ion of the subcategory of the product .

CATEGORY_ID Integer(2) Unique ident if ier of the category of a product .

Table: LU_SUPPLIER

Lookup table for Supplier data, which lists the dist ributor for a set of brands.

SUPPLIER_ID Integer(2) Unique ident if ier of supplier values.




SUPPLIER_NAMENVarChar(50)

Name of the dist ributor for a set of brands.

CONTACT_LAST_NAMENVarChar(50)

Last name of the contact person at the supplier'slocat ion.

CONTACT_FIRST_NAME

NVarChar(50)

First name of the contact person at the supplier'slocat ion.

Table: LU_TELCO_PLANS

Lookup table for Telephone Plan data, which lists the telephone plan details.

PLAN_ID Integer(2)Unique ident if ier of the phone plan purchased bythe customer.

PLAN_DESCNVarChar(255)

Name given to a phone plan.

PLAN_MINUTES DoubleTalk t ime, in minutes, available under the planselected by the customer.

PLAN_PRICE_MO Double Price per month of the phone plan.

PLAN_COST_ACQ Double Acquisit ion cost of the phone plan.

PLAN_COST_FIX_MO Double Monthly f ixed cost of the phone plan.

PLAN_COST_VAR_MO Double Monthly variable cost of the phone plan.

PLAN_PRICE_MINPK Double Price per minute for calls during peak t ime.

PLAN_PRICE_MINOP Double Price per minute for calls during of f -peak t ime.

Table: LU_YEAR

Lookup table for Year data, which lists the calendar year of purchase.

YEAR_ID Integer(2) Unique ident if ier of year.

YEAR_DATE TimeStamp Year and date details.

YEAR_DURATION Integer(2) Durat ion in years.




Table: MNTH_CATEGORY_SLS

Fact table that stores sales data at the Month and Category logical level.


MONTH_ID Integer(4) Unique ident if ier of month values.




GROSS_DOLLAR_SALES


Table: MTD_DAY

Table that def ines the month-to-date t ime period for a given date.


MTD_DAY_DATE TimeStamp Month-To-Date day and date.

Table: ORDER_DETAIL

Fact table that stores Order Details.

ORDER_ID Integer(4) Unique ident if ier of an order.

ORDER_DATE TimeStamp Date on which the order was placed.


QTY_SOLD Double Number of items sold.

UNIT_PRICE DoubleThe amount of money charged by the company tothe customer per individual item sold.




PROMOTION_ID Integer(4)Unique ident if ier of the date range for apart icular discount period under which an item ispurchased.

DISCOUNT Double A monetary reduct ion made from a regular price.




Table: ORDER_FACT

Fact table containing Order data.



ORDER_DATE TimeStamp Date on which the order was placed.

ORDER_AMT DoubleThe total amount of money charged by thecompany to the customer for the order.

FREIGHT DoubleThe compensat ion paid for the transportat ion ofgoods.

SHIP_DATE TimeStampThe date on which an order is shipped from thedist ribut ion center.

QTY_SOLD Double Quant ity of items sold in the order.

ORDER_COST DoubleThe total amount charged by the supplier to thecompany for the ordered items.


PYMT_TYPE Integer(2)The mode used by a customer to pay for anorder.




SHIPPER_ID Integer(2)Unique ident if ier of the vendor used to sendproducts to the customer.

GROSS_DOLLAR_SALES


Table: PROMOTIONS

Fact table for Promot ion details.



Table: QTD_DAY

Table that def ines the quarter-to-date t ime period for a given date.


QTD_DAY_DATE TimeStamp Quarter-to-date day and date.

Table: QTR_CATEGORY_SLS

Fact table that stores sales data at Quarter and Category logical level.


QUARTER_ID Integer(2) Unique ident if ier of the quarters.




GROSS_DOLLAR_SALES





Table: REL_CAT_ITEM

Relat ion table showing relat ion of Category and I tem.


CAT_ID Integer(2) Unique ident if ier of category values.

Table: RUSH_ORDER

Table for Rush Order data that indicates whether a customer chose to expedite delivery of anorder.


RUSH_CHARGE RealThe amount of money charged to expeditedelivery service.

Table: STATE_REGION_MNTH_SLS

Fact table that stores sales data at State, Region, and Month logical levels.







GROSS_DOLLAR_SALES


Table: STATE_SUBCATEG_MNTH_SLS

Fact table that stores sales data at State, Subcategory, and Month logical levels.










GROSS_DOLLAR_SALES


Table: STATE_SUBCAT_REGION_SLS

Fact table that stores sales data at State, Subcategory, and Region logical levels.







GROSS_DOLLAR_SALES


Table: SUBCAT_MNTH_CTR_SLS




Fact table that stores sales data at Subcategory, Month, and Call Center logical levels.

SUBCAT_ID Integer(2) Unique ident if ier of the subcategory of an item.






GROSS_DOLLAR_SALES


Table: YR_CATEGORY_SLS

Fact table that stores sales data at Year and Category logical levels.


YEAR_ID Integer(2) Unique ident if ier of the year of purchase.




GROSS_DOLLAR_SALES


Table: YTD_DAY




Table that def ines the year-to-date t ime period for a given date.


YTD_DAY_DATE TimeStamp The year-to-date day and date.



LOGICAL TABLESPro ject Design Gu id e


MicroStrategy uses logical tables to relate the data stored in your datawarehouse to the schema objects that consti tute a MicroStrategy project.Logical tables and logical table al iases represent physical tables in yourdata warehouse. Logical views are defined using SQL queries against thedata warehouse, which can combine data from multiple physical tables intoone logical table representation in MicroStrategy.

This chapter introduces you to the di fferent types of logical tables, wi th afocus on how you can use the logical view feature to take advantage of theenhanced schema support in MicroStrategy.

Logical tables

Logical tables are MicroStrategy objects that form the foundation of aschema. Physical tables in a data warehouse consist of columns, andlogical tables in the MicroStrategy schema relate this column data toattributes and facts. These attributes and facts are part of the reportdefini tion that the MicroStrategy Engine refers to when a report is executed.

The types of logical tables are:

Logical table: A logical representation of a physical table thatMicroStrategy uses to generate SQL. A logical table is created for eachphysical table that is imported into a project, using the Warehouse Catalog.This type of logical table maps directly to physical tables in the datawarehouse. These physical tables are referenced in the SQL that isgenerated for the report.

This type of logical table is the most common logical table. Based onthese tables, you can create MicroStrategy schema objects, such asattributes and facts. For more information on how to use the WarehouseCatalog, refer to the Help (search for "Warehouse Catalog").

Logical tables also al low you to support the fol lowing configurations:

Defining logical table sizes, page 507



Defining the primary key for a table, page 511

Logical table alias: A logical table that uses a di fferent name for a physicaltable. One physical table can have more than one logical table al ias.Logical table al iases are used to create attribute roles.

When an attribute plays more than one role, you need to create anattribute in the logical model for each of the roles. To accompl ish this,you create multiple logical table al iases pointing to the same physicaltable and define those logical table al iases as the lookup tables for theattributes in di fferent roles.

For example, i f the Customer table is used to represent both Ship toCustomer and Bi l l to Customer, you can create a logical table al ias toresolve the double usage case. First, create a logical table al ias bycopying the existing logical table and giving i t a di fferent name; thendefine the new attributes using the appropriate tables.

For detai led information on attribute roles, refer to Attributes that use thesame lookup table: Attribute roles, page 307. To create a logical tableal ias, right-cl ick the logical table name and select Create Table Alias.For step-by-step instructions, refer to the Help (search for "Create atable al ias").

Logical view: A logical table that is created using a SQL statement insteadof being a direct representation of a physical table. Once created, thelogical view can be used in the same way as any logical table. The logicalview is also referenced in the SQL that is generated for the report; thewhole SQL query is displayed in the place of physical tables, as is standardfor other logical tables. Logical views are created using the Table Edi tor.

If your project supports data internationalization, you cannot use logical v iewsas lookup tables for attributes that use translated data. For information onsupporting data internationalization, see Supporting datainternational ization, page 64 .



Logical views are di fferent from the above-mentioned logical tables andlogical table al iases for the fol lowing reasons:

Logical views do not map directly to physical tables in the data warehouse,and instead are defined using SQL queries.

Logical views are manual ly created to return data, from potential ly mul tiplephysical tables, as one logical table. Logical tables and logical tableal iases can only retrieve data from a single physical table.

However, once logical views are created, they can be used in the sameway as logical tables and logical table al iases. This means that you canuse the logical views to bui ld attributes and facts, and that you can alsocreate logical table al iases for the logical views.

The biggest benefi t of using logical views is that you can model aMicroStrategy schema that cannot be supported with only the physicaldatabase structures in the data warehouse. Many common model ingscenarios are easier to manage using logical views. Examples are:

Slowly-changing dimensions

Attribute form expressions from multiple tables

Consol idated dimension tables

Recursive hierarchies

For common usage examples, refer to Logical view examples, page 516.

In the MicroStrategy Tutorial , logical tables and al l the other schemaobjects are stored in the Schema Objects folder. Using the Logical TableEdi tor, you can define your logical view using a SQL statement, as wel l asview the content of al l the logical tables and their associated warehousetables.

Whenever you create or add logical tables, logical table al iases, or logicalviews to the project, you need to update the schema. The Update Schemaoption can be accessed from the Schema menu.



Creating logical tables

Logical tables are brought into the project by using the Warehouse Catalogor Archi tect, and table al iases are created by dupl icating existing logicaltables. Steps on how to add logical tables to a project are provided for bothmethods, as l isted below:

Using Archi tect: Adding, removing, and administering tables, page 140

Using the Warehouse Catalog: Adding and removing tables for a project,page 329

Defining logical table sizesMicroStrategy assigns a size to every table in the project when you ini tial lyadd i t to the project. These size assignments are based on the columns inthe tables and the attributes to which those columns correspond. BecauseMicroStrategy uses the conceptual or logical attribute defini tions to assigna size to each table in the project, this measurement is referred to aslogical table size.

The logical table size determines which logical table to use to answer aquery when multiple logical tables would provide the same data. The tablewi th the lowest logical table size is used, as a lower logical table sizemeans the table has a higher level of aggregation. The performance ofaccessing a table wi th a higher level of aggregation is usual ly better thanaccessing a table wi th a lower level of aggregation.

MicroStrategy ini tial ly assigns logical table sizes based on an algori thmthat takes into account the number of attribute columns and the variouslevels at which they exist in their respective hierarchies. If this does notmeet your requirements, you can define the logical table size for a table asrequired.

For example, a base fact table contains mi l l ions of rows of transaction-leveldata. The other tables have only higher-level or summary information. Sincethe levels of the attributes are lower in the base fact table, the base fact



table is assigned a higher value for i ts logical table size than are thesummary tables with higher-level attributes. This means the table wi thsummary information is used to return data rather than the table wi thtransaction-level data when the tables can be used to answer the samequery.

However, in the example scenario described above, there may be a reasonthat you want to access the table wi th transaction-level data instead of thetable wi th summary information. In these types of scenarios, you canmanual ly define the logical table size for a table, for which you have thefol lowing options:

Defining the logical table size of a single table, page 508

Defining logical table size whi le comparing al l project tables, page 509

Defining the logical table size of a single table

The steps to define the logical table size of a single table using the TableEdi tor are described below.

To define the logical table size of a single table

From MicroStrategy Developer, log in to a project.

Browse to the location where you store your tables, and double-cl ick thedesired table. If a message is displayed asking i f you want to use readonly mode or edi t mode, select Edit and cl ick OK to open the TableEdi tor in edi t mode so that you can make changes to the table. TheTable Edi tor opens.





On the Logical View tab, in the Logical size area, type the value for thetable's logical size.

If multiple tables can be used to answer the same query, the table with thelowest logical table size is used.

To lock the logical table size of a table, select the Preserve this logicalsize when updating schema information check box. When a table'slogical size is locked, the table is excluded from the logical table sizecalculation when a schema update is performed.

Cl ick Save and Close to save your modi fications to the table and close theTable Edi tor.

You must update the schema for the new logical table size to take effect.Close al l edi tors, then from the Schema menu, select Update Schema.

Defining logical table size while comparing all project tables

The steps to define the logical table size of a table whi le comparing al lproject tables are described below.

To define the logical table size of a table while comparing all project

tables

From MicroStrategy Developer, log in to a project.

From the Schema menu, select Edit Logical Size. If a message isdisplayed asking i f you want to use read only mode or edi t mode, selectEdit and cl ick OK to open the Logical Size Edi tor in edi t mode so thatyou can make changes to the table's logical size. The Logical SizeEdi tor opens.





In the Size value column for a table, type the desired value for the table'slogical size.

If multiple tables can be used to answer the same query, the table with thelowest logical table size is used.

You can sort any column in the Logical Size Editor by click ing on the columnheading.

You can display the number of rows in each table by selecting Show thetable row count from the Edit menu.

To lock the size of a table, select that table's Size locked check box. Whena table's logical size is locked the table is excluded from the logical tablesize calculation when a schema update is performed. This helps to retainany table sizes that are manual ly defined.

To unlock the table's size, clear the Size locked check box.

To lock or unlock all table values displayed, c lick the Lock all or Unlock alltoolbar options.

To al low MicroStrategy to calculate the table logical size automatical ly foral l tables, cl ick the Calculate all icon.

From the File menu, select Save to save your changes.

From the File menu, select Close to close the Logical Size Edi tor.

You must update the schema for any new logical table sizes to take effect.Close al l edi tors, then from the Schema menu, select Update Schema.



Defining the primary key for a tableMicroStrategy requires each table to have a primary key, which is a uniquevalue identi fying each distinct data record or row. A primary key can bedefined by one or more columns in the table. For more information onprimary keys, see Uniquely identi fying data in tables with key structures,page 44.

MicroStrategy determines the primary key for a table based on the attributesmapped to the columns of the table. In the Table Edi tor on the Layout tab, akey icon displayed by the attribute name indicates that the attribute is partof the primary key for this table. The primary key is made up of the lowestlevel attributes. For example, a warehouse table's primary key is definedusing the columns CUSTOMER_ID , PRODUCT_ID , and ORDER_ID . If thesethree columns are mapped to attributes in MicroStrategy, then the primarykey is represented correctly. In this case, from the Table Edi tor's Layouttab, you can select the The key specified is the true key for thewarehouse table check box. This is the defaul t behavior for al l tablesadded to a MicroStrategy project.

If the primary key for the warehouse table is not identical to the attributesl isted as key attributes for the table in MicroStrategy, clear the The keyspecified is the true key for the warehouse table check box. Using theexample described above, consider the scenario in which CUSTOMER_ID

and PRODUCT_ID are mapped to MicroStrategy attributes, but ORDER_ID isnot mapped to an attribute in MicroStrategy. In this case, only CUSTOMER_

ID and PRODUCT_ID would be recognized by MicroStrategy as part of thetable's primary key. In this scenario, this check box should be cleared sothat the warehouse table's primary key can be veri fied. Otherwise, selectingthis check box for such a scenario could cause incorrect or erroneous datato be returned.



Creating logical views

Logical views can be created in MicroStrategy Developer using the TableEdi tor, which is shown in the image below.

The Object Browser on the left-hand side l ists al l tables and columns thathave been imported into the project. Any physical table in the projectdatabase instance can be used in the SELECT statement. The SQLstatement panel , displayed near the top and on the right-hand side, iswhere you type in your SQL query. The Mapping panel , displayed justbelow the SQL statement panel , is where you map the columns returned bythe SQL query.

Since SQL queries are required to create logical views, you should beexperienced with using SQL before you use the logical view feature. It isyour responsibi l i ty to ensure the accuracy and val idi ty of your SQLstatements. In addi tion, you should also understand that the SQL queryentered for logical views is not modi fied in any way by MicroStrategy.



Therefore, make sure that your RDBMS is optimized to answer the querythat you create.

Because the MicroStrategy Engine does not parse through the SQL syntax,the statistics log does not contain any information about the actual physicaltables accessed; the logical view is logged instead. The same holds true i fyou use a view in the database, in which case table objects accessed arenot logged ei ther.

In the SQL generated for a report, logical views are generated as ei ther aderived table or a common table expression (CTE) depending on the type ofdatabase that you use. It is recommended that you use derived tables todefine logical views, al though CTEs are also supported by somedatabases. Derived tables are advantageous because they are nested inthe SQL generated by the Engine. CTEs, however, are not nested in theSQL because this would resul t in inval id SQL syntax. Refer to your thi rd-party database documentation for any appl icable SQL syntax requirements.

When the MicroStrategy Engine needs to use a logical table that mapsdirectly to a physical database table, i t inserts the name of the table into theFROM clause. For a logical view, which maps to a SQL statement, theMicroStrategy Engine inserts the SQL syntax in the FROM clause. TheEngine generates derived table syntax to represent the logical view.

The results of logical v iews are not cached. Instead, the logical v iew appearsas additional syntax in the report SQL generated by MicroStrategy.

The steps on how to create a logical view are described below.

Prerequisite

You must have the MultiSource Option to create logical views on datasources other than the data source for the primary database instance. If youdo not have the MultiSource Option, then you can only create logical viewsfor the data source that belongs to the primary database instance.



To create a logical view in the Table Editor

From the File menu, select New and then Logical Table. The Table Edi toris displayed with the Physical View tab selected by defaul t.

If you have the MultiSource Option, from the Select current databaseinstance drop-down l ist, select which data source to retrieve the data fromfor the logical view. Select a database instance for the data source to usefor the logical view.

If you do not have the MultiSource Option, then you can only createlogical views for the data source that belongs to the primary databaseinstance. This means that there is no drop-down l ist to select a databaseinstance.

When choosing a database instance, i f you select the database instancel isted as the project's primary database instance, the database instancefor the logical view is changed anytime the project's primary databaseinstance is changed. For examples of when to use each option, seeAdding data into a project, page 358.

In the SQL Statement panel , type your SQL statement. You can drag anddrop columns from the Object Browser to insert them into the statement.

It is recommended that you use derived tables to define logical viewsbecause the logical view SQL syntax becomes nested inside SQLstatements generated by the Engine. Al though common tableexpressions (CTEs) are also supported for some databases, theseexpressions cannot be nested in the SQL because this would resul t ininval id SQL syntax. Refer to your thi rd-party database documentation forany appl icable SQL syntax requirements.

By defaul t, the Enclose SQL statement in parentheses check box isselected. This encloses the enti re SQL statement that you typed in the SQLstatement panel in parentheses when the SQL statement is executed, whichis val id i f the SQL statement uses a standard select clause.



However, i f you include SQL functions to create tables, the parenthesescan cause inval id SQL syntax. Table creation syntax in a SQL statementcan be of the form TABLE (arg1, arg2, ..., argN) . If youinclude table creation SQL functions or other SQL functions that cannotsupport parentheses that enclose the enti re SQL statement, clear thischeck box. Refer to your thi rd-party database documentation for anyappl icable SQL syntax requirements.

Cl ick Add to map columns returned by the SQL statement.

Type in the column name under Column Object. This creates a newcolumn.

Al ternatively, you can also drag and drop columns from the ObjectBrowser to the Column Object cel l . By doing this, you map an existingcolumn to the logical view.

The names of the columns must match exactly the column al iasesdefined in the SQL statement. However, the order of the columns doesnot have to match the order in which the column al iases appear in theSQL statement.

Select a Data Type for the column by using the drop-down l ist.

If you used an existing column in the mapping in this step, the data typeof that column is inheri ted. If you change the data type, the change wi l laffect al l the tables with that column.

Modi fy the Precision and Scale of the column, i f appl icable:

Precision : The total number of digi ts used to define a number. Forexample, the number 1234.56789 has a precision of nine and a scale offive.

Scale: The number of digi ts to the right of the decimal point used to definea number. The scale of a data type must be less than or equal to theprecision for the data type. For example, the number 1234.56789 has ascale of five and a precision of nine.



From the toolbar, cl ick Save and Close to save the logical table and closethe Table Edi tor.

From the Schema menu, select Update Schema to ensure that the newlogical view is loaded into the project.

Based on the logical view that you just created, you can now create newattributes and facts, as you would with any other logical table (see Creatingattributes, page 251 and Creating facts, page 208). You can also map thecolumns of the logical table to existing attributes and facts. This can bedone by modi fying the attributes or facts to include the logical table as asource table.

Logical view examples

The fol lowing business cases are intended to help you understand how youcan use the logical view feature in your appl ications.

Business case 1: Distinct attribute lookup tableMany star schemas feature a single lookup table that is shared by al l theattributes in one dimension (see the fol lowing example). Whi le i t is possibleto model a schema with such a dimension table, often two problems arise:

The model cannot support fact tables at the level of attributes that are notkeys. This restriction appl ies to summary tables as wel l as to intermediateresul ts that may be generated by the SQL Engine.

Usual ly, in one-SQL-pass reports, the MicroStrategy Engine joins thefact table wi th one lookup table and does the aggregation. If there is nodistinct l ist of attribute elements, you may double count i f you have tojoin to a table where that attribute is part of the key.

Too many rows in the dimension table may slow down the SELECTDISTINCT query, thus affecting element browsing requests that display al ist of attribute elements, for example, when populating pick l ists forprompts.



The fol lowing is an example lookup table for Store, Market, and Region.

Lookup_store

Store_ID Store_Name Market_ ID Market_Name Region_ID Region_Name Level

In this table, Market and Region are not the keys. Therefore, i f therequested fact table is at the Market or Region level , a direct join betweenthe fact table and the above lookup table may resul t in double-counting. Toavoid that, you can use the Logical View feature to define another logicaltable Lookup_Market as fol lows:

Select Market_ID, Market_Name, Region_ID

From Lookup_store

Where level=1

Then use this table as the lookup table for Market. When i t is joined with aMarket-level fact table (Market_Sales), the fol lowing report SQL isgenerated:

Select a11.Market_ID,a11.Market_Desc,

SUM(a12.Sales)

From (select Market_ID, Market_Name, Region_ID

from Lookup_Store

where level=1) a11,

Market_Sales a12

Where a11.Market_ID = a12.Market_ID

Group by a11.Market_ID,

a11.Market_Name

Business case 2: Attribute form expression across multipletablesCustomers often request the abi l i ty to generate an attribute form expressionacross multiple tables. Usual ly, the case is on Date columns. For example,



you want to define an attribute based on the Date di fference between twoDate columns (Ship_Date and Order_Date) in two di fferent tables asfol lows.

F_Table1

Ship_Date Order_ID Fact1

F_Table2

Order_Date Order_ID Fact2

Using the Logical View feature, you can use the fol lowing SQL query tocreate a logical table to calculate the Date di fference and then define theattribute on that new column:

Select Ship_Date-Order_Date Cycle_time,

F_table1.Order_ID, Fact1, Fact2

From F_table1, F_table2

Where F_table1.Order_ID=F_table2.Order_ID

The new logical table (logical view) looks l ike the fol lowing table, and anew attribute can be defined on the Cycle_Time column.

Logical view

Cycle_Time Order_ID Fact1 Fact2



Business case 3: Slowly changing dimensionsSlowly changing dimensions (SCDs) are a common characteristic in manybusiness intel l igence environments. Usual ly, dimensional hierarchies arepresented as independent of time. For example, a company may annual lyreorganize their sales organization or recast their product hierarchy foreach retai l season. "Slowly" typical ly means after several months or evenyears. Indeed, i f dimensional relationships change more frequently, i t maybe better to model separate dimensions.

SCDs are wel l documented in the data warehousing l i terature. RalphKimbal l has been particularly influential in describing dimensionalmodel ing techniques for SCDs (see The Data Warehouse Toolki t, forinstance). Kimbal l has further coined di fferent distinctions among ways tohandle SCDs in a dimensional model . For example, a Type I SCD presentsonly the current view of a dimensional relationship, a Type II SCDpreserves the history of a dimensional relationship, and so forth.

The discussion below is based on an example sales organization thatchanges slowly in time as the terri tories are reorganized; for example, salesrepresentatives switch districts in time.

As-is vs. as-was analysis

One of the capabi l i ties avai lable wi th slowly changing dimensions is theabi l i ty to perform ei ther "as-is" analysis or "as-was" analysis:

"As-is" analysis presents a current view of the slowly changingrelationships. For example, you can display sales by District according tothe way Districts are organized today.

"As-was" analysis presents a historical view of the slowly changingrelationships. For example, you can display sales by District according tothe way Districts were organized at the time the sales transactionsoccurred.



The techniques described here provide the flexibi l i ty to perform ei ther typeof analysis. They also provide you an easy way to speci fy which type ofanalysis you would l ike to perform.

Example 1: Compound key with Effective Date and End Date

One way to physical ly store an SCD is to employ Effective Date and EndDate columns that capture the period of time during which each elementrelationship existed. In the example below, Sales Rep Jones moved fromDistrict 37 to District 39 on 1/1/2004, and Kel ly moved from District 38 to 39on 7/1/2004.

For information on compound keys, please refer to Lookup tables: Attributestorage, page 45 .

LU_SALES_REP

Sales_Rep_ID Sales_Rep_Name Distr ict_ ID Eff_Dt End_Dt

1 Jones 37 1/1/1900 12/31/2003

2 Smith 37 1/1/1900 12/31/2099

3 Kelly 38 1/1/1900 6/30/2004

4 Madison 38 1/1/1900 12/31/2099

1 Jones 39 1/1/2004 12/31/2099

3 Kelly 39 7/1/2004 12/31/2099

When using this type of dimensional lookup table, the fact table mustinclude a date field, such as a transaction date.

FACT_TABLE



Sales_Rep_ID Trans_Dt Sales

1 9/1/2003 100

2 9/10/2003 200

3 9/15/2003 150

1 3/1/2004 200

2 3/10/2004 250

3 3/15/2004 300

2 9/5/2004 125

3 9/15/2004 275

4 9/20/2004 150

To specify the MicroStrategy schema

Create a logical view to represent just the current District-Sales Reprelationships.

LVW_CURRENT_ORG

select Sales_Rep_ID, District_ID

from LU_SALES_REP

where End_Dt = '12/31/2099'

Create another logical view that performs the "as-was" join between thelookup table and fact table, resul ting in a fact view at the District level .

The resulting view is an "as-was" or historical v iew, which captures the SalesRep-Distric t relationships that existed at the time the transactions occurred.

LVW_HIST_DISTRICT_SALES

select District_ID, Trans_Dt, sum(sales)

sales

from LU_SALES_REP L



join FACT_TABLE F

on(L.Sales_Rep_ID = F.Sales_Rep_ID)

where F.Trans_Dt between L.Eff_Dt and

L.End_Dt

group by District_ID, Trans_Dt

Create a table al ias LU_CURRENT_DISTRICT for LU_DISTRICT.

Define the fol lowing attributes:

Sales Rep :

@ID = sales_rep_id; @Desc = sales_rep_name

Tables: LU_SALES_REP (lookup), LVW_CURRENT_ORG, FACT_TABLE

Current District:

@ID = district_id; @Desc = district_name

Tables: LU_CURRENT_DISTRICT (lookup), LVW_CURRENT_ORG

Chi ld: Sales Rep

Historical District:


Tables: LU_DISTRICT (lookup), LU_SALES_REP, LVW_HIST_DISTRICT_SALES

Chi ld: Sales Rep

Date:

@ID = date_id, trans_dt

Tables: LU_TIME (lookup) , FACT_TABLE, LVW_HIST_DISTRICT_SALES

Month :

@ID = MONTH_ID

Tables: LU_TIME (lookup)



Define the Sales fact:

Expression : sales

Tables: FACT_TABLE, LVW_HIST_DISTRICT_SALES

Define the metric as required:

Sales: SUM(sales)

The resul t of this is a logical schema that looks l ike the fol lowing:

As-was analysis

Speci fy the "as-was" analysis by using the Historical District attribute onreports:

Report definition : Historical District, Month, Sales

Resulting SQL

Select a11.District_ID District_ID,

max(a13.District_Name) District_Name,

a12.Month_ID Month_ID,

sum(a11.SALES) WJXBFS1

From (select District_ID, Trans_dt,sum(sales) sales

from LU_SALES_REP L

join FACT_TABLE F



on (L.Sales_rep_ID = F.Sales_rep_ID)

where F.trans_dt between L.EFF_DT and

L.END_DT

group by District_ID, Trans_dt)

a11

join LU_TIME a12

on (a11.Trans_dt = a12.Date_ID)

join LU_DISTRICT a13

on (a11.District_ID = a13.District_ID)

group by a11.Distrcit_ID,

a12.Month_ID

Report results

As-is analysis

Speci fy the "as-is" analysis by using the Current District attribute onreports:

Report definition : Current District, Month, Sales

Resulting SQL

select a12.District_ID District_ID,

max (a14.District_Name) District_Name,



from FACT_TABLE a11

join (select Sales_rep_ID, District_ID

from LU_SALES_REP

where END_DT = '12/31/2099')a12



on (a11.Sales_Rep_ID =

a12.Sales_Rep_ID)

join LU_TIME a13



on (a12.District_ID = a14.District_ID)

group by a12.District_ID,

a13.Month_ID

Report result

Example 2: New surrogate key for each changing element

A more flexible way to physical ly store a SCD is to employ surrogate keysand introduce new rows in the dimension table whenever a dimensionalrelationship changes. Another common characteristic is to include anindicator field that identi fies the current relationship records. An exampleset of records is shown below.

LU_SALES_REP

Sales_Rep_CD Sales_Rep_ID Sales_Rep_Name Distr ict_ ID Current_Flag

1 1 Jones 37 0

2 2 Smith 37 1

3 3 Kelly 38 0

4 4 Madison 38 1



Sales_Rep_CD Sales_Rep_ID Sales_Rep_Name Distr ict_ ID Current_Flag

5 1 Jones 39 1

6 3 Kelly 39 1

When using this type of dimensional lookup table, the fact table must alsoinclude the surrogate key. A transaction date field may or may not exist.

FACT_TABLE

Sale-Rep_CD Sale

1 100

2 200

3 150

5 200

2 250

3 300

2 125

6 275

4 150

Specifying the MicroStrategy schema

Create a logical view to represent just the current District-Sales Reprelationship.

LVW_CURRENT_ORG

select Sales_rep_ID, District_ID

from LU_SALES_REP

where Current_flag = 1



Create a table al ias LU_CURRENT_DISTRICT for LU_DISTRICT.

Define the fol lowing attributes:

Sales Rep Surrogate:

@ID = sales_rep_cd

Tables: LU_SALES_REP (lookup), FACT_TABLE

Sales Rep :

@ID = sales_rep_id; @Desc = sales_rep_name

Tables: LU_SALES_REP (lookup), LVW_CURRENT_ORG

Chi ld: Sales Rep Surrogate

Current District:


Tables: LU_CURRENT_DISTRICT (lookup), LVW_CURRENT_ORG

Chi ld: Sales Rep

Historical District:


Tables: LU_DISTRICT (lookup), LU_SALES_REP

Chi ld: Sales Rep

Date:

@ID = date_id, trans_dt

Tables: LU_TIME (lookup), FACT_TABLE

Month :

@ID = MONTH_ID

Tables: LU_TIME (lookup)



Chi ld: Date

Define the Sales fact:

Expression : sales

Tables: FACT_TABLE, LVW_HIST_DISTRICT_SALES

Define the metric as required:

Sales: SUM(sales)

The resul t is a logical schema as fol lows:

As-was analysis

Speci fy the "as-was" analysis by using the Historical District attribute onreports:

Report definition : Historical District, Month, Sales

Resulting SQL


max(a14.Distrcit_Name) Distrcit_Name,



from FACT_TABLE a11

join LU_SALES_REP a12



on (a11.Sales_Rep_CD =

a12.Sales_Rep_CD)

join LU_TIME a13



on (a12.District_ID =

a14.District_ID)


a13.Month_ID

Report results

As-is analysis

Speci fy the "as-is" analysis by using the Current District attribute onreports:

Report definition : Current District, Month, Sales

Resulting SQL :


max(a15.Distrcit_Name) District_Name,



from FACT_TABLE a11

join LU_SALES_REP a12

on (a11.Sales_Rep_CD =

a12.Sales_Rep_CD)

join (select Sales_rep_ID, District_ID

from LU_SALES_REP



where current_flag = 1)

a13

on (a12.Sales_Rep_ID =

a13.Sales_Rep_ID)

join LU_TIME a14



on (a13.District_ID =

a15.District_ID)


a14.Month_ID

Report result

Business case 4: One-to-many transformation tablesIn order to support time-series analysis, such as month-to-date and year-to-date calculations, you need to define transformations. Al though one-to-onetransformations, such as Last Month, can be defined in terms of anexpression, one-to-many transformations require tables in the database thatmap each date to al l the previous dates that make up "month-to-date."

If you do not already have such a table in the warehouse and yourci rcumstances do not al low you to add addi tional tables to the database,then you can use the logical view approach to address this issue as long asyou already have a lookup table for the Day attribute.

The SQL below can be used to define a logical MTD_DATE table, whichcontains the Day attribute. The MTD transformation can then be definedusing the MTD_DATE column.



Select day_date day_date, B.day_date mtd_date

From lu_day A, lu_day B

Where A.day_date >= B.day_date

And MONTH(A.day_date)= MONTH(B.day_date)

The same technique can be used to define a year-to-date transformation.

Select A.day_date day_date, B.day_date

ytd_date

From lu_day A, lu_day B

Where A.day_date >= B.day_date

And YEAR(A.day_date) = YEAR(B.day_date)

Business case 5: Outer joins between attribute lookup tablesA common request is the abi l i ty to generate an outer join between attributelookup tables for a report that contains only attributes (that is, no metrics).For example, consider the tables below.

EMPLOYEE EMERGENCY CONTACT DEPARTMENT

EMP_ID EMP_ID DEPT_ID

FIRST_NAME CONTACT_FIRST_NAME DEPT_NAME

LAST_NAME CONTACT_LAST_NAME BUS_UNIT_ID

HIRE_DATE CONTACT_PHONE_NUMBER

DEPT_ID

Given this structure, you could model an attribute hierarchy as fol lows:

Business Uni t -< Department -< Employee

Hire Date -< Employee

Emergency Contact -< Employee



In addi tion, the relationship between Employees and Emergency Contactsis such that each employee may have up to one contact, which means notal l employees have contacts on record. One of the reports you probablywould l ike to create may look l ike the fol lowing:

Employee Department Emergency Contact Phone Number

Gonzalez, James Market ing

Dawson, John Finance Dawson, Jane 555-1212

Larkins, Abraham R & D Taylor, Mary 555-3456

Walker, George Finance Walker, Martha 555-9876

. . . . . . . . . . . .

NULLS are displayed for employees who do not have emergency contacts.

However, i f you model the attributes as described below, you would not getthe desired output:

Employee:

@ID = EMP_ID, @[First Name] = FIRST_NAME, @[Last Name] = LAST_NAME

Tables: EMPLOYEE (lookup), EMERGENCY_CONTACT

Department:

@ID = DEPT_ID

Tables: DEPARTMENT (lookup), EMPLOYEE

Chi ld: Employee

Hire Date:

@ID = HIRE_DATE

Tables: EMPLOYEE (lookup)



Chi ld: Employee

Emergency Contact:

@ID = CONTACT_PHONE_NUMBER, @[First Name] = CONTACT_FIRST_NAME, @[Last Name] = CONTACT_LAST_NAME

Tables: EMERGENCY_CONTACT (lookup)

Chi ld: Employee

Using the above model , the SQL generated would join the EMPLOYEEtable to the EMERGENCY_CONTACT table, and only those employees whohave emergency contacts would appear in the final resul t. In order to see al lemployees, you can perform an outer join using a logical view, describedas fol lows.

Using a logical view for an outer join

To perform an outer join for the case described above, you can use thefol lowing SQL and the l ist of columns to map to the view:

select E.EMP_ID,

E.FIRST_NAME,

E.LAST_NAME,

E.HIRE_DATE,

E.DEPT_ID,

C.CONTACT_FIRST_NAME,

C.CONTACT_LAST_NAME,

C.CONTACT_PHONE_NUMBER

from EMPLOYEE E

left outer join EMERGENCY_CONTACT C

on (E.EMP_ID = C.EMP_ID)



LVW_EMERGENCY_CONTACT

EMP_ID

FIRST_NAME

LAST_NAME

HIRE_DATE

DEPT_ID

CONTACT_FIRST_NAME

CONTACT_LAST_NAME

CONTACT_PHONE_NUMBER

Make sure to include al l columns from the original chi ld table (for example,EMPLOYEE). The new logical table LVW_EMERGENCY_CONTACT canthen be used to define attributes as fol lows:

Employee:

@ID = EMP_ID, @[First Name] = FIRST_NAME, @[Last Name] = LAST_NAME

Tables: EMPLOYEE (lookup), LVW_EMERGENCY_CONTACT

Department:

@ID = DEPT_ID

Tables: DEPARTMENT (lookup), EMPLOYEE, LVW_EMERGENCY_CONTACT

Chi ld: Employee

Hire Date:

@ID = HIRE_DATE

Tables: EMPLOYEE (lookup), LVW_EMERGENCY_CONTACT



Chi ld: Employee

Emergency Contact:

@ID = CONTACT_PHONE_NUMBER, @[First Name] = CONTACT_FIRST_NAME, @[Last Name] = CONTACT_LAST_NAME

Tables: EMERGENCY_CONTACT (lookup), LVW_EMERGENCY_CONTACT

Chi ld: Employee

The Employee attribute is not represented in the original EMERGENCY_CONTACT table and all attributes represented in the EMPLOYEE table arealso represented in the LVW_EMERGENCY_CONTACT table.

Now if we run a report wi th Employee and Emergency Contact attributes,the EMPLOYEE table wi l l be outer joined to the EMERGENCY_CONTACTtable, and NULLs wi l l be returned for any employees who do not haveemergency contacts. Also note that i f we run a report that includes only theEmployee attribute, i t wi l l be executed against the EMPLOYEE table; theEMERGENCY_CONTACT table wi l l be joined only when necessary.

This technique is appl icable any time that the lookup tables should alwaysbe outer joined. The technique does not work when the lookup tablesshould sometimes be outer joined and sometimes be inner joined.



DATA TYPESPro ject Design Gu id e


To generate SQL or retrieve data from data sources, MicroStrategy must beaware of the data types that exist in your database. As each RDBMSsupports a di fferent set of data types, MicroStrategy general izes them into aset of MicroStrategy-speci fic data types.

Mapping of external data types to MicroStrategy datatypes

When you create a project and add tables from your data warehouse to theMicroStrategy Warehouse Catalog, MicroStrategy automatical ly maps thecolumns within those tables to MicroStrategy-speci fic data types. Eachcolumn from your database becomes associated with a MicroStrategy datatype.

This database data type to MicroStrategy data type mapping is necessary,in part, because each database names data types in di fferent ways. Datatypes that may be conceptual ly the same can have di fferent names.Therefore, MicroStrategy must map every column brought into the projectschema to an internal data type.

Suppose you add a table to the Warehouse Catalog. In your relationaldatabase, a column within that table has a data type of "SMALLINT."MicroStrategy maps this column to a MicroStrategy-speci fic data type, forexample, "INTEGER." This al lows MicroStrategy to maintain a consistentSQL generation process.

The MicroStrategy data type stores data values internal ly and in themetadata reposi tory and is later used during SQL generation when definingintermediate tables, and data mart tables, and generating the correct syntaxfor l i terals. The data type is also used whenever mul ti -pass SQL is used, aswith custom groups. For more information about data marts and customgroups, see the Advanced Reporting Guide.

The table below l ists the supported data types for supported databases aswel l as the MicroStrategy data type that is used to define the data in




MicroStrategy. For information on MicroStrategy data types, seeMicroStrategy data types, page 587.The databases that are l isted in thistable include:

DB2, page 539

Generic, page 545

Informix, page 546

MetaMatrix, page 551

MySQL, page 552

Netezza, page 560

Oracle, page 569

PostgreSQL, page 570

SQL Server, page 571

Sybase, page 577

Sybase IQ , page 578

Teradata, page 583



Database Supported database data types MicroStrategy data type

DB2 BIGINT Big Decimal




BLOB LongVarBin




CHAR Char




CHARACTER Char




CLOB LongVarChar




DATE Date

DEC Numeric

DECIMAL Numeric

DOUBLE Double

DOUBLE PRECISION Double

FLOAT Double

GRAPHIC NChar

INT Integer

INTEGER Integer

LABEL VarChar

LONG VarChar

LONG VARCHAR VarChar

LONGVAR VarChar

NUM Numeric

NUMERIC Numeric

RAW VarBin

REAL Real

SMALLINT Integer

TIME Time

TIMESTAMP Timestamp

TIMESTMP Timestamp

VARCHAR VarChar

VARGRAPHIC NVarChar




Generic

BIT Binary

BIT VARYING VarBin

CHAR Char

CHAR VARYING VarChar

CHARACTER Char

CHARACTER VARYING VarChar

DATE Date

DECIMAL Decimal

DOUBLE PRECISION Float

FLOAT Float

INT Integer

INTEGER Integer

NUMERIC Numeric

REAL Real

SMALLINT Integer

VARBIT VarBin

VARCHAR VarChar




Informix BOOLEAN Char




BYTE LongVarBin




CHAR Char




CHARACTER Char




DATE Date

DATETIME Timestamp

DATETIME HOUR TO SECOND Timestamp

DATETIME YEAR TO SECOND Timestamp

DEC Decimal

DECIMAL Decimal


FLOAT Double

INT Integer

INT8 Big Decimal

INTEGER Integer

LVARCHAR LongVarChar

MONEY Numeric

NCHAR NChar

NUMERIC Decimal

NVARCHAR NVarChar

REAL Real

SERIAL Integer

SERIAL8 Integer

SMALLFLOAT Real

SMALLINT Integer

TEXT LongVarChar

VARCHAR VarChar




MetaMatrix

BIGDECIMAL Numeric

BIGINTEGER Integer

BLOB VarBin

BOOLEAN Binary

BYTE Integer

CHAR Char

CLOB VarChar

DATE Date

DOUBLE Double

FLOAT Float

INTEGER Integer

LONG Integer

SHORT Integer

STRING VarChar

TIME Time

TIMESTAMP Timestamp




MySQL BIGINT Integer




BINARY Binary




BIT Unsigned




BLOB LongVarBin




CHAR Char




DATE Date




DATETIME Timestamp




DECIMAL Decimal

DOUBLE Double

ENUM Char

FLOAT Float

INT Integer

LONGBLOB LongVarBin

LONGTEXT LongVarChar

MEDIUMBLOB LongVarBin

MEDIUMINT Integer

MEDIUMTEXT LongVarChar

NCHAR NChar

NVARCHAR NVarChar

SET Char

SMALLINT Integer

TEXT LongVarChar

TIME Time

TIMESTAMP Timestamp

TINYBLOB LongVarBin

TINYINT Integer

TINYTEXT LongVarChar

VARBINARY VarBin

VARCHAR VarChar

YEAR Integer




Netezza BIGINT Big Decimal




BIT Binary




BIT VARYING VarBin




BYTEINT Integer




CHAR Char




CHAR VARYING VarChar




CHARACTER Char




CHARACTER VARYING VarChar




DATE Date

DATETIME Timestamp

DECIMAL Numeric

DOUBLE Float

DOUBLE PRECISION Float

FLOAT Float

FLOAT4 Float

FLOAT8 Float

INT Integer

INT1 Integer

INT2 Integer

INT4 Integer

INT8 Big Decimal

INTEGER Integer

NCHAR NChar

NUMERIC Numeric

NVARCHAR NVarChar

REAL Real

SMALLINT Integer

TIME Time

TIMESTAMP TimeStamp

VARBIT VarBin

VARCHAR VarChar




Oracle

BLOB LongVarBin

CHAR Char

CLOB LongVarChar

DATE Timestamp

DECIMAL Numeric

FLOAT Float

INTEGER Numeric

LONG LongVarChar

LONG RAW LongVarBin

LONG VARCHAR LongVarChar

NCHAR NChar

NUMBER Numeric

NVARCHAR2 NVarChar

RAW VarBin

REAL Float

SMALLINT Numeric

TIMESTAMP(6) Timestamp

VARCHAR VarChar

VARCHAR2 VarChar




PostgreSQL

BIGINT Integer

BIGSERIAL Integer

BIT Binary

BIT VARYING VarBin

BOOLEAN Integer

CHAR Char

DATE Date

DECIMAL Decimal


INTEGER Integer

NUMERIC Decimal

REAL Real

SERIAL Integer

SMALLINT Integer

TEXT LongVarChar

TIME Time

TIMESTAMP Timestamp

VARBIT VarBin

VARCHAR VarChar




SQL Server BIGINT Numeric




BINARY VarBin




BIT Binary




CHAR VarChar




CHARACTER VarChar




DATE Timestamp

DATETIME Timestamp

DEC Numeric

DECIMAL Numeric

DOUBLE Float

FLOAT Float

IMAGE LongVarBin

INT Integer

INTEGER Integer

MONEY Numeric

NCHAR NChar

NTEXT LongVarChar

NUMERIC Numeric

NVARCHAR NVarChar

REAL Float

SMALLDATETIME Timestamp

SMALLINT Integer

SMALLMONEY Numeric

TEXT LongVarChar

TIME TimeStamp

TIMESTAMP VarBin

VARBINARY VarBin

VARCHAR VarChar




Sybase

BINARY Binary

BIT Binary

CHAR Char

DATETIME Timestamp

DECIMAL Numeric

FLOAT Float

IMAGE LongVarBin

INT Integer

INTEGER Integer


MONEY Numeric

NCHAR VarChar

NTEXT LongVarChar

REAL Real


SMALLINT Integer

SMALLMONEY Numeric

TEXT LongVarChar

TINYINT Unsigned

UNICHAR NChar

UNIVARCHAR NVarChar

VARBINARY VarBin

VARCHAR VarChar




Sybase IQ BIGINT Integer




BINARY Binary




BIT Binary




CHAR Char




DATE Date

DATETIME Timestamp

DECIMAL Numeric

DOUBLE Double

FLOAT Float

INT Integer

INTEGER Integer

LONG BINARY LongVarBin


MONEY Numeric

NUMERIC Numeric

REAL Real


SMALLINT Integer

SMALLMONEY Numeric

TIME Time

TIMESTAMP Timestamp

TINYINT Unsigned

UNSIGNED BIGINT Unsigned

UNSIGNED INT Unsigned

UNSIGNED SMALLINT Unsigned

VARBINARY VarBin

VARCHAR VarChar




Teradata BLOB LongVarBin




BYTE Binary




BYTEINT Integer




BYTEINTEGER Integer

BYTES Binary

CHAR Char

CHARACTER Char

CHARACTERS Char

CHARS Char

CLOB LongVarChar

DATE Date

DEC Decimal

DECIMAL Decimal


FLOAT Double

INT Integer

INTEGER Integer

LONG VARCHAR VarChar

NCHAR NChar

NVARCHAR NVarChar

NUMERIC Decimal

REAL Double

SMALLINT Integer

TIME Time

TIMESTAMP Timestamp

VARBYTE VarBin

VARCHAR VarChar



MicroStrategy data types

When the data warehouse catalog is read from the Warehouse Catalog, al lcolumns in the database are automatical ly mapped to one of the fol lowingMicroStrategy data types.

Data Type Description

Big Decimal High-precision f ixed point numbers.

BinaryFixed-length bit st rings.

Similar to ANSI BIT.

CharFixed-length character st rings.

Similar to ANSI CHAR.

DateCalendar dates.

Similar to ANSI DATE.

Decimal

Fixed point numbers up to 15 digits ofprecision.

Similar to ANSI DECIMAL.

Double8-byte f loat ing point numbers.

Similar to ANSI DOUBLE PRECISION.

Float4-byte f loat ing point numbers.

Similar to ANSI FLOAT.

IntegerSigned integer values.

Similar to ANSI INTEGER.

LongVarBinLarge strings of bits.

Similar to ANSI BLOB.

LongVarCharLarge strings of characters.

Similar to ANSI CLOB.



Data Type Description

NCharFixed-length character st rings used to supportvarious character sets.

NumericFixed point numbers up to 15 digits of precision.

Similar to ANSI NUMERIC.

NVarCharVariable-length character st rings used tosupport various character sets.

Real4-byte f loat ing point numbers.

Similar to ANSI REAL.

TimeTime of day.

Similar to ANSI TIME.

TimestampCombinat ions of calendar date and t ime of day.

Similar to ANSI TIMESTAMP.

Unsigned Unsigned integer values.

VarBinVariable-length bit st rings.

Similar to ANSI BIT VARYING.

VarCharVariable-length character st rings.

Similar to ANSI VARCHAR.

If the Warehouse Catalog displays a column with data type as Unknown, itimplies that the data type in the database has not mapped to one of theMicroStrategy data types.

Format types

Attribute forms are also associated with a MicroStrategy format type, whichspeci fies how attribute form values should be displayed on MicroStrategy



interfaces. You speci fy the format type of an attribute form in the FormFormat: Type drop-down menu in the Attribute Edi tor.

The attribute form format types are described in the fol lowing table.

FormatType

Description

BigDecimal

Informat ion is stored and displayed in the Big Decimal form, which representshigh-precision f ixed point numbers. For more informat ion about Big Decimal, seeBig Decimal, page 592.

BinaryInformat ion from binary data types is stored and displayed as a string ofcharacters. For more informat ion on support of binary data types, see Appendix ,MicroStrategy support for binary data types .

DateInformat ion is stored and displayed as dates in a sequent ial form to performcalculat ions on the dates. I t represents dates in the MM/DD/YYYY format.

Datet imeInformat ion is stored and displayed both as date and t ime in the format specif icto the data. The date follows the MM/DD/YYYY format and t ime follows theHH:MM:SS format.

Email Informat ion is stored and displayed in the form of an e-mail address.

HTMLTag

Informat ion is stored and displayed as an HTML tag.

Number Informat ion is stored and displayed in a number format.

Picture stored and displayed the form of an image f i le, such as bitmap, JPG, or GIF.

Text Informat ion is stored and displayed in a text format.

TimeInformat ion is stored and displayed as t ime in the HH:MM:SS format. Thisdisplays only the t ime and not the date.

URLInformat ion is stored and displayed as either an absolute or a relat ive UniversalResource Locator.



Data type and format type compatibility

If you change the MicroStrategy data type of one of the columns in yourproject—using a column al ias, for example—you must also change theformat type of the attribute. The data type of your column must be consistentwi th the format type you select because SQL generation issues can occur i fthe format type and data type are incompatible. You are warned in theAttribute Edi tor whenever you have selected a format type that isincompatible wi th the data type of your column.

For example, you edi t the ID form of the Year attribute in the AttributeEdi tor. In the Column Al ias tab, you notice that the Year attribute isassigned an "Integer" data type. However, you create a new column al iasand assign i t the "Date" data type.

When you return to the Defini tion pane in the Attribute Edi tor, you mustselect an appropriate format type from the Form Format: Type drop-downmenu. This format type must be compatible wi th the data type you assignedin the Column Al ias tab. If you select a format type that is incompatible wi ththe data type and cl ick OK to exi t the Attribute Edi tor, a warning messageappears noti fying you of the incompatibi l i ty. Al though you have the optionto continue by cl icking Yes, doing so can sti l l resul t in SQL generationissues.

The fol lowing chart is intended to guide you in assigning format types thatare compatible wi th the data type you have assigned to a column.

Different format types are compatible with different data types given thespecific data in your column. Therefore, some of the data type-format typecombinations below may not work with your specific data.

Data Type Compatible Format Types

Big Decimal Big Decimal



Data Type Compatible Format Types

Binary Number, Text , Picture

Char Text , URL, E-mail, HTML Tag

Date Date, Datet ime

Decimal Number

Double Number

Float Number

Integer Number

LongVarBin Picture, BLOB, Text depending on data

LongVarChar Picture, Text

Numeric Number

Real Number

Time Time, Datet ime

Timestamp Datet ime, Date or Time depending on data

Unsigned Number

VarBin Picture, Text

VarChar Text , URL, E-mail, HTML Tag, Picture

Supporting the BLOB format typeColumns in your data source that use BLOB format types can be mapped toattribute forms and facts in MicroStrategy. BLOB format types arerepresented in MicroStrategy as the LongVarBin data type. This data type istreated as a long string of binary data. This representation in MicroStrategyhas the fol lowing effects on including data from a BLOB format type on aMicroStrategy report or document:



Since the BLOB format type is represented as a LongVarBin, the data isdisplayed in ei ther binary or hexadecimal representation. The data is notconverted into any other format such as an image or PDF format. Therefore,columns in a data source that use BLOB format types to represent images,PDFs, or other non-binary or hexadecimal data should not be included inMicroStrategy.

MicroStrategy supports BLOB format types that include data records of up to32 Ki lobytes. If a BLOB, that contains more than 32 Ki lobytes, is included ina report, this can cause an error wi th a message such as String data,

right truncated .

Big Decimal

Big Decimal is a MicroStrategy-speci fic data type that al lows users tosupport high-precision attribute ID values that have more than 15 digi ts ofprecision, such as BIGINT and DECIMAL (precision, scale) data types.Examples of such attribute ID values are account numbers, credi t cardnumbers, and long integers.

Using the Big Decimal data typeWith the Big Decimal data type, MicroStrategy preserves the precision ofattribute ID values and attribute ID forms when displaying IDs andperforming operations such as fi l tering, dri l l ing, and page-by. For moreinformation about these operations, see the Basic Reporting Guide.

You can define attributes that are identi fied by numeric columns in thedatabase. These numeric columns can have more than 15 digi ts ofprecision, such as account numbers and other long integers. You must usethe Big Decimal data type to handle these values, because these datavalues have higher precision and cannot be stored in normal numeric datatypes.




If you do not associate high-precis ion database fields with the Big Decimaldata type, you may see numbers truncated starting with the 16th digit. TheWHERE clause in the report SQL statement in drill reports may truncatenumbers starting from the 16th digit, and page-by may not return results.

When using the Big Decimal data type, fol low the rules l isted below:

Constant: You can force a constant to be stored as a Big Decimal value byenclosing i t in hash marks. For example, you can define a fi l ter as"Customer@ID exactly #12345678#", even though 12345678 does notnecessari ly require the Big Decimal data type.

Attribute form: If you change the column data type to Big Decimal on theColumn Al ias tab in the Attribute Edi tor, you must also select Big Decimalas the form format type in the Form format: Type drop-down menu in theDefini tion tab.

Attribute ID : Fol low the steps in the topic Defining attributes with high-precision ID forms in the MicroStrategy Developer Help (formerly theMicroStrategy Desktop Help).

Metric: Al though i t is possible to define Big Decimal as the data type formetric values, consider the fol lowing drawbacks:

Precision is lost when any Analytical Engine calculation is performed, themetric is used in a data field in a document, the metric is subtotaled, ormetric values are displayed in Graph view.

Numeric formatting strings supported in MicroStrategy can have a di fferenteffect when appl ied to the Big Decimal data type. For numeric formattingdescriptions and examples when using the Big Decimal data type, seeNumeric data formatting, page 594.

When qual i fying on a Big Decimal metric, you must expl ici tly identi fy high-precision constants by enclosing the value within hash (#) symbols. Forexample, #1234567890123456#.



Note that the Warehouse Catalog does not automatical ly map DECIMAL(p,s) or NUMERIC(p, s) columns to the Big Decimal MicroStrategy data typeeven when the precision is greater than 15. This is because Big Decimalshould only be used when the column is used as an attribute ID form.

Numeric data formatting

You can apply the fol lowing numeric data formatting to the Big Decimaldata type:

For information on how numeric data formatting is applied to other data typesin MicroStrategy, see the Advanced Reporting Guide .

Symbol Description

0 (zero)

Digit placeholder.

• I f the number contains fewer digits than the placeholders contained in theformat, the number is padded with zeros.

For example, the format code 00000 will display the number 12 as 00012.

• I f there are more digits to the right of the decimal point than the placeholdersin the format, the decimal port ion is rounded to the number of places specif iedby the placeholders.

• I f there are more digits to the lef t of the decimal point than the placeholdersin the format, the extra digits are retained.

• I f the format contains zeros to the lef t of the decimal point , numbers less thanone are displayed with zeros to the lef t of the decimal point .

#

Digit placeholder.

• This digit placeholder displays signif icant digits and insignif icant zeros.

For example, the format code ##.### will display the number 0025.630 as 25.630.

• I f there are more digits to the right of the decimal point than the placeholdersin the format, the decimal port ion is rounded to the number of places specif iedby the placeholders.

• I f there are more digits to the lef t of the decimal point than the placeholders in




Symbol Description

the format, the extra digits are retained.

• I f the format contains only number signs (#) to the lef t of the decimal point ,numbers less than one are displayed beginning with a zero.

For example, the format #.00 will display the number 0.43 as 0.43.

,(comma)

Thousands separator.

• I f the format contains commas separated by #'s or 0's, commas separate thethousands. Note that the actual thousands separator used depends on thesession locale.

.(period)

Decimal separator. Note that the actual decimal separator used depends on thesession locale.

The fol lowing table l ists examples of custom numeric formats. It includesthe formatting symbols, the report data, and how that data is displayed afterapplying the formatting to a Big Decimal data type.

Format Cell data Display

#.##250.4360.43

250.440.43

#.0#250.436125

250.44125.0

#,### 1500 1,500

"Sales="0.0 123.45 Sales=123.5

"X="0.0;"x="-0.0 -12.34 x=-12.3

"Cust . No. " 0000 1234 Cust . No. 1234

ALT+0163 #.## 250.45 £ 250.45



MicroStrategy support for binary data types

MicroStrategy maps binary data types from databases to ei ther the Binary orVarbin MicroStrategy data types. For example, some databases are l istedbelow with their various binary data types and their MicroStrategy mapping:

Database Mapped to Binary Data Type Mapped to Varbin Data Type

Oracle Not Applicable Raw

Teradata Byte Varbyte

SQL Server Binary Varbinary

Sybase IQ Binary Varbinary

Sybase ASE Binary Varbinary

MySQL Binary Varbinary

PostgreSQL Bit Bit Varying

To determine how and when to use binary data types in MicroStrategy, thefol lowing MicroStrategy features are supported for binary data types:

MicroStrategy supports the fol lowing features for attributes that have an IDform mapped to a binary data type:

Element l ist qual i fications.

Dri l l ing.

Element browsing.

Page-by.

Sorting.

Exporting, which exports the binary data as a string of characters.



MicroStrategy supports the fol lowing features for any attributes that havenon-ID attribute forms that are mapped to a binary data type:

Inclusion in data marts (SQL Server only)

Attribute form qual i fications, excluding qual i fications that use operators tocompare characters such as Like or Contains.

Supporting barcode data with VarChar

MicroStrategy Mobi le for iPhone lets you scan and enter barcodeinformation to determine the inventory of i tems, as wel l as other types ofanalysis.

Barcodes are commonly a combination of numbers and letters. Therefore,barcode data is best represented as a text value rather than a numericvalue. This barcode data can be used by MicroStrategy Mobi le for iPhoneby creating a MicroStrategy prompt. For information on creating prompts tosupport barcode scanning, see the MicroStrategy Mobi le AdministrationGuide.

To support barcode scanning using MicroStrategy Mobi le for iPhone, youmust store the barcode data used in the associated prompt wi th a databasedata type that supports text data. MicroStrategy recommends using theVarChar data type for your database to store the barcode data. Forinformation on how VarChar data types from databases are mapped toMicroStrategy data types, see Mapping of external data types toMicroStrategy data types, page 537.


