PRJESS 901 Jan11 Color PDF

MICROSTRATEGY A RCHITECT: PROJECT DESIGN ESSENTIALS
Course Guide
Version: PRJESS-901-Jan11-CG
© 2000–2011 MicroStrategy Incorporated. All rights reserved.
This Course (course and course materials) and any Software are provided “as is” and without express or limited
warranty of any kind by either MicroStrategy Incorporated (“MicroStrategy”) or anyone who has been involved in the
creation, production, or distribution of the Course or Software, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the Course
and Software is with you. Should the Course or Software prove defective, you (and not MicroStrategy or anyone else
who has been involved with the creation, production, or distribution of the Course or Software) assume the entire cost
of all necessary servicing, repair, or correction.
In no event will MicroStrategy or any other person involved with the creation, production, or distribution of the Course
or Software be liable to you on account of any claim for damage, including any lost profits, lost savings, or other
special, incidental, consequential, or exemplary damages, including but not limited to any damages assessed against or
paid by you to any third party, arising from the use, inability to use, quality, or performance of such Course and
Software, even if MicroStrategy or any such other person or entity has been advised of the possibility of such damages,
or for the claim by any other party. In addition, MicroStrategy or any other person involved in the creation, production,
or distribution of the Course and Software shall not be liable for any claim by you or any other party for damages
arising from the use, inability to use, quality, or performance of such Course and Software, based upon principles of
contract warranty, negligence, strict liability for the negligence of indemnity or contribution, the failure of any remedy
to achieve its essential purpose, or otherwise.
The Course and the Software are copyrighted and all rights are reserved by MicroStrategy. MicroStrategy reserves the
right to make periodic modifications to the Course or the Software without obligation to notify any person or entity of
such revision. Copying, duplicating, selling, or otherwise distributing any part of the Course or Software without prior
written consent of an authorized representative of MicroStrategy are prohibited.
U.S. Government Restricted Rights. It is acknowledged that the Course and Software were developed at private
expense, that no part is public domain, and that the Course and Software are Commercial Computer Software and/or
Commmercial Computer Software Documentation provided with RESTRICTED RIGHTS under Federal Acquisition
Regulations and agency supplements to them. Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFAR 252.227-7013 et. seq. or subparagraphs (c)(1) and (2) of the Commercial Computer Software—Restricted Rights
at FAR 52.227-19, as applicable. The Contractor is MicroStrategy, 1850 Towers Crescent Plaza, Vienna, Virginia 22182.
Rights are reserved under copyright laws of the United States with respect to unpublished portions of the Software.
Trademark Information
MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition,

MicroStrategy 7i Olap Services, MicroStrategy 8, MicroStrategy 9, MicroStrategy Distribution Services, MicroStrategy
MultiSource Option, MicroStrategy Command Manager, MicroStrategy Enterprise Manager, MicroStrategy Object
Manager, MicroStrategy Reporting Suite, MicroStrategy Power User, MicroStrategy Analyst, MicroStrategy Consumer,
MicroStrategy Email Delivery, MicroStrategy BI Author, MicroStrategy BI Modeler, MicroStrategy Evaluation Edition,
MicroStrategy Administrator, MicroStrategy Agent, MicroStrategy Architect, MicroStrategy BI Developer Kit,
MicroStrategy Broadcast Server, MicroStrategy Broadcaster, MicroStrategy Broadcaster Server, MicroStrategy
Business Intelligence Platform, MicroStrategy Consulting, MicroStrategy CRM Applications, MicroStrategy Customer
Analyzer, MicroStrategy Desktop, MicroStrategy Desktop Analyst, MicroStrategy Desktop Designer, MicroStrategy
eCRM 7, MicroStrategy Education, MicroStrategy eTrainer, MicroStrategy Executive, MicroStrategy Infocenter,
MicroStrategy Intelligence Server, MicroStrategy Intelligence Server Universal Edition, MicroStrategy MDX Adapter,
MicroStrategy Narrowcast Server, MicroStrategy Objects, MicroStrategy OLAP Provider, MicroStrategy SDK,
MicroStrategy Support, MicroStrategy Telecaster, MicroStrategy Transactor, MicroStrategy Web, MicroStrategy Web
Business Analyzer, MicroStrategy World, Application Development and Sophisticated Analysis, Best In Business
Intelligence, Centralized Application Management, Information Like Water, Intelligence Through Every Phone,
Intelligence To Every Decision Maker, Intelligent E-Business, Personalized Intelligence Portal, Query Tone, Rapid
Application Development, MicroStrategy Intelligent Cubes, The Foundation For Intelligent E-Business, The Integrated
Business Intelligence Platform Built For The Enterprise, The Platform For Intelligent E-Business, The Scalable
Business Intelligence Platform Built For The Internet, Industrial-Strength Business Intelligence, Office Intelligence,
MicroStrategy Office, MicroStrategy Report Services, MicroStrategy Web MMT, MicroStrategy Web Services, Pixel
Perfect, Pixel-Perfect, MicroStrategy Mobile, MicroStrategy Integrity Manager and MicroStrategy Data Mining
Services are all registered trademarks or trademarks of MicroStrategy Incorporated.
All other company and product names may be trademarks of the respective companies with which they are associated.
Specifications subject to change without notice. MicroStrategy is not responsible for errors or omissions.
MicroStrategy makes no warranties or commitments concerning the availability of future products or versions that
may be planned or under development.
Patent Information
This product is patented. One or more of the following patents may apply to the product sold herein: U.S. Patent Nos.
6,154,766, 6,173,310, 6,260,050, 6,263,051, 6,269,393, 6,279,033, 6,567,796, 6,587,547, 6,606,596, 6,658,093,
6,658,432, 6,662,195, 6,671,715, 6,691,100, 6,694,316, 6,697,808, 6,704,723, 6,741,980, 6,765,997, 6,768,788,
6,772,137, 6,788,768, 6,798,867, 6,801,910, 6,820,073, 6,829,334, 6,836,537, 6,850,603, 6,859,798, 6,873,693,
6,885,734, 6,940,953, 6,964,012, 6,977,992, 6,996,568, 6,996,569, 7,003,512, 7,010,518, 7,016,480, 7,020,251,
7,039,165, 7,082,422, 7,113,993, 7,181,417, 7,127,403, 7,174,349, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181,
7,272,212, 7,302,639, 7,324,942, 7,330,847, 7,340,040, 7,356,758, 7,356,840, 7,415,438, 7,428,302, 7,430,562,
7,440,898, 7,486,780, 7,509,671, 7,516,181, 7,559,048, 7,574,376, 7,617,201, 7,725,811, 7,801,967, 7,836,178, 7,861,161
and 7,861,253. Other patent applications are pending.
How to Contact Us
MicroStrategy Education Services MicroStrategy Incorporated

1850 Towers Crescent Plaza 1850 Towers Crescent Plaza
Vienna, VA 22182 Vienna, VA 22182
Phone: 877.232.7168 Phone: 703.848.8600
Fax: 703.848.8602 Fax: 703.848.8610
E-mail: education@microstrategy.com E-mail: info@microstrategy.com
http://www.microstrategy.com/education http://www.microstrategy.com
TABLE OF CONTENTS
Preface Course Description.................................................................... 11

Who Should Take This Course .............................................. 12
Course Prerequisites ............................................................. 12
Follow-Up Courses ................................................................ 12
Related Certifications............................................................. 12
Course Objectives ................................................................. 13
About the Course Materials ......................................................... 15
Content Descriptions ............................................................. 15
Learning Objectives ............................................................... 15
Lessons ................................................................................. 16
Opportunities for Practice ...................................................... 16
Typographical Standards ....................................................... 16
MicroStrategy Courses .......................................................... 19
Core Courses......................................................................... 19
1. Introduction to Lesson Description ................................................................... 21

MicroStrategy Lesson Objectives ................................................................. 22
Architect
Overview of MicroStrategy Architect............................................ 23
Populating the Metadata ........................................................ 24
Creating Schema Objects ...................................................... 26
Roles of MicroStrategy Architect ................................................. 28
MicroStrategy Architect and Reporting .................................. 28
MicroStrategy Architect and Drilling....................................... 30
MicroStrategy Architect and Browsing ................................... 32
Overview of the Project Design Process ..................................... 35
Designing the Logical Data Model ......................................... 36
Designing the Data Warehouse Schema............................... 36
© 2011 MicroStrategy, Inc. 5

Table of Contents MicroStrategy Architect: Project Design Essentials
Creating the Project in MicroStrategy Architect ..................... 37

Managing the Project Schema............................................... 38
Course Organization .............................................................. 39
2. Designing the Logical Lesson Description ................................................................... 41

Data Model Lesson Objectives ................................................................. 42
Introduction to Logical Data Modeling ......................................... 43
What Is a Logical Data Model? .............................................. 43
Using the Logical Data Model in MicroStrategy Architect ...... 44
Logical Data Model Components................................................. 47
Facts ...................................................................................... 47
Attributes................................................................................ 48
Hierarchies............................................................................. 55
Structure of a Logical Data Model.......................................... 57
Creating a Logical Data Model .................................................... 58
Factors to Consider ............................................................... 58
Steps to Creating a Logical Data Model ................................ 61
Business Scenario: Creating a Logical Data Model..................... 67
3. Designing the Data Lesson Description ................................................................... 75

Warehouse Schema Lesson Objectives ................................................................. 76
Introduction to Physical Schemas................................................ 77
What Is a Physical Schema? ................................................. 77
Using the Physical Schema in MicroStrategy Architect ......... 78
Physical Schema Components.................................................... 80
Column Types........................................................................ 80
Table Keys ............................................................................. 81
Lookup Tables ....................................................................... 83
Relationship Tables ............................................................... 84
Fact Tables ............................................................................ 87
Schema Types............................................................................. 90
Normalized Versus Denormalized Schemas ......................... 90
Completely Normalized Schema............................................ 92
Moderately Denormalized Schema........................................ 93
Completely Denormalized Schema........................................ 94
Summary of Schema Types................................................... 98
Creating a Data Warehouse Schema .......................................... 99
Factors to Consider ............................................................... 99
Business Scenario: Creating a Data Warehouse Schema ........ 102
6 © 2011 MicroStrategy, Inc.

MicroStrategy Architect: Project Design Essentials Table of Contents
4. Creating a Project in Lesson Description ................................................................. 109

MicroStrategy Lesson Objectives ............................................................... 110
Architect
Overview of Project Creation ..................................................... 111
Configuring the Project Metadata ........................................ 111
Configuring Project Connectivity.......................................... 123
Creating the Schema Objects .............................................. 133
Updating the Project Schema .............................................. 134
Project Creation Interfaces ........................................................ 138
Project Creation Assistant.................................................... 138
Schema Object Editors ........................................................ 142
Architect Graphical Interface................................................ 143
Exercises: Creating a Project in MicroStrategy Architect .......... 144
Creating the Metadata Database ......................................... 144
Creating the DSN for the Metadata...................................... 146
Creating the Metadata Shell ................................................ 147
Creating the Project Source................................................. 148
Creating the Database Instance .......................................... 149
Creating the Project Object.................................................. 151
5. Working with Tables Lesson Description ................................................................. 155

Lesson Objectives ............................................................... 156
What Is a Project Table? ........................................................... 157
Physical Tables Versus Logical Tables ............................... 158
Using the Warehouse Catalog................................................... 160
Adding Tables to a Project................................................... 165
Removing Tables from a Project.......................................... 168
Using the Logical Table Editor................................................... 171
Exercises: Working with Tables................................................. 174
Adding Fact Tables to the Project........................................ 174
Adding Lookup Tables to the Project ................................... 177
6. Working with Facts Lesson Description ................................................................. 183

Lesson Objectives ............................................................... 184
What Is a Fact?.......................................................................... 185
Types of Facts ........................................................................... 188
Homogeneous Facts............................................................ 188
Heterogeneous Facts .......................................................... 189
Types of Fact Expressions................................................... 190
Using the Fact Creation Wizard................................................. 193

Defining Fact Creation Rules ............................................... 196

Creating Facts ..................................................................... 197
Using the Fact Editor ................................................................. 201
Creating Facts ..................................................................... 203
Modifying Facts.................................................................... 209
Exercises: Working with Facts................................................... 216
Creating Facts in the Project................................................ 216
Modifying Facts in the Project.............................................. 219
Adding Another Fact to the Project ...................................... 224
7. Working with Lesson Description ................................................................. 229

Attributes Lesson Objectives ............................................................... 230
What Is an Attribute? ................................................................. 231
What Is an Attribute Form?........................................................ 234
Types of Attributes..................................................................... 237
Compound Attributes ........................................................... 237
Homogeneous Attributes ..................................................... 238
Heterogeneous Attributes .................................................... 239
Types of Attribute Form Expressions................................... 240
Using the Attribute Creation Wizard .......................................... 243
Defining Attribute Creation Rules......................................... 246
Creating Attributes ............................................................... 248
Creating Compound Attributes............................................. 263
Using the Attribute Editor........................................................... 269
Creating Attributes ............................................................... 271
Creating Compound Attributes............................................. 283
Modifying Attributes ............................................................. 287
Creating Attribute Relationships .......................................... 299
Defining Attribute Form Display ........................................... 308
What Is the System Hierarchy? ................................................. 311
Exercises: Working with Attributes ............................................ 313
Creating Attributes in the Project ......................................... 313
Modifying Attributes in the Project ....................................... 328
Adding More Attributes to the Project .................................. 338
8. Working with User Lesson Description ................................................................. 345

Hierarchies Lesson Objectives ............................................................... 346
What Is a User Hierarchy?......................................................... 347
Using the Hierarchy Editor......................................................... 352

MicroStrategy Architect: Project Design Essentials Table of Contents
Creating User Hierarchies.................................................... 354

Defining User Hierarchy Elements....................................... 358
Defining the Sort Order for User Hierarchies ....................... 372
Exercises: Working with User Hierarchies................................. 381
Creating User Hierarchies in the Project.............................. 381
Creating a Report in the Project........................................... 396
9. Introduction to the Lesson Description ................................................................. 403

Architect Graphical Lesson Objectives ............................................................... 404
Interface
Introduction to Architect ............................................................. 405
Accessing the Architect Graphical Interface ........................ 406
Overview of Architect Components ........................................... 408
Warehouse Tables Pane ..................................................... 409
Project Tables View Tab ...................................................... 414
Hierarchy View Tab.............................................................. 420
Properties Pane ................................................................... 423
Project Objects Pane ........................................................... 427
Menu Bar ............................................................................. 429
Toolbar................................................................................. 430
Saving Project Work in Architect ............................................... 433
Undo and Redo Actions in Architect .......................................... 435
Overview of Architect Settings................................................... 437
Configuration Settings ......................................................... 438
Display Settings ................................................................... 440
Automatic Heuristic Settings ................................................ 442
Metric Creation Settings....................................................... 447
................................................................................................... 449
Demonstration of Architect ........................................................ 450
A. MicroStrategy Tutorial Appendix Description.............................................................. 453

The MicroStrategy Tutorial Data Model ..................................... 454
Geography Hierarchy........................................................... 456
Customers Hierarchy ........................................................... 457
Time Hierarchy..................................................................... 458
Products Hierarchy .............................................................. 459
The MicroStrategy Tutorial Schema .......................................... 459
Geography Schema ............................................................. 463
Customers Schema ............................................................. 464
Time Schema....................................................................... 465

Products Schema ................................................................ 466

Fact Tables Schema ............................................................ 467
Partition Mapping Table ....................................................... 467
B. What’s New in Appendix Description.............................................................. 469

MicroStrategy 9.0.2 for
Usability Enhancements in Graphical Architect ......................... 470
Project Architects
Ribbon Toolbars .................................................................. 470
Expand or Collapse All Tables............................................. 470
Auto Arrange Layouts .......................................................... 471
Ability to Set Generic Metric Names Based on the Aggregation
Operator............................................................................... 471
Auto Recognize Form Formats ............................................ 473
Supporting Multi-User Architecting ............................................ 475
Data Access Enhancements...................................................... 477
Using the New MDX Cube Source....................................... 477
Using Freeform XQuery Access to Consume Data from Web
Services ............................................................................... 477
............................................................................................. 478
Index ......................................................................................... 479

PREFACE
Course Description
This 2-day course covers how to design and create a

MicroStrategy project. The course assumes an understanding
of basic report development concepts from the 2-day
MicroStrategy Desktop: Reporting Essentials course.
Students will learn about the role of MicroStrategy

Architect™ in supporting various project functions. Then,
students will learn how to design a logical data model and
physical schema for the data warehouse in preparation for
creating a MicroStrategy project. Students will then learn
about the project creation process, including how to use the
Project Creation Assistant and schema object editors to work
with tables, facts, attributes, and user hierarchies to create a
fully-functioning project. Finally, students will learn about
the Architect graphical interface and how they can use it to
fine-tune projects.

Preface MicroStrategy Architect: Project Design Essentials
Who Should Take This Course

This course is designed for:
• Project architects
Course Prerequisites
Before starting this course, you should know all topics
covered in the following course:
• MicroStrategy Desktop: Reporting Essentials
Follow-Up Courses
After taking this course, you might consider taking the
following courses:
• MicroStrategy Architect: Advanced Project Design
• MicroStrategy Advanced Data Warehousing
Related Certifications
To validate your proficiency in the content of this course, you
might consider taking the following certification:
• Certified Project Designer
12 Who Should Take This Course © 2011 MicroStrategy, Inc.

MicroStrategy Architect: Project Design Essentials Preface
Course Objectives
After completing this course, you will be able to:
• Describe how you use MicroStrategy Architect to populate

the metadata and create schema objects; explain how
MicroStrategy Architect supports reporting, drilling, and
browsing; and describe the project design process. (Page
22)
• Describe the purpose of a logical data model and explain

how you use it in MicroStrategy Architect, describe the
components of a logical data model, and describe the
factors to consider and the steps you must complete to
create a logical data model. (Page 42)
• Describe the purpose of a physical schema and explain

how you use it in MicroStrategy Architect, describe the
components of a physical schema, describe the
characteristics of various types of schema designs, and
describe the factors to consider in creating a data
warehouse schema. (Page 76)
• Explain the tasks involved in creating a project in

MicroStrategy Architect, complete the initial tasks
involved in project creation, and describe the project
creation interfaces available in MicroStrategy Architect.
(Page 110)
• Describe how tables are used in a MicroStrategy project,

select project tables using the Warehouse Catalog, and
view information for project tables using the Logical Table
Editor. (Page 156)
• Describe how facts are used in a MicroStrategy project,

explain the different types of facts and fact expressions,
create and modify basic and complex facts using the Fact
Creation Wizard and Fact Editor. (Page 184)
© 2011 MicroStrategy, Inc. Course Objectives 13

• Describe how attributes and attribute forms are used in a

MicroStrategy project, explain the different types of
attributes and attribute form expressions, create and
modify basic and complex attributes using the Attribute
Creation Wizard and Attribute Editor, and describe how
the system hierarchy is created and used in a
MicroStrategy project. (Page 230)
• Describe how user hierarchies are used in a MicroStrategy

project and create user hierarchies, define user hierarchy
elements, and define the sort order for user hierarchies
using Hierarchy Editor. (Page 346)
• Describe how the Architect graphical interface differs from

the Project Creation Assistant and schema object editors,
access Architect in MicroStrategy Desktop, describe the
components of Architect, save project work in Architect,
perform undo and redo actions in Architect, describe
Architect settings, and describe how you can use Architect
to work on projects. (Page 404)
14 Course Objectives © 2011 MicroStrategy, Inc.

About the Course Materials

This course is organized into lessons and reference
appendices. Each lesson focuses on major concepts and skills
that help you to better understand MicroStrategy products
and use them to implement MicroStrategy projects. The
appendices provide you with supplemental information to
enhance your knowledge of MicroStrategy products.
Content Descriptions
Each major section of this course begins with a Description
heading. The Description introduces you to the content
contained in that section.
Learning Objectives
Learning objectives enable you to focus on the key knowledge
and skills you should obtain by successfully completing this
course. Objectives are provided for you at the following three
levels:
• Course—You will achieve these overall objectives by

successfully completing all the lessons in this course. The
Course Objectives heading in this Preface contains the list
of course objectives.
• Lesson—You will achieve these main objectives by
successfully completing all the topics in the lesson. You
can find the primary lesson objectives directly under the
Lesson Objectives heading at the beginning of each
lesson.
• Main Topic—You will achieve this secondary objective by

successfully completing the main topic. The topic
objective is stated at the beginning of the topic text. You
can find a list of all the topic objectives in each lesson
under the Lesson Objectives heading at the beginning of
each lesson.
© 2011 MicroStrategy, Inc. About the Course Materials 15

Lessons
Each lesson sequentially presents concepts and guides you
with step-by-step procedures. Illustrations, screen examples,
bulleted text, notes, and definition tables help you to achieve
the learning objectives.
Opportunities for Practice

A Workshop is a reinforcement and assessment activity that
follows two or more lessons. Because a Workshop covers
content and applied skills presented in several lessons, it is a
separate section on the level of a lesson.
The following sections within lessons provide you with

opportunities to reinforce important concepts, practice new
product and project skills, and monitor your own progress in
achieving the lesson and course objectives:
• Review
• Case Study
• Business Scenario
• Exercises
Typographical Standards
Following are explanations of the font style changes, icons,
and different types of notes that you see in this course.
Actions
References to screen elements and keys that are the focus of

actions are in bold Arial font style. The following example
shows this style:
Click Select Warehouse.
16 About the Course Materials © 2011 MicroStrategy, Inc.

Code
References to code, formulas, or calculations within

paragraphs are formatted in regular Courier.New font style.
The following example shows this style:
Sum(Sales)/Number of Months
Data Entry
References to literal data you must type in an exercise or

procedure are in bold Arial font style. References to data you
type that could vary from user to user or system to system are
in bold italic Arial font style. The following example shows
this style:
Type copy c:\filename d:\foldername\filename.
Keyboard Keys
References to a keyboard key or shortcut keys are in

uppercase letters in bold Arial font style. The following
example shows this style:
Press CTRL+B.
New Terms
New terms to note are in regular italic font style. These terms
are defined when they are first encountered in the course.
The following example shows this style:
The aggregation level is the level of calculation for the

metric.

Notes and Warnings
A note icon indicates helpful information.

Ainformation
warning icon calls your attention to very important
that you should read before continuing
the course.
Heading Icons
The following heading icons are used to indicate specific

practice and review sections:
— Precedes a Review section
— Precedes a Case Study
— Precedes a Business Scenario
— Precedes Exercises

MicroStrategy Courses
Core Courses
• Implementing MicroStrategy: Development and
Deployment
• MicroStrategy Architect: Project Design Essentials
• MicroStrategy Desktop: Advanced Reporting
• MicroStrategy Desktop: Reporting Essentials
• MicroStrategy Report Services: Document Essentials
• MicroStrategy Report Services: Dynamic Dashboards
• MicroStrategy Web for Professionals
• MicroStrategy Web for Reporters and Analysts
*All courses are subject to change. Please visit the MicroStrategy Web site for the
latest education offerings.


1
INTRODUCTION TO
MICROSTRATEGY ARCHITECT
Lesson Description
This lesson introduces you to MicroStrategy Architect, which

enables you to create MicroStrategy projects.
In this lesson, you will learn how you use MicroStrategy

Architect to populate the metadata and create schema
objects, which form the foundation of a project. Then, you
will learn how MicroStrategy Architect supports reporting,
browsing, and drilling. Finally, you will learn about the steps
involved in the project design process.

1 Introduction to MicroStrategy Architect MicroStrategy Architect: Project Design Essentials
Lesson Objectives
After completing this lesson, you will be able to:

Describe how you use MicroStrategy Architect to populate
the metadata and create schema objects; explain how
MicroStrategy Architect supports reporting, drilling, and
browsing; and describe the project design process.
After completing the topics in this lesson, you will be able to:
• Describe how you use MicroStrategy Architect to populate

the metadata and create various types of schema objects.
(Page 23)
• Explain how MicroStrategy Architect supports reporting,

drilling, and browsing. (Page 28)
• Describe the steps involved in the project design process.

(Page 35)
22 Lesson Objectives © 2011 MicroStrategy, Inc.

MicroStrategy Architect: Project Design Essentials Introduction to MicroStrategy Architect 1
Overview of MicroStrategy Architect
After completing this topic, you will be able to:

Describe how you use MicroStrategy Architect to populate
the metadata and create various types of schema objects.
In the MicroStrategy Desktop: Reporting Essentials course,

you learned how to create reports and other application
objects within a MicroStrategy project. However, all of those
reporting functions are dependent on having a properly
architected project. In this course, you will learn how to
design and create MicroStrategy projects.
MicroStrategy Architect provides a set of tools that you can

use to create new projects and modify the structure of
existing projects. You access MicroStrategy Architect
functions from the MicroStrategy Desktop™ interface.
MicroStrategy Architect enables you to perform the following

tasks:
• Initially populate the metadata
• Create schema objects
© 2011 MicroStrategy, Inc. Overview of MicroStrategy Architect 23

Populating the Metadata

you learned about the MicroStrategy business intelligence
architecture:
MicroStrategy Business Intelligence Architecture
A central part of this architecture is the metadata database.

The metadata is the repository that stores all of your project
information.
MicroStrategy applications use the metadata to translate user

requests into SQL queries and then translate the results of
those queries back into MicroStrategy objects like reports and
documents.
24 Overview of MicroStrategy Architect © 2011 MicroStrategy, Inc.

The following illustration shows the role of the metadata in

generating report and document results:
Role of the Metadata
As you can see, generating the correct SQL for a report or

document requires information about how objects in the
report or document relate to data warehouse content.
Any time you create, modify, or remove any type of project

object, those changes are stored in the metadata. However, in
creating a new project, you use MicroStrategy Architect to
initially populate the project metadata with the following
information:
• Project definitions and parameters
• Schema objects
This information becomes the foundation for all of the other

types of objects you create in the project that are stored in the
metadata.

Creating Schema Objects

The MicroStrategy metadata contains all the information
needed for a MicroStrategy project to function, including
data warehouse connection information, project settings, and
MicroStrategy object definitions. However, the most
fundamental objects stored in the metadata are schema
objects. Schema objects are logical objects that relate
application objects to data warehouse content. They are the
bridge between your reporting environment and your data
warehouse. As such, you have to create the basic schema
objects a project requires before you can complete any other
tasks, such as creating templates, filters, reports, or
documents.
Creating schema objects is the primary task you perform in

MicroStrategy Architect. The following basic schema objects
form the foundation of a MicroStrategy project:
• Tables—Logical objects that correspond to physical tables

stored in the data warehouse that you want to use in a
MicroStrategy project
• Facts—Logical objects that relate aggregatable data stored

in the data warehouse to the MicroStrategy reporting
environment. They are usually numeric, and you can
aggregate them to different levels, depending on your
reporting needs.
• Attributes—Logical objects that relate descriptive

(non-fact) data stored in the data warehouse to the
MicroStrategy reporting environment. They provide
context for reporting on facts and define the level of detail
at which you want to analyze facts.
• Hierarchies—Logical objects that enable you to group

attributes to reflect their relationships or provide
convenient browsing and drilling paths in the
MicroStrategy reporting environment.
26 Overview of MicroStrategy Architect © 2011 MicroStrategy, Inc.

The following illustration shows an example of each of these

types of schema objects:
Basic Schema Objects
Although you can create other types of schema objects in

MicroStrategy Architect that you use for more advanced
functions, these basic schema objects are essential to any
MicroStrategy project.
In addition to creating new schema objects, MicroStrategy

Architect also enables you to manage existing schema objects,
so you can modify or remove objects as necessary.

Roles of MicroStrategy Architect

Explain how MicroStrategy Architect supports reporting,
drilling, and browsing.
The basic schema objects that you create in MicroStrategy

Architect form the foundation of a MicroStrategy project.
Specifically, MicroStrategy Architect plays an important roles
in supporting the following project functions:
• Reporting
• Drilling
• Browsing
MicroStrategy Architect and Reporting

you learned how to use attributes and metrics to build
templates and filters, which are the essential components of
reports. Attributes and metrics are two of the objects you
most frequently use in designing reports. Attributes are
schema objects, while metrics consist of facts, which are also
schema objects. As such, report content largely depends on
schema objects. Therefore, MicroStrategy Architect is critical
to being able to build the reports you need.
28 Roles of MicroStrategy Architect © 2011 MicroStrategy, Inc.

For example, consider the schema objects used in the

following report:
Schema Objects Used in a Report
This report contains the Year and Region attributes and the
Revenue and Profit metrics in its template. The attributes
determine the level of detail for the metrics. The metrics
consist of two facts, Sales and Cost, that are aggregated to
produce the metric values displayed in the report.
The filter uses the Year attribute and the Revenue metric to
limit the result set to those regions that sold more than
$1,000,000 in 2007 or 2008.
You have to create the attributes and facts used in this report
before you can build the report itself. How you define these
schema objects directly affects the report result set.
© 2011 MicroStrategy, Inc. Roles of MicroStrategy Architect 29

MicroStrategy Architect and Drilling

you learned how to drill on reports to view different levels of
detail. The basic drilling options available for any given
report directly relate to how you define the following items in
MicroStrategy Architect:
• Relationships between attributes
• Hierarchies and their drilling configuration
For example, consider the options available for drilling on the

Subcategory attribute in a report. The following image shows
the drill option for viewing the report data at a higher level of
detail:
Drilling Up on the Subcategory Attribute
You can drill up from the Subcategory attribute to the

Category attribute. This drill path exists because you define a
relationship between Category and Subcategory in
MicroStrategy Architect. In this example, Category is a parent
of Subcategory, which is why it displays on the Up menu.

The following image shows the drill option for viewing the
report data at a lower level of detail:
Drilling Down on the Subcategory Attribute
You can drill down from the Subcategory attribute to the Item
attribute. This drill path exists because you define a
relationship between Item and Subcategory in MicroStrategy
Architect. In this example, Item is a child of Subcategory,
which is why it displays on the Down menu.

The following image shows the drill option for viewing the
report data at various levels of detail, including other
hierarchies:
Drilling Across on the Subcategory Attribute
You can drill across from the Subcategory attribute to

attributes in other hierarchies. These drill paths exist because
you define these hierarchies in MicroStrategy Architect and
make them available for drilling.
As you can see, basic drilling functions are directly dependent

on how you define various schema objects in MicroStrategy
Architect.
MicroStrategy Architect and Browsing

you learned how to use hierarchies to browse attributes and
their respective elements. You use MicroStrategy Architect to
create and define these hierarchies, which determine the
various paths for browsing attributes.

The following image shows the two types of hierarchies that

you create in MicroStrategy Architect:
Types of Hierarchies
The system hierarchy contains all project attributes, and its

available browse paths are determined by how you define
attributes and their relationships. User hierarchies enable
you to create your own custom groupings of attributes and
define their associated browse paths.
You will learn more about the differences between

system and user hierarchies later in this course. For
more information on the system hierarchy, see “What
Is the System Hierarchy?” starting on page 311. For
more information on user hierarchies, see “What Is a
User Hierarchy?” starting on page 347.
You typically use user hierarchies for browsing attributes.

However, whichever type of hierarchy you choose to browse,
the attributes and browse paths available in that hierarchy
are dependent on how you define the underlying schema
objects in MicroStrategy Architect.

For example, in the image on the previous page, the Time

user hierarchy displays the Day, Month, Month of Year,
Quarter, and Year attributes because those are the attributes
included in the hierarchy. You can browse directly from the
Year attribute to the Quarter or Month attributes because
those browse paths are included in the hierarchy.

Overview of the Project Design Process

Describe the steps involved in the project design process.
Now that you have learned about MicroStrategy Architect

and the important roles it has in a MicroStrategy project, you
are ready to learn about the project design process.
Project design involves more than just creating a project in

MicroStrategy Architect. Understanding how users want to
report on information in the data warehouse, how data in the
warehouse is related, and how that data is stored are all
fundamental parts of the project design process.
The following illustration shows the primary steps involved

in the project design process:
Project Design Process
In this course, you will learn about each part of the project
design process. The following topics describe each of these
steps in more detail.
© 2011 MicroStrategy, Inc. Overview of the Project Design Process 35

Designing the Logical Data Model

Designing the logical data model is the first step in the project
design process. As part of this step, you need to complete the
following tasks:
• Determine the information users want to see in reports
• Determine what information is available to include in

reports
• Design a logical data model that incorporates the

information users want to see and shows how it is related
For information on logical data models, see the

“Designing the Logical Data Model” lesson starting on
page 41.
Designing the Data Warehouse Schema

Designing the data warehouse schema is the second step in
the project design process. As part of this step, you need to
complete the following tasks:
• Consider the advantages and disadvantages of various

structures for storing data in the data warehouse
• Determine the optimal schema design that balances the

reporting requirements, performance requirements, and
maintenance overhead
• Create the data warehouse using this schema design or

modify the existing data warehouse to use this schema
design
For information on schema designs, see the

“Designing the Data Warehouse Schema” lesson
starting on page 75.
36 Overview of the Project Design Process © 2011 MicroStrategy, Inc.

Creating the Project in MicroStrategy Architect

You need to have a solid design for the logical data model and
data warehouse schema before you move on to creating the
actual project. Both of these components can directly affect
how you query data in a project, what data you can query,
how fast queries run, and so forth.
Creating a project without first having a logical data

model in place can complicate the task of project
creation since you are essentially defining your logical
data model in MicroStrategy Architect.
Creating a project without first having an effective

data warehouse schema design in place can result in
more modifications to schema objects later on as you
change the physical structure of the schema to
accommodate your reporting needs.
After these steps are complete, you are ready to create a

project in MicroStrategy Architect, which is the third step in
the project design process. As part of this step, you need to
complete the following tasks:
• Configure the project metadata if necessary
• Configure connectivity to the project metadata and data

warehouse if necessary
• Create the project object in MicroStrategy Architect
• Create the necessary schema objects for the project based

on the logical data model, mapping them to appropriate
structures in the data warehouse schema
For information on creating a project in MicroStrategy

Architect, see the “Creating a Project in MicroStrategy
Architect” lesson starting on page 109.

Managing the Project Schema

Managing the project schema is the final and ongoing step in
the project design process. Over the life of the project, your
logical data model or data warehouse may change, or your
reporting needs may change, which can necessitate changes
to schema objects. Ongoing management of the project
schema involves tasks such as the following:
• Creating new schema objects as necessary
• Modifying the definitions of existing schema objects as

necessary
• Removing schema objects you no longer need in the

project
• Updating the project schema to reflect any changes you

make to schema objects
• Creating advanced schema objects for more complex

functions
For information on creating advanced schema objects

in MicroStrategy Architect, see the MicroStrategy
Architect: Advanced Project Design course.

Course Organization
The remainder of the MicroStrategy Architect: Project Design
Essentials course is organized around the steps in the project
design process. The following illustration shows how each
lesson relates to the project design process:
Course Organization and the Project Design Process

Lesson Summary
• MicroStrategy Architect enables you to create new
projects or modify the structure of existing projects.
• When you create a new project, you use MicroStrategy

Architect to initially populate the project metadata with
project definitions and parameters and schema objects.
• Schema objects are logical objects that relate application

objects to data warehouse content.
• You have to create the basic schema objects a project

requires before you can complete any other tasks, such as
creating templates, filters, reports, or documents.
• The following basic schema objects form the foundation of

a MicroStrategy project: tables, facts, attributes, and
hierarchies.
• The content of reports is largely dependent on the schema

objects you create in MicroStrategy Architect.
• The basic drilling functions are directly dependent on how

you define attribute relationships and hierarchies in
MicroStrategy Architect.
• The attributes and browse paths available in the system

and user hierarchies are dependent on how you define the
underlying schema objects in MicroStrategy Architect.
• The project design process involves the following steps:

designing the logical data model, designing the data
warehouse schema, creating the project in MicroStrategy
Architect, and managing the project schema.

2
DESIGNING THE LOGICAL
DATA MODEL
Lesson Description
This lesson describes how to design the logical data model for
a MicroStrategy project.
In this lesson, you will learn about logical data models and
how they are used in MicroStrategy Architect. Then, you will
learn about the different components of a logical data model.
Finally, you will learn how to create a logical data model,
including factors you need to consider and the steps for
completing this task.

2 Designing the Logical Data Model MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe the purpose of a logical data model and explain how
you use it in MicroStrategy Architect, describe the
components of a logical data model, and describe the factors
to consider and the steps you must complete to create a
logical data model.
• Describe the purpose of a logical data model and explain

how you use it when creating a project in MicroStrategy
Architect. (Page 43)
• Describe the components of a logical data model.

(Page 47)
• Describe the factors to consider when designing a logical

data model and the steps you must complete to create a
logical data model. (Page 58)

MicroStrategy Architect: Project Design Essentials Designing the Logical Data Model 2
Introduction to Logical Data Modeling

Describe the purpose of a logical data model and explain how
you use it when creating a project in MicroStrategy Architect.
The first step in the project design process is to design the

logical data model. Before you learn how to design a logical
data model, you need to understand the basic concept of a
logical data model, how you use it in MicroStrategy Architect,
and its various components.
What Is a Logical Data Model?

A logical data model is a diagram that shows the information
you want to analyze in a project and how that information is
related. It typically depicts the flow of data in an
organization, and it should make sense to even the most basic
of end users. It does not show the physical structure of how
the information is stored in the data warehouse.
The logical data model should include any information users

want to see on reports that you can obtain from relevant
source data. Logical data models can be simple or complex,
depending on the nature of your reporting requirements and
the structure of available source data.
Logical data modeling is similar to multidimensional

data modeling. However, MicroStrategy Architect does
not require you to explicitly define dimensions, so this
course uses the term “logical data modeling.”
© 2011 MicroStrategy, Inc. Introduction to Logical Data Modeling 43

The following illustration shows a simple logical data model:

Logical Data Model
This logical data model shows the relationships within

customer, time, geography, and product data and how these
types of data are related to each other through a series of
facts.
For information on the various components of a

logical data model, see “Logical Data Model
Components” starting on page 47.
Using the Logical Data Model in MicroStrategy Architect

When you create a project in MicroStrategy Architect, you
define your logical data model within the tool. You create
schema objects that map the information in your logical data
model to physical tables and columns in the data warehouse.
You also explicitly define the relationships in the logical data
model. The role of MicroStrategy Architect is to translate the
logical representation of the data into something users can
query in reports.
44 Introduction to Logical Data Modeling © 2011 MicroStrategy, Inc.

When users run reports, the MicroStrategy Engine has to

generate the appropriate SQL to retrieve the necessary data
from the data warehouse. MicroStrategy Architect enables
you to align your logical data model with the underlying data
warehouse structure. The schema objects you create serve as
the link between the logical and physical structures of the
data. You can then use these schema objects to create
application objects such as metrics, filters, templates,
reports, and documents.
For example, the logical data model referenced earlier in this

lesson includes the Quarter and Month attributes and a
Revenue fact:
Quarter and Month Attributes and Revenue Fact
© 2011 MicroStrategy, Inc. Introduction to Logical Data Modeling 45

The following illustration shows how schema objects that

map to these attributes and fact relate the objects on a report
to data in the data warehouse:
Relating a Report to the Data Warehouse
The Quarter and Month attributes and the Revenue fact

relate the logical objects from the data model to the
appropriate physical tables and columns in the data
warehouse. You can then build a MicroStrategy report using
these objects that displays revenue by quarter and month.
You can use the Quarter and Month attributes directly on the
report. You can create a Revenue metric based on the
Revenue fact and use this metric on the report. When users
run the report, the MicroStrategy Engine generates SQL to
obtain the result set based on how you defined the underlying
schema objects.
46 Introduction to Logical Data Modeling © 2011 MicroStrategy, Inc.

Logical Data Model Components

Describe the components of a logical data model.
A logical data model includes the following three

components:
• Facts
• Attributes
• Hierarchies
The following topics describe each of these components in

detail.
Facts
Facts are measures that you use to analyze your business.
Fact data is typically numeric, and it is generally
aggregatable. Revenue, unit sales, inventory, and account
balance are just a few examples of facts that you may use in
your business.
In the data warehouse, facts exist as columns in fact tables.

They can come from different source systems, and they may
be stored at different levels of detail. For example, you may
capture revenue data in one system and inventory data in
another system. You may also track revenue data by quarter
in one table and by day in another table.
© 2011 MicroStrategy, Inc. Logical Data Model Components 47

Facts are critical to much of the analysis that users perform

on your business data. In MicroStrategy projects, they map to
fact schema objects, which form the basis for all the metrics
you use in reports. The other components of a logical data
model provide context for the facts.
Iftheyounumeric
are familiar with SQL, facts generally represent
columns in tables on which you perform
SQL aggregations like SUM, AVG, and so forth. For
example, in the following SQL statement, the
ORDER_AMT column is a fact:
SELECT a22.EMP_ID, sum(a21.ORDER_AMT)

FROM ORDER_FACT a21
JOIN LU_EMPLOYEE a22
ON (a21.EMP_ID = a22.EMP_ID)
WHERE a22.CALL_CTR_ID in (5, 9, 12)
Attributes
Attributes are descriptive data that provide context for
analyzing facts. They enable you to answer questions about
facts and report on various aspects. Without this context,
facts are meaningless.
For example, if you want to analyze your company’s sales, it is

not enough to simply know that the total sales are $500,000.
To make that number meaningful, you need to understand
more about how you achieved that sales total, such as the
following:
• Over what timeframe did these sales occur?
• What products were sold?
• Which customers purchased these products?
• What employees were responsible for making these sales?
• Which region had the best and worst sales?
The answers to all these questions involve attributes that

provide specific details about the nature of your sales. Month,
year, item, customer, employee, and region are just a few
examples of attributes you may use in your business.
48 Logical Data Model Components © 2011 MicroStrategy, Inc.

In the data warehouse, attributes exist as columns in lookup,

relationship, and fact tables. They can come from different
source systems, and you can use them to analyze facts at
various levels of detail.
Attributes provide levels for aggregating and qualifying fact

data. As such, they provide the parameters for much of the
analysis that users perform on facts. In MicroStrategy
projects, they map to attribute schema objects, which
describe the metrics on reports.
For example, consider the following report:

Using Attributes for Aggregation and Qualification
The presence of the Year and Region attributes on the

template means that the Profit metric is aggregated by year
and region. The use of the Year attribute in the filter qualifies
the result set, so it includes only data for years later than
2007.

Ifrepresent
you are familiar with SQL, attributes generally
the non-aggregatable columns in tables that
you use to qualify and group fact data. For example, in
the following SQL statement, the MONTH_ID column
is an attribute:
SELECT a11.MONTH_ID,
sum(a11.TOT_DOLLAR_SALES)
FROM MNTH_CATEGORY_SLS a11
JOIN LU_MONTH a12
ON (a11.MONTH_ID = a12.MONTH_ID)
WHERE a11.MONTH_ID in (200801, 200802,
200803)
GROUP BY a11.MONTH_ID
Attributes and Attribute Forms
Attributes in the logical data modeling context differ from

what are commonly defined as attributes in entity
relationship diagrams (ERDs) or source systems.
For example, consider the following table in an ERD:

ERD Table
From an ERD perspective, Employee is considered an entity,

and all the columns in the table that describe employees are
attributes.

However, in logical data modeling, attributes are not simply

table columns. They are logical categories that provide
context for facts. In this table, the following items could be
candidates for attributes:
• Employee
• Hire Date
• Birth Date
Each of these items represent distinct categories of data that

you may want to use to aggregate facts.
For the Employee attribute, the table contains three types of

descriptive information:
• IDs
• Names
• Social Security Numbers (SSNs)
Each employee in the table has only one ID, name, and SSN,
so these columns are considered attribute forms of the
Employee attribute.
Employees could have multiple hire dates if they were

hired more than once. For both hire dates and birth
dates, more than one employee could have the same
hire date and birth date, so you may want to aggregate
facts using this data. For these reasons, you would
probably want to consider these columns attributes.
Attribute forms are not explicitly included in logical data

models. However, understanding how columns correspond to
attributes versus attribute forms helps you identify which
columns you need to include in a logical data model as
attributes.
Attribute forms are a MicroStrategy-specific concept.

For more information on attribute forms, see “What Is
an Attribute Form?” starting on page 234.

Attribute Elements
Attribute elements are the unique values of an attribute. For

example, the elements of the Year attribute could include
2006, 2007, and 2008, while the elements of the Customer
City attribute could include New York, Denver, and San
Francisco.
In MicroStrategy projects, attribute elements are the data

that display on a report under the attribute headers. You can
also use attribute elements for very precise qualifications on
fact data.
For example, consider the following report:

Using Attribute Elements for Display and Qualification
The years and regions that display under the Year and Region
attribute headers are the elements for these attributes. The
use of the Northwest, Southwest, and Central elements of the
Region attribute in the filter qualifies the result set, so it
includes only data for those regions.
Attribute elements are not explicitly included in logical data

models. However, understanding attribute elements helps
you determine the relationships that exist between attributes.

Attribute Relationships
Attribute relationships are essential to the structure of a

logical data model as they are the key to joining data from
different attributes and aggregating fact data to different
levels. Attribute relationships describe logical associations
between attributes that exist based on business rules.
Attributes are related to each other in one of the following

ways:
• Direct—A parent-child relationship exists between two or

more attributes. In the data warehouse, direct
relationships are explicitly defined using lookup tables or
distinct relationship tables.
• Indirect—Two or more attributes are related only through

a fact or set of facts. In the data warehouse, indirect
relationships are stored only in fact tables.
For example, Month and Date are attributes that have a

direct relationship. Each month is directly related to specific
dates. However, Customer and Date are attributes that have
an indirect relationship. Without facts, these attributes are
not inherently related. However, if customers make
purchases on specific dates, you can relate these two
attributes through the facts that capture those sales.
In a logical data model, determining the direct relationships

that exist between attributes helps you identify logical
groupings of attributes. Every direct relationship between
attributes has two parts—a parent and a child. A child
attribute always has at least one parent, and a parent
attribute can have multiple child attributes. The parent
attribute is at a higher level than the child. For example, in a
relationship between Month and Date, Month is the parent
attribute, and Date is the child attribute.

You determine the type of relationship that exists between

directly related attributes by looking at the elements of each
attribute. Directly related attributes have one of the following
types of relationships:
• One-to-one—Each element of the parent attribute

corresponds to only one element for the child attribute,
and each element of the child attribute corresponds to
only one element for the parent attribute. The
relationship between Citizen and Taxpayer ID attributes
is an example of a one-to-one relationship. A citizen can
have only one taxpayer ID, and a taxpayer ID is associated
to only one citizen.
• One-to-many—Each element of the parent attribute can

correspond to one or more elements for the child
attribute, but each element of the child attribute
corresponds to only one element for the parent attribute.
This relationship is the most common type that occurs
between attributes. The relationship between Month and
Date attributes is an example of a one-to-many
relationship. One month contains many dates, but each
date can occur only in one month.
• Many-to-many—Each element of the parent attribute can

correspond to one or more elements for the child
attribute, and each element of the child attribute can
correspond to one or more elements for the parent
attribute. The relationship between Customer and
Account attributes is an example of a many-to-many
relationship. One customer can have many accounts, and
each account can be associated with multiple customers
(for example, a joint checking account).

The following illustration shows examples of the three

relation types and how they are represented in a logical data
model:
Attribute Relationships
In MicroStrategy projects, you explicitly define any direct

relationships between attributes. These relationships enable
you to browse attribute data and drill on attributes in reports.
After you have defined the attributes and their relationships,

you are ready to define hierarchies, a way of grouping related
attributes.
Hierarchies
Hierarchies are groupings of directly related attributes
ordered to reflect their relationships. In a logical data model,
hierarchies are also sometimes referred to as dimensions.
You generally organize attributes into hierarchies based on
logical business areas.
For example, you can group attributes such as Year, Quarter,

Month, and Date to form a Time hierarchy, or you can group
attributes such as Category, Subcategory, and Item to form a
Products hierarchy.
Hierarchies contain only attributes that are directly related

to each other. Attributes in one hierarchy are indirectly
related to attributes in other hierarchies.

For example, Month and Date are attributes that are usually
directly related to each other. You do not need any additional
information to establish the relationship between these two
attributes.
Month and Customer are attributes that are usually indirectly

related to each other. Therefore, they would generally not be
part of the same hierarchy. You have to know some sort of
additional information to establish a relationship between
these attributes. They are related through the existence of one
or more facts, such as when a customer purchased an item or
a customer’s average account balance for a particular month.
Hierarchies do not explicitly exist in the data warehouse, but

they often parallel the logical dimensions you use to describe
and organize your business data.
In MicroStrategy projects, the composite of all the hierarchies

you include in the logical data model forms the system
hierarchy. User hierarchies may or may not follow the
structure of individual hierarchies from the logical data
model.
For more information on the system hierarchy, see

“What Is the System Hierarchy?” starting on page 311.
For more information on user hierarchies, see “What
Is a User Hierarchy?” starting on page 347.

Structure of a Logical Data Model

When you put all these components together—facts,
attributes and their relationships, and hierarchies—you have
a logical data model. The following illustration shows how
each component is represented within a logical data model:
Structure of a Logical Data Model
Attributes are grouped by hierarchies. Within each hierarchy,

the direct relationships between attributes are shown. Facts
are grouped based on the hierarchies to which they are
related.
Inthethis logical data model, all the facts are related to all
hierarchies, so you need only one grouping of facts.

Creating a Logical Data Model

Describe the factors to consider when designing a logical data
model and the steps you must complete to create a logical
data model.
Now that you are familiar with the components of a logical

data model, you are ready to learn how to create a logical data
model.
Factors to Consider
Before you begin to organize your business data into a logical
data model, you need to consider the following factors that
influence the design of the logical data model:
• User reporting requirements
• Existing source data
• Technical and performance considerations
The following topics describe each of these factors in detail.
User Reporting Requirements
Your logical data model should take into account the

reporting requirements of end users. It should include all
information needed for reports. You do not need to include
any information you capture in source systems that is not
needed for reports.
Your user community may be very diverse from executives

who are interested in analyzing overall trends for the
company to local managers who need to track sales for their
particular area of responsibility. You need to consider all the
potential users and how to accommodate their varied
requirements.
58 Creating a Logical Data Model © 2011 MicroStrategy, Inc.

Developing a logical data model that meets the needs of users

involves the following tasks:
• Communicating with users to determine the types of

questions they need to ask and what they need to analyze
• Working with users to document their reporting

requirements
• Evaluating whether you can readily support these

reporting requirements given the existing source data and
other environmental characteristics
• Incorporating user reporting requirements into the logical

data model design
Ensuring that the logical data model adequately addresses

user reporting requirements is often an iterative process.
Over time, as requirements change, the logical data model
may change as well. You may need to add new facts,
attributes, or hierarchies or remove some components that
are no longer needed or cannot be practically supported. You
often create multiple “draft” versions of a logical data model
before you complete the final design.
You should create your logical data model with the end users
firmly in mind. Its design should enable maximum flexibility,
while making analysis as simple and efficient as possible for
users.
Existing Source Data
Your logical data model should take into account what source
data is available for you to use. You need to ensure that you
have sufficient source data to support user reporting
requirements and address any gaps that exist.
An initial review of your source systems may reveal that you

have the necessary source data to support all the user
reporting requirements. However, sometimes the original
source data is not sufficient to answer specific reporting
requirements. In such cases, you may be able to use the
original source data to derive additional data that satisfies
those requirements.
© 2011 MicroStrategy, Inc. Creating a Logical Data Model 59

For example, your company may record sales transactions by

customer and city, but your users also want to analyze sales
by state or region. State and region data are not part of the
source data, but you can extract this information based on the
cities in which sales occur. Although this data does not exist
in the source system, you can readily infer it, so you can
include Region and State attributes in the logical data model.
At other times, the absence of data in source systems may

render it impossible to support certain user reporting
requirements.
For example, your company may record inventory levels by

week, but your users want to know the inventory for items on
a particular date. You cannot support this requirement at the
database level using the original source data since inventory
is available only at the week level or above. Furthermore, you
cannot determine the inventory for an item for a particular
date based on its inventory for the pertinent week. That level
of detail is not possible to achieve unless you change how you
capture inventory data.
Sometimes, there are application-level workarounds

within MicroStrategy for missing source data that you
cannot extrapolate at the database level. For more
information refer to Fact Level Extensions in
MicroStrategy Desktop: Advanced Project Design
course.
Finally, your source data may include information that is not

needed to satisfy user reporting requirements. Just because
the information exists in the source data, you do not have to
include it in the logical data model. Only information needed
for reports should be part of the logical data model.
Technical and Performance Considerations
A number of technical and performance factors can affect

how you design the logical data model, particularly with
regard to its size and complexity. The more information you
want to include in the logical data model and the more
complex analysis you want to support with the logical data
model, the greater demand there is on your business
intelligence system.

Technical issues such as the robustness of the database server

and software can affect the volume or types of queries you can
support in the reporting environment. Other factors such as
network bandwidth or the volume of concurrent users can
influence speed and system demand.
You also have to evaluate what level of performance you can

deliver with the technical resources at your disposal. Complex
user reporting requirements or source data structures pose
greater challenges to delivering optimal performance.
Large projects may contain thousands of attributes, each with

the potential to have hundreds, thousands, or even millions
of elements. It is important to consider any technical or
performance limitations posed by the hardware and database
software you are using. These limitations may require you to
scale back the size or complexity of the logical data model or
sacrifice some user reporting requirements.
Steps to Creating a Logical Data Model

Most of the time, an evaluation of your source data and user
reporting requirements is the starting point for creating a
logical data model. After you create the logical data model,
you then move on to designing the data warehouse schema.
However, although it is certainly best practice to create your

logical data model before implementing your data
warehouse, companies sometimes begin building the data
warehouse without a logical data model in place. Even in
these situations, taking the time to create a logical data model
before you begin creating your MicroStrategy project is
important. Doing so provides the following benefits:
• Facilitates the project creation process in MicroStrategy

Architect so you know exactly which schema objects you
need and their respective relationships
• Helps identify potential problems with the structure or

content of the data warehouse schema at a time when you
can more easily remedy them

You can create any number of logical data models from the
same source data. Your user reporting requirements and the
characteristics of your reporting environment largely affect
the choices you make about what content to include and the
best logical structure for it.
Creating a logical data model involves the following steps:
1 List all the information from the source data you need to
include in the logical data model based on the user
reporting requirements.
2 Identify which items are facts.
3 Identify which items are attributes.
4 Determine the direct relationships between attributes.
5 Organize directly related attributes into hierarchies.
Asdatamentioned earlier, before you create the logical

model, you need to identify your user reporting
requirements and review the available source data to
ensure you can support those requirements.
Understanding the physical structure of the source data helps

you complete these steps. The physical structure of source
data is often represented by an ERD or some other type of
schema diagram that enables you to easily recognize tables,
columns, and the data they store.
The following topics describe each of these steps in more

detail.
List Information from the Source Data
The easiest way to ensure that you do not miss any content
you need to include in the logical data model is to just list all
the information you need without determining what type of
component it will be in the logical data model.
For example, you may have the following user requirement:
• Users want to analyze sales and cost for items in various

product categories by week and region.

From this brief summary, you can conclude the following

information is necessary to meet this requirement:
• Sales
• Cost
• Item
• Category
• Week
• Region
More in-depth analysis of the requirement or discussions

with users may uncover more information that is desired,
such as Month, Store, Department, and so forth. However,
the written requirement alone provides key details as to the
source data you need to include at a minimum.
Creating a master list of the content you need to include

based on user reporting requirements prepares you for the
next steps where you map this information to the appropriate
logical data model components.
Identify Facts
After you have created a list of all the information you need
from the source data, you need to review the list and identify
which items are facts. To help you determine which items are
facts, remember that facts are usually values that are numeric
and aggregatable.
After you have identified the facts, you need to review the
structure of the source data to determine the level at which
each fact is recorded.

For example, consider the following tables:

Determining Fact Levels
The Sales table records data for the Dollar Sales and Unit
Sales facts by Item, Customer, Date, and Store. These four
attributes comprise the level of the two facts.
The Profit table records data for the Profit fact by Item, Week,
and Region. These three attribute comprise the level of the
fact.
The fact level identifies which attributes are related to a fact

or set of facts. As you continue to develop the logical data
model, knowing the fact levels helps you group facts based on
the hierarchies and attribute levels to which they are related.
Itattribute
is possible for the same fact to be stored at different
levels within a hierarchy.

Identify Attributes
After you have identified which items from the list are facts,
you need to review the remaining items and identify which
ones are attributes. To help you determine which items are
attributes, remember that attributes describe fact data, and
they provide levels for aggregating or qualifying fact data.
Keep in mind the distinction between attributes and attribute
forms since attribute forms are not explicitly part of a logical
data model.
Generally, all or most of the remaining items are

attributes. You may have a few items that are either
attribute forms or metrics that you will later create in
the MicroStrategy project.
Some attributes may not be included in the existing source

data, but you can derive them from the source data. For
example, the source system may record facts only at the date
level, but users want to analyze these facts by month, quarter,
and year. You can use the date information that is in the
source system to derive these other levels of time.
Determine Direct Attribute Relationships
After you have identified the attributes, you need to review

the list of attributes and determine any direct relationships
that exist between attributes. If attributes answer the same
business question at different levels, then they probably are
directly related to each other. For example, all attributes
associated with time answer questions about when a fact
occurred. Therefore, attributes like Year, Quarter, Month,
and Date are directly related.

You also need to determine the type of relationship that exists

between directly related attributes—one to one, one to many,
or many to many. Reviewing the physical table structure of
the source data often provides details about the types of
relationships that exist between attributes.
You should not assume the type of relationship that

exists between two attributes no matter how obvious it
seems. For example, Year may seem to have a
one-to-many relationship to Quarter. However, the
manner in which the data is stored for the Quarter
attribute determines the relationship. If the quarter
data is stored as Q1, Q2, Q3, and Q4 without the
associated year, the relationship between Year and
Quarter is many to many. However, if the quarter data
is stored as Q1 2008, Q2 2008, Q3 2008, and Q4
2007, then the relationship between Year and Quarter
is one to many.
Organize Hierarchies
After you have determined the direct relationships between

attributes, you need to organize each group of directly related
attributes into a hierarchy. Remember that your hierarchies
should reflect the various business dimensions users want to
analyze.
For example, you could group all the customer-related

attributes into a Customers hierarchy and all the
product-related attributes into a Products hierarchy.
Depending on the complexity of your data and the nature of
your business, you may have very few hierarchies, or you may
have many hierarchies in your logical data model.


Business Scenario: Creating a Logical Data
Model
Your instructor will provide guidelines for completing this
business scenario in groups. After you work on the business
scenario with your group to create a logical data model, the
class will review the scenario together and discuss possible
solutions for how to structure the logical data model.
Creating a logical data model is an exercise that is

open to interpretation and variability. As long as the
decisions you make in how you structure the logical
data model are in keeping with user requirements and
the nature of the underlying source data, you can come
up with different “right” answers for this scenario. The
structure of some logical data models may be
preferred over others based on implementation
requirements, but it is often possible to create several
serviceable data models for the same scenario.
Overview
Your company captures information about various aspects of

its business and stores it in a dedicated source system. Now,
the company wants to use this existing data to create a
well-organized data warehouse that enables users to better
analyze business data.
© 2011 MicroStrategy, Inc. Business Scenario: Creating a Logical Data Model 67

You are new to the company, but you have been assigned the
task of creating the logical data model that will eventually be
used to design the data warehouse. In creating the logical
data model, you need to consider the available source data,
which is shown in the following illustration:
Existing Source Data
This illustration shows a very simple source system

structure. In most business environments, source
systems are much more complex, and you often have
to integrate information from multiple source systems.
You need to create the logical data model based on the

following requirements:
• The logical data model must include everything from the

source data.
• Users want to analyze data at different levels of time.
• Users want to analyze customer purchases by customer

age.
68 Business Scenario: Creating a Logical Data Model © 2011 MicroStrategy, Inc.

As you work, remember the five steps for creating a logical

data model:
1 List all the information from the source data you need to
include in the logical data model based on the user
reporting requirements.
2 Identify which items are facts.
3 Identify which items are attributes.
4 Determine the direct relationships between attributes.
5 Organize directly related attributes into hierarchies.
You may use the blank pages that follow to record your logical
data model.



Lesson Summary
• A logical data model is a diagram that shows the
information you want to analyze in a project and how that
information is related.
• When you create a project in MicroStrategy Architect, you

define your logical data model within the tool.
• A logical data model includes the following three

components: facts, attributes, and hierarchies.
• Facts are measures that you use to analyze your business.

Fact data is typically numeric, and it is generally
aggregatable.
• In MicroStrategy projects, facts map to fact schema

objects, which form the basis for metrics on reports.
• Attributes are descriptive data that provide context for

analyzing facts. They enable you to answer questions
about facts.
• Attributes provide levels for aggregating and qualifying

fact data.
• In MicroStrategy projects, attributes map to attribute

schema objects, which describe metrics on reports.
• Understanding how columns correspond to attributes

versus attribute forms helps you identify which columns
you need to include in a logical data model as attributes.
• Attribute elements are the unique values of an attribute.
• Attribute elements are the data that display on a report

under the attribute headers. You can also use attribute
elements for very precise qualifications on fact data.
• A direct attribute relationship is one in which a

parent-child relationship exists between two or more
attributes.
• An indirect attribute relationship is one in which two or

more attributes are related only through a fact or set of
facts.

• There are three types of direct attribute

relationships—one to one, one to many, and many to
many.
• In MicroStrategy projects, you explicitly define any direct

relationships between attributes. These relationships
enable you to browse attribute data and drill on attributes
in reports.
• Hierarchies are groupings of directly related attributes

ordered to reflect their relationships.
• In MicroStrategy projects, the composite of all the

hierarchies you include in the logical data model forms
the system hierarchy.
• In MicroStrategy projects, user hierarchies may or may
not follow the structure of individual hierarchies from the
logical data model.
• When creating a logical data model, you need to consider

the following factors that influence the design: user
reporting requirements, existing source data, and
technical and performance considerations.
• Creating a logical data model involves the following steps:

listing all the information from the source data you need
to include in the logical data model, identifying facts,
identifying attributes, determining direct attribute
relationships, and organizing directly related attributes
into hierarchies.


3
DESIGNING THE DATA
WAREHOUSE SCHEMA
Lesson Description
This lesson describes how to design the physical schema for a

data warehouse.
In this lesson, you will learn about physical schemas and how
they are used in MicroStrategy Architect. Then, you will learn
about the different components that comprise a physical
schema and various types of schema designs. Finally, you will
learn about factors you need to consider in creating a data
warehouse schema.

3 Designing the Data Warehouse Schema MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe the purpose of a physical schema and explain how
you use it in MicroStrategy Architect, describe the
components of a physical schema, describe the
characteristics of various types of schema designs, and
describe the factors to consider in creating a data warehouse
schema.
• Describe the purpose of a physical schema and explain

how you use it when creating a project in MicroStrategy
Architect. (Page 77)
• Describe the components of a physical schema, including

various types of columns and tables. (Page 80)
• Describe the characteristics of various types of schema

designs. (Page 90)
• Describe the factors to consider in creating a data

warehouse schema. (Page 99)

MicroStrategy Architect: Project Design Essentials Designing the Data Warehouse Schema 3
Introduction to Physical Schemas

Describe the purpose of a physical schema and explain how
you use it when creating a project in MicroStrategy Architect.
The second step in the project design process is to design the

data warehouse schema. Before you learn how to design a
data warehouse schema, you need to understand the basic
concept of a physical schema, how you use it in MicroStrategy
Architect, and its various components.
What Is a Physical Schema?

A physical schema is a detailed, graphical representation of
the physical structure of a database. When the database in
question is a data warehouse, the physical schema shows how
your business data is stored. You design the physical schema
based on the organization of the logical data model. You can
create various physical schema designs from a single logical
data model, depending on how you want to store the data
representing logical objects in the data warehouse.
While the logical data model shows you the facts and
attributes, the physical schema shows you how the
underlying data for these objects is stored in the data
warehouse.
© 2011 MicroStrategy, Inc. Introduction to Physical Schemas 77

The following illustration shows a simple physical schema:

Physical Schema
This physical schema shows tables and columns that store

product, geography, time, and sales data.
For information on the various components of a

physical schema, see “Physical Schema Components”
Using the Physical Schema in MicroStrategy Architect

As you have already learned, the schema objects you create in
MicroStrategy Architect serve as the link between the logical
structure of the data model and the physical structure of the
data warehouse content.
78 Introduction to Physical Schemas © 2011 MicroStrategy, Inc.

When you create a project in MicroStrategy Architect, two of

the primary tasks involved in that process are creating fact
and attribute schema objects. When you create facts and
attributes, you map these logical objects to specific columns
and tables in the data warehouse. Therefore, understanding
the physical schema of the data warehouse is essential to
creating the correct mappings between schema objects and
the actual data.
© 2011 MicroStrategy, Inc. Introduction to Physical Schemas 79

Physical Schema Components

Describe the components of a physical schema, including
various types of columns and tables.
A physical schema includes the following two primary

components:
• Columns
• Tables
A physical schema consists of a set of tables, and those tables

contain columns that store the actual data. The following
topics describe each of these components in more detail.
Column Types
In a data warehouse, the columns in tables store fact or
attribute data. The following are the three types of columns:
• ID columns—These columns store the IDs for attributes.

IDs are often numeric and generally serve as the unique
key that identifies each element of an attribute. All
attributes have an ID column.
• Description columns—These columns store the text

descriptions of attributes. Description columns are
optional. However, most attributes have an ID column
and at least one description column. If an attribute has
additional description columns, you can create attribute
forms for each column.
When an attribute does not have a separate

description column, the ID column serves as both
the ID and description.
• Fact columns—These columns store fact data. They are

usually numeric.
80 Physical Schema Components © 2011 MicroStrategy, Inc.

The following illustration shows examples of all three column

types:
Column Types
In the LU_EMPLOYEE table, the Employee_ID column

stores the unique IDs for each employee, while the other
three columns store description information about each
employee, including their names, e-mails, and addresses.
In the FACT_SALES table, the Dollar_Sales and Unit_Sales

columns store values for these two facts. The remaining
columns are attribute ID columns.
Table Keys
Before you learn about the different types of tables in a
physical schema, it is important to understand some basic
concepts about table structure.
Every table has a primary key that consists of a unique value

that identifies each distinct record (or row) in the table. There
are two types of primary keys:
• Simple key—This type of key requires only one column to

uniquely identify each record within a table.
• Compound key—This type of key requires two or more

columns to uniquely identify each record within a table.
© 2011 MicroStrategy, Inc. Physical Schema Components 81

The type of key you use for a table depends on the nature of
the data itself. The specific requirements of your business
may also influence what type of key is used.
The following illustration shows examples of simple and

compound keys:
Simple and Compound Keys
In the first example, you can uniquely identify each call

center in the LU_CALL_CTR table using only the
Call_Ctr_ID column. Since each call center has a unique ID,
the table has a simple key.
In the second example, you can uniquely identify each call

center in the LU_CALL_CTR table only if you use both the
Call_Ctr_ID and Region_ID columns. The table requires a
compound key because call centers from different regions can
have the same ID. For example, Boston and Baltimore have
the same IDs, but they belong to different regions. You
cannot distinguish between these two call centers unless you
also know the IDs for their respective regions.

Simple keys are generally easier to work with in a data

warehouse than compound keys because they require less
storage space and they allow for simpler SQL. Compound
keys tend to increase SQL complexity and query time and
require more storage space. However, compound keys are
often present in source system data. In such cases, retaining
compound keys provides for a less complex and more
efficient ETL process.
There are advantages and disadvantages to both types of

table keys, so you have to consider which key structure best
meets your needs when designing the data warehouse
schema.
Lookup Tables
You can have several types of tables in a physical schema.
Lookup tables store information about attributes, including
their IDs and any descriptions. They enable you to easily
browse attribute data.
Depending on how you design the physical schema, a lookup

table can store information for a single attribute or multiple
related attributes.

The following illustration shows two examples of lookup

tables:
Lookup Tables
The LU_CATEGORY, LU_SUBCATEGORY, and LU_ITEM

lookup tables each store information only for a single
attribute—Category, Subcategory, or Item. The
LU_PRODUCT table stores information for all three of these
attributes.
Relationship Tables
Relationship tables store information about the relationship
between two or more attributes. They enable you to join data
for related attributes. To map the relationship between two or
more attributes, their respective ID columns must exist
together in a relationship table.
Lookup tables can serve a dual function as both lookup and

relationship tables in some circumstances. At other times,
you need to have a relationship table that is distinct from any
associated lookup tables.

Working with One-to-One Relationships
For attributes that have a one-to-one relationship, you do not

need a separate relationship table. Typically, you do not even
have a separate lookup table for the parent attribute. Instead,
you place the parent directly in the lookup table of the child
attribute to map the relationship between the two attributes.
The following illustration shows an example of using a single

lookup and relationship table for two attributes:
Single Lookup and Relationship Table
E-mail and Employee have a one-to-one relationship.

Therefore, the LU_EMPLOYEE table can serve as both the
lookup and relationship table for both attributes.
Inattribute
a MicroStrategy project, you often treat the parent
in a one-to-one relationship as a form of the
attribute it describes. If you want to treat the parent
attribute as a separate attribute, you may want a
separate lookup table for the parent. For more
information on attribute forms, see “What Is an
Attribute Form?” starting on page 234.
Working with One-to-Many Relationships
For attributes that have a one-to-many relationship, you also

do not need a separate relationship table. Instead, you can
define the parent-child relationship by including the ID
column for the parent attribute in the lookup table of the
child attribute. Placing the parent ID in the child table creates
a foreign key on the parent ID that enables you to map the
relationship between the two attributes using their respective
lookup tables.

The following illustration shows an example of a lookup table

that also functions as a relationship table:
Combined Lookup and Relationship Table
Category and Subcategory have a one-to-many relationship.

Therefore, the LU_SUBCATEGORY table can serve as both
the lookup table for the Subcategory attribute and the
relationship table for the Category and Subcategory
attributes. The Category_ID column is a foreign key that
maps back to the LU_CATEGORY table.
Working with Many-to-Many Relationships
For attributes that have a many-to-many relationship, you

must create a separate relationship table to map the
parent-child relationship.
The following illustration shows an example of a distinct

relationship table:
Distinct Relationship Table

Supplier and Item have a many-to-many relationship.

Therefore, you cannot place the ID column for the Supplier
attribute in the LU_ITEM table and still retain only the
Item_ID column as the primary key. The
REL_SUPPLIER_ITEM table includes the ID columns for
both the Supplier and Item attributes to map the relationship
between them. These two ID columns form a compound
primary key for the relationship table.
You generally use separate relationship tables in a data

warehouse only for attributes that have
many-to-many relationships.
Analyzing facts using attributes that have a

many-to-many relationship requires you to use a
distinct relationship table and include the relationship
in any corresponding fact tables.
Fact Tables
Fact tables store fact data and attribute ID columns that
describe the level at which the fact values are recorded. They
enable you to analyze fact data with regard to the business
dimensions or hierarchies those attributes represent.
The following illustration shows an example of a fact table:

Fact Table

The FACT_SALES table stores dollar and unit sales data by

item, employee, and date. These three attributes comprise the
fact table level. Using this table, you can view dollar or unit
sales data at any of these levels, or you can aggregate the fact
data from these levels to higher attribute levels within the
same hierarchies. For example, you could aggregate the
date-level dollar sales to the month level or the item-level
unit sales to the subcategory level.
Base and Aggregate Fact Tables
There are two types of fact tables that you typically have in a
data warehouse. Base fact tables are tables that store a fact or
set of facts at the lowest possible level of detail. Aggregate
fact tables are tables that store a fact or set of facts at a
higher, or summarized, level of detail.
For example, consider the following two fact tables:

Base and Aggregate Fact Tables
The FACT_SALES table stores dollar and unit sales data at

the lowest possible level of detail—by item, employee, and
date. Therefore, it is the base fact table for these two facts.
The FACT_SALES_AGG table stores dollar and unit sales
data at a higher level of detail—by category, region, and
month. Therefore, it is an aggregate fact table for these two
facts.

Because they store data at a higher level, aggregate fact tables

reduce query time. For example, if you want to view a report
that shows unit sales by region, you can obtain the result set
more quickly using the FACT_SALES_AGG table than the
FACT_SALES table.
In a data warehouse, you often have multiple aggregate fact

tables for the same fact or set of facts to enable you to more
quickly analyze fact data at various levels of detail.

Schema Types

Describe the characteristics of various types of schema
designs.
As you learned earlier, for any given logical data model, you
can design a variety of schemas to store the data using
different physical structures. The type of schema design you
select for the data warehouse depends on the nature of the
data, how users want to query the data, and other factors
unique to your project and database environments.
Before you learn about the various types of schema designs,

you need to understand the difference between normalized
and denormalized schemas.
Normalized Versus Denormalized Schemas

A basic characteristic of any physical schema is its degree of
normalization or denormalization.
Normalization occurs whenever you have a schema design

that does not store data redundantly. Denormalization
occurs whenever you have a schema design that stores at least
some data multiple times, or redundantly. You generally
denormalize tables for performance purposes to reduce the
number of joins necessary between tables for queries.
90 Schema Types © 2011 MicroStrategy, Inc.

For example, consider the following lookup tables:

Normalized and Denormalized Tables
The normalized LU_ITEM table contains the minimal

amount of information necessary to store items and map
their relationships to subcategories. The denormalized
LU_ITEM table stores all this information, but it also
contains the descriptions for each subcategory and the IDs
and descriptions for the corresponding categories. You store
this data multiple times for each item to which it
corresponds. You may also have separate lookup tables that
store just the subcategory and category data, so you may be
storing the same information redundantly across multiple
tables.
Schema designs largely vary in terms of the degree of

denormalization they employ. Now that you understand the
difference between normalization and denormalization, you
are ready to learn about the following commonly used
schema designs:
• Completely normalized schema
• Moderately denormalized schema
• Completely denormalized schema
© 2011 MicroStrategy, Inc. Schema Types 91

Completely Normalized Schema

A completely normalized schema does not store any data
redundantly. The following illustration shows an example of
a completely normalized schema:
Completely Normalized Schema
For simplicity, the image above shows only one fact

table as part of the schema. However, schemas
generally contain multiple fact tables at different
levels.
The lookup tables in this example contain only the IDs and
descriptions for their respective attributes as well as the IDs
of the immediate parent attributes. For example, the
LU_EMPLOYEE table has only three
columns—Employee_ID, Employee_Name, and
Call_Ctr_ID.
This schema design stores the minimal amount of

information, but it can require more joins between tables,
depending on the level at which you query data.

Moderately Denormalized Schema

A moderately denormalized schema stores some data
redundantly. The following illustration shows an example of
a moderately denormalized schema:
Moderately Denormalized Schema

levels.
The lookup tables in this example contain the IDs and

of all related higher-level attributes within the hierarchy. For
example, the LU_EMPLOYEE table has four
columns—Employee_ID, Employee_Name, Call_Ctr_ID,
and Region_ID.
This schema design stores the IDs of related higher-level

attributes redundantly. However, because it stores this
information redundantly, this design can reduce the number
of joins required between tables.

Completely Denormalized Schema

A completely denormalized schema stores the maximum
amount of data redundantly. The following illustration shows
an example of a completely denormalized schema:
Completely Denormalized Schema

levels.
The lookup tables in this example contain the IDs and

and descriptions of all related higher-level attributes within
the hierarchy. For example, the LU_EMPLOYEE table has six
columns—Employee_ID, Employee_Name, Call_Ctr_ID,
Call_Ctr_Desc, Region_ID, and Region_Desc.
This schema design stores the ID and descriptions of related

higher-level attributes redundantly. However, because it
stores so much information redundantly, this design can
further reduce the number of joins required between tables.

Higher-Level Lookup Tables
In a completely denormalized schema, the lowest-level

lookup tables for each hierarchy actually contain all the
information found in the higher-level lookup tables:
Lowest-Level Lookup Tables
The LU_ITEM, LU_EMPLOYEE, and LU_DATE tables

contain all the possible information for their respective
hierarchies. The other, higher-level lookup tables do not
provide any information that you cannot obtain from these
three tables.

You could eliminate all the higher-level lookup tables to

create a schema that has only one table for each hierarchy,
which is often referred to as a star schema:
Star Schema
You can simplify a completely denormalized schema to a

single table per hierarchy. However, there are advantages to
retaining the higher-level lookup tables.
First, depending on how you key the tables in a star schema,

you can more efficiently browse higher-level attributes using
the higher-level lookup tables rather than the consolidated
lookup tables.
For example, if you want a report that shows a list of

categories, the MicroStrategy Engine has to perform a
SELECT DISTINCT query on the LU_PRODUCT table to
obtain this result set since this table does not have a distinct
list of categories. The Engine can obtain the same result by
performing a simple SELECT on the LU_CATEGORY table.
SELECT DISTINCT queries are much more resource
intensive and can negate any performance gains that come
from joining fewer tables.
Second, you need the higher-level lookup tables to take

advantage of aggregate fact tables that you may have in your
schema.

For example, consider the aggregate fact table in the

following schema:
Using Aggregate Fact Tables
The FACT_SALES table stores dollar and unit sales at the

item, employee, and date level. However,
FACT_SALES_REGION is an aggregate fact table that stores
the same data at the item, region, and date level.
If you want to view sales by employee, you have to obtain this

data from the FACT_SALES table. However, if you want to
view sales by region, you can obtain the data from either the
FACT_SALES or FACT_SALES_REGION tables. Querying
the FACT_SALES_REGION table is more efficient since the
data is already aggregated to the region level. However, after
the MicroStrategy Engine obtains the sales data from the
FACT_SALES_REGION table, it has to join to a lookup table
to retrieve the corresponding region descriptions.
If you use the LU_EMPLOYEE table for this join, it does not
contain a distinct list of regions. Instead, the regions are
repeated for each employee in each region. As a result, the
Engine would join to each region for every occurrence in the
LU_EMPLOYEE table, which results in counting the sales
multiple times. The result set would show inflated sales
values.

If you use the LU_REGION table for this join, it contains a

distinct list of regions, which enables the Engine to perform
the join correctly and produce the correct sales values.
Therefore, this higher-level lookup table is necessary to use
the aggregate fact table.
For more information on aggregate fact tables, see

“Base and Aggregate Fact Tables” starting on page 88.
For more information on star schemas and the use of

aggregate fact tables with star schemas, see the
MicroStrategy Advanced Data Warehousing course.
Summary of Schema Types

You have learned about three commonly used schema
designs. Each of these schema types have advantages and
disadvantages. The following table provides a comparison of
the characteristics of each schema type:
Schema Type Comparison
Schema Lookup Table

Advantages Disadvantages
Type Structure
Completely Contains an Requires minimal Requires more

Normalized attribute’s ID and storage space and joins for queries
Schema description columns no data on higher-level
as well as the ID redundancy attributes
column of its
immediate parent
Moderately Contains an Significantly Requires slightly

Denormalized attribute’s ID and reduces the more storage
Schema description columns number of joins space and some
as well as the ID necessary for data redundancy
columns of all related queries on
higher-level attributes higher-level
attributes
Completely Contains an Further reduces Requires

Denormalized attribute’s ID and the number of significantly
Schema description columns joins necessary more storage
as well as the ID and for queries on space and the
description columns higher-level greatest degree
of all related attributes of data
higher-level attributes redundancy

Creating a Data Warehouse Schema

Describe the factors to consider in creating a data warehouse
schema.
Now that you are familiar with the components of a physical

schema and various schema types, you are ready to learn how
to create a data warehouse schema.
There are many ways to structure your data warehouse

schema, and no single design is right or wrong. The optimal
schema design depends on a variety of factors that are
specific to your project and database environments.
The best structure for your data warehouse is often a

combination of schema types. For example, you may choose
to normalize one hierarchy, while completely denormalizing
another hierarchy. You may even need to normalize and
denormalize various tables within the same hierarchy to best
meet your needs.
Factors to Consider
As you create a data warehouse schema, you need to consider
the following factors that influence the design of the schema:
• Query performance
• Data volume
• Database maintenance
Compromises and tradeoffs that balance each of these factors

are integral to the process of designing the schema. The
following topics describe each of these factors in detail.
© 2011 MicroStrategy, Inc. Creating a Data Warehouse Schema 99

User Reporting Requirements
The structure of your data warehouse schema should take

into account the reporting requirements of end users.
Understanding what information users need on reports helps
you determine your query profile—the types of queries users
will execute and how often they will execute them.
For example, normalizing a particular part of the data

warehouse schema may require more joins between tables to
access higher-level attributes. However, if users query that
data very infrequently, it may be worthwhile to normalize the
tables. On the other hand, data that users frequently query
may be good candidates for denormalization.
Query Performance

into account what type of query performance you need to
deliver to users. More granular, detail-level queries involve
accessing a greater volume of data, which can degrade
performance. Denormalizing tables can often help speed
query performance by reducing the number of joins between
tables.
Again, understanding your query profile—specifically, the

number of higher-level versus detailed queries users will
execute—can help with planning for optimal performance.
However, you always have to weigh the performance benefit
denormalization can provide against the maintenance burden
it may create.
Data Volume

into account the volume of data you store for each attribute in
each hierarchy. Attributes and hierarchies with greater data
volumes are often better candidates for denormalization,
while you can often use a more normalized schema design for
those with lower data volumes. In such cases, joining more
tables that contain less data may be preferable to significantly
increasing the size of smaller tables.
100 Creating a Data Warehouse Schema © 2011 MicroStrategy, Inc.

Database Maintenance

into account the effort involved in maintaining whatever
schema design you choose. Often, designs that provide
greater flexibility in terms of query performance and detail
also require more work to maintain.
In general, the more you denormalize a table, the more you

have to do to maintain the table. Because denormalized
schemas store data redundantly, when changes occur, there
are simply more tables and columns to update. You
constantly have to balance the benefits such denormalization
provides against the maintenance burdens it creates.
For example, you may have some tables in a hierarchy that

you want to denormalize for performance reasons. However,
you also know that the data in these tables is very volatile and
subject to lots of changes. In considering the maintenance
overhead this will create, you map opt to partially
denormalize the tables.
Another thing to consider with regard to database

maintenance is the complexity of your ETL process for
converting data from source system structures to the
structure you are planning for the data warehouse. Because
you use source systems and data warehouses for
fundamentally different purposes, some structural changes
are usually necessary to create a schema that is optimized for
analysis. However, the more you have to rekey tables,
combine data from multiple tables, or separate data into
multiple tables, the more complex the conversion becomes.
At times, you may need to weigh the benefits you will realize
from these schema changes against the demands of the ETL
work required to create them.
© 2011 MicroStrategy, Inc. Creating a Data Warehouse Schema 101


Business Scenario: Creating a Data Warehouse
Schema
Your instructor will provide guidelines for completing this
business scenario in groups. After you work on the business
scenario in groups to create a data warehouse schema, the
class will review the scenario together and discuss possible
solutions for how to structure the physical schema.
Creating a data warehouse schema is an exercise that

is open to interpretation and variability. As long as the
decisions you make in how you structure the physical
schema are in keeping with the characteristics of the
project and database environments described in the
overview, you can come up with different “right”
answers for this scenario. The structure of some
physical schema designs may be preferred over others
based on implementation requirements, but it is often
possible to create several serviceable schema designs
for the same scenario.
102 Business Scenario: Creating a Data Warehouse Schema © 2011 MicroStrategy, Inc.
Overview
You work for a bank that is building a data warehouse to

better analyze its business. The following illustration shows
the logical data model that has been created:
Logical Data Model
Now, the bank wants to use this logical data model to design
the data warehouse schema. You have been assigned the task
of creating the schema for the Geography and Account
hierarchies. In creating the physical schema, you need to
consider the following factors to select an optimal design for
each hierarchy:
• The bank evaluates and makes organizational changes to

its regions and districts at least three times each year,
which results in those relationships changing frequently.
• The bank plans to open 50 new branches this year.
• The bank currently has 7 regions, 4o districts, and 1500

branches. The logical data model must include everything
from the source data.
• The bank has 4 divisions with a total of over 5 million

accounts.
© 2011 MicroStrategy, Inc. Business Scenario: Creating a Data Warehouse Schema

• The source system database that the bank uses to capture

transactions uses a normalized schema.
• Users tend to execute a lot of queries to view data at the

branch level. They also execute selected queries to view
data at the region and district levels.
• Users execute a variety of queries at both the division and

account levels.
• Detailed, account-level queries often degrade

performance in the current reporting system. As part of
designing the data warehouse schema, the bank hopes to
better address the performance issues posed by such
queries.
The source system contains the following minimum

information for each attribute in the Geography and Account
hierarchies:
• ID column that uniquely identifies its elements
• DESC column that provides a text description for each

element
For the Employee attribute, the source system also stores

each employee’s Social Security Number, home address, and
home phone number.
As you work, remember the four factors to consider in

designing a data warehouse schema:
• Query performance
• Data volume
• Database maintenance
You may use the blank pages that follow to record your
schema design for the Geography and Account hierarchies.

Lesson Summary
• A physical schema is a detailed, graphical representation
of the physical structure of a database.
• Understanding the physical schema of the data warehouse

is essential to creating the correct mappings between
schema objects and the actual data in MicroStrategy
Architect.
• A physical schema includes the following two primary

components: columns and tables.
• In data warehouses, the columns in tables store attribute

or fact data. Tables may contain ID, description, or fact
columns.
• Every table has a primary key. A simple key requires only

one column to uniquely identify each record within a
table, while a compound key requires two or more
columns.
• Simple keys require less storage space and allow for

simpler SQL.
• Compound keys require more storage space and increase

SQL complexity and query time. They can provide for a
less complex and more efficient ETL process.
• Lookup tables store information about attributes,

including their IDs and descriptions. They enable you to
easily browse attribute data.
• Relationship tables store information about the

relationship between two or more attributes. They enable
you to join data for related attributes.
• You can use a single lookup table as both the lookup and
relationship table for attributes with a one-to-one
relationship.
• You can use a combined lookup and relationship table for

attributes with a one-to-many relationship. The parent ID
in the child lookup table is a foreign key that maps to the
parent lookup table.
• You must have a distinct relationship table for attributes

with a many-to-many relationship.

• Fact tables store fact data and attribute ID columns that

describe the level at which the fact values are recorded.
They enable you to analyze fact data with regard to the
hierarchies those attributes represent.
• Base fact tables are tables that store a fact or set of facts at
the lowest possible level of detail.
• Aggregate fact tables are tables that store a fact or set of

facts at a higher, or summarized, level of detail.
• Normalization occurs when you have a schema design

that does not store data redundantly.
• Denormalization occurs when you have a schema design

that stores at least some data redundantly. You generally
denormalize tables for performance purposes to reduce
the number of joins necessary between tables for queries.
• A completely normalized schema does not store any data

redundantly. Its lookup tables contain the IDs and
descriptions for attributes as well as the IDs of the
immediate parent attributes.
• A moderately denormalized schema stores some data

redundantly. Its lookup tables contain the IDs and
descriptions for attributes as well as the IDs of all related
higher-level attributes within the hierarchy.
• A completely denormalized schema stores the maximum

amount of data redundantly. Its lookup tables contain the
IDs and descriptions for attributes as well as the IDs and
descriptions of all related higher-level attributes within
the hierarchy.
• In a completely denormalized schema, retaining the

higher-level lookup tables enables you to more efficiently
browse higher-level attributes and take advantage of
aggregate fact tables.
• When creating a data warehouse schema, you need to

consider the following factors that influence the design:
user reporting requirements, query performance, data
volume, and database maintenance.
4
CREATING A PROJECT IN
MICROSTRATEGY ARCHITECT
Lesson Description
This lesson describes the process of creating a project in

MicroStrategy Architect.
In this lesson, you will learn about the tasks involved in

project creation, including configuring the project metadata,
configuring project connectivity, creating schema objects
using the project creation workflow, and updating the project
schema. Then, you will learn about the various project
creation interfaces available in MicroStrategy Architect,
including the Project Creation Assistant, schema object
editors, and the Architect graphical interface.

4 Creating a Project in MicroStrategy Architect MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Explain the tasks involved in creating a project in
MicroStrategy Architect, complete the initial tasks involved
in project creation, and describe the project creation
interfaces available in MicroStrategy Architect.
• Configure the project metadata, configure project

connectivity, use the project creation workflow to create
schema objects, and update the project schema.
(Page 111)
• Describe how to use the Project Creation Assistant,

schema object editors, and Architect graphical interface to
create projects in MicroStrategy Architect. (Page 137)

MicroStrategy Architect: Project Design Essentials Creating a Project in MicroStrategy Architect 4
Overview of Project Creation

Configure the project metadata, configure project
connectivity, use the project creation workflow to create
schema objects, and update the project schema.
The third step in the project design process is to create a

project in MicroStrategy Architect. Before you learn how to
create a project, you need to understand the basic tasks
involved in project creation, including the following:
• Configuring the project metadata
• Configuring project connectivity
• Creating the necessary schema objects using the project

creation workflow
• Updating the project schema
The following topics describe each of these concepts in more

detail.
Configuring the Project Metadata

You create a MicroStrategy project inside a metadata that
stores all of its information. You can store any number of
projects within the same metadata.
When you are ready to create a project in MicroStrategy

Architect, you may have an existing metadata in which you
want to create the project. If not, before you can begin to
build the project, you have to configure the project metadata.
The metadata is a relational database with a predefined

structure that consists of 23 empty tables known as the
metadata shell. As you create a project and continue to add to
it, you populate these tables with information.
© 2011 MicroStrategy, Inc. Overview of Project Creation 111

Configuring the project metadata includes the following

steps:
1 Create an empty metadata database.
2 Create a data source name (DSN) to connect to the

metadata database.
3 Create the metadata shell.
Creating the Metadata Database
You can create an empty database for the metadata using any
certified or supported database platform. The database
platform for the data warehouse and metadata do not have to
be the same.
For information on certified and supported database

platforms for the metadata, see the readme file for the
version of MicroStrategy that you have installed.
Creating the DSN to Connect to the Metadata
After you create the empty metadata database, you need to

create a DSN that enables MicroStrategy to connect to it. You
can create this DSN using either the MicroStrategy
Connectivity Wizard or the ODBC Data Source
Administrator.
The MicroStrategy Connectivity Wizard shows only database

drivers that are certified or supported by MicroStrategy, and
it displays only the DSN settings that are necessary for
MicroStrategy to connect to the database. However, it does
not provide access to all certified and supported drivers.
To create a DSN using the MicroStrategy Connectivity

Configuration Wizard:
1 On the Start menu, point to Programs, point to

MicroStrategy, point to Tools, and select Connectivity
Wizard.
112 Overview of Project Creation © 2011 MicroStrategy, Inc.

2 In the MicroStrategy Connectivity Wizard, click Next.
3 In the Driver Selection window, click the appropriate

driver.
4 Click Next.
5 In the Driver Details window, enter the appropriate

connection information for the DSN.
The exact settings in this window vary, depending

on the driver you select.
Ifyouyouenter,
want to test the connection information that
click Test. In the Test Connection
window, enter the appropriate user name and
password. Click Connect. A message window
shows whether the test connection succeeded.
6 Click Finish.
7 In the DSN Created window, click OK.

The following image shows the Driver Selection window of

the MicroStrategy Connectivity Wizard:
MicroStrategy Connectivity Wizard—Driver Selection
Window
If the certified or supported database driver that you need to

use is not available in the MicroStrategy Connectivity
Configuration Wizard, you can use the ODBC Data Source
Administrator to create the DSN. The ODBC Data Source
Administrator shows all installed drivers, so you need to be
aware of which drivers are certified or supported for your
specific database platform. It also displays all the DSN
settings, not just those that are necessary for MicroStrategy
to connect to the database.
To create a DSN using the ODBC Data Source Administrator:
1 On the Start menu, point to Settings and select Control

Panel.
2 In the Control Panel window, double-click

Administrative Tools.

3 In the Administrative Tools window, double-click the

Data Sources (ODBC) shortcut.
4 In the ODBC Data Source Administrator window, click the

System DSN tab.
5 On the System DSN tab, click Add.
6 In the Create New Data Source window, select the

appropriate driver.
7 Click Finish.
8 In the next window, enter the appropriate connection

information for the DSN.
The name of this window and the exact settings it

displays vary, depending on the driver you select.
For some drivers, the ODBC Data Source
Administrator may display additional windows
with other DSN settings. You can move through
these windows and enter any required connection
information.
9 When you have finished entering the appropriate

connection information, in the ODBC Data Source
Administrator window, click OK.
10 Close the Administrative Tools window.

The following image shows the System DSN tab of the ODBC
Data Source Administrator:
ODBC Data Source Administrator—System DSN Tab
The following image shows the Create New Data Source

window with a Microsoft Access® driver selected:
Create New Data Source Window

The following image shows a Microsoft Access DSN that

connects to an empty metadata database:
Microsoft Access Metadata DSN
Creating the Metadata Shell
The final step in configuring the project metadata is to create

the metadata shell. You use the MicroStrategy Configuration
Wizard to accomplish this task.
To access the MicroStrategy Configuration Wizard:

MicroStrategy, and select Configuration Wizard.

The following image shows the MicroStrategy Configuration

Wizard:
MicroStrategy Configuration Wizard
In the MicroStrategy Configuration Wizard, you select the

DSN that points to the metadata in which you want to create
the metadata shell. When you connect to the metadata using
that DSN, the wizard automatically selects the appropriate
SQL script to execute. This script removes any existing
metadata tables, creates the empty metadata tables, grants
the appropriate permissions for those tables, and then
populates some of the tables with basic initialization data.
Ametadata
truly empty metadata should not have existing
tables.

To create the metadata shell:
1 Open the MicroStrategy Configuration Wizard.
2 In the MicroStrategy Configuration Wizard, click

Metadata, History List and Statistics Repository
Tables.
3 Click Next.
4 In the Repository Configuration: Repository Types

window, ensure that only the Metadata Tables check box
is selected.
You should clear the History List Tables and

Statistics Tables check boxes.
5 Click Next.
6 In the Repository Configuration: Metadata Tables

window, in the DSN drop-down list, select the DSN that
connects to the appropriate metadata database.
Ifclicking
the DSN does not yet exist, you can create it by
New and then using the MicroStrategy
Connectivity Wizard to define the DSN.
7 In the User Name box, type the appropriate database

login.
8 In the Password box, type the appropriate password.
9 Click Advanced.
10 If you want to use a table prefix in creating the metadata

tables, in the Table Prefix box, type the desired prefix.
11 In the Script box, ensure the appropriate SQL script is

selected.
ByWizard
default, the MicroStrategy Configuration
selects the script that is optimized for your
metadata database platform.

12 Click Next.
The MicroStrategy Configuration Wizard connects

to the metadata database. If it detects an existing
MicroStrategy 9.0.1 metadata in the database, a
message window displays asking if you want to
re-create (overwrite) the existing tables. If it
detects an existing metadata from an earlier
version of MicroStrategy, the Repository
Configuration: Upgrade Metadata window displays
giving you the option to remove the existing tables
and create a new repository or upgrade them to
MicroStrategy 9. If you are truly configuring an
empty metadata, you should not see either of these
windows.
13 In the Summary window, click Finish.
Atostatus bar displays at the bottom of the window

show the progress of the SQL script being
executed. When the script finishes executing, a
message states that the configuration completed
successfully.
14 Click Close.
15 In the MicroStrategy Configuration Wizard, click Exit.

The following image shows the Repository Configuration:

Repository Types window of the MicroStrategy Configuration
Wizard:
MicroStrategy Configuration Wizard—Repository
Configuration: Repository Types Window

The following image shows the Repository Configuration:

Metadata Tables window of the MicroStrategy Configuration
Wizard:
MicroStrategy Configuration Wizard—Repository
Configuration: Metadata Tables Window

The following image shows the Summary window of the

MicroStrategy Configuration Wizard:
MicroStrategy Configuration Wizard—Summary Window
Configuring Project Connectivity

After you configure the project metadata, the next task is to
configure project connectivity to the metadata and data
warehouse in MicroStrategy Desktop. Configuring project
connectivity includes the following steps:
1 Create a project source.
2 Create a database instance, including a database

connection and database login.
Iftoatheproject source and database instance that connect

desired metadata and data warehouse already
exist in MicroStrategy Desktop, you can skip this task
and move on to creating the actual project.

Creating a Project Source
The project source is an object you create in MicroStrategy

Desktop that enables you to connect to the metadata. You can
configure a project source to connect to the metadata in one
of two ways:
• Direct—You connect to the metadata in two-tier mode by

specifying a DSN, login, and password.
• Server—You connect to the metadata in three-tier mode

by selecting an Intelligence Server that governs and
validates the database connection.
Before you can create a project in a metadata, you have to

create a project source that enables you to connect to that
metadata. You can use the Project Source Manager to
accomplish this task. It enables you to easily create a project
source from within MicroStrategy Desktop.
You can also use the MicroStrategy Configuration

Wizard to create project sources.
To create a project source:
1 Open MicroStrategy Desktop.
You do not need to log in to an existing project

source.
2 In MicroStrategy Desktop, on the Tools menu, select

Project Source Manager.
3 In the Project Source Manager, click Add.
4 In the Project Source Manager window, in the Project

source box, type the name of the project source.
5 In the Connection mode drop-down list, select the

appropriate connection mode.

6 On the Connection tab, do one of the following:
If you selected the server connection mode, in the Server

name box, type the name of the Intelligence Server you
want to use.
You can also browse and select the Intelligence

Server.
You can change the port number and connection

timeout settings if desired.
OR
If you selected the direct connection mode, in the ODBC

DSN drop-down list, select the DSN for the metadata.
In the Login id box, type the appropriate database login.
In the Password box, type the appropriate password.
7 Click OK.
8 In the Project Source Manager, click OK.
The new project source displays in the Folder List

in MicroStrategy Desktop.
The following image shows the Project Source Manager:

Project Source Manager

The following image shows the server mode settings in the

Project Source Manager:
Project Source Manager—Server Mode Settings

The following image shows the direct mode settings in the

Project Source Manager:
Project Source Manager—Direct Mode Settings
When you log in to a project source, it connects you to the

corresponding metadata. You can create any number of
projects inside the same project source, so the metadata can
store objects from different projects.
Creating a Database Instance
After you create a project source to connect to the metadata,

the next step is to establish a connection to the data
warehouse in MicroStrategy Desktop. The database instance
is a configuration object you create in Desktop that enables
you to connect to the data warehouse. When you create a
project, you specify its corresponding data warehouse by
selecting the appropriate database instance. A database
instance consists of a database connection, which in turn
uses a specific DSN and database login.

You create the database instance and database connection

inside a project source. You can use the Database Instances
manager to accomplish this task. It enables you to easily
create these configuration objects within any project source
in Desktop.
To create a database instance and database connection:
2 In MicroStrategy Desktop, log in to the project source in

which you want to create the database instance.
3 In the project source, expand Administration.
4 Under Administration, expand Configuration Managers.
5 Under Configuration Managers, right-click the Database

Instances manager, point to New, and select Database
Instance.
6 In the Database Instances window, on the General tab, in

the Database instance name box, type the name of the
database instance.
7 In the Database connection type drop-down list, select the

appropriate database connection type.
The database connection type should match the

database platform of the data warehouse.
8 Under Database connection (default), click New.
Ifyouyoucanwant to use an existing database connection,

select it from the list and click OK. This
action creates a new database instance and
associates it with the selected database connection.
You can skip the remaining steps in this procedure.
9 In the Database Connections window, on the General tab,

in the Database connection name box, type the name of
the database connection.
10 In the Local system ODBC data sources list, click the DSN
you want to use.

11 Under Default database login name, click New.
Ifcanyouselect
want to use an existing database login, you
it from the list and click OK. This action
creates a new database connection and associates it
with the selected database login. Continue to step
17 in this procedure.
12 In the Database Logins window, in the Database login

box, type the name of the database login.
13 In the Login ID box, type the appropriate database login.
14 In the Password box, type the appropriate password.
15 Click OK.
16 In the Database Connections window, click OK.
17 In the Database Instances window, under Database

connection (default), click the database connection you
want to use.
18 In the Database Instances window, click OK.
The new database instance displays in the

Database Instances manager in MicroStrategy
Desktop.
The following image shows the Database Instances manager:

Database Instances Manager

The following image shows the Database Instances window:

Database Instances Window

The following image shows the Database Connections

window:
Database Connections Window
The following image shows the Database Logins window:

Database Logins Window

You can create any number of database instances and

database connections inside the same project source. You can
then use these configuration objects for any project you
create in that project source.
Understanding Project Connectivity
The project source and database instance provide

connectivity to the metadata and data warehouse for a
project. The project itself is the configuration object in which
you define all the schema and application objects that
comprise the reporting environment. The following
illustration shows how project connectivity works:
Project Connectivity

A project source connects to a metadata, which can contain

any number of projects. Each project uses a database instance
that connects to the data warehouse. This database instance
uses a database connection that points to the DSN and login
for the data warehouse.
Every project has at least one primary database

instance. You can map a project to multiple database
instances using MicroStrategy MultiSource Option™.
For information on using MultiSource Option, see the
MicroStrategy Architect: Advanced Project Design
course.
Creating the Schema Objects

After you configure project connectivity, the next task is to
create the project itself. Creating the project involves creating
the project object and the necessary schema objects in the
appropriate metadata (project source) using the appropriate
data warehouse (database instance).
The following basic schema objects are essential to creating a

fully-functioning project:
• Tables
• Facts
• Attributes
• User hierarchies
The following illustration shows the recommended workflow

for creating a project:
Project Creation Workflow

First, you add the tables from the data warehouse that you
want to use in the project. Then, you create the facts that are
part of your logical data model. Next, you create the
attributes that are part of your logical data model and define
their relationships, which establishes the system hierarchy.
Finally, you create the user hierarchies that you need for
browsing data and drilling on reports.
There are various interfaces available for creating schema

objects, which you will learn about later in this lesson. You
will learn how to create each of the basic schema objects later
in this course.
Updating the Project Schema

After you finish creating schema objects, the last step in
creating a project is to ensure that the project schema is
updated. The project schema consists of all the schema
objects in a project. It is an internal map that MicroStrategy
Architect uses to keep track of table sizes, fact levels, attribute
relationships, and so forth.
When you make any changes to schema objects—adding,

modifying, or deleting them—you have to update the project
schema. This update indicates to MicroStrategy Architect
that the definitions of schema objects have changed and need
to be loaded into memory.
Changes to schema object definitions are written to

the metadata when you save the objects. Changes to
other components, such as table keys, fact entry levels,
and logical table sizes, are not written to the metadata
until you update the project schema.

Most of the time, updating the project schema is a task you

perform manually since you do not want MicroStrategy
Architect to automatically update the entire schema every
time you make a change. It is easier to make all your changes
and then manually update the entire schema.
For three-tier projects, the schema is automatically

updated when you stop and restart the Intelligence
Server. For two-tier projects, the schema is
automatically updated when you disconnect and
reconnect to the project or project source.
To manually update the project schema:
1 In MicroStrategy Desktop, on the Schema menu, select

Update Schema.
You have to open and select a project to use this

option.
2 In the Schema Update window, select or clear the

following check boxes as appropriate:
• Update schema logical information—Select this

check box if you add, modify, or delete schema objects.
• Recalculate table keys and fact entry levels—Select

this check box if you change the key structure of a table
or the level at which a fact is stored.

• Recalculate table logical sizes—Select this check

box if you want MicroStrategy Architect to use its
algorithm to recalculate logical table sizes. This action
overrides any changes you have made to logical table
sizes unless you preserve them at the table level.
Logical table sizes determine which tables the

MicroStrategy Engine uses in a query. For
information on how MicroStrategy Architect
calculates logical table sizes, see the MicroStrategy
• Recalculate project client object cache size—Select

this check box to update the client object cache size for
the project.
Ifvalue
you select this check box and the Use custom
option for object caches is selected in the
Project Source Manager, MicroStrategy uses an
algorithm to calculate the client object cache size. If
the Use custom value option is not selected, the
client object cache size is determined by the object
cache setting in the Project Configuration Editor.
For more information on object caching, see the
MicroStrategy Administration course.
• Purge all element caches—Select this check box to

purge all element caches.
3 Click Update.
The update process may take a few minutes to

complete.

The following image shows the Schema Update window:

Schema Update Window

Project Creation Interfaces

Describe how to use the Project Creation Assistant, schema
object editors, and Architect graphical interface to create
projects in MicroStrategy Architect.
Now that you understand the tasks involved in creating a

project, you are ready to learn about the different interfaces
available in MicroStrategy Architect for completing these
tasks.
MicroStrategy Architect has three types of interfaces for

defining projects and creating schema objects:
• Project Creation Assistant
• Schema object editors
• Architect graphical interface
The following topics describe each of these interfaces in more

detail.
Project Creation Assistant

The Project Creation Assistant is a collection of wizards that
leads you through the basic tasks of project creation using a
very linear, step-by-step approach. It is the primary tool for
bulk project creation. It enables you to perform the following
tasks:
• Create the project object
• Select the project tables
• Create basic facts
• Create basic attributes and their relationships
138 Project Creation Interfaces © 2011 MicroStrategy, Inc.

You use the Project Creation Assistant when you initially

create the project. You can then use other interfaces to create
more complex facts and attributes as well as user hierarchies
or to fine-tune the project.
To access the Project Creation Assistant:

Create New Project.
The following image shows the Project Creation Assistant:

Project Creation Assistant
© 2011 MicroStrategy, Inc. Project Creation Interfaces 139

The Project Creation Assistant provides access to the

following components:
• Create project—Enables you to create the project object,

name the project, and configure selected project-level
settings
• Select tables from the Warehouse Catalog—Enables

you to select the primary database instance for the project
and then use the Warehouse Catalog to select the data
warehouse tables you want to use in the project
• Create facts—Enables you to use the Fact Creation

Wizard to create basic facts
• Create attributes—Enables you to use the Attribute

Creation Wizard to create basic attributes
• Architect—Enables you to open the Architect graphical

interface
This component provides an alternative interface

for project creation. You can use it instead of the
Warehouse Catalog, Fact Creation Wizard, and
Attribute Creation Wizard.
You can access the Warehouse Catalog, Fact Creation Wizard,

Attribute Creation Wizard, and Architect graphical interface
individually outside the Project Creation Assistant as well.
You will learn more about using each of these components
later in this course.
Regardless of which interface you use to work on a project in

MicroStrategy Architect, creating the project object is the one
task you have to complete using the Project Creation
Assistant.
To create the project object:
1 In the Project Creation Assistant, click Create project.
2 In the New Project window, in the appropriate box, type

the name of the project.
Entering a project description or configuring other

settings in this window is optional.

3 Click OK.
The process of creating the initial project files takes

a few minutes.
4 In the Project Creation Assistant, click OK.
This action enables you to save the project and

complete the rest of project creation at a later time
outside the Project Creation Assistant. If you want
to continue working in the Project Creation
Assistant, you can click Select tables from the
Warehouse Catalog.
5 In the message window, click OK.
The following image shows the New Project window:

New Project Window

Schema Object Editors

MicroStrategy Architect provides several editors for working
with the different types of schema objects. These schema
object editors enable you to create and modify individual
schema objects one at a time. They also provide access to
more advanced functions for creating more complex schema
objects.
The following schema object editors are ones you may

routinely use in project creation:
• Attribute Editor—Enables you to create and modify

attributes, configure attribute settings, and define
attribute relationships
• Fact Editor—Enables you to create and modify facts and
configure fact settings
• Hierarchy Editor—Enables you to create and modify user

hierarchies and configure user hierarchy settings
• Logical Table Editor—Enables you to configure logical

table settings and create logical views (similar to a
database view at the application level)
You primarily use schema object editors to create more

complex facts and attributes and user hierarchies or to
modify objects you already created using other interfaces.
After initial project creation, you perform most of your
ongoing maintenance of schema objects using these editors.
You will learn how to use each of these editors later in this
course.

Architect Graphical Interface

The Architect graphical interface provides a more visual,
freeform approach to working on projects. You can use it for
initial project creation, but it also provides a consolidated
interface for fine-tuning projects that enables you to access a
variety of functions. It enables you to work with the following
schema objects:
• Tables
• Facts
• Attributes
• User hierarchies
You can create, modify, and remove schema objects or

configure various settings for these objects using this
interface.
For more information on using the Architect graphical

interface, see the “Introduction to the Architect
Graphical Interface” lesson starting on page 403.


Exercises: Creating a Project in MicroStrategy
Architect
Over the next five lessons, you will use the Project Creation
Assistant and schema object editors to create a new project
called My Tutorial Project.
In this set of exercises, you will configure the metadata,

create the project source and database instance in
MicroStrategy Desktop, and create the project object.
Creating the Metadata Database
Overview
In this exercise, you will create an empty Microsoft Access

database named My_Tutorial_Metadata to use as the
metadata for your project. Save the database in the C:\MSTR
folder.
You can use the detailed instructions if you want help.
144 Exercises: Creating a Project in MicroStrategy Architect © 2011 MicroStrategy, Inc.

Detailed Instructions
The following instructions are for Microsoft Access

2007. The exact steps vary for earlier versions of
Microsoft Access. You can ask your instructor if you
have questions on how to create the database in the
version you are using.
Open Microsoft Access

Microsoft Office, and select Microsoft Office Access
2007.
Create the empty metadata database
2 In Microsoft Access, under New Blank Database, select

Blank Database.
3 In the File Name box, type My_Tutorial_Metadata.
4 Click Browse.
5 In the File New Database window, browse to the C:\MSTR

folder.
6 Click OK.
7 In Microsoft Access, click Create.
8 Close Microsoft Access.
© 2011 MicroStrategy, Inc. Exercises: Creating a Project in MicroStrategy Architect 145

Creating the DSN for the Metadata
Overview
In this exercise, you will use the MicroStrategy Connectivity

Wizard to create a DSN named My_Tutorial_Metadata to
connect to the My_Tutorial_Metadata database in the
C:\MSTR folder.
Open the MicroStrategy Connectivity Wizard

MicroStrategy, point to Tools, and select Connectivity
Wizard.
Create the DSN for the metadata database
2 In the MicroStrategy Connectivity Wizard, click Next.
3 In the Driver Selection window, click Other Relational

Databases.
4 Click Next.
5 In the second Driver Selection window, select Microsoft

Access Driver (*.mdb, *.accdb).
6 Click Next.
7 In the ODBC Microsoft Access Setup window, in the Data

Source Name box, type My_Tutorial_Metadata.
8 Under Database, click Select.
9 In the Select Database window, browse to the C:\MSTR

folder.
10 Select the My_Tutorial_Metadata database.

11 Click OK.
12 In the ODBC Microsoft Access Setup window, click OK.
13 In the DSN Created window, click OK.
Creating the Metadata Shell
Overview
In this exercise, you will use the MicroStrategy Configuration

Wizard to create the metadata shell in the
My_Tutorial_Metadata database in the C:\MSTR folder.
Open the MicroStrategy Configuration Wizard

MicroStrategy, and select Configuration Wizard.
Create the metadata shell in the metadata database
2 In the MicroStrategy Configuration Wizard, click

Metadata, History List and Statistics Repository
Tables.
3 Click Next.
4 In the Repository Configuration: Repository Types

window, clear the History List Tables check box.
5 Clear the Statistics Tables check box.
6 Click Next.

7 In the Repository Configuration: Metadata Tables

window, in the DSN drop-down list, select
My_Tutorial_Metadata.
You do not need to provide a login and password

since you are using a Microsoft Access database.
8 Click Next.
9 In the Summary window, click Finish.
10 When the configuration is complete, click Close.
11 In the MicroStrategy Configuration Wizard, click Exit.
Creating the Project Source
Overview
In this exercise, you will use the Project Source Manager in

MicroStrategy Desktop to create a two-tier project source
named My Tutorial Project Source that connects to the
My_Tutorial_Metadata database.
Open the Project Source Manager
You do not need to log in to an existing project

source.
2 In MicroStrategy Desktop, on the Tools menu, select

Project Source Manager.

Create the project source
3 In the Project Source Manager, click Add.
4 In the Project Source Manager window, in the Project

source box, type My Tutorial Project Source.
5 In the Connection mode drop-down list, select Direct.
6 On the Connection tab, in the ODBC DSN drop-down list,

select My_Tutorial_Metadata.
7 Click OK.
You do not need to provide a login and password

since you are using a Microsoft Access database.
8 In the Confirm Login/Password window, click Yes.
9 In the Project Source Manager, click OK.
10 Keep MicroStrategy Desktop open for the next exercise.
Creating the Database Instance
Overview
In this exercise, you will use the Database Instances manager

in MicroStrategy Desktop to create a database instance
named Tutorial Data that connects to the
MicroStrategy_Tutorial_Data data warehouse. As part of
creating the database instance, you will also create a database
connection named Tutorial Data and a database login named
Tutorial.
The DSN for the MicroStrategy_Tutorial_Data data

warehouse already exists on your machine.

Open the Database Instances manager
1 In MicroStrategy Desktop, log in to the My Tutorial

Project Source.
You can log in as Administrator with no password.

You have not yet created any projects in the project
source, so you should see a message window
display stating that no projects were returned for
the project source. Click OK.
2 In the My Tutorial Project Source, expand

Administration.
3 Under Administration, expand Configuration Managers.
4 Under Configuration Managers, right-click the Database

Instances manager, point to New, and select Database
Instance.
Create the database instance
5 In the Database Instances window, on the General tab, in

the Database instance name box, type Tutorial Data.
6 In the Database connection type drop-down list, select

Microsoft Access 2007.
Create the database connection
7 Under Database connection (default), click New.
8 In the Database Connections window, on the General tab,

in the Database connection name box, type Tutorial Data.
9 In the Local system ODBC data sources list, click

MicroStrategy_Tutorial_Data.
Create the database connection
10 Under Default database login name, click New.
11 In the Database Logins window, in the Database login

box, type Tutorial.

12 In the Login ID box, type Tutorial.
You do not actually have a login and password

since you are using a Microsoft Access data
warehouse. However, you have to create a database
login to associate with the database connection.
You can leave the password blank.
13 Click OK.
14 In the Database Connections window, click OK.
15 In the Database Instances window, click OK.
16 Keep MicroStrategy Desktop open for the next exercise.
Creating the Project Object
Overview
In this exercise, you will create a new project object named

My Tutorial Project in the My Tutorial Project Source. You
will use the Project Creation Assistant and schema object
editors to add tables, facts, attributes, and user hierarchies to
this project over the next several lessons.
Open the Project Creation Assistant
1 In MicroStrategy Desktop, in the My Tutorial Project

Source, on the Schema menu, select Create New Project.
Create the project object
2 In the Project Creation Assistant, click Create project.
3 In the New Project window, type My Tutorial Project as

the project name.

4 Click OK.
5 In the Project Creation Assistant, click OK.
You will continue creating this project in the

exercises for subsequent lessons.

Lesson Summary
• The basic tasks involved in project creation include
configuring the project metadata, configuring project
connectivity, creating the necessary schema objects using
the project creation workflow, and updating the project
schema.
• The metadata is a relational database with a predefined

structure that consists of 23 empty tables known as the
metadata shell. You can store any number of projects
within the same metadata.
• Configuring the project metadata includes creating an

empty metadata database, creating a data source name
(DSN) to connect to the metadata, and creating the
metadata shell.
• You can use the MicroStrategy Connectivity Configuration

Wizard or the ODBC Data Source Administrator to create
DSNs.
• You use the MicroStrategy Configuration Wizard to create

the metadata shell.
• Configuring project connectivity includes creating a

project source and database instance to connect to the
metadata and data warehouse in MicroStrategy Desktop.
• A project source is the object in MicroStrategy Desktop

that enables you to connect to the metadata.
• A direct project source enables you to connect to the

metadata in two-tier mode using a DSN, login, and
password.
• A server project source enables you to connect to the

metadata in three-tier mode using an Intelligence Server.
• You use the Project Source Manager to create a project

source.
• A database instance is the configuration object in

MicroStrategy Desktop that enables you to connect to the
data warehouse. It consists of a database connection,
which uses a specific DSN and database login.

• You use the Database Instances manager to create a

database instance and database connection inside a
project source.
• The following basic schema objects are essential to a

project: tables, facts, attributes, and user hierarchies.
• You create schema objects using the project creation

workflow. The recommended workflow includes the
following tasks: add project tables, create facts, create
attributes and relationships, and create user hierarchies.
• The project schema consists of all the schema objects in a

project.
• When you make any changes to schema objects, you have

to update the project schema.
• MicroStrategy Architect has three types of interfaces for

defining projects and creating schema objects: the Project
Creation Assistant, schema object editors, and Architect
graphical interface.
• The Project Creation Assistant is a collection of wizards

that provides a step-by-step approach to project creation.
It is the primary tool for bulk project creation.
• The schema object editors in MicroStrategy Architect

enable you to create and modify individual schema objects
one at a time and provide access to more advanced
functions for creating more complex schema objects.
• The Architect graphical interface provides a more visual,

freeform approach to working on projects. This
consolidated interface enables you to access a variety of
functions for fine-tuning projects.

5
WORKING WITH TABLES
Lesson Description
This lesson describes how to work with tables when creating a

project in MicroStrategy Architect.
In this lesson, you will learn how tables are used in a

MicroStrategy project. Then, you will learn how to select the
tables for a project using the Warehouse Catalog. Finally, you
will learn how to view information about project tables using
the Logical Table Editor.

5 Working with Tables MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe how tables are used in a MicroStrategy project,
select project tables using the Warehouse Catalog, and view
information for project tables using the Logical Table Editor.
• Describe how tables are used in a MicroStrategy project

and explain the difference between physical and logical
tables. (Page 157)
• Select project tables using the Warehouse Catalog.

(Page 160)
• View information for project tables using the Logical Table

Editor. (Page 171)

MicroStrategy Architect: Project Design Essentials Working with Tables 5
What Is a Project Table?

Describe how tables are used in a MicroStrategy project and
explain the difference between physical and logical tables.
In the previous lesson, you learned in detail how to configure

the metadata and project connectivity and update the project
schema. However, you learned about the task of creating
schema objects only at a high level. Now, you are ready to
learn about the details of creating the basic schema objects
you use in a project. You create schema objects using the
project creation workflow:
The first task in the project creation workflow is to add tables

to your MicroStrategy project. You can have any number of
tables in your data warehouse, but the tables you actually
select to use in a project are called project tables. Project
tables are the only tables in the data warehouse that
MicroStrategy uses in the reporting environment. It
effectively ignores any other tables that are present.
You can choose to include all the tables in your data

warehouse in a project, or you can select only a subset of
tables. The tables you select for the project are the tables
users can access when executing reports.
© 2011 MicroStrategy, Inc. What Is a Project Table? 157

Physical Tables Versus Logical Tables

When you select a physical table from the data warehouse to
include in a project, MicroStrategy Architect automatically
creates a corresponding logical table in the metadata. For
example, if you choose to include the LU_CUSTOMER table
in the project, you have a corresponding LU_CUSTOMER
table in the metadata.
Physical tables store the actual data, and the MicroStrategy

Engine executes report SQL against these tables to obtain
result sets. Logical tables store information about their
corresponding physical tables, including table names,
column names and data types, and schema objects associated
with the table columns. The Engine uses the logical tables to
generate the appropriate report SQL.
The following illustration shows the physical and logical

tables for the LU_CUST_STATE table:
Physical and Logical Tables—LU_CUST_STATE
158 What Is a Project Table? © 2011 MicroStrategy, Inc.

The LU_CUST_STATE physical table contains the

CUST_STATE_ID, CUST_STATE_NAME, and
CUST_REGION_ID columns. The corresponding
LU_CUST_STATE logical table has both a physical and
logical view. The physical view displays these same columns
and their data types. The logical view shows the attributes in
the project that are mapped to the table columns. Both views
show the name of the data warehouse table to which the
logical table maps.
For more information on the Logical Table Editor, see

“Using the Logical Table Editor” starting on page 171.
© 2011 MicroStrategy, Inc. What Is a Project Table? 159

Using the Warehouse Catalog

Select project tables using the Warehouse Catalog.
The Warehouse Catalog enables you to select the tables you

want to include in a MicroStrategy project. You can access the
Warehouse Catalog as part of the Project Creation Assistant
when you first create a project. You can also launch the
Warehouse Catalog directly from the Schema menu in
MicroStrategy Desktop to select tables for an existing project.
To access the Warehouse Catalog from the Project Creation

Assistant:
1 In MicroStrategy Desktop, open the Project Creation

Assistant.
2 In the Project Creation Assistant, create the project object.
You have to create the project object before you can

select the database instance and project tables.
3 In the Project Creation Assistant, click Select tables from

the Warehouse Catalog.
4 In the Warehouse Database Instance window, in the

drop-down list, select the database instance you want to
use for the project.
MicroStrategy Architect retrieves the list of

available tables from the database that corresponds
to the database instance you select. This database
instance is the primary data source for the project.
5 Click OK.
160 Using the Warehouse Catalog © 2011 MicroStrategy, Inc.

The following image shows where you access the Warehouse

Catalog in the Project Creation Assistant:
Accessing the Warehouse Catalog from the Project
Creation Assistant
© 2011 MicroStrategy, Inc. Using the Warehouse Catalog 161

The following image shows the Warehouse Database Instance

window:
Warehouse Database Instance Window
To access the Warehouse Catalog directly from the Schema

menu in MicroStrategy Desktop:
1 In MicroStrategy Desktop, open the desired project.
2 On the Schema menu, select Warehouse Catalog.
3 If you have not yet selected the database instance for the
project, in the Warehouse Database Instance window, in
the drop-down list, select the database instance you want
to use for the project.
MicroStrategy Architect retrieves the list of

available tables from the database that corresponds
to the database instance you select. This database
instance is the primary data source for the project.
The Warehouse Database Instance window does

not display if you have previously selected the
database instance for the project. Instead, the
Warehouse Catalog displays immediately.
4 Click OK.

The following image shows the option for accessing the

Warehouse Catalog from the Schema menu:
Accessing the Warehouse Catalog from the Schema Menu
The following image shows the Warehouse Catalog:

Warehouse Catalog

The Warehouse Catalog has the following components:
• Select current database instance drop-down list—This

drop-down list enables you to select the database instance
for which you want to view available tables. By default, it
displays the primary database instance for the project.
Ayouproject can use secondary database instances if

have MicroStrategy MultiSource Option. For
information on using MultiSource Option, see the
course.
• Tables available in the database instance list—This list

displays the tables that are available in the selected
database instance. If you have already added a table to the
project, it does not display in this list.
• Tables being used in the project list—This list displays

the tables you are currently using in the project.
When the Warehouse Catalog opens, MicroStrategy Architect

queries the system catalog of the database associated with the
selected database instance to retrieve a list of all tables and
columns. From this list, you select which tables you want to
include in the project. The tables you select form the project’s
unique warehouse catalog.
The Warehouse Catalog has settings that enable you to

configure various aspects of its behavior. You can also
customize the SQL statement MicroStrategy Architect
uses to retrieve the list of tables and columns. For
information on Warehouse Catalog settings, see the
course.

Adding Tables to a Project

You can use the Warehouse Catalog to add tables to a project
as part of the initial project creation, or you can use it to add
tables to an existing project.
To add tables to a project using the Warehouse Catalog:
1 Open the Warehouse Catalog.
2 In the Warehouse Catalog, in the Select current database

instance list, select the database instance from which you
want to add tables.
3 Do one of the following:
If you want to add all the available tables, click the >>
button to add the tables to the Tables being used in the
project list.
OR
If you want to add selected tables, hold CTRL and select

the tables you want to add.
Click the > button to add the tables to the Tables being
used in the project list.
4 Click Save and Close.
After closing the Warehouse Catalog, you can

update the project schema if desired.

The following image shows the Warehouse Catalog with

selected lookup and fact tables added to a project:
Warehouse Catalog—Lookup and Fact Tables Added to
Project

When you add tables to a project, MicroStrategy Architect

automatically creates the corresponding logical tables. These
logical tables are stored in the Schema Objects\Tables folder,
as shown in the following image:
Logical Tables

Removing Tables from a Project

You can use the Warehouse Catalog to remove tables from a
project.
To remove tables from a project using the Warehouse Catalog:
1 Open the Warehouse Catalog.
2 In the Warehouse Catalog, in the Tables being used in the

project list, do one of the following:
If you want to remove all the project tables, click the <<
button to move the tables to the Tables available in the
database instance list.
OR
If you want to remove selected tables, hold CTRL and

select the tables you want to remove.
Click the < button to move the tables to the Tables

available in the database instance list.
After closing the Warehouse Catalog, you can


When you save and close the Warehouse Catalog, it displays a

warning if you are removing a table that has dependent
objects. For example, if you remove a table that has a fact
mapped to one of its columns, the fact is dependent on that
table. The following image shows this warning:
Warning for Dependent Objects
In this example, the CITY_CTR_SLS table has one or more

dependent objects. You can respond to this warning by either
choosing to proceed with the changes and remove the table
from the project, or you can keep the specified table in the
project. If multiple tables have dependent objects, each table
is listed in the warning message.
If you choose to continue removing the table and doing so

leaves dependent objects in an invalid state, the Warehouse
Catalog displays the following warning:
Warning for Invalid Objects

In this example, the Revenue fact will have an invalid

definition if you remove the associated table. You invalidate
an object when you remove a table if that table is the only
table to which the object is mapped. To continue removing
the table, you have to delete the invalid object first.
Alternatively, you can choose to keep the table in the project.
Ifmayyouhave
choose to delete an invalid object, that object
other objects that are dependent on it. You
cannot delete objects that have dependencies without
first removing those dependent associations. For
example, a fact may be used in a metric definition.
Before you can delete the fact, you have to either delete
the metric or remove the fact from its definition.

Using the Logical Table Editor

View information for project tables using the Logical Table
Editor.
The Warehouse Catalog is the primary tool you use to add

and remove tables within a project. However, if you want to
view the definition of project tables, you use the Logical Table
Editor. The Logical Table Editor is one of the schema object
editors available in MicroStrategy Architect. It enables you to
view logical and physical information for tables and configure
a variety of table-related settings.
The logical view of a table displays the attributes and facts

that are mapped to columns in the table. The physical view of
a table displays the columns and data types of the
corresponding physical table in the data warehouse.
To view information for a project table:
1 Open the desired project.
2 In the Schema Objects folder, select the Tables folder.
3 In the Tables folder, double-click the table for which you

want to view information.
4 In the Logical Table Editor, do one of the following:
If you want to view logical information for the table, on

the Logical View tab, view the schema objects mapped to
the table.
OR
If you want to view physical information for the table,

click the Physical View tab.
On the Physical View tab, view the columns and data

types contained in the table.
© 2011 MicroStrategy, Inc. Using the Logical Table Editor 171

The following image shows the Logical View tab on the

Logical Table Editor:
Logical Table Editor—Logical View Tab
Three attributes and five facts are mapped to the

STATE_REGION_MNTH_SLS table.
Ifbefore
you view a project table in the Logical Table Editor
you create facts and attributes, the logical view
is empty. The logical view is populated with
information only when you have at least one fact or
attribute created and mapped to the table.
172 Using the Logical Table Editor © 2011 MicroStrategy, Inc.

The following image shows the Physical View tab on the

Logical Table Editor:
Logical Table Editor—Physical View Tab
The STATE_REGION_MNTH_SLS table contains seven

columns. You can see the name and data type for each
column.
© 2011 MicroStrategy, Inc. Using the Logical Table Editor 173


Exercises: Working with Tables
In this set of exercises, you will add fact and lookup tables to
the My Tutorial Project that you created in the previous
exercises.
Adding Fact Tables to the Project
Overview
In this exercise, you will use the Warehouse Catalog to add

fact tables to the My Tutorial Project. You should select
Tutorial Data as the database instance for the project. Then,
you need to add the following fact tables to the project:
Fact Table Name
CITY_CTR_SLS
CITY_MNTH_SLS
CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
INVENTORY_ORDERS
ITEM_CCTR_MNTH_SLS
ITEM_EMP_SLS
ITEM_MNTH_SLS
MNTH_CATEGORY_SLS
ORDER_DETAIL
ORDER_FACT
QTR_CATEGORY_SLS
174 Exercises: Working with Tables © 2011 MicroStrategy, Inc.

Fact Table Name
STATE_REGION_MNTH_SLS
STATE_SUBCATEG_MNTH_SLS
STATE_SUBCATEG_REGION_SLS
SUBCATEG_MNTH_CTR_SLS
YR_CATEGORY_SLS
After you have added these fact tables, keep the Warehouse
Catalog open and continue to the next exercise to add lookup
tables to the project.
Open the Warehouse Catalog for the My Tutorial Project
1 In the My Tutorial Project Source, open the My Tutorial

Project.
2 On the Schema menu, click Warehouse Catalog.
Select Tutorial Data as the database instance
3 In the Warehouse Database Instance window, in the

drop-down list, select Tutorial Data as the database
instance for the project.
4 Click OK.
5 In the Warehouse Catalog, in the Select current database

instance list, ensure that Tutorial Data is selected.
© 2011 MicroStrategy, Inc. Exercises: Working with Tables 175

Add fact tables to the project
6 In the Tables available in the database instance list, hold

CTRL and select the following tables:
Fact Table Name
CITY_CTR_SLS
CITY_MNTH_SLS
CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
INVENTORY_ORDERS
ITEM_CCTR_MNTH_SLS
ITEM_EMP_SLS
ITEM_MNTH_SLS
MNTH_CATEGORY_SLS
ORDER_DETAIL
ORDER_FACT
QTR_CATEGORY_SLS
YR_CATEGORY_SLS
7 Click the > button to add the tables to the Tables being
8 Keep the Warehouse Catalog open and continue to the

next exercise to add lookup tables to the project.

Adding Lookup Tables to the Project
Overview
In this exercise, you will use the Warehouse Catalog to add

lookup tables to the My Tutorial Project. Using the Tutorial
Data database instance, you need to add the following lookup
tables to the project:
Lookup Table Name
LU_BRAND
LU_CALL_CTR
LU_CATALOG
LU_CATEGORY
LU_COUNTRY
LU_CUST_CITY
LU_CUST_REGION
LU_CUST_STATE
LU_CUSTOMER
LU_DAY
LU_DIST_CTR
LU_EDUCATION
LU_EMPLOYEE
LU_GENDER
LU_INCOME
LU_ITEM
LU_MANAGER
LU_MONTH
LU_MONTH_OF_YEAR
LU_PYMT_TYPE
LU_QUARTER
LU_REGION

Lookup Table Name
LU_SHIPPER
LU_SUBCATEG
LU_SUPPLIER
LU_YEAR
REL_CAT_ITEM
For most attributes relationships, lookup tables serve

as both lookup and relationship tables. However, one
attribute relationship that you will create requires a
distinct relationship table REL_CAT_ITEM to be
added to the project.
After you have added these lookup tables, save and close the
Warehouse Catalog and update the project schema.
Add lookup tables to the project
1 In the Warehouse Catalog, in the Tables available in the

database instance list, hold CTRL and select the following
tables:
Lookup Table Name
LU_BRAND
LU_CALL_CTR
LU_CATALOG
LU_CATEGORY
LU_COUNTRY
LU_CUST_CITY
LU_CUST_REGION
LU_CUST_STATE

Lookup Table Name
LU_CUSTOMER
LU_DAY
LU_DIST_CTR
LU_EDUCATION
LU_EMPLOYEE
LU_GENDER
LU_INCOME
LU_ITEM
LU_MANAGER
LU_MONTH
LU_MONTH_OF_YEAR
LU_PYMT_TYPE
LU_QUARTER
LU_REGION
LU_SHIPPER
LU_SUBCATEG
LU_SUPPLIER
LU_YEAR
REL_CAT_ITEM
2 Click the > button to add the tables to the Tables being
Save and close the Warehouse Catalog

Update the project schema

Update Schema.
5 In the Update Schema window, ensure the following

check boxes are selected:
• Update schema logical information
• Recalculate table keys and fact entry levels
• Recalculate table logical sizes
6 Click Update.

Lesson Summary
• The first task in the project creation workflow is to add
tables to a MicroStrategy project.
• The tables you select to use in a project are called project

tables. Project tables are the only tables in the data
warehouse that MicroStrategy uses in the reporting
environment.
• When you select a physical table from the data warehouse

to include in a project, MicroStrategy Architect
automatically creates a corresponding logical table in the
metadata.
• Physical tables store the actual data, and the
MicroStrategy Engine executes report SQL against these
tables to obtain result sets.
• Logical tables store information about their

corresponding physical tables, including table names,
column names and data types, and schema objects
associated with the table columns. The MicroStrategy
Engine uses these tables to generate the appropriate
report SQL.
• You can use the Warehouse Catalog to select the tables

you want to include in a project.
• You can access the Warehouse Catalog as part of the

Project Creation Assistant, or you can launch it directly
from the Schema menu in MicroStrategy Desktop.
• When you open the Warehouse Catalog, MicroStrategy

Architect queries the system catalog of the database
associated with the selected database instance to retrieve
a list of all tables and columns.
• The tables you select to include in a project form the

project’s warehouse catalog.
• You can use the Warehouse Catalog to add tables to a

project or remove tables from a project.
• Logical tables are stored in the Schema Objects\Tables

folder.

• The Warehouse Catalog warns you if you try to remove a

table that has dependent objects or leaves dependent
objects in an invalid state.
• You use the Logical Table Editor to view information for

project tables.
• The logical view of a logical table displays the attributes

and facts mapped to columns in the table.
• The physical view of a logical table displays the columns

and data types of the corresponding physical table in the
data warehouse.

6
WORKING WITH FACTS
Lesson Description
This lesson describes how to work with facts when creating a

project in MicroStrategy Architect.
In this lesson, you will learn how facts are used in a

MicroStrategy project. Then, you will learn about different
types of facts. Finally, you will learn how to create and modify
facts using the Fact Creation Wizard and Fact Editor.

6 Working with Facts MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe how facts are used in a MicroStrategy project,
explain the different types of facts and fact expressions,
create and modify basic and complex facts using the Fact
Creation Wizard and Fact Editor.
• Describe how facts are used in a MicroStrategy project.

(Page 185)
• Explain the difference between homogeneous and

heterogeneous facts and simple and derived fact
expressions. (Page 188)
• Create basic facts using the Fact Creation Wizard.

(Page 193)
• Create and modify basic and complex facts using the Fact
Editor. (Page 201)

MicroStrategy Architect: Project Design Essentials Working with Facts 6
What Is a Fact?

Describe how facts are used in a MicroStrategy project.
In the previous lesson, you learned how to select the tables

for a MicroStrategy project, which is the first task in the
project creation workflow as shown in the following image:
The second task in the project creation workflow is to create

the facts for your MicroStrategy project. You create facts
based on your logical data model and map them to columns
in the data warehouse schema. You then use facts to define
metrics. As such, the fact schema object serves as a bridge
between fact values stored in the data warehouse and the
metrics users want to see on MicroStrategy reports. Facts
point to the appropriate physical columns in the data
warehouse, while metrics perform aggregations on those
columns.
© 2011 MicroStrategy, Inc. What Is a Fact? 185

The existence of facts at the application level enables you to

create a layer of abstraction between the underlying structure
of your data warehouse and the metrics users require on
reports. Consider the following example:
Sales Fact Layer of Abstraction
In the data warehouse, the Sales fact exists in both the

FACT_SALES and FACT_SALES_AGG tables. However, it is
stored in these tables using different column
names—Dollar_Sales and Revenue. Depending on which
table you need to query for a report, you either need to
aggregate the Dollar_Sales column or the Revenue column.
The optimal table to use for a query varies based on the
attributes used in the report.
You can define the Sales fact to map to both columns in both
tables. That way, the MicroStrategy Engine can use a single
fact to access either table. You then use this Sales fact to
define the Sales metric. Because of the existence of the Sales
fact, users can access any table that contains sales data using
a single metric. Without the Sales fact, you would need to
create two metrics—one defined as SUM(Dollar_Sales) and
one defined as SUM(Revenue). Then, users would have to
know which metric to use on a report to access the
appropriate table.
The Sales fact creates a layer of abstraction that makes the

discrepancies in how the columns are named in the data
warehouse transparent to users. For users, sales are sales,
regardless of the column name used to identify them.
186 What Is a Fact? © 2011 MicroStrategy, Inc.

The layer of abstraction created by facts provides the

following benefits:
• Report developers and end users do not need to

understand the structure of the data warehouse.
• The data warehouse can contain fact columns with

different names that store the same data.
• You do not have to resolve discrepancies in the data

warehouse to make reporting on such data seamless for
users.
© 2011 MicroStrategy, Inc. What Is a Fact? 187

Types of Facts

Explain the difference between homogeneous and
heterogeneous facts and simple and derived fact expressions.
Before you learn how to create facts in MicroStrategy

Architect, you need to understand the different types of facts
and fact expressions that exist. There are two primary types
of facts:
• Homogeneous
• Heterogeneous
The following topics describe both of these types of facts in

more detail.
Homogeneous Facts
You associate facts to columns in data warehouse tables. You
can map the same fact to any number of tables. A
homogeneous fact is one that points to the same column or
set of columns in every table to which it maps.
188 Types of Facts © 2011 MicroStrategy, Inc.

The following illustration shows an example of a

homogeneous fact:
Homogeneous Fact
The Sales fact maps to three different tables—ITEM_SALES,

CATEGORY_SALES, and CUSTOMER_SALES. However, it
is a homogeneous fact because it maps to the same
Dollar_Sales column in each table.
Heterogeneous Facts
Whereas a homogenous fact always maps to the same column
or set of columns, a heterogeneous fact is one that points to
two or more different columns or sets of columns in the
tables to which it maps.
© 2011 MicroStrategy, Inc. Types of Facts 189


heterogeneous fact:
Heterogeneous Fact
The Sales fact maps to three different tables—ITEM_SALES,

CATEGORY_SALES, and CUSTOMER_SALES. However, in
the first two tables, it maps to the Dollar_Sales column, but
in the third table, it maps to the Revenue column. Therefore,
it is a heterogeneous fact because it maps to two different
columns.
Types of Fact Expressions

A fact expression consists of a column or set of columns to
which the fact maps. All facts have at least one expression.
However, facts can have any number of expressions. There
are two primary types of fact expressions:
• Simple
• Derived
The following topics describe both of these types of fact

expressions in more detail.

Simple Fact Expressions
A simple fact expression is one that maps directly to a single

fact column. It can map to that same column for any number
of tables.
The following illustration shows an example of a simple fact

expression:
Simple Fact Expression
The Sales fact maps directly to the Dollar_Sales column in

the ITEM_SALES table, creating a simple fact expression.
Derived Fact Expressions
A derived fact expression is one that maps to an expression

from which the fact values are obtained. A derived fact
expression can contain multiple fact columns from the same
table, mathematical operators, numeric constants, and
various functions.
Ifdatabase
you want to combine fact columns from different
tables in a derived fact expression, you have
to create a logical view. For information on logical
views, see the MicroStrategy Advanced Data
Warehousing course.
MicroStrategy provides a variety of out-of-the-box

functions that you can use in defining fact expressions,
including passthrough functions that enable you to
pass SQL statements directly to the data warehouse.
For information on using advanced functions to define
facts, see the MicroStrategy Architect: Advanced
Project Design course.
© 2011 MicroStrategy, Inc. Types of Facts 191

The following illustration shows an example of a derived fact

expression:
Derived Fact Expression
The Sales fact maps to an expression that combines the

Unit_Price and Quantity_Sold columns in the ITEM_SALES
table, creating a derived fact expression.
MicroStrategy Architect enables you to create derived

fact expressions at the application level. However, you
can also store derived fact columns at the database
level. The advantage of using derived fact columns in
the data warehouse is that the calculation is performed
ahead of time during the ETL process and the result is
stored as a single column. This method translates into
simpler report SQL and better performance. If you
implement a derived fact expression at the application
level, the calculation has to be performed each time
you process a query that uses that fact.

Using the Fact Creation Wizard

Create basic facts using the Fact Creation Wizard.
The Fact Creation Wizard enables you to create multiple facts

very quickly. You generally use it during initial project
creation when you are creating the majority of facts for a
project, but you can use it any time you need to create a large
number of facts. However, you are limited to creating basic
facts using this tool. Basic facts are ones that are
homogeneous and use only simple fact expressions. You can
sometimes begin defining more complex facts in the Fact
Creation Wizard. However, if you need to create
heterogeneous or derived expressions for the fact, you have to
use the Fact Editor to complete its definition.
The Fact Editor also enables you to change various fact

properties, such as column aliases and level
extensions, that you cannot access from the Fact
Creation Wizard. For more information on the Fact
Editor, see “Using the Fact Editor” starting on
page 201.
You can access the Fact Creation Wizard as part of the Project
Creation Assistant when you first create a project. You can
also launch the Fact Creation Wizard directly from the
Schema menu in MicroStrategy Desktop to create facts for an
existing project.
To access the Fact Creation Wizard from the Project Creation

Assistant:

Assistant.
© 2011 MicroStrategy, Inc. Using the Fact Creation Wizard 193

3 Select the database instance and tables for the project.
You have to create the project object and select the

database instance and project tables before you can
create facts.
4 Click Create facts.
The following image shows where you access the Fact

Creation Wizard in the Project Creation Assistant:
Accessing the Fact Creation Wizard from the Project
Creation Assistant
To access the Fact Creation Wizard directly from the Schema

menu in MicroStrategy Desktop:
2 On the Schema menu, select Fact Creation Wizard.
194 Using the Fact Creation Wizard © 2011 MicroStrategy, Inc.

The following image shows the option for accessing the Fact
Creation Wizard from the Schema menu:
Accessing the Fact Creation Wizard from the Schema
Menu
The following image shows the Introduction window for the

Fact Creation Wizard:
Fact Creation Wizard—Introduction Window

Defining Fact Creation Rules

The Introduction window of the Fact Creation Wizard
enables you to define the rules that govern how the wizard
works. First, you can select which column data types the Fact
Creation Wizard displays as possible fact columns. By
default, it displays only numeric columns since facts are
generally numeric. However, if you have fact columns with
other data types, you can select those other data types.
Second, you can choose how the Fact Creation Wizard
renames fact columns as fact objects.
To define rules for the Fact Creation Wizard:
1 In the Fact Creation Wizard, in the Introduction window,

click Define Rules.
2 In the Fact Creation Rules window, under Column data

type, select the check boxes for the data types you want to
display in the Fact Creation Wizard.
3 Under Fact name, if you want to replace underscores in

column names with spaces, ensure that the Replace
underscores in fact name with spaces check box is
selected.
4 If you want to capitalize the first letter of each word in fact

names, ensure that the First letter in upper case check
box is selected.
5 Click OK.

The following image shows the Fact Creation Rules window:

Fact Creation Rules Window
Creating Facts
You can use the Fact Creation Wizard to create facts as part of
the initial project creation. You can also use it to create
multiple facts in an existing project at any point in time.
You cannot use the Fact Creation Wizard to modify

existing facts.

After you define the rules for the Fact Creation Wizard, you
can proceed to the Column Selection window where you
actually create facts. The following image shows this window:
Fact Creation Wizard—Column Selection Window
The Column Selection window of the Fact Creation Wizard

has the following components:
• Available columns list—This list displays the available

columns in the project tables that match the selected data
types based on the rules you define. It shows a distinct list
of columns across all project tables.
Columns that you have already used to define a fact

do not display in this list.
• Facts list—This list displays the facts you are creating in

the project.
When the Column Selection window of the Fact Creation

Wizard opens, MicroStrategy Architect retrieves a list of all
the columns in project tables that match the selected data
types. From this list, you select which columns you want to
use as facts.

To create facts using the Fact Creation Wizard:
The following procedure assumes you have already

opened the Fact Creation Wizard and made any
necessary changes to the fact creation rules.

click Next.
2 In the Column Selection window, in the Available

columns list, hold CTRL and select the columns you want
to use as facts.
3 Click the > button to add the columns to the Facts list.
This action automatically renames the columns as

fact objects based on the rules you define. If you
want to modify a fact name, in the Facts list,
right-click the fact and select Rename.
Iffactyouandwantclicktotheremove a fact from the list, select the

< button to move the
corresponding column to the Available columns
list.
4 Click Next.
5 In the Finish window, review the list of facts you are

creating.
6 Click Finish.
After the Fact Creation Wizard closes, you can


The following image shows the Fact Creation Wizard with

selected facts created in a project:
Fact Creation Wizard—Facts Created in Project
When you create facts in a project, they are stored in the

Schema Objects\Facts folder, as shown in the following
image:
Facts

Using the Fact Editor

Create and modify basic and complex facts using the Fact
Editor.
The Fact Creation Wizard is the primary tool for mass

creation of basic facts. However, if you want to create
individual facts, modify existing facts, or add complexity to
facts you initially created in the Fact Creation Wizard, you
use the Fact Editor. The Fact Editor is one of the schema
object editors available in MicroStrategy Architect. It enables
you to create or modify any type of fact or fact expression and
configure a variety of fact-related settings.
To access the Fact Editor:
If you are creating a new fact, on the File menu, point to

New and select Fact.
OR
If you are modifying an existing fact, in the Schema

Objects folder, select the Facts folder.
In the Facts folder, double-click the fact you want to

modify.
© 2011 MicroStrategy, Inc. Using the Fact Editor 201

The following image shows the Fact Editor:

Fact Editor
The Fact Editor has the following tabs:
• Definition—This tab enables you to create, modify, and

delete fact expressions.
• Column Alias—This tab enables you to modify the

column alias for a fact.
• Extensions—This tab enables you to create, modify, and

delete level extensions for a fact.
All facts have a definition and column alias, but level

extensions for facts are optional. This lesson focuses on tasks
you perform using the first two tabs.
Most facts do not have level extensions. You create

them to resolve specific reporting scenarios. For
information on level extensions, see the MicroStrategy
202 Using the Fact Editor © 2011 MicroStrategy, Inc.

Creating Facts
You can use the Fact Editor to create simple or derived fact
expressions. You can also create heterogeneous facts that
have multiple expressions.
To create a simple fact expression using the Fact Editor:
1 Open the Fact Editor.
2 In the Fact Editor, in the Create New Fact Expression

window, in the Source table drop-down list, select the
desired table.
The source table is any logical table that contains

the column you want to use for the fact expression.
3 In the Available columns list, drag the column you want to

map to the fact to the Fact expression box.
You can also double-click the column to add it to

the Fact expression box.
4 Under Mapping method, select the desired method for

mapping the column to the fact.
With automatic mapping, MicroStrategy Architect

scans the project tables and maps all tables that
contain the column to the fact as source tables.
With manual mapping, MicroStrategy Architect
still locates the project tables that contain the
column, but you have to manually select the ones
you want to use as source tables for the fact.
Automatic mapping makes project maintenance

easier. However, some scenarios require manual
mapping. For example, if the same column does
not contain the same data across different project
tables, you must use manual mapping.

5 Click OK.
6 In the Fact Editor, do one of the following:
If you selected automatic mapping for the fact

expression, continue to step 7.
OR
If you selected manual mapping for the fact expression,

on the Definition tab, in the Source tables list, select the
check box for each table to which you want to map the
fact.
After closing the Fact Editor, you can update the

project schema if desired.
The following image shows the Create New Fact Expression

window:
Create New Fact Expression Window

The following image shows the Fact Editor with a simple

expression for the Gross Revenue fact:
Fact Editor—Simple Expression
To create a derived fact expression using the Fact Editor:

desired table.

the columns you want to use for the fact
expression.
3 In the Available columns list, drag the columns you want

to use in the expression to the Fact expression box.
You can also double-click the columns to add them

to the Fact expression box.

4 In the Fact expression box, complete the derived

expression as appropriate.
You can use the toolbar above the box to insert

parentheses, mathematical operators, or other
functions. You can also type information directly in
the box.

mapping the expression to the fact.
6 Click OK.

OR

fact.


The following image shows the Fact Editor with a derived

expression for the Enrollment Length fact:
Fact Editor—Derived Expression
To create a heterogeneous fact using the Fact Editor:

desired table.

to use in the expression to the Fact expression box.
4 In the Fact expression box, complete the expression as

appropriate.

mapping the expression to the fact.
6 Click OK.


expression, on the Definition tab, click New.
OR

fact.
Click New.
8 Repeat steps 2 to 7 for each fact expression you want to

create.
9 When you have created all the expressions for the fact,
click Save and Close.

The following image shows the Fact Editor with multiple

expressions for the heterogeneous Revenue fact:
Fact Editor—Heterogeneous Fact

Modifying Facts
You can also use the Fact Editor to modify existing facts. You
can perform the following tasks:
• Create new fact expressions
• Modify existing fact expressions, including mapping

methods and source tables
• Delete existing fact expressions
• Modify column aliases
The following topics describe how to perform each of these

tasks.
Creating New Fact Expressions
You can create new fact expressions for existing facts. Often,
you may be able to create the first expression for a fact in the
Fact Creation Wizard, but you have other expressions you
must create in the Fact Editor.
To create a new fact expression for an existing fact using the

Fact Editor:
1 Open the fact in the Fact Editor.
2 In the Fact Editor, on the Definition tab, click New.
3 In the Create New Fact Expression window, define the

new fact expression.
4 Click OK.
5 In the Fact Editor, click Save and Close.


Modifying Existing Fact Expressions
You can also modify existing fact expressions for facts. You
can change the actual expressions, mapping methods, and
source tables.
To modify an existing fact expression for a fact using the Fact

Editor:
2 In the Fact Editor, on the Definition tab, in the Fact

expressions list, select the fact expression you want to
modify.
3 Click Modify.
4 In the Modify Fact Expression window, modify the fact

expression as desired.
You can change the expression or mapping

method.
5 Click OK.
6 In the Fact Editor, on the Definition tab, in the Source

tables list, modify the source tables if desired.


The following image shows the Modify Fact Expression

window:
Modify Fact Expression Window
Deleting Existing Fact Expressions
You can also delete existing fact expressions for facts if you
no longer need them.
To delete an existing fact expression for a fact using the Fact

Editor:
2 In the Fact Editor, on the Definition tab, in the Fact

expressions list, select the fact expression you want to
delete.
3 Click Delete.


Modifying Column Aliases
You can also modify column aliases for existing facts. Every
fact you create has a default column alias, regardless of the
type or number of expressions you define for it. The column
alias specifies the data type that the MicroStrategy Engine
uses for a fact when it generates SQL for temporary tables.
By default, a fact inherits its data type from the column on

which it is defined. Therefore, if you map a fact to a column
called QTY_SOLD that uses an Integer data type,
MicroStrategy Architect automatically creates a
corresponding column alias called QTY_SOLD with an
Integer data type.
If a fact maps only to a derived expression, MicroStrategy

Architect creates a custom column alias. Custom column
aliases use the naming convention CustCol_<n> where
“Cust” stands for custom, “Col” stands for column, and n is a
number. The first custom column alias MicroStrategy
Architect creates in a project is CustCol_1, the next
CustCol_2, and so forth.
Since the column alias name is used in any SQL that

the MicroStrategy Engine generates, you can change
the name of custom column aliases to make them
more meaningful. Having column alias names that
correlate to underlying fact names can be useful when
troubleshooting the SQL for complex reports.
If you define a fact using multiple expressions, the column

alias uses the column name and data type of the first
expression you create.
Ifexpression,
the first expression you create is a derived
MicroStrategy Architect creates a custom
column alias as described above.
Most of the time, you do not need to modify the column alias.
However, there are specific scenarios in which you may need
to change the default data type. For example, you could create
a fact defined as the difference between two dates, such as a
start date and expire date. This fact has the following
expression:
[EXPIRE_DATE] - [START_DATE]

The column alias for this fact automatically uses a

TimeStamp data type because the EXPIRE_DATE and
START_DATE columns use the TimeStamp data type.
However, the result of the expression (the difference between
the two dates) produces an integer.
The difference in data types can cause problems when the

MicroStrategy Engine needs to insert values for this fact into
a temporary table. The Engine uses a TimeStamp data type to
define this fact column in the temporary table and then tries
to insert integer numbers into the column. While this may
not be a problem for some database platforms, it can cause an
error. To eliminate the conflicting data types, you can modify
the column alias for the fact to change the data type from
TimeStamp to Integer.
To modify the column alias for an existing fact using the Fact
Editor:
2 In the Fact Editor, click the Column Alias tab.
3 On the Column Alias tab, click Modify.
4 In the Column Editor - Column Selection window, do one

of the following:
If you want to modify the default column alias, in the

Available columns list, select the default column alias.
You can only change the properties of custom

column aliases.
Click Modify.
OR
If you want to create and assign a new column alias, click

New.
5 In the Column Editor - Definition window, in the Column

name box, type the name for the column alias.
Ifalready
you are modifying a custom column alias, it
has a name, but you can change the name.

6 In the Data type box, select the data type you want to use.
7 Configure the data type as appropriate.
Depending on the data type you select, you may

need to configure the precision, scale, byte length,
bit length, or time scale.
8 Click OK.
9 In the Column Editor - Column Selection window, click

OK.

The following image shows the Column Alias tab on the Fact
Editor:
Fact Editor—Column Alias Tab

The following image shows the Column Editor - Column

Selection window:
Column Editor - Column Selection Window
The following image shows the Column Editor - Definition

window:
Column Editor - Definition Window


Exercises: Working with Facts
In this set of exercises, you will create facts in the My Tutorial
Project. You will also modify some of these facts to add more
complexity to them.
Creating Facts in the Project
Overview
In this exercise, you will use the Fact Creation Wizard to

create facts in the My Tutorial Project. You need to create the
following facts:
You do not need to modify the default fact creation

rules since all these columns are numeric.
Expression Fact Name
DISCOUNT Discount
FREIGHT Freight
GROSS_DOLLAR_SALES Gross Revenue
TOT_COST Cost
TOT_DOLLAR_SALES Revenue
TOT_UNIT_SALES Units Sold

UNIT_COST Unit Cost
UNIT_PRICE Unit Price
UNITS_RECEIVED Units Received
You need to rename the Gross Revenue, Cost, Revenue,

and Units Sold facts to match the names in the table above.
216 Exercises: Working with Facts © 2011 MicroStrategy, Inc.

After you have created these facts, save and close the Fact
Creation Wizard and update the project schema.
Open the Fact Creation Wizard for the My Tutorial Project

Project.
2 On the Schema menu, select Fact Creation Wizard.
Create facts in the project

click Next.
4 In the Column Selection window, in the Available

columns list, hold CTRL and select the following fact
columns:
Fact Column
DISCOUNT
FREIGHT
GROSS_DOLLAR_SALES
TOT_COST
TOT_DOLLAR_SALES
TOT_UNIT_SALES
UNIT_COST
UNIT_PRICE
UNITS_RECEIVED
5 Click the > button to add the columns to the Facts list.
© 2011 MicroStrategy, Inc. Exercises: Working with Facts 217

Rename selected facts
6 In the Facts list, right-click the following facts, select

Rename, and rename the facts as follows:
Original Fact Name New Fact Name
Gross Dollar Sales Gross Revenue
Tot Cost Cost

Tot Dollar Sales Revenue
Tot Unit Sales Units Sold
Save and close the Fact Creation Wizard
7 Click Finish.

Update Schema.
9 In the Update Schema window, ensure the following

check boxes are selected:
• Update schema logical information
• Recalculate table keys and fact entry levels
• Recalculate table logical sizes
10 Click Update.

Modifying Facts in the Project
Overview
In this exercise, you will use the Fact Editor to modify the
Cost, Gross Revenue, Revenue, and Units Sold facts you
created in the My Tutorial Project. You need to create the
following expressions for these facts:
You should also keep the existing expressions for each

of these facts.
Fact Expressions Source Tables
Cost QTY_SOLD * UNIT_COST ORDER_DETAIL
ORDER_COST ORDER_FACT
Gross QTY_SOLD * UNIT_PRICE ORDER_DETAIL

Revenue
Revenue QTY_SOLD * (UNIT_PRICE ORDER_DETAIL

- DISCOUNT)
ORDER_AMT ORDER_FACT
Units Sold QTY_SOLD ORDER_DETAIL
ORDER_FACT
You should use automatic mapping for all fact expressions.
After you have modified all these facts, update the project
schema.
You can use the detailed instructions if you want help. There
is a separate set of instructions for each fact you modify.

Detailed Instructions—Cost Fact
Open the Fact Editor
1 In the My Tutorial Project, expand the Schema Objects

folder.
2 In the Schema Objects folder, select the Facts folder.
3 In the Facts folder, double-click the Cost fact.
Create the second expression for the Cost fact
5 In the Create New Fact Expression window, in the Source

table drop-down list, select ORDER_DETAIL.
6 In the Fact expression box, create the following

expression:
QTY_SOLD * UNIT_COST
7 Under Mapping method, click Automatic.
8 Click OK.
Create the third expression for the Cost fact

table drop-down list, select ORDER_FACT.

expression:
ORDER_COST
13 Click OK.
Save and close the Cost fact

Detailed Instructions—Gross Revenue Fact
1 In the Facts folder, double-click the Gross Revenue fact.
Create the second expression for the Gross Revenue fact

table drop-down list, select ORDER_DETAIL.

expression:
QTY_SOLD * UNIT_PRICE
6 Click OK.
Save and close the Gross Revenue fact

Detailed Instructions—Revenue Fact
Since you have practiced modifying several different

facts using step-by-step instructions, these
instructions are written at a higher level to help better
test your understanding.
1 Open the Revenue fact in the Fact Editor.
Create the second expression for the Revenue fact
2 In the Fact Editor, modify the Revenue fact to create a

second expression:
QTY_SOLD * (UNIT_PRICE - DISCOUNT)
You can find these columns in the

ORDER_DETAIL table.
3 Use Automatic as the mapping method.
4 Click OK.
Create the third expression for the Revenue fact
5 In the Fact Editor, modify the Revenue fact to create a

third expression:
ORDER_AMT
You can find this column in the ORDER_FACT

table.
7 Click OK.
Save and close the Revenue fact
8 Save and close the Revenue fact.

Detailed Instructions—Units Sold Fact

facts using step-by-step instructions, these
1 Open the Units Sold fact in the Fact Editor.
Create the second expression for the Units Sold fact
2 In the Fact Editor, modify the Units Sold fact to create a

second expression:
QTY_SOLD
You can find this column in either the

ORDER_DETAIL or ORDER_FACT tables.
4 Click OK.
Save and close the Units Sold fact
5 Save and close the Units Sold fact.
6 Update the project schema.

Adding Another Fact to the Project
Overview
In this exercise, you will use the Fact Editor to create the
Profit fact in the My Tutorial Project. You need to create the
following expressions for this fact:
Fact Expressions Source Tables
Profit TOT_DOLLAR_SALES - CITY_CTR_SLS

TOT_COST
CITY_MNTH_SLS
CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
ITEM_CCTR_MNTH_SLS
ITEM_EMP_SLS
ITEM_MNTH_SLS
MNTH_CATEGORY_SLS
QTR_CATEGORY_SLS
YR_CATEGORY_SLS
QTY_SOLD * (UNIT_PRICE - ORDER_DETAIL

DISCOUNT) - UNIT_COST
ORDER_AMT - ORDER_COST ORDER_FACT
You should use automatic mapping for all fact expressions.

After you have created this fact, save the fact in the Schema
Objects\Facts folder, close the Fact Editor and update the
project schema.
Since you have already used the Fact Editor to modify

several different facts using step-by-step instructions,
these instructions are written at a higher level to help
better test your understanding.
Create the first expression for the Profit fact
2 In the Fact Editor, create the following expression:

TOT_DOLLAR_SALES - TOT_COST
You can find these columns in several different

tables. It does not matter which table you select
since you will create the expression using
automatic mapping. You can use the first table in
the list, which is CITY_CTR_SLS.
4 Click OK.
Create the second expression for the Profit fact
5 In the Fact Editor, create a second expression:

QTY_SOLD * (UNIT_PRICE - DISCOUNT)-
UNIT_COST
You can find these columns in the

ORDER_DETAIL table.
7 Click OK.

Create the third expression for the Profit fact
8 In the Fact Editor, create a third expression:

ORDER_AMT - ORDER_COST
You can find these columns in the ORDER_FACT

table.
10 Click OK.
Save and close the Profit fact
11 Save the Profit fact in the Schema Objects\Facts folder.
12 Close the Fact Editor.

Lesson Summary
• The second task in the project creation workflow is to
create the facts for a MicroStrategy project.
• Facts create a layer of abstraction between the underlying

structure of the data warehouse and the metrics users
require on reports. They make discrepancies in how
columns are named transparent to users.
• A homogeneous fact is one that points to the same column

or set of columns in every table to which it maps.
• A heterogeneous fact is one that points to the two or more

different columns or sets of columns in the tables to which
it maps.
• A fact expression consists of a column or set of columns to

which the fact maps. All facts have at least one expression.
Facts can have any number of expressions.
• A simple fact expression is one that maps directly to a

single fact column. It can map to that same column for
any number of tables.
• A derived fact expression is one that maps to an

expression from which the fact values are obtained. It can
contain multiple fact columns from the same table,
mathematical operators, numeric constants, and various
functions.
• You can use the Fact Creation Wizard to create multiple

facts very quickly. You generally use it during initial
project creation, but you can use it any time you need to
create a large number of facts.
• With the Fact Creation Wizard, you are limited to creating

basic facts. Basic facts are ones that are homogenous and
use only simple fact expressions.
• You can begin defining more complex facts in the Fact

Creation Wizard, but you need to complete their
definitions in the Fact Editor.
• You can access the Fact Creation Wizard as part of the

Project Creation Assistant, or you can launch it directly
from the Schema menu in MicroStrategy Desktop.

• When you first open the Fact Creation Wizard, you can
define the rules that govern how it works. You can select
which column data types the Fact Creation Wizard
displays, and you can choose how it renames fact
columns.
• Facts are stored in the Schema Objects\Facts folder.
• You can use the Fact Editor to create individual facts,

modify existing facts, or add complexity to facts you
initially created in the Fact Creation Wizard.
• All facts have a definition and column alias, but level

extensions are optional.
• You can use the Fact Editor to create simple or derived

fact expressions. You can also create heterogeneous facts
that have multiple expressions.
• You can use the Fact Editor to modify existing facts,

including the following tasks: creating new fact
expressions, modifying existing fact expressions, deleting
existing fact expressions, and modifying column aliases.
• The column alias specifies the data type that the

MicroStrategy Engine uses for a fact when it generates
SQL for temporary tables.
• Every fact you create has a default column alias. A fact

inherits its data type from the column on which it is
defined. If a fact maps only to a derived expression,
MicroStrategy Architect creates a custom column alias. If
a fact has multiple expressions, the alias uses the column
name and data type of the first expression you create.
• Most of the time, you do not need to modify the column

alias for a fact. However, there are specific scenarios in
which you may need to change the default data type to
avoid possible database errors.

7
WORKING WITH ATTRIBUTES
Lesson Description
This lesson describes how to work with attributes when

creating a project in MicroStrategy Architect.
In this lesson, you will learn how attributes and attribute

forms are used in a MicroStrategy project. Then, you will
learn about different types of attributes. Next, you will learn
how to create and modify attributes using the Attribute
Creation Wizard and Attribute Editor. Finally, you will learn
how defining attributes creates the system hierarchy for a
project.

7 Working with Attributes MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe how attributes and attribute forms are used in a
MicroStrategy project, explain the different types of
attributes and attribute form expressions, create and modify
basic and complex attributes using the Attribute Creation
Wizard and Attribute Editor, and describe how the system
hierarchy is created and used in a MicroStrategy project.
• Describe how attributes are used in a MicroStrategy

project. (Page 231)
• Describe how attribute forms are used in a MicroStrategy

project. (Page 234)
• Explain the difference between compound, homogeneous,

and heterogeneous attributes and simple and derived
attribute form expressions. (Page 237)
• Create basic attributes using the Attribute Creation

Wizard. (Page 243)
• Create and modify basic and complex attributes using the

Attribute Editor, including creating attribute relationships
and defining attribute form display. (Page 269)
• Describe how the system hierarchy is created and used in

a MicroStrategy project. (Page 311)

MicroStrategy Architect: Project Design Essentials Working with Attributes 7
What Is an Attribute?

Describe how attributes are used in a MicroStrategy project.
In the previous lesson, you learned how to create the facts for
a MicroStrategy project, which is the second task in the
project creation workflow as shown in the following image:
The third task in the project creation workflow is to create the

attributes for your MicroStrategy project. You create
attributes based on your logical data model and map them to
columns in the data warehouse physical schema. You also
define any direct relationships between attributes. You can
then use attributes as components in reports.
© 2011 MicroStrategy, Inc. What Is an Attribute? 231

On templates, attributes enable you to describe metrics at

various levels. For example, the following illustration shows
two reports with the same metric aggregated to different
levels based on the attributes in their respective templates:
Attributes and Metric Aggregation
The total for the Profit metric on each report is the same.
However, the first report displays profit by year and category
since those are the attributes on the template and they are not
directly related. The second report displays profit by call
center only since the Region and Call Center attributes on the
template are directly related and call centers represent the
lower level.
You can also use attributes to directly define the level

of aggregation for a specific metric. For information on
level metrics, see the MicroStrategy Desktop:
Advanced Reporting course.
232 What Is an Attribute? © 2011 MicroStrategy, Inc.

In filters, attributes enable you to qualify the result set of a

report based on attribute data. For example, the following
illustration shows two reports with the same template that
return different result sets based on the attributes in their
respective filters:
Attributes and Qualification
The attributes on each report are the same. However, the first
report displays profit for all years only for the Books and
Music categories since those Category attribute elements are
in the filter. The second report displays profit for all
categories only for 2007 since that Year attribute element is
in the filter.
© 2011 MicroStrategy, Inc. What Is an Attribute? 233

What Is an Attribute Form?

Describe how attribute forms are used in a MicroStrategy
project.
As part of creating attributes in a MicroStrategy project, you

create forms for each attribute. Attribute forms enable you to
display different types of descriptive information about an
attribute. You can use attribute forms to display the ID for an
attribute along with any number of description fields. It is the
attribute forms that actually map directly to the columns in
the data warehouse.
All attributes have an ID form. Most have at least one

primary description form. Some attributes have many
description forms, so you can display various aspects of that
attribute on reports. For example, you may store the
following information about customers in the data
warehouse:
Customer Information
The LU_CUSTOMER table contains a variety of information

about each customer that may be useful to view or analyze in
the reporting environment, including the following:
• ID
• Name
• Home phone
234 What Is an Attribute Form? © 2011 MicroStrategy, Inc.

• Home address
• E-mail
• Birth date
• Gender
• Income
In deciding what forms to create for an attribute, you have to

consider what users intend to do with this customer
information and whether the unique characteristics of
attribute forms will meet those needs.
First, attribute forms must have a one-to-one relationship

with other forms of the same attribute. For example, if a
customer has more than one e-mail address, then the
relationship between E-mail and Customer is not one to one.
In this case, if you want to display all the e-mail addresses for
a single customer, you have to create E-mail as a separate
attribute rather than an attribute form of Customer.
Ifrelationship
you create attribute forms that have a one-to-many
with the attribute they describe, only the
first element displays on reports.
Second, you can use attribute forms for the following

functions:
• Display—You can choose to display different forms of an

attribute on reports or in the Data Explorer when you
browse the attribute.
• Sorting—You can sort report data using attribute forms.

You can sort using any attribute form, not just those
displayed on a report.
• Qualification—You can qualify on the elements of any

attribute form. You can qualify using any attribute form,
not just those displayed on a report.
© 2011 MicroStrategy, Inc. What Is an Attribute Form? 235

If all users need to do is display, sort, or qualify on descriptive

data, creating an attribute form for that data is sufficient.
However, if users need to be able to aggregate metrics based
on descriptive data, you need to create it as a separate
attribute rather than an attribute form.
Because ID forms are the unique identifiers for

attributes, they are included in the GROUP BY clause
when aggregating metrics on reports.
For example, you probably do not need to aggregate revenue

data for customers based on their name, home address, home
phone, e-mail, or birth date. However, you may want to
aggregate revenue data based on their gender or income.
Therefore, you would probably want to create Gender and
Income as separate attributes rather than attribute forms.
The ability to create multiple forms for an attribute provides

flexibility in reporting. Users can choose to display different
forms for an attribute on different reports. They can view as
many or as few forms as they want.
The following image shows a report with various attribute

forms displayed for the Customer attribute:
Customer Attribute Forms
This report displays each customer’s ID, last name, first

name, address, and e-mail all under the Customer attribute
header.
236 What Is an Attribute Form? © 2011 MicroStrategy, Inc.

Types of Attributes

Explain the difference between compound, homogeneous,
and heterogeneous attributes and simple and derived
attribute form expressions.
Before you learn how to create attributes in MicroStrategy

Architect, you need to understand the different types of
attributes and attribute form expressions that exist. There are
three primary types of attributes:
• Compound
• Homogeneous
• Heterogeneous
The following topics describe each of these types of attributes

in more detail.
Compound Attributes
A compound attribute is one that uses two or more columns
as its ID. Therefore, its ID form maps to a combination of
columns. These attributes require a compound primary key
in the data warehouse to uniquely identify their elements.
The following illustration shows an example of a compound

attribute:
Compound Attribute
© 2011 MicroStrategy, Inc. Types of Attributes 237

The Item attribute has two different columns that comprise

its primary key in the LU_ITEM table—Item_ID and
Color_ID. Therefore, it is a compound attribute since you
have to map its ID form to the combination of these two
columns.
Homogeneous Attributes
You associate the forms of an attribute to columns in data
warehouse tables. You can map the same attribute form to
any number of tables. A homogeneous attribute is one where
each attribute form points to the same column or set of
columns in every table to which it maps.

homogeneous attribute:
Homogeneous Attribute
The illustration above shows an example where the ID

for an attribute occurs in multiple tables. Other
attribute forms can also exist in multiple tables,
although this scenario most frequently occurs with ID
forms.
238 Types of Attributes © 2011 MicroStrategy, Inc.

The ID form for the Region attribute maps to three different

tables—LU_REGION, LU_CALL_CTR, and
REGION_SALES. However, Region is a homogeneous
attribute because its ID form maps to the same Region_ID
column in each table.
Heterogeneous Attributes
Whereas each form for a homogenous attribute always maps
to the same column or set of columns, a heterogeneous
attribute is one where at least one attribute form points to
two or more different columns or sets of columns in the
tables to which it maps.

heterogeneous attribute:
Heterogeneous Attribute
The illustration above shows an example where the ID

for an attribute occurs in multiple tables. Other
attribute forms can also exist in multiple tables,
although this scenario most frequently occurs with ID
forms.

The ID form for the Region attribute maps to three different

tables—LU_REGION, LU_CALL_CTR, and
REGION_SALES. However, in the first two tables, it maps to
the Region_ID column, but in the third table, it maps to the
Reg_ID column. Therefore, Region is a heterogeneous
attribute because its ID form maps to two different columns.
Types of Attribute Form Expressions

All attributes have one or more attribute forms. The attribute
forms directly map to columns in the data warehouse. An
attribute form expression consists of a column or set of
columns to which an attribute form maps. All attribute forms
have at least one expression. However, attribute forms can
have any number of expressions. There are two primary
types of attribute form expressions:
• Simple
• Derived
The following topics describe both of these types of attribute

form expressions in more detail.
Simple Attribute Form Expressions
A simple attribute form expression is one that maps directly

to a single attribute column. It can map to that same column
for any number of tables.
The following illustration shows an example of a simple

attribute form expression:
Simple Attribute Form Expression

The ID form for the Days to Ship attribute maps directly to

the Days_to_Ship column in the LU_SHIPMENT table,
creating a simple attribute form expression.
Derived Attribute Form Expressions
A derived attribute form expression is one that maps to an

expression from which the attribute form values are
obtained. A derived attribute form expression can contain
multiple attribute columns from the same table,
mathematical operators, constants, and various functions.
Ifdifferent
you want to combine attribute columns from
database tables in a derived attribute form
expression, you have to create a logical view. For
information on logical views, see the MicroStrategy
Advanced Data Warehousing course.
MicroStrategy provides a variety of out-of-the-box

functions that you can use in defining attribute form
expressions, including passthrough functions that
enable you to pass SQL statements directly to the data
warehouse. For information on using advanced
functions to define attributes, see the MicroStrategy
The following illustration shows an example of a derived

attribute form expression:
Derived Attribute Form Expression

The ID form for the Days to Ship attribute maps to an

expression that combines the Ship_Date and Order_Date
columns in the LU_SHIPMENT table, creating a derived
attribute form expression.
MicroStrategy Architect enables you to create derived

attribute form expressions at the application level.
However, you can also store derived attribute columns
at the database level. The advantage of using derived
attribute columns in the data warehouse is that the
calculation is performed ahead of time during the ETL
process and the result is stored as a single column.
This method translates into simpler report SQL and
better performance. If you implement a derived
attribute form expression at the application level, the
calculation has to be performed each time you process
a query that uses that attribute form.

Using the Attribute Creation Wizard

Create basic attributes using the Attribute Creation Wizard.
The Attribute Creation Wizard enables you to create multiple

attributes very quickly. You generally use it during initial
project creation when you are creating the majority of
attributes for a project, but you can use it any time you need
to create a large number of attributes. However, you are
limited to creating basic attributes using this tool. Basic
attributes are ones that are homogeneous, use only simple
form expressions, and have no more than two attribute forms
(an ID and primary description). You can sometimes begin
defining more complex attributes in the Attribute Creation
Wizard. However, if you need to create heterogeneous or
derived attribute form expressions or define additional forms
for the attribute, you have to use the Attribute Editor to
complete its definition.
The Attribute Editor also enables you to change

various attribute properties, such as column aliases,
relationships, and attribute form displays, that you
cannot access from the Attribute Creation Wizard. For
more information on the Attribute Editor, see “Using
the Attribute Editor” starting on page 269.
You can access the Attribute Creation Wizard as part of the

Project Creation Assistant when you first create a project.
You can also launch the Attribute Creation Wizard directly
from the Schema menu in MicroStrategy Desktop to create
attributes for an existing project.
To access the Attribute Creation Wizard from the Project

Creation Assistant:

Assistant.
© 2011 MicroStrategy, Inc. Using the Attribute Creation Wizard 243

3 Select the database instance and tables for the project.
You have to create the project object and select the

database instance and project tables before you can
create attributes.
4 Create the facts for the project.
You generally create facts before creating

attributes, but you are not required to do so.
5 Click Create attributes.
The following image shows where you access the Attribute

Creation Wizard in the Project Creation Assistant:
Accessing the Attribute Creation Wizard from the Project
Creation Assistant
244 Using the Attribute Creation Wizard © 2011 MicroStrategy, Inc.

To access the Attribute Creation Wizard directly from the

Schema menu in MicroStrategy Desktop:
2 On the Schema menu, select Attribute Creation Wizard.
The following image shows the option for accessing the

Attribute Creation Wizard from the Schema menu:
Accessing the Attribute Creation Wizard from the Schema
Menu

The following image shows the Introduction window for the

Attribute Creation Wizard:
Attribute Creation Wizard—Introduction Window
Defining Attribute Creation Rules

The Introduction window of the Attribute Creation Wizard
enables you to define the rules that govern how the wizard
works. First, you can select which column data types the
Attribute Creation Wizard displays as possible ID columns
for attributes. By default, it displays only numeric and
date/time columns since attribute IDs generally belong to
one of these data types. However, if you have attribute ID
columns with other data types, you can select those other
data types. Second, you can choose how the Attribute
Creation Wizard renames attribute ID columns as attribute
objects. Finally, you can provide the naming conventions you
use in your data warehouse for ID and description columns
and lookup tables to help MicroStrategy Architect better
identify these objects.

To define rules for the Attribute Creation Wizard:
1 In the Attribute Creation Wizard, in the Introduction

window, click Define Rules.
2 In the Attribute Creation Rules window, under Column

data type, select the check boxes for the data types you
want to display as possible attribute ID columns in the
Attribute Creation Wizard.
3 Under Attribute name, if you want to replace underscores

in column names with spaces, ensure that the Replace
underscores in attribute name with spaces check box
is selected.
4 If you use “ID” as a naming convention for attribute ID

columns and you want to remove this text when creating
attribute names, ensure that the Remove ‘ID’ from
attribute name check box is selected.
5 If you want to capitalize the first letter of each word in

attribute names, ensure that the First letter in upper
case check box is selected.
6 Under Warehouse search, if you use standard naming

conventions in your data warehouse, in the To find
identifier columns (ID) look for box, type the text patterns
you use for attribute ID columns.
For any naming conventions you define in steps 6

to 8, you can enter multiple text patterns separated
by semicolons (for example, ID;NBR).
7 In the To find description columns (DESC) look for box,

type the text patterns you use for attribute description
columns.
8 In the To find lookup tables look for box, type the text
patterns you use for lookup tables.
9 Click OK.

The following image shows the Attribute Creation Rules

window:
Attribute Creation Rules Window
Creating Attributes
You can use the Attribute Creation Wizard to create
attributes as part of the initial project creation. You can also
use it to create multiple attributes in an existing project at
any point in time.
You cannot use the Attribute Creation Wizard to

modify existing attributes.
Creating attributes in the Attribute Creation Wizard involves

the following tasks:
• Creating attribute ID forms
• Creating attribute description forms (if applicable)

• Selecting lookup tables for attributes
• Creating attribute relationships
You perform each of these tasks on a separate window in the

Attribute Creation Wizard. You can move between the
windows using the Back and Next buttons if you need to go
back and make changes.
The following topics describe each of these tasks in more

detail.
Creating Attribute ID Forms
After you define the rules for the Attribute Creation Wizard,
you can proceed to the ID Column Selection window where
you create the initial attribute objects and their respective ID
forms. The following image shows this window:
Attribute Creation Wizard—ID Column Selection Window

The ID Column Selection window of the Attribute Creation

Wizard has the following components:
• Available columns list—This list displays the available

columns in the project tables that match the selected data
types based on the rules you define. It shows a distinct list
of columns across all project tables.
Columns that you have already used to define an

attribute do not display in this list.
• Attributes list—This list displays the attributes you are

creating in the project.
• Compound Attributes button—This button opens a

window that enables you to create compound attributes
by selecting multiple ID columns.
For information on creating compound attributes

in the Attribute Creation Wizard, see “Creating
Compound Attributes” starting on page 263.
When the ID Column Selection window of the Attribute

Creation Wizard opens, MicroStrategy Architect retrieves a
list of all the columns in project tables that match the selected
data types. From this list, you select which columns you want
to use as ID columns for attributes.

To create attribute ID forms using the Attribute Creation

Wizard:

opened the Attribute Creation Wizard and made any
necessary changes to the attribute creation rules.

window, click Next.
2 In the ID Column Selection window, do one of the

following:
If you want to use all the selected columns as ID forms for

attributes, continue to step 3.
MicroStrategy Architect automatically selects any

columns that conform to the naming conventions
you defined for ID columns.
OR
In the Available columns list, select any column to clear

the automatically selected columns.
Hold CTRL and select the columns you want to use as ID

forms for attributes.
3 Click the > button to add the columns to the Attributes

list.
This action automatically renames the columns as

attribute objects based on the rules you define. If
you want to modify an attribute name, in the
Attributes list, right-click the attribute and select
Rename.
Ifselect
you want to remove an attribute from the list,
the attribute and click the < button to move
the corresponding column to the Available
columns list.

The following image shows the Attribute Creation Wizard

with selected attributes created in a project:
Attribute Creation Wizard—Attributes Created in Project

Creating Attribute Description Forms
After you create the attribute ID forms, you can proceed to

the Description Column Selection window where you create
the attribute description forms. The following image shows
this window:
Attribute Creation Wizard—Description Column Selection
Window
The Description Column Selection window of the Attribute

Creation Wizard displays a list of the attributes you have
created and the suggested columns to use as description
forms for each attribute.
Based on the naming conventions you defined for

description columns and the ID columns you selected
for each attribute, MicroStrategy Architect
automatically selects possible description columns.
Iflisted
you are creating compound attributes, they are not
in this window. For information on creating
description forms for compound attributes in the
Attribute Creation Wizard, see “Creating Compound
Attributes” starting on page 263.

For each attribute, you can either keep the suggested column
or select another column to use as the description form. Any
column that is stored in a table with the ID column for the
attribute is available as a possible description form.
To create attribute description forms using the Attribute

Creation Wizard:

opened the Attribute Creation Wizard, made any
necessary changes to the attribute creation rules, and
created the attribute ID forms.
1 In the Attribute Creation Wizard, in the ID Column

Selection window, click Next.
2 In the Description Column Selection window, in the

Attributes list, under Description column name, review
the description form selected for each attribute.
3 If you need to change the description form for an

attribute, in the Description column name drop-down list,
select the column you want to use.
Ifform,
the attribute does not have a separate description
select Use ID as description. If you select
this option, the attribute is created with only an ID
form.
Ifcananselect
attribute has multiple description forms, you
only one of them in the Attribute
Creation Wizard. You have to create the other
description forms in the Attribute Editor.


with the correct description forms selected for each attribute:
Attribute Creation Wizard—Description Forms Selected

Selecting Lookup Tables for Attributes
After you create the attribute description forms, you can

proceed to the Lookup Table Selection window where you
select the lookup tables for attributes. The following image
shows this window:
Attribute Creation Wizard—Lookup Table Selection
Window
The Lookup Table Selection window of the Attribute Creation

Wizard displays a list of the attributes you have created and
the suggested tables to use as lookup tables for each attribute.
Based on the naming conventions you defined for

lookup tables and the ID and description columns you
selected for each attribute, MicroStrategy Architect
automatically selects possible lookup tables.
Iflisted
you are creating compound attributes, they are not
in this window. For information on selecting
lookup tables for compound attributes in the Attribute
Creation Wizard, see “Creating Compound Attributes”

For each attribute, you can either keep the suggested table or
select another table to use as the lookup table. Any table that
contains the ID and description columns for the attribute is
available as a possible lookup table.
To select lookup tables for attributes using the Attribute

Creation Wizard:

necessary changes to the attribute creation rules, and
created the attribute ID and description forms.
1 In the Attribute Creation Wizard, in the Description

Column Selection window, click Next.
2 In the Lookup Table Selection window, in the Attributes

list, under Lookup Table Name, review the lookup table
selected for each attribute.
3 If you need to change the lookup table for an attribute, in

the Lookup Table Name drop-down list, select the table
you want to use.


with the correct lookup tables selected for each attribute:
Attribute Creation Wizard—Lookup Tables Selected

Creating Attribute Relationships
After you select the lookup tables for attributes, you can
proceed to the Relationship Definition window where you
create attribute relationships. The following image shows this
window:
Attribute Creation Wizard—Relationship Definition
Window
IfCompound
you are creating compound attributes, the
Attribute Definition window opens before
the Relationship Definition window. This window
enables you to select the lookup table and description
form for each compound attribute. For information on
creating compound attributes in the Attribute
Creation Wizard, see “Creating Compound Attributes”

The Relationship Definition window of the Attribute Creation

Wizard has the following components:
• Attributes list—This list displays the attributes you have

created.
• Children of list—This list displays the children of the

parent attribute selected in the Attributes list, along with
the relationship types.
• Add button—This button opens a window that enables

you to add child attributes for the parent attribute
selected in the Attributes list.
• Remove button—This button opens a window that

enables you to remove child attributes for the parent
attribute selected in the Attributes list.
For each parent attribute, you need to create the child

relationships. Any attribute you are creating in the wizard
whose ID column exists in a table with the ID of the parent
attribute is available as a possible child attribute.
To create attribute relationships using the Attribute Creation

Wizard:

necessary changes to the attribute creation rules,
created the attribute ID and description forms, and
selected the lookup tables for attributes.
1 In the Attribute Creation Wizard, in the Lookup Table

Selection window, click Next.
2 In the Relationship Definition window, in the Attributes

list, select an attribute for which you want to add child
relationships.
3 Click Add.
4 In the Select Children Attributes window, in the Available

children for list, hold CTRL and select the child
attributes.

5 Click OK.
This action adds the attributes as children with a

default relationship type of one to many.
6 In the Relationship Definition window, in the Children of

list, in the Relationship type drop-down list for each child
attribute, select the appropriate relationship type.
You may not need to change the default

relationship types.
7 Repeat steps 2 to 6 for each attribute for which you need

to create child relationships.
8 When you have created all the child relationships for

attributes, click Next.
9 In the Finish window, review the list of attributes you are

creating.
10 Click Finish.
After the Attribute Creation Wizard closes, you can

The following image shows the Select Children Attributes

window:
Select Children Attributes Window


with the relationships created for each attribute:
Attribute Creation Wizard—Relationships Created
The image above displays the child relationships for

the Customer attribute.
When you create attributes in a project, they are stored in the

Schema Objects\Attributes folder, as shown in the following
image:
Attributes

Creating Compound Attributes

As you learned earlier, compound attributes have IDs that
consist of multiple columns. The Attribute Creation Wizard
provides the easiest method for creating compound attributes
because it contains functions specific to these attributes.
The ID Column Selection window of the Attribute Creation

Wizard includes a Compound Attributes button that enables
you to select multiple columns to create the ID forms for
compound attributes. The following image shows this button:
ID Column Selection Window—Compound Attributes
Button

The Attribute Creation Wizard also includes a separate

window for creating the description forms and selecting
lookup tables for compound attributes. The Compound
Attribute Definition window displays only if you create
compound attributes in the ID Column Selection window.
The following image shows this window:
Attribute Creation Wizard—Compound Attribute Definition
Window
Although it is more straightforward to create

compound attributes in the Attribute Creation Wizard,
you can also create them in the Attribute Editor. For
information on creating compound attributes in the
Attribute Editor, see “Creating Compound Attributes”

To create compound attributes using the Attribute Creation

Wizard:
The following procedure demonstrates how to create

compound attributes in conjunction with creating
other attributes in the Attribute Creation Wizard. It
assumes you have already opened the Attribute
Creation Wizard and made any necessary changes to
the attribute creation rules.

window, click Next.
2 In the ID Column Selection window, create the ID forms

for attributes that map to single ID columns.
3 Click Compound Attributes.
4 Click Add.
5 In the New Compound Attribute window, in the

Compound attribute name box, type the name of the
attribute.
6 In the Available columns list, hold CTRL and select the

columns that comprise the ID of the attribute.
7 Click OK.
8 Repeat steps 4 to 7 for each compound attribute you need

to create.
9 When you have created all the compound attributes, in

the ID Column Selection window, click Next.
10 In the Description Column Selection window, create the

description form for each attribute listed.
Compound
window.
attributes do not display in this
11 Click Next.

12 In the Lookup Table Selection window, select the lookup

table for each attribute listed.
Compound
window.
attributes do not display in this
13 Click Next.
14 In the Compound Attribute Definition window, in the

Compound attributes list, select a compound attribute.
15 In the ID lookup table for drop-down list, select the

lookup table for the compound attribute.
16 Click Add.
17 In the Description Columns window, in the Available

columns list, select the description column for the
compound attribute.
18 Click OK.
19 Repeat steps 14 to 18 for each compound attribute listed.
20 When you have defined all the compound attributes, in

the Compound Attribute Definition window, click Next.
21 In the Relationship Definition window, create the child

relationships for each attribute listed.
22 Click Next.
23 In the Finish window, review the list of attributes you are

creating.
24 Click Finish.
After the Attribute Creation Wizard closes, you can


The following image shows the New Compound Attribute

window:
New Compound Attribute Window

with a compound attribute created:
Attribute Creation Wizard—Compound Attribute Created

The following image shows the Description Columns window:

Description Columns Window

with the lookup table selected and description form created
for the compound attribute:
Attribute Creation Wizard—Compound Attribute Defined

Using the Attribute Editor

Create and modify basic and complex attributes using the
Attribute Editor, including creating attribute relationships
and defining attribute form display.
The Attribute Creation Wizard is the primary tool for mass

creation of basic attributes. However, if you want to create
individual attributes, modify existing attributes, or add
complexity to attributes you initially created in the Attribute
Creation Wizard, you use the Attribute Editor. The Attribute
Editor is one of the schema object editors available in
MicroStrategy Architect. It enables you to create or modify
any type of attribute or attribute form expression and
configure a variety of attribute-related settings.
To access the Attribute Editor:
If you are creating a new attribute, on the File menu, point

to New and select Attribute.
OR
If you are modifying an existing attribute, in the Schema

Objects folder, select the Attributes folder.
In the Attributes folder, double-click the attribute you

want to modify.
© 2011 MicroStrategy, Inc. Using the Attribute Editor 269

The following image shows the Attribute Editor:

Attribute Editor
Inthetheattribute
Source tables list, the primary lookup table for
displays in bold type.
The Attribute Editor has the following tabs:

• Forms—This tab enables you to create, modify, and delete
attribute forms and attribute form expressions. It also
enables you to modify the column alias for an attribute.
• Children—This tab enables you to add and remove child

relationships for an attribute.
• Parents—This tab enables you to add and remove parent

relationships for an attribute.
• Display—This tab enables you to define which attribute

forms are used for report display and browsing.
270 Using the Attribute Editor © 2011 MicroStrategy, Inc.

Creating Attributes
Creating attributes in the Attribute Editor involves creating
attribute forms and form expressions. As you learned earlier,
every attribute must have at least one attribute form, and
each form can have any number of attribute form
expressions.
As part of the task of creating an attribute form, you have to

configure its properties. Before you learn how to create
attribute forms and form expressions, it is important to
understand how these properties work.
Attribute Form Properties
Attribute form properties are divided into the following

categories:
• Form definition—Includes the attribute form expressions

that map the attribute form to columns and tables in the
data warehouse
• Form general information—Includes the name and

description of the attribute form as well as an option to
configure support for multiple languages. This name is
the one displayed to users as they work with the attribute
form.

• Form category—Includes the form category that

specifies the type of attribute form. The default form
categories are ID, DESC, and None. You can also create
new form categories to use.
Generally, you have only one form assigned to the

ID and DESC categories for each attribute. You
assign all other forms to the None category or a
category that you create. If you want multiple
forms to be part of the ID or DESC form categories,
you have to create a form group. For information
on creating a form group, see “Creating Compound
Attributes” starting on page 283.
• Form format—Includes the data type used to display the

attribute form and the default sort order for report display
and browsing. The data type defaults to the data type of
the column to which the attribute form maps.
The following image shows these attribute form properties:

Attribute Form Properties

Creating Attribute Forms and Form Expressions
You can use the Attribute Editor to create attributes with

forms that have simple or derived attribute form expressions.
You can also create heterogeneous attributes that have forms
with multiple expressions.
To create an attribute form with a simple attribute form

expression using the Attribute Editor:
1 Open the Attribute Editor.
2 In the Attribute Editor, in the Create New Form

Expression window, in the Source table drop-down list,
select the desired table.

the column you want to use for the attribute form
expression.
3 In the Available columns list, drag the column you want to

map to the attribute form to the Form expression box.
You can also double-click the column to add it to

the Form expression box.

mapping the column to the attribute form.
With automatic mapping, MicroStrategy Architect

scans the project tables and maps all tables that
contain the column to the attribute form as source
tables. With manual mapping, MicroStrategy
Architect still locates the project tables that contain
the column, but you have to manually select the
ones you want to use as source tables for the
attribute form.
Automatic mapping makes project maintenance

easier. However, some scenarios require manual
mapping. For example, if the same column does
not contain the same data across different project
tables, you must use manual mapping.
5 Click OK.

6 In the Create New Attribute Form window, do one of the

following:
If you selected automatic mapping for the attribute form

OR
If you selected manual mapping for the attribute form

expression, on the Definition tab, in the Source tables list,
select the check box for each table to which you want to
map the attribute form.
7 In the Name box, type the name of the attribute form.
8 In the Description box, type the description for the

attribute form.
Entering
optional.
a description for the attribute form is
9 If you want to configure the attribute form to support

multiple languages, select the Supports multiple
languages check box.
This check box is available only if the project is

configured to support data internationalization.
For information on configuring data
internationalization, see the MicroStrategy
Administration course.
10 In the Category used drop-down list, select the

appropriate form category.
11 If you want to modify the data type of the attribute form,

in the Type drop-down list, select the appropriate data
type.
12 If you want to set the default sort order for displaying the
attribute form on reports, in the Report sort drop-down
list, select the desired sort order.
13 If you want to set the default sort order for browsing the
attribute form, in the Browse sort drop-down list, select
the desired sort order.

14 Click OK.
15 In the Attribute Editor, click Save and Close.
After closing the Attribute Editor, you can update

the project schema if desired.
The following image shows the Create New Form Expression

window:
Create New Form Expression Window

The following image shows the Create New Attribute Form

window:
Create New Attribute Form Window

The following image shows the Attribute Editor with a simple

form expression for the Shipper attribute:
Attribute Editor—Simple Form Expression
To create an attribute form with a derived attribute form

expression using the Attribute Editor:
2 In the Attribute Editor, in the Create New Attribute Form


the columns you want to use for the attribute form
expression.


to use in the expression to the Form expression box.
You can also double-click the columns to add them

to the Form expression box.
4 In the Form expression box, complete the derived

expression as appropriate.
You can use the toolbar above the box to insert

parentheses, mathematical operators, or other
functions. You can also type information directly in
the box.

mapping the expression to the attribute form.
6 Click OK.

following:

OR


attribute form.



type.

15 Click OK.

The following image shows the Attribute Editor with a

derived form expression for the Days To Ship attribute:
Attribute Editor—Derived Form Expression

To create a heterogeneous attribute using the Attribute Editor:
2 In the Attribute Editor, in the Create New Attribute Form


to use in the expression to the Form expression box.
4 In the Form expression box, complete the expression as

appropriate.

mapping the expression to the attribute form.
6 Click OK.

following:

OR


attribute form.




type.
15 Click New.
16 Repeat steps 2 to 15 for each attribute form expression

you want to create.
17 When you have created all the expressions for the

attribute form, click OK.


The following image shows the Attribute Editor with multiple

expressions for the ID form of the heterogeneous Day
attribute:
Attribute Editor—Heterogeneous Attribute

Creating Compound Attributes

As you learned earlier, the easiest way to create compound
attributes is through the Attribute Creation Wizard.
However, because you typically use this wizard only when
you are creating multiple attributes, you also have the option
to create compound attributes using the Attribute Editor.
In the Attribute Editor, you create a compound attribute by

assigning two or more attribute forms to the ID form
category. When you assign more than one attribute form to
the same form category, you create a form group.
The ability to create compound attributes in the

Attribute Editor is the primary function of form
groups. Although you can assign multiple forms to
other form categories besides the ID, it rarely makes
sense to do so because it does not affect how the forms
function unless they are ID forms.
To create a compound attribute using the Attribute Editor:
2 In the Attribute Editor, create the first ID form for the

attribute, selecting ID as the form category.
Toformavoid confusion, it is best not to use “ID” as the

name. For example, you can use “ID 1.” This
way, you can reserve “ID” as the name of the form
group.
3 Create the second ID form for the attribute, selecting ID as

the form category.
Toformavoid confusion, it is best not to use “ID” as the

name. For example, you can use “ID 2.” This
way, you can reserve “ID” as the name of the form
group.
When you click OK on the Create New Attribute

Form window, you see a message window that
prompts you to create a form group.
4 In the message window, click Yes.

5 In the Create New Attribute Form window, in the Name

box, type ID as the name of the form group.
You do not have to use “ID” as the form group

name. However, this naming convention may be
easiest for users to understand.
6 In the Description box, type the description for the form

group.
Entering
optional.
a description for the form group is
7 If you want to configure the form group to support

This check box is available only if the project is

configured to support data internationalization.
For information on configuring data
internationalization, see the MicroStrategy
Administration course.
8 In the Category used drop-down list, ensure that ID is

selected.
9 Click OK.


The following image shows the message window that

prompts you to create a form group:
Form Group Message Window
The following image shows the Create New Attribute Form

window in which you create the form group:
Create New Attribute Form Window

The following image shows the Attribute Editor with an ID

form group created that combines two ID forms:
Attribute Editor—ID Form Group Created
You can also create a compound attribute using

attribute forms that already exist. In the Attribute
Editor, on the Forms tab, in the Attribute forms list,
hold CTRL and select the forms that are part of the ID.
Right-click the forms and select Group. From this
point, the procedure for creating the form group is the
same.
Architect will not allow you to group/ungroup an

attribute form if the definition of any application
object depends on it.

Modifying Attributes
You can also use the Attribute Editor to modify existing
attributes. You can perform the following tasks:
• Create new attribute forms
• Modify existing attribute forms, including form

expressions, mapping methods, source tables, and form
properties
• Delete existing attribute forms
• Modify lookup tables
• Modify attribute keys
• Modify column aliases
The following topics describe how to perform each of these

tasks.
Creating New Attribute Forms
You can create new attribute forms for existing attributes.

Often, you may be able to create the ID and primary
description forms for an attribute in the Attribute Creation
Wizard, but you have other forms you must create in the
Attribute Editor.
To create a new attribute form for an existing attribute using

the Attribute Editor:
1 Open the attribute in the Attribute Editor.
2 In the Attribute Editor, on the Forms tab, click New.
3 In the Create New Form Expression window, define the

new attribute form expression.
4 Click OK.
5 In the Create New Attribute Form window, configure the

properties for the new attribute form.

6 Click OK.

Modifying Existing Attribute Forms
You can also modify existing attribute forms for attributes.

You can change the actual form expressions, mapping
methods, source tables, and form properties.
To modify an existing attribute form for an attribute using the

Attribute Editor:
2 In the Attribute Editor, on the Forms tab, in the Attribute

Forms list, select the attribute form you want to modify.
3 Click Modify.

4 In the Modify Attribute Form window, on the Definition

tab, do one of the following:
If you want to create a new form expression, click New.
In the Create New Form Expression window, define the

new attribute form expression.
Click OK.
OR
If you want to modify an existing form expression, in the

Expressions list, select the form expression you want to
modify.
Click Modify.
In the Modify Form Expression window, modify the form
expression as desired.
You can change the expression or mapping

method.
Click OK.
In the Modify Attribute Form window, on the Definition

tab, in the Source tables list, modify the form as desired.
You can change the source tables or form

properties.
OR
If you want to delete an existing form expression, in the

Expressions list, select the form expression you want to
delete.
Click Delete.
5 In the Modify Attribute Form window, click OK.


The following image shows the Modify Attribute Form

window:
Modify Attribute Form Window

The following image shows the Modify Form Expression

window:
Modify Form Expression Window
Deleting Existing Attribute Forms
You can also delete existing attribute forms for attributes if

you no longer need them.
You cannot delete the ID form for an attribute.

To delete an existing attribute form for an attribute using the
Attribute Editor:

forms list, select the attribute form you want to delete.
3 Click Delete.


Modifying Lookup Tables
You can also modify the primary lookup tables for existing
attributes.
To modify the lookup table for an existing attribute using the

Attribute Editor:

forms list, select the ID form for the attribute.
3 Click Modify.

tab, do one of the following:
If the attribute form has only one expression, continue to

step 5.
OR
If the attribute form has multiple expressions, in the

Expressions list, select the expression that maps to the
current lookup table.
5 In the Source tables list, select the table you want to use as
the lookup table.
6 Click Set as Lookup.
7 Click OK.
8 Repeat steps 2 to 7 for each form of the attribute.
9 When you have modified the lookup table for the

necessary attribute forms, in the Attribute Editor, click
Save and Close.


Modifying Attribute Keys
The attribute key is the attribute form that functions as the

unique identifier for an attribute. By default, the ID form for
an attribute is used as the attribute key since this form
typically corresponds to the ID column for the attribute in the
data warehouse. However, you can modify the attribute key
to use another form.
To modify the attribute key for an existing attribute using the

Attribute Editor:

forms list, right-click the attribute form you want to use as
the attribute key and select Set as key.
When you modify the attribute key, if you have

already created relationships between this
attribute and other attributes or used this attribute
in application objects, a message window displays
warning you that this change may affect other
objects and asking if you still want to make the
change.
Ifobjects,
modifying the attribute key will invalidate other
the Invalid Objects window displays,
listing the affected objects. If you still want to
modify the attribute key, click OK.


Modifying Column Aliases
You can also modify column aliases for existing attributes.

Every form you create for an attribute has a default column
alias, regardless of the type or number of expressions you
define for it. The column alias specifies the data type that the
MicroStrategy Engine uses for an attribute form when it
generates SQL for temporary tables.
By default, an attribute form inherits its data type from the

column on which it is defined. Therefore, if you map an
attribute form to a column called CUSTOMER_ID that uses
an Integer data type, MicroStrategy Architect automatically
creates a corresponding column alias called CUSTOMER_ID
with an Integer data type.
If an attribute form maps only to a derived expression,

MicroStrategy Architect creates a custom column alias.
Custom column aliases use the naming convention
CustCol_<n> where “Cust” stands for custom, “Col” stands
for column, and n is a number. The first custom column alias
MicroStrategy Architect creates in a project is CustCol_1, the
next CustCol_2, and so forth.
Since the column alias name is used in any SQL that

the MicroStrategy Engine generates, you can change
the name of custom column aliases to make them
more meaningful. Having column alias names that
correlate to underlying attribute form names can be
useful when troubleshooting the SQL for complex
reports.
If you define an attribute form using multiple expressions,

the column alias uses the column name and data type of the
first expression you create.
Ifexpression,
the first expression you create is a derived
MicroStrategy Architect creates a custom
column alias as described above.

Most of the time, you do not need to modify the column alias.
However, there are specific scenarios in which you may need
to change the default data type. For example, you could create
an attribute whose ID form is defined as the difference
between two dates, such as a ship date and order date. This
attribute form has the following expression:
[SHIP_DATE] - [ORDER_DATE]
The column alias for this attribute automatically uses a

TimeStamp data type because the SHIP_DATE and
ORDER_DATE columns use the TimeStamp data type.
However, the result of the expression (the difference between
the two dates) produces an integer.
The difference in data types can cause problems when the

MicroStrategy Engine needs to insert values for this attribute
form into a temporary table. The Engine uses a TimeStamp
data type to define this attribute column in the temporary
table and then tries to insert integer numbers into the
column. While this may not be a problem for some database
platforms, it can cause an error. To eliminate the conflicting
data types, you can modify the column alias for the attribute
form to change the data type from TimeStamp to Integer.
Ifform,
you need to modify the column alias for an attribute
you probably also need to modify the data type
for the format of the attribute form to ensure the two
are compatible.
To modify the column alias for an existing attribute using the

Attribute Editor:

forms list, select the attribute form for which you want to
modify the column alias.
3 Click Modify.
4 In the Modify Attribute Form window, click the Column

Alias tab.
5 On the Column Alias tab, click Modify.

6 In the Column Editor - Column Selection window, do one

of the following:
If you want to modify the default column alias, in the

Available columns list, select the default column alias.
You can only change the properties of custom

column aliases.
Click Modify.
OR
If you want to create and assign a new column alias, click

New.
7 In the Column Editor - Definition window, in the Column

name box, type the name for the column alias.
Ifalready
you are modifying a custom column alias, it
has a name, but you can change the name.
8 In the Data type box, select the data type you want to use.
9 Configure the data type as appropriate.
Depending on the data type you select, you may

need to configure the precision, scale, byte length,
bit length, or time scale.
10 Click OK.
11 In the Column Editor - Column Selection window, click

OK.
Ifwiththethedatadatatypetypeforforthetheformcolumn
format is incompatible
alias, a message
window displays warning you that SQL generation
problems can occur. If you still want to modify the
column alias, click Yes.


The following image shows the Column Alias tab on the

Modify Attribute Form window:
Modify Attribute Form Window—Column Alias Tab

The following image shows the Column Editor - Column

Selection window:
Column Editor - Column Selection Window
The following image shows the Column Editor - Definition

window:
Column Editor - Definition Window

Creating Attribute Relationships

As you learned earlier, part of the task of creating attributes
involves defining direct parent-child relationships between
attributes. You need to create the direct relationships that
exist in your logical data model.
Attribute relationships form links between attributes that

enable you to join data from their respective lookup tables.
The relationships you create between attributes directly affect
how the MicroStrategy Engine joins tables and columns for
reports and even whether it can make the necessary joins.
Although you can create attribute relationships in the

Attribute Creation Wizard, you also have the option to create
them in the Attribute Editor. Whereas in the Attribute
Creation Wizard you can only define children for parent
attributes, the Attribute Editor enables you to either define
children on parent attributes or parents on child attributes.
You create attribute relationships either by opening

the parent attribute and adding children or by opening
the child attribute and adding parents. You do not
need to perform both tasks for the same set of
attributes. For example, if you add Customer State as a
parent of the Customer City attribute, this action
automatically associates Customer City as a child of
the Customer State attribute.
To create child attributes for an attribute using the Attribute

Editor:
2 In the Attribute Editor, click the Children tab.
3 On the Children tab, click Add.

4 In the Add Children Attributes window, in the Child

candidates list, hold CTRL and select the child attributes.
Any attribute whose ID column exists in a table

with the ID of the parent attribute is available as a
possible child attribute.
IfCreate
you select more than one child attribute, the
as Joint Child check box is enabled. A joint
child relationship occurs any time you have two or
more child attributes that are jointly related in
combination to a parent attribute. If the child
attributes you are adding are separately related to
the parent, you should create them as individual
children. If they are jointly related to the parent,
you should select the Create as Joint Child check
box.
5 Click the > button to add the attributes to the Selected

children list.
6 Click OK.
This action adds the attributes as children with a

default relationship type of one to many.
7 In the Attribute Editor, on the Children tab, in the

Attribute children list, in the Relationship type
drop-down list for each child attribute, select the
appropriate relationship type.

relationship types.
8 In the Relationship table drop-down list for each child

attribute, select the appropriate relationship table.

relationship tables.


The following image shows the Children tab on the Attribute

Editor:
Attribute Editor—Children Tab

The following image shows the Add Children Attributes

window:
Add Children Attributes Window

The following image shows a child attribute created for the

Month attribute:
Child Attribute Created for the Month Attribute
You can also remove child attributes using the

Attribute Editor. On the Children tab, select the child
attribute you want to remove and click Remove.
To create parent attributes for an attribute using the Attribute

Editor:
2 In the Attribute Editor, click the Parents tab.
3 On the Parents tab, click Add.

4 In the Add Parent Attributes window, in the Parent

candidates list, hold CTRL and select the parent
attributes.
Any attribute whose ID column exists in a table

with the ID of the child attribute is available as a
possible parent attribute.

parents list.
6 Click OK.
This action adds the attributes as parents with a

default relationship type of many to one.
7 In the Attribute Editor, on the Parents tab, in the

Attribute parents list, in the Relationship type drop-down
list for each parent attribute, select the appropriate
relationship type.

relationship types.
8 In the Relationship table drop-down list for each parent

attribute, select the appropriate relationship table.

relationship tables.


The following image shows the Parents tab on the Attribute

Editor:
Attribute Editor—Parents Tab

The following image shows the Add Parent Attributes

window:
Add Parent Attributes Window

The following image shows all the parent attributes created

for the Order attribute:
Parent Attributes Created for the Order Attribute
You can also remove parent attributes using the

Attribute Editor. On the Parents tab, select the parent
attribute you want to remove and click Remove.

Defining Attribute Form Display

As you learned earlier, attribute forms enable you to display
different types of information about an attribute. If you
create multiple forms for an attribute, you need to define
which forms are part of its default report and browse
displays.
Report display forms are the attribute forms that display

when an attribute is present on a report. Browse forms are
the attribute forms that display when you browse an attribute
in a hierarchy in the Data Explorer.
Attribute ID forms are automatically added to the

default report display and browse forms only if other
forms do not exist. Other types of attribute forms are
always added to the default report display and browse
forms. If you create a new form and you do not want to
use it for report display or browsing, you need to
remove it from both lists before saving the attribute.
The default report display you define at the attribute

level determines which forms users initially see when
they view an attribute on a report. However, you can
change the default form display for a particular report.
At the attribute level, you should include the forms you
need to display on most reports. You can then use the
report-level display to address any exceptions.
To define report display and browse forms for an attribute

using the Attribute Editor:
2 In the Attribute Editor, click the Display tab.
3 On the Display tab, in the Available forms list, hold CTRL

and select the forms you want to use for report display.
4 Click the upper > button to add the forms to the Report
display forms list.
5 In the Available forms list, hold CTRL and select the

forms you want to use for browsing.

6 Click the lower > button to add the forms to the Browse
forms list.

The following image shows the Display tab on the Attribute

Editor:
Attribute Editor—Display Tab
You can remove attribute forms from the default

report display or browse forms, by selecting the form
you want to remove and clicking the appropriate <
button.

The Element display settings on the Display tab of the

Attribute Editor enable you to configure various
options for attribute forms such as defining limits and
locks for browsing the system hierarchy, applying
security filters, and enabling element caching. For
information on configuring these options, see the
MicroStrategy Architect: Advanced Project Design and
MicroStrategy Administration courses.

What Is the System Hierarchy?

Describe how the system hierarchy is created and used in a
MicroStrategy project.
When you create attributes and their corresponding

relationships, you automatically create the system hierarchy.
The system hierarchy includes all the attributes in a project
and their respective relationships. It derives its structure
from the direct relationships you define between attributes.
All highest-level attributes (attributes without parents) are

entry points in the hierarchy. From these entry points, you
can then browse to other directly related attributes. The
system hierarchy is automatically updated any time you add,
modify, or remove attributes or attribute relationships.
The system hierarchy is useful for showing all the attributes

in a project and their relationships. However, its structure is
generally not the most conducive to browsing attribute data.
It does form the basis for the drill paths you use in reports to
drill up and down to directly related attributes.
You can create user hierarchies that enable users to

efficiently browse attribute data in the project. For
information on user hierarchies, see the “Working
with User Hierarchies” lesson starting on page 345.
To view the system hierarchy for a project:
2 Expand the Data Explorer browser.
3 In the Data Explorer browser, expand the System

Hierarchy.
© 2011 MicroStrategy, Inc. What Is the System Hierarchy? 311

4 In the system hierarchy, expand any attribute to view its

elements.
Only highest-level attributes that are entry points

display when you first expand the system
hierarchy.
5 Under the attribute, expand any attribute element to view

child attributes.
You can continue expanding child attributes to

view their respective elements, or you can expand
other entry points in the system hierarchy.
The following image shows the system hierarchy for a project

with one of its entry points expanded:
System Hierarchy
312 What Is the System Hierarchy? © 2011 MicroStrategy, Inc.


Exercises: Working with Attributes
In this set of exercises, you will create attributes in the My
Tutorial Project. You will also modify some of these attributes
to add more complexity to them.
Creating Attributes in the Project
Overview
In this exercise, you will use the Attribute Creation Wizard to

create attributes in the My Tutorial Project. You need to
create the following attributes:
You do not need to modify the default attribute

creation rules since all these columns are numeric or
date/time.
ID Form Expression Attribute Name
BIRTH_DATE Employee Birth

Date
BRAND_ID Brand
CALL_CTR_ID Call Center
CAT_ID Catalog
CATEGORY_ID Category
COUNTRY_ID Country
CUST_BIRTHDATE Customer Birth

Date
CUST_CITY_ID Customer City
CUST_REGION_ID Customer Region
CUST_STATE_ID Customer State
© 2011 MicroStrategy, Inc. Exercises: Working with Attributes 313

ID Form Expression Attribute Name
CUSTOMER_ID Customer
DAY_DATE Day
COUNTRY_ID, Distribution
DIST_CTR_ID Center
EDUCATION_ID Education
EMP_ID Employee
GENDER_ID Gender
HIRE_DATE Hire Date
INCOME_ID Income
ITEM_ID Item
MANAGER_ID Manager
MONTH_ID Month
MONTH_OF_YEAR Month of Year
ORDER_ID Order
PYMT_TYPE Payment Type
QUARTER_ID Quarter
REGION_ID Region
SHIP_DATE Ship Date
SHIPPER_ID Shipper
SUBCAT_ID Subcategory
SUPPLIER_ID Supplier
YEAR_ID Year
Distribution Center is a compound attribute.

You need to rename the following attributes to match the
names in the table above:
• Employee Birth Date
• Call Center
• Catalog
• Customer Birth Date
314 Exercises: Working with Attributes © 2011 MicroStrategy, Inc.

• Customer City
• Customer Region
• Customer State
• Day
• Employee
• Payment Type
• Subcategory
After you have created these attributes along with their ID

forms, you need to create the following description forms for
each attribute:
Attribute Name DESC Form Expression
Brand BRAND_DESC
Call Center CENTER_NAME
Catalog CAT_DESC
Category CATEGORY_DESC
Country COUNTRY_NAME
Customer CUST_LAST_NAME
Customer Birth Date Use ID as description
Customer City CUST_CITY_NAME
Customer Region CUST_REGION_NAME
Customer State CUST_STATE_NAME
Day Use ID as description
Education EDUCATION_DESC
Employee EMP_LAST_NAME
Employee Birth Date Use ID as description

Gender GENDER_DESC
Hire Date Use ID as description
Income BRACKET_DESC
Item ITEM_NAME

Attribute Name DESC Form Expression
Manager MGR_LAST_NAME
Month MONTH_DESC
Month of Year MONTH_OF_YEAR_NAME
Order Use ID as description
Payment Type PYMT_DESC
Quarter QUARTER_DESC
Region REGION_NAME
Ship Date Use ID as description
Shipper SHIPPER_DESC
Subcategory SUBCAT_DESC
Supplier SUPPLIER_NAME
Year Use ID as description
You will create the description form for the

Distribution Center attribute later in this exercise.
After you have created the description forms, you need to

select the following lookup tables for each attribute:
Attribute Name Lookup Table
Brand LU_BRAND
Call Center LU_CALL_CTR
Catalog LU_CATALOG
Category LU_CATEGORY
Country LU_COUNTRY
Customer LU_CUSTOMER
Customer Birth Date LU_CUSTOMER
Customer City LU_CUST_CITY
Customer Region LU_CUST_REGION
Customer State LU_CUST_STATE
Day LU_DAY

Education LU_EDUCATION
Employee LU_EMPLOYEE
Employee Birth Date LU_EMPLOYEE

Gender LU_GENDER
Hire Date LU_EMPLOYEE
Income LU_INCOME
Item LU_ITEM
Manager LU_MANAGER
Month LU_MONTH
Month of Year LU_MONTH_OF_YEAR

Order ORDER_FACT
Payment Type LU_PYMT_TYPE
Quarter LU_QUARTER
Region LU_REGION
Ship Date ORDER_FACT
Shipper LU_SHIPPER
Subcategory LU_SUBCATEG
Supplier LU_SUPPLIER
Year LU_YEAR
You will select the lookup table for the Distribution

Center attribute later in this exercise.
After you have selected the lookup tables for these attributes,
you need to define the Distribution Center attribute as
follows:
• Select LU_DIST_CTR as the lookup table
• Add DIST_CTR_NAME as the description form

After you have defined the Distribution Center attribute, you

need to create the following child relationships for each
attribute:
All relationships are one to many unless another type

of relationship is indicated in the table. One-to-one
relationships are indicated as 1:1, and many-to-many
relationships are indicated as M:M.
Attribute Name Child Attribute
Brand Item
Call Center Employee
Catalog Item (M:M)
Category Subcategory
Country Region
Country Distribution Center
Customer Order
Customer Birth Date Customer
Customer City Customer
Customer Region Customer State
Customer State Customer City
Distribution Center Call Center (1:1)
Education Customer
Employee Birth Date Employee
Gender Customer
Hire Date Employee

Income Customer
Manager Call Center (1:1)
Month Day
Month of Year Month
Payment Type Order
Quarter Month
Region Call Center
Ship Date Order

Shipper Order
Subcategory Item
Supplier Item
Year Quarter
After you have created the child relationships for these

attributes, save and close the Attribute Creation Wizard and
update the project schema.
Open the Attribute Creation Wizard for the My Tutorial

Project

Project.
2 On the Schema menu, select Attribute Creation Wizard.
Create attributes and their ID forms in the project

window, click Next.
4 In the ID Column Selection window, in the Available

columns list, hold CTRL and select the following attribute
columns:
Attribute Column
BIRTH_DATE
BRAND_ID
CALL_CTR_ID
CAT_ID
CATEGORY_ID

Attribute Column
COUNTRY_ID
CUST_BIRTHDATE
CUST_CITY_ID
CUST_REGION_ID
CUST_STATE_ID
CUSTOMER_ID
DAY_DATE
EDUCATION_ID
EMP_ID
GENDER_ID
HIRE_DATE
INCOME_ID
ITEM_ID
MANAGER_ID
MONTH_ID
MONTH_OF_YEAR
ORDER_ID
PYMT_TYPE
QUARTER_ID
REGION_ID
SHIP_DATE
SHIPPER_ID
SUBCAT_ID
SUPPLIER_ID
YEAR_ID
5 Click the > button to add the columns to the Attributes

list.

Rename selected attributes
6 In the Attributes list, right-click the following attributes,

select Rename, and rename the attributes as follows:
Original Attribute
New Attribute Name
Name
Birth Date Employee Birth Date
Call Ctr Call Center

Cat Catalog
Cust Birthdate Customer Birth Date
Cust City Customer City
Cust Region Customer Region
Cust State Customer State
Day Date Day
Emp Employee
Pymt Type Payment Type
Subcat Subcategory
Create the Distribution Center compound attribute in the

project
7 Click Compound Attributes.
8 Click Add.
9 In the New Compound Attribute window, in the

Compound attribute name box, type Distribution Center.

10 In the Available columns list, hold CTRL and select

COUNTRY_ID and DIST_CTR_ID.
Make sure that the Address column at the top of

the Available columns list is not selected, or it will
cause an error when you close this window.
11 Click OK.
The Distribution Center attribute displays under

Compound Attributes in the ID Column Selection
window. You can see its ID column components by
expanding the attribute.
Create description forms for the attributes in the project
12 In the ID Column Selection window, click Next.
13 In the Description Column Selection window, in the

Attributes list, in the Description column name
drop-down list, select the following description columns
for each attribute:
For many of these attributes, MicroStrategy

Architect selects the correct column automatically.
You need only to verify that these attributes map to
the correct description columns.
Attribute Name Description Column
Brand BRAND_DESC
Call Center CENTER_NAME

Catalog CAT_DESC
Category CATEGORY_DESC
Country COUNTRY_NAME
Customer CUST_LAST_NAME
Customer Birth Date Use ID as description
Customer City CUST_CITY_NAME
Customer Region CUST_REGION_NAME
Customer State CUST_STATE_NAME
Day Use ID as description

Attribute Name Description Column
Education EDUCATION_DESC
Employee EMP_LAST_NAME
Employee Birth Date Use ID as description

Gender GENDER_DESC
Hire Date Use ID as description
Income BRACKET_DESC
Item ITEM_NAME
Manager MGR_LAST_NAME
Month MONTH_DESC
Month of Year MONTH_OF_YEAR_NAME

Order Use ID as description
Payment Type PYMT_DESC
Quarter QUARTER_DESC
Region REGION_NAME
Ship Date Use ID as description
Shipper SHIPPER_DESC
Subcategory SUBCAT_DESC
Supplier SUPPLIER_NAME
Year Use ID as description

Select lookup tables for the attributes in the project
14 Click Next.
15 In the Lookup Table Selection window, in the Attributes

list, in the Lookup Table Name drop-down list, select the
following lookup tables for each attribute:
For many of these attributes, MicroStrategy

Architect selects the correct lookup table
automatically. You need only to verify that these
attributes map to the correct lookup tables.
Brand LU_BRAND
Call Center LU_CALL_CTR
Catalog LU_CATALOG
Category LU_CATEGORY
Country LU_COUNTRY
Customer LU_CUSTOMER
Customer Birth Date LU_CUSTOMER
Customer City LU_CUST_CITY
Customer Region LU_CUST_REGION
Customer State LU_CUST_STATE
Day LU_DAY
Education LU_EDUCATION
Employee LU_EMPLOYEE
Employee Birth Date LU_EMPLOYEE
Gender LU_GENDER
Hire Date LU_EMPLOYEE
Income LU_INCOME
Item LU_ITEM
Manager LU_MANAGER
Month LU_MONTH
Month of Year LU_MONTH_OF_YEAR

Order ORDER_FACT
Payment Type LU_PYMT_TYPE
Quarter LU_QUARTER
Region LU_REGION
Ship Date ORDER_FACT
Shipper LU_SHIPPER
Subcategory LU_SUBCATEG
Supplier LU_SUPPLIER
Year LU_YEAR
Select the lookup table and add the description form for
the Distribution Center attribute
16 Click Next.
17 In the Compound Attribute Definition window, in the ID

lookup table for drop-down list, select LU_DIST_CTR.
18 Click Add.
19 In the Description Columns window, in the Available

columns list, select DIST_CTR_NAME.
20 Click OK.

Create child relationships for the attributes in the project
21 In the Compound Attribute Definition window, click

Next.
22 In the Relationship Definition window, create the

following child relationships for each attribute using the
steps listed below the table:
All relationships are one to many unless another

type of relationship is indicated in the table.
One-to-one relationships are indicated as 1:1, and
many-to-many relationships are indicated as M:M.
Brand Item
Call Center Employee
Catalog Item (M:M)
Category Subcategory
Country Region
Country Distribution Center
Customer Order
Customer Birth Date Customer
Customer City Customer
Customer Region Customer State
Customer State Customer City
Distribution Center Call Center (1:1)
Education Customer
Employee Birth Date Employee
Gender Customer
Hire Date Employee

Income Customer
Manager Call Center (1:1)
Month Day
Month of Year Month

Payment Type Order
Quarter Month
Region Call Center
Ship Date Order
Shipper Order
Subcategory Item
Supplier Item
Year Quarter
In the Attributes list, select an attribute.
Click Add.
In the Select Children Attributes window, in the Available

children for list, select the child attribute.
Click OK.
If you need to change the relationship type, in the

Relationship Definition window, in the Children of list, in
the Relationship type drop-down list, select the
appropriate relationship type.
Repeat these steps for each attribute in the table until you
have created all the child relationships.
Save and close the Attribute Creation Wizard
23 Click Next.
24 In the Finish window, click Finish.

Modifying Attributes in the Project
Overview
In this exercise, you will use the Attribute Editor to modify

the Customer, Day, Employee, Item, and Manager
attributes you created in the My Tutorial Project. You need to
create or modify the following forms and expressions for
these attributes:
Ifresult
an attribute form or expression already exists as a
of the work you completed in the Attribute
Creation Wizard and it is not listed in the table below,
you should keep its current definition.
Attribute Forms Expressions Source Tables Report Display Browse
Customer DESC CUST_LAST_NAME + “, ”+ LU_CUSTOMER Yes Yes

CUST_FIRST_NAME
First Name CUST_FIRST_NAME LU_CUSTOMER No No
Last Name CUST_LAST_NAME LU_CUSTOMER No No

Address ADDRESS LU_CUSTOMER No Yes
E-mail EMAIL LU_CUSTOMER No Yes
Day ID ORDER_DATE ORDER_DETAIL Yes Yes
ORDER_FACT
Employee DESC EMP_LAST_NAME + “, ” + LU_EMPLOYEE Yes Yes

EMP_FIRST_NAME
First Name EMP_FIRST_NAME LU_EMPLOYEE No No

Last Name EMP_LAST_NAME LU_EMPLOYEE No No
SSN EMP_SSN LU_EMPLOYEE No Yes
Item Long DESC ITEM_LONG_DESC LU_ITEM No Yes

Manager DESC MGR_LAST_NAME + “, ” + LU_MANAGER Yes Yes
MGR_FIRST_NAME
First Name MGR_FIRST_NAME LU_MANAGER No No
Last Name MGR_LAST_NAME LU_MANAGER No No

As you create or modify these attributes, you should do the

following:
• Use automatic mapping for all attribute form expressions
• Use None as the form category for all forms other than
the ID and primary description (DESC)
• Define the report display and browse forms as indicated

for each attribute
After you have modified all these attributes, update the

project schema.
is a separate set of instructions for each attribute you modify.
Detailed Instructions—Customer Attribute
Open the Attribute Editor
1 In the My Tutorial Project, expand the Schema Objects

folder.
2 In the Schema Objects folder, select the Attributes folder.
3 In the Attributes folder, double-click the Customer

attribute.
Modify the DESC form for the Customer attribute

forms list, select the DESC form.
5 Click Modify.

tab, click Modify.
7 In the Modify Form Expression window, in the Form

expression box, modify the expression to look like the
following:
CUST_LAST_NAME + ", " + CUST_FIRST_NAME
8 Under Mapping method, keep Automatic selected.

9 Click OK.
Create the First Name form for the Customer attribute
12 In the Create New Form Expression window, in the Form

expression box, create the following expression:
CUST_FIRST_NAME
14 Click OK.
15 In the Create New Attribute Form window, on the

Definition tab, in the Name box, type First Name.
16 Click OK.
Create the Last Name form for the Customer attribute

CUST_LAST_NAME
20 Click OK.

Definition tab, in the Name box, type Last Name.
22 Click OK.
Create the Address form for the Customer attribute

ADDRESS

26 Click OK.

Definition tab, in the Name box, type Address.
28 Click OK.
Create the E-mail form for the Customer attribute

EMAIL
32 Click OK.

Definition tab, in the Name box, type E-mail.
34 Click OK.
Define the report display forms for the Customer attribute
35 In the Attribute Editor, click the Display tab.
36 On the Display tab, in the Report display forms list, select

the First Name form.
37 Click the upper < button to remove it from the Report

display forms list.
38 In the Report display forms list, select the Last Name

form.

display forms list.
40 In the Report display forms list, select the Address form.

display forms list.

42 In the Report display forms list, select the E-mail form.

display forms list.
Define the browse forms for the Customer attribute
44 In the Browse forms list, select the First Name form.
45 Click the lower < button to remove it from the Browse

forms list.
46 In the Browse forms list, select the Last Name form.
47 Click the lower < button to remove it from the Browse

forms list.
Save and close the Customer attribute
Detailed Instructions—Day Attribute
1 In the Attributes folder, double-click the Day attribute.
Modify the ID form for the Day attribute

forms list, select the ID form.
3 Click Modify.

tab, click New.
5 In the Create New Form Expression window, in the

Source table drop-down list, select ORDER_DETAIL.
6 In the Form expression box, create the following

expression:
ORDER_DATE

8 Click OK.
Save and close the Day attribute
Detailed Instructions—Employee Attribute

attributes using step-by-step instructions, these
1 Open the Employee attribute in the Attribute Editor.
Modify the DESC form for the Employee attribute
2 In the Attribute Editor, modify the expression for the

DESC form to look like the following:
EMP_LAST_NAME + ", " + EMP_FIRST_NAME
You can find these columns in the LU_EMPLOYEE

table.
3 Keep Automatic as the mapping method.
4 Click OK.
Create the First Name form for the Employee attribute
6 In the Attribute Editor, create a First Name form with the

following expression:
EMP_FIRST_NAME
8 Click OK.

9 In the Create New Attribute Form window, change the

form name to First Name.
10 Click OK.
Create the Last Name form for the Employee attribute
11 In the Attribute Editor, create a Last Name form with the

EMP_LAST_NAME
13 Click OK.

form name to Last Name.
15 Click OK.
Create the SSN form for the Employee attribute
16 In the Attribute Editor, create an SSN form with the

EMP_SSN
18 Click OK.

form name to SSN.
20 Click OK.
Define the report display forms for the Employee attribute
21 In the Attribute Editor, remove the First Name, Last

Name, and SSN forms from the list of report display
forms.

Define the browse forms for the Employee attribute
22 Remove the First Name and Last Name forms from the
list of browse forms.
Save and close the Employee attribute
23 Save and close the Employee attribute.
Detailed Instructions—Item Attribute

1 Open the Item attribute in the Attribute Editor.
Create the Long DESC form for the Item attribute
2 In the Attribute Editor, create a Long DESC form with

the following expression:
ITEM_LONG_DESC
You can find this column in the LU_ITEM table.

4 Click OK.

form name to Long DESC.
6 Click OK.
Define the report display forms for the Item attribute
7 In the Attribute Editor, remove the Long DESC form

from the list of report display forms.
Save and close the Item attribute
8 Save and close the Item attribute.

Detailed Instructions—Manager Attribute

1 Open the Manager attribute in the Attribute Editor.
Modify the DESC form for the Manager attribute
2 In the Attribute Editor, modify the expression for the

DESC form to look like the following:
MGR_LAST_NAME + ", " + MGR_FIRST_NAME
You can find these columns in the LU_MANAGER

table.
3 Keep Automatic as the mapping method.
4 Click OK.
Create the First Name form for the Manager attribute
6 In the Attribute Editor, create a First Name form with the

MGR_FIRST_NAME
8 Click OK.

form name to First Name.
10 Click OK.

Create the Last Name form for the Manager attribute
11 In the Attribute Editor, create a Last Name form with the

MGR_LAST_NAME
13 Click OK.

form name to Last Name.
15 Click OK.
Define the report display forms for the Manager attribute
16 In the Attribute Editor, remove the First Name and Last

Name forms from the list of report display forms.
Define the browse forms for the Manager attribute
17 Remove the First Name and Last Name forms from the
list of browse forms.
Save and close the Manager attribute
18 Save and close the Manager attribute.

Adding More Attributes to the Project
Overview
In this exercise, you will use the Attribute Editor to create the
Salary and Warranty attributes in the My Tutorial Project.
You need to define these attributes as follows:
Both child attribute relationships are one to many.

Attribute ID Form Expression Source Tables Child Attribute
Salary SALARY LU_EMPLOYEE Employee
Warranty WARRANTY LU_ITEM Item
You should use automatic mapping for all attribute form

expressions.
You should save the attributes in the Schema

Objects\Attributes folder.
After you have created both attributes, update the project

schema.
is a separate set of instructions for each attribute you create.

Detailed Instructions—Salary Attribute
Since you have already used the Attribute Editor to

modify several different attributes using step-by-step
instructions, these instructions are written at a higher
level to help better test your understanding.
Create the Salary attribute
2 In the Attribute Editor, create an ID form with the

SALARY
You can find this column in the LU_EMPLOYEE

table.
4 Click OK.
5 In the Create New Attribute Form window, click OK.
Add Employee as a child of the Salary attribute
6 In the Attribute Editor, add Employee as a child

attribute.
7 Click OK.
8 In the Attribute Editor, keep the default relationship type

and relationship table.
Save and close the Salary attribute
9 Save the Salary attribute in the Schema

10 Close the Attribute Editor.

Detailed Instructions—Warranty Attribute
Since you have already used the Attribute Editor to

modify several different attributes using step-by-step
instructions, these instructions are written at a higher
level to help better test your understanding.
Create the Warranty attribute
2 In the Attribute Editor, create an ID form with the

WARRANTY
You can find this column in the LU_ITEM table.

4 Click OK.
5 In the Create New Attribute Form window, click OK.
Add Item as a child of the Warranty attribute
6 In the Attribute Editor, add Item as a child attribute.
7 Click OK.
8 In the Attribute Editor, keep the default relationship type

and relationship table.
Save and close the Warranty attribute
9 Save the Warranty attribute in the Schema

10 Close the Attribute Editor.

Lesson Summary
• The third task in the project creation workflow is to create
the attributes for a MicroStrategy project and define any
direct relationships between attributes.
• You use attributes as components in reports. On

templates, attributes enable you to describe metrics at
various levels. In filters, attributes enable you to qualify
the result set of a report based on attribute data.
• Attribute forms enable you to display different types of

descriptive information about an attribute. They map
directly to columns in the data warehouse.
• All attributes have an ID form, and most have at least one
primary description form.
• Attribute forms must have a one-to-one relationship with
other forms of the same attribute.
• You can use attribute forms for report display, sorting,

and qualification.
• A compound attribute is one that uses two or more

columns as its ID. It requires a compound primary key to
uniquely identify its elements.
• A homogeneous attribute is one where each attribute form

points to the same column or set of columns in every table
to which it maps.
• A heterogeneous attribute is one where at least one

attribute form points to two or more different columns or
sets of columns in the tables to which it maps.
• An attribute form expression consists of a column or set of

columns to which the attribute form maps. All attribute
forms have at least one expression. Attribute forms can
have any number of expressions.
• A simple attribute form expression is one that maps

directly to a single attribute column. It can map to that
same column for any number of tables.

• A derived attribute form expression is one that maps to an

expression from which the attribute values are obtained.
It can contain multiple attribute columns from the same
table, mathematical operators, constants, and various
functions.
• You can use the Attribute Creation Wizard to create

multiple attributes very quickly. You generally use it
during initial project creation, but you can use it any time
you need to create a large number of attributes.
• With the Attribute Creation Wizard, you are limited to

creating basic attributes. Basic attributes are ones that are
homogenous, use only simple form expressions, and have
no more than two attribute forms (an ID and primary
description).
• You can begin defining more complex attributes in the

Attribute Creation Wizard, but you need to complete their
definitions in the Attribute Editor.
• You can access the Attribute Creation Wizard as part of

the Project Creation Assistant, or you can launch it
directly from the Schema menu in MicroStrategy Desktop.
• When you first open the Attribute Creation Wizard, you

can define the rules that govern how it works. You can
select which column data types the Attribute Creation
Wizard displays, choose how it renames attribute
columns, and provide the naming conventions you use in
the data warehouse for ID and description columns and
lookup tables.
• Creating attributes in the Attribute Creation Wizard

involves the following tasks: creating attribute ID forms,
creating attribute description forms, selecting lookup
tables for attributes, and creating attribute relationships.
The wizard has a separate window for each of these tasks.
• Attributes are stored in the Schema Objects\Attributes

folder.
• The Attribute Creation Wizard provides the easiest

method for creating compound attributes because it
contains functions specific to these attributes.

• You can use the Attribute Editor to create individual

attributes, modify existing attributes, or add complexity
to attributes you initially created in the Attribute Creation
Wizard.
• Attribute form properties include the form definition,

form name and description, form category, and form
format.
• You can use the Attribute Editor to create simple or

derived attribute form expressions. You can also create
heterogeneous attributes that have forms with multiple
expressions.
• You can create compound attributes in the Attribute

Editor by assigning two or more attributes to the ID form
category, which creates a form group.
• You can use the Attribute Editor to modify existing

attributes, including the following tasks: creating new
attribute forms; modifying existing attribute forms;
deleting existing attribute forms; and modifying lookup
tables, attribute keys, and column aliases.
• The attribute key is the attribute form that functions as

the unique identifier for an attribute. By default, the ID
form for an attribute is used as the attribute key.
• The column alias specifies the data type that the

MicroStrategy Engine uses for an attribute form when it
generates SQL for temporary tables.
• Every attribute form you create has a default column

alias. An attribute form inherits its data type from the
column on which it is defined. If an attribute form maps
only to a derived expression, MicroStrategy Architect
creates a custom column alias. If an attribute form has
multiple expressions, the alias uses the column name and
data type of the first expression you create.
• Most of the time, you do not need to modify the column

alias for an attribute form. However, there are specific
scenarios in which you may need to change the default
data type to avoid possible database errors.
• Attribute relationships form links between attributes that

enable you to join data from their respective lookup
tables.

• You can use the Attribute Editor to create parent and child
relationships between attributes.
• If you create multiple attribute forms for an attribute, you

need to define which forms are part of its default report
and browse displays.
• Report display forms are attribute forms that display

when an attribute is present on a report.
• Browse forms are attribute forms that display when you

browse an attribute in a hierarchy in the Data Explorer.
• You use the Attribute Editor to define the default report

display and browse forms for an attribute.
• When you create attributes and their corresponding

relationships, you automatically create the system
hierarchy.
• The system hierarchy includes all the attributes in a

project and their respective relationships. It derives its
structure from the direct relationships you define between
attributes.
• The system hierarchy is automatically updated any time

you add, modify, or remove attributes or attribute
relationships.
• The system hierarchy forms the basis for the drill paths
you use in reports to drill up and down to directly related
attributes.

8
WORKING WITH USER
HIERARCHIES
Lesson Description
This lesson describes how to work with user hierarchies when

creating a project in MicroStrategy Architect.
In this lesson, you will learn how user hierarchies are used in
a MicroStrategy project. Then, you will learn how to create
user hierarchies, define user hierarchy elements, and define
the sort order for user hierarchies using the Hierarchy Editor.

8 Working with User Hierarchies MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe how user hierarchies are used in a MicroStrategy
project and create user hierarchies, define user hierarchy
elements, and define the sort order for user hierarchies using
Hierarchy Editor.
• Describe how user hierarchies are used in a MicroStrategy

project. (Page 347)
• Create user hierarchies, define user hierarchy elements,

and define the sort order for user hierarchies using the
Hierarchy Editor. (Page 352)

MicroStrategy Architect: Project Design Essentials Working with User Hierarchies 8
What Is a User Hierarchy?

Describe how user hierarchies are used in a MicroStrategy
project.
In the previous lesson, you learned how to create the

attributes and their relationships for a MicroStrategy project,
which is the third task in the project creation workflow as
shown in the following image:
The final task in the project creation workflow is to create the

user hierarchies for your MicroStrategy project. User
hierarchies provide convenient paths for browsing attribute
data. They may or may not reflect the structure of the
hierarchies in your logical data model. Instead, you define the
structure of user hierarchies based on how users need to
browse data.
© 2011 MicroStrategy, Inc. What Is a User Hierarchy? 347

For example, if users typically browse geography data at the

employee level, you could create a user hierarchy that enables
users to navigate from the Region attribute, a higher-level
attribute in the hierarchy, directly to the Employee attribute,
the lowest-level attribute in the hierarchy. The following
illustration shows how the hierarchy from the logical data
model and the user hierarchy might differ in structure:
Logical Data Model Versus User Hierarchy
The logical data model does not have a direct path between
the Region and Employee attributes. You have to go through
the Call Center attribute. However, if users need to browse
directly from Region to Employee, you can include this path
in the user hierarchy, eliminating the need to have to browse
call center data first.
User hierarchies are also not limited to directly related

attributes. You can include attributes from different
hierarchies in the logical data model in the same user
hierarchy.
348 What Is a User Hierarchy? © 2011 MicroStrategy, Inc.

For example, if users often browse data by Region and

Month, you could create a user hierarchy that includes these
attributes, even though they are not directly related. The
following illustration shows how a user hierarchy can
combine attributes from different hierarchies in the logical
data model:
User Hierarchy with Unrelated Attributes
Even though Region and Month are from different

hierarchies in the logical data model, combining them in a
user hierarchy together provides quick access to browse
between these attributes.
Although user hierarchies are not required in a MicroStrategy

project, they are certainly helpful for users. Ultimately, you
need to consider how users navigate attribute data to
determine the best structure for any user hierarchies you
create.

When you create user hierarchies for browsing, they are

available to users throughout the project. For example, users
can access them in the Data Explorer browser, the Object
Browser within object editors, and prompts. The following
illustration shows a few examples of how user hierarchies
enable users to accomplish routine tasks within a project:
Browsing User Hierarchies
350 What Is a User Hierarchy? © 2011 MicroStrategy, Inc.

In addition to providing users with a convenient method of

browsing attribute data throughout the project, you can also
configure user hierarchies as drill paths for analyzing report
data. The following illustration shows how users can drill on
user hierarchies within reports:
Drilling on User Hierarchies

Using the Hierarchy Editor

Create user hierarchies, define user hierarchy elements, and
define the sort order for user hierarchies using the Hierarchy
Editor.
The Project Creation Assistant does not have a wizard for

creating user hierarchies since they are not required for a
MicroStrategy project. Instead, you create and modify user
hierarchies using the Hierarchy Editor. The Hierarchy Editor
is one of the schema object editors available in MicroStrategy
Architect. It enables you to configure a variety of
hierarchy-related settings.
You cannot directly modify the system hierarchy

using the Hierarchy Editor. Instead, you change the
system hierarchy indirectly by adding, modifying, or
removing attributes and attribute relationships.
To access the Hierarchy Editor:
If you are creating a new user hierarchy, on the File menu,

point to New and select Hierarchy.
OR
If you are modifying an existing user hierarchy, in the

Schema Objects folder, expand the Hierarchies folder.
In the Hierarchies folder, select the Data Explorer folder.
Ifcantheaccess
user hierarchy is not used for browsing, you
it directly from the Hierarchies folder.
In the Data Explorer folder, double-click the user

hierarchy you want to modify.
352 Using the Hierarchy Editor © 2011 MicroStrategy, Inc.

The following image shows the Hierarchy Editor:

Hierarchy Editor
When you create a new user hierarchy, the Select

Objects window opens first, so you can select the
attributes to include in the hierarchy. After you select
the desired attributes, the Hierarchy Editor opens.
© 2011 MicroStrategy, Inc. Using the Hierarchy Editor 353

Creating User Hierarchies

You can use the Hierarchy Editor to create as many user
hierarchies as you need for a project. The primary task in
creating a user hierarchy is to select the attributes you want
to include in the hierarchy.
To create a user hierarchy using the Hierarchy Editor:
1 Open the Hierarchy Editor.
2 In the Select Objects window, in the Available objects list,

hold CTRL and select the attributes you want to include in
the user hierarchy.
The Available objects list displays the contents of

the Schema Objects\Attributes folder. If you have
created your project attributes in subfolders, you
need to browse to the appropriate subfolders to
select the attributes.

objects list.
4 Click OK.
5 In the Hierarchy Editor, make any necessary changes to

the user hierarchy.
For information on the various elements you can

define for a user hierarchy, see “Defining User
Hierarchy Elements” starting on page 358.
After closing the Hierarchy Editor, you can update


The following image shows the Select Objects window:

Select Objects Window

The following image shows the Time user hierarchy, which

includes the Year, Quarter, Month, and Day attributes:
Time User Hierarchy
Saving User Hierarchies
When you create a user hierarchy, you can save it in the

Schema Objects\Hierarchies folder. However, if you want to
make the hierarchy available for browsing in the Data
Explorer, you have to save it in the Schema
Objects\Hierarchies\Data Explorer folder. Saving user
hierarchies to this folder also makes them available for
browsing data when you create reports and other application
objects.
The Data Explorer browser reads from this folder, so

only user hierarchies in this folder are visible in the
browser.

When you create a new user hierarchy and save it in the Data
Explorer folder, you have to refresh the Data Explorer
browser for the hierarchy to display under the browser.
To refresh the Data Explorer browser:
1 Select the Data Explorer browser.
Click Refresh object with latest definition.
OR
Press F5.
The following image shows the Time user hierarchy stored in

the Data Explorer folder and available in the Data Explorer
browser:
Time User Hierarchy Available for Browsing
Inbrowser
addition to user hierarchies, the Data Explorer
automatically displays the system hierarchy.

Defining User Hierarchy Elements

After you initially create a user hierarchy and select its
attributes, you can use the Hierarchy Editor to define the
various elements of the hierarchy. These characteristics
determine the structure of the user hierarchy and how it
functions.
Defining user hierarchy elements includes the following

tasks:
• Defining browse attributes
• Setting entry points

• Setting element display
• Defining attribute filters
• Configuring a user hierarchy for drilling
The following topics describe each of these tasks in more

detail.
Defining Browse Attributes
You can define the browse attributes for each attribute in a

user hierarchy. Browse attributes are the attributes to which
you can directly browse from any given attribute.
By default, when you create a user hierarchy, only the

immediate children of a parent attribute are defined as
browse attributes. However, if you want to provide direct
access to more attribute levels, you can select additional
browse attributes.
Browse attributes are indicated by a line that connects the

two attributes.

To define browse attributes for a user hierarchy using the

Hierarchy Editor:
1 Open the user hierarchy in the Hierarchy Editor.
2 In the Hierarchy Editor, select an attribute for which you

want to define browse attributes.
3 Right-click the attribute and select Define Browse

Attributes.
4 In the Browse Attributes window, in the Available

attributes list, hold CTRL and select the attributes you
want to define as browse attributes.

attributes list.
6 Click OK.
7 Repeat steps 2 to 6 for all attributes for which you want to

define browse attributes.
8 When you have defined all the browse attributes, click

Save and Close.


The following image shows the Time user hierarchy with

additional browse attributes defined for the Year and Quarter
attributes:
Time User Hierarchy—Browse Attributes
Setting Entry Points
You can also set the entry points for a user hierarchy. Entry
points are the attributes that display when you first open a
user hierarchy. You can begin browsing a user hierarchy from
any attribute that is an entry point.
By default, when you create a user hierarchy, only the

highest-level attributes (those without a parent) are defined
as entry points. However, if you want to provide direct access
to other attributes in the hierarchy, you can set those
attributes as entry points.

Attributes that are entry points for a user hierarchy are

indicated by a green checkmark beside the attribute icon.
To set the entry points for a user hierarchy using the

Hierarchy Editor:
2 In the Hierarchy Editor, select an attribute you want to

use as an entry point.
3 Right-click the attribute and select Set as entry point.
4 Repeat steps 2 to 3 for all attributes you want to set as

entry points.
5 When you have set all the entry points, click Save and
Close.


The following image shows the Time user hierarchy with the
Year, Quarter, and Month attributes all defined as entry
points:
Time User Hierarchy—Entry Points

Setting Element Display
You can also set the element display for attributes in a user
hierarchy. The element display setting determines the extent
to which you can browse attribute elements. You have the
following options for configuring an attribute’s element
display:
• Unlocked—You can browse all the elements of an

attribute at one time.
• Locked—You cannot browse the elements of an attribute

at all.
• Limit—You can browse a specified number of elements for

an attribute. You can then either retrieve the next set of
elements or return to browsing the previous set of
elements.
By default, the element display for attributes is unlocked

when you add them to a user hierarchy. However, you can
choose to lock or limit the element display of any attribute.
You generally use locks and limits on attributes either to
enforce security requirements on specific data or conserve
system resources by restricting the volume of data retrieved
for attributes that have a large number of elements.
Locking or limiting the element display for an

attribute only affects how you can browse it in that
particular user hierarchy. You can use different
element display settings for the same attribute in other
user hierarchies.
Attributes that are locked for a user hierarchy are indicated

by a padlock beside the attribute icon.
To set the element display for a user hierarchy using the

Hierarchy Editor:
2 In the Hierarchy Editor, select an attribute for which you

want to set the element display.

If you want to unlock the element display for the attribute,

right-click the attribute, point to Element Display, and
select Unlocked.
Attributes are always unlocked when you first add

them to a user hierarchy.
OR
If you want to lock the element display for the attribute,

select Locked.
OR
If you want to limit the element display for the attribute,

select Limit.
In the Limit window, in the Limit box, type the number of

elements you want to display at one time.
Click OK.
4 Repeat steps 2 to 3 for all attributes for which you want to

set the element display.
5 When you have set the element display for the desired
attributes, click Save and Close.


element display for the Day attribute unlocked:
Day Attribute—Unlocked Element Display

element display for the Day attribute locked:
Day Attribute—Locked Element Display

element display for the Day attribute limited to displaying 10
elements at one time:
Day Attribute—Limited Element Display
You can double-click Previous 10 elements to return

to browsing the first 10 days in the month, or you can
double-click Next 10 elements to retrieve and view
the next 10 days in the month.
Defining Attribute Filters
You can also define filters on the attributes in a user

hierarchy. Attribute filters on a user hierarchy control the
data displayed for the attributes to which they are applied. A
filter on an attribute in a hierarchy works just like a filter on a
report. Only attribute elements that match the filter
conditions display when you browse the attribute.
You can apply any type of filter to user hierarchies. For

example, you can use filters that contain metric
qualifications, multiple conditions, or reports in their
definition.

For example, if you browse the Year attribute with a filter for
2008, you see only the data for 2008. If users perform most
of their analysis on 2008 data, this filter enables them to
quickly access the necessary timeframe without having to
retrieve and browse through data for other years in the data
warehouse.
Attribute filters on a user hierarchy are not a security

measure to prevent users from viewing attribute data.
Rather, you use them to restrict the results of a browse
request to the specific information users need to
analyze without retrieving unnecessary data.
By default, a user hierarchy does not have any filters applied

to it. You define filters on a user hierarchy at the attribute
level. Therefore, if a hierarchy has multiple entry points, you
need to define the same filter on each one to ensure that the
filter conditions are applied regardless of where a user begins
browsing the hierarchy.
Attributes that have a filter applied to them for a user

hierarchy are indicated by a filter icon beside the attribute
icon.
To define attribute filters for a user hierarchy using the

Hierarchy Editor:
2 In the Hierarchy Editor, select an attribute on which you

want to define a filter.
3 Right-click the attribute and select Define Attribute

Filters.
Ifabout
you see a message window that displays a tip
using filters in the Hierarchy Editor, click
OK.
Ifcreate
no filters exist in the project, you can choose to
one. This action opens the Filter Editor for
you to create the filter. Then, you can apply it in the
Hierarchy Editor.


select the filter you want to use.
The Available objects list displays filters stored in

the Public Objects\Filters folder, but you can
browse to any filter in the project.
You can select multiple filters to apply to an

attribute.
5 Click the > button to add the filter to the Selected objects
list.
6 Click OK.
7 Repeat steps 2 to 6 for all attributes that are entry points.
8 When you have defined the attribute filter on all entry

points, click Save and Close.


The following image shows the Time user hierarchy with a

filter defined on the Year, Quarter, and Month attributes:
Time User Hierarchy—Attribute Filters
Configuring a User Hierarchy for Drilling
User hierarchies are generally used for browsing attribute

data, but you can also configure them for drilling. When you
choose to make a user hierarchy available for drilling, it
displays as a drill path for attributes in reports.
By default, a user hierarchy is configured for drilling. You can

use a single hierarchy for browsing, drilling, or both tasks.
Ifdisplayed
you configure a user hierarchy for drilling, it is
on the Other directions drill menu. For
information on drilling, see the MicroStrategy
Desktop: Reporting Essentials course.

To configure a user hierarchy for drilling using the Hierarchy

Editor:
2 In the Hierarchy Editor, ensure that the Use as a drill

hierarchy check box is selected.
Ifyouyoufirstconfigure a user hierarchy for drilling, when

save the hierarchy, you see a message
window confirming that you have defined the
hierarchy as a drill hierarchy. Click OK.


The following image shows the Time user hierarchy

configured for drilling:
Time Hierarchy Configured for Drilling
Defining the Sort Order for User Hierarchies

When you create user hierarchies, you can define the sort
order used to display their attributes. You customize the sort
order for user hierarchies by using a combination of settings
in the Project Configuration Editor and Hierarchy Editor.
These options enable you to define sort orders for browsing
and drilling.

Defining the Sort Order for Browsing
By default, when you create a user hierarchy for browsing, its

attributes display in alphabetical order. However, it may
make more sense to users for the attributes to display in a
logical order based on their relationships. You can customize
the order in which the attributes display.
The sort order you define for browsing also applies to

hierarchy prompts since these objects are based on
browsing user hierarchies.
To define the sort order for a browsing user hierarchy:
1 In MicroStrategy Desktop, right-click the project that

contains the user hierarchy for which you want to define
the sort order and select Project Configuration.
2 In the Project Configuration Editor, under the Project

definition category, select Advanced.
3 Under Advanced Prompt Properties, clear the Display

Attribute alphabetically in hierarchy prompt check box.
4 Click OK.
5 In the Schema Objects folder, in the Hierarchies folder, in

the Data Explorer folder, right-click the user hierarchy for
which you want to define the sort order and select Edit.
6 In the Hierarchy Editor, on the Edit menu, select Add

Attributes.
7 In the Select Objects window, using the arrow buttons to

the right of the Selected objects list, change the order of
the attributes in the user hierarchy to the desired display
order.
After you clear the project-level setting, the order

of the attributes in the Selected objects list
determines the order in which they display in the
user hierarchy.

8 Click OK.
9 In the Hierarchy Editor, click Save and Close.

The following image shows the sort order setting for

browsing user hierarchies in the Project Configuration
Editor:
Project Configuration Editor—Sort Order Setting for
Browsing User Hierarchies

The following image shows the Select Objects window with a

customized sort order for the attributes in the Time user
hierarchy:
Select Objects Window—Customized Sort Order for
Attributes
The attributes in the Time user hierarchy are ordered from

highest to lowest rather than alphabetically.

When you view the user hierarchy in the Data Explorer, the
attributes display using this same sort order, as shown in the
following image:
Data Explorer—Customized Sort Order for Attributes
Inbecause
the image above, the Day attribute does not display
it is not an entry point for the user hierarchy.
You may need to refresh the user hierarchy in the Data

Explorer browser to see the customized sort order.
Defining the Sort Order for Drilling
By default, when you create a user hierarchy for drilling, its

attributes display according to their order in the Hierarchy
Editor. If you do not customize the sort order of the attributes
in the Hierarchy Editor, they display in alphabetical order.
However, you can change the sort order to arrange the
attributes in whatever order is most convenient for users
when drilling on reports.
Ifandyoudrilling,
configure a user hierarchy for both browsing
you can only define one sort order. If you
want the user hierarchy to display attributes using
different sort orders depending on whether you use it
for browsing or drilling, you must create separate user
hierarchies for browsing and drilling.

To define the sort order for a drilling user hierarchy:
1 In MicroStrategy Desktop, right-click the project that

contains the user hierarchy for which you want to define
the sort order and select Project Configuration.
2 In the Project Configuration Editor, under the Project

definition category, select Drilling.
3 Under Advanced, clear the Sort drilling options in

ascending alphabetical order check box.
Bymaydefault, this check box is not selected, so you

not need to change this setting.
4 Click OK.
5 In the Schema Objects folder, in the Hierarchies folder,

right-click the hierarchy for which you want to define the
sort order and select Edit.
6 In the Hierarchy Editor, on the Edit menu, select Add

Attributes.
7 In the Select Objects window, using the arrow buttons to

the right of the Selected objects list, change the order of
the attributes in the user hierarchy to the desired display
order.
After you clear the project-level setting, the order

of the attributes in the Selected objects list
determines the order in which they display in the
user hierarchy.
8 Click OK.
9 In the Hierarchy Editor, click Save and Close.


The following image shows the sort order setting for drilling
user hierarchies in the Project Configuration Editor:
Project Configuration Editor—Sort Order Setting for
Drilling User Hierarchies

The following image shows the Select Objects window with a

customized sort order for the attributes in the Time user
hierarchy:
Select Objects Window—Customized Sort Order for
Attributes
The attributes in the Time user hierarchy are ordered from

the most to least frequently used attribute for drilling.

When you view the user hierarchy while drilling on a report,

the attributes display using this same sort order, as shown in
the following image:
Drilling on a Report—Customized Sort Order for Attributes


Exercises: Working with User Hierarchies
In this set of exercises, you will first create user hierarchies in
the My Tutorial Project, which completes the basic schema
objects you need for this project. Then, you will create a
simple report within the project.
Creating User Hierarchies in the Project

In these exercises, you will use the Hierarchy Editor to create
user hierarchies in the My Tutorial Project. You need to
create the following user hierarchies:
• Customers
• Geography (USA)
• Products
• Time
Because of the number of tasks involved in creating user

hierarchies, there is a separate overview and set of
instructions for each user hierarchy you create.
© 2011 MicroStrategy, Inc. Exercises: Working with User Hierarchies 381

Overview—Customers User Hierarchy
In this exercise, you will use the Hierarchy Editor to create a

Customers user hierarchy for the customer attributes in the
My Tutorial Project. The following table shows which
attributes to include in the user hierarchy and how to define
them:
Customers User Hierarchy
Attributes Browse Attributes Entry Point Element Display
Customer Order Yes Limit of 100
Customer Birth Date Customer Yes Limit of 100
Customer City Customer Yes Unlocked
Customer Region Customer State, Customer Yes Unlocked

City
Customer State Customer City, Customer Yes Unlocked
Education Customer Yes Unlocked
Gender Customer Yes Unlocked
Income Customer Yes Unlocked
Order None No Locked

Payment Type Order Yes Unlocked
Ship Date Order Yes Limit of 100
Shipper Order Yes Unlocked
You should configure the Customers user hierarchy for

drilling as well as browsing.
After you have created this user hierarchy, save and close the
Hierarchy Editor and update the project schema.
382 Exercises: Working with User Hierarchies © 2011 MicroStrategy, Inc.

Detailed Instructions—Customers User

Hierarchy
Open the Hierarchy Editor in the My Tutorial Project

Project.
2 In the My Tutorial Project, on the File menu, point to New

and select Hierarchy.
Select the attributes for the Customers user hierarchy

hold CTRL and select the following attributes:
Attribute
Customer
Customer Birth Date
Customer City
Customer Region
Customer State
Education
Gender
Income
Order
Payment Type
Ship Date
Shipper

objects list.
5 Click OK.

Define the browse attributes for the Customers user

hierarchy
6 In the Hierarchy Editor, select the Customer Region

attribute.
7 Right-click the Customer Region attribute and select

Define Browse Attributes.

attributes list, select Customer City.
9 Click the > button to add it to the Selected attributes list.
10 Click OK.
11 In the Hierarchy Editor, select the Customer State

attribute.
12 Right-click the Customer State attribute and select

Define Browse Attributes.

attributes list, select Customer.
15 Click OK.
Set the entry points for the Customers user hierarchy
16 In the Hierarchy Editor, select the Customer State

attribute.
17 Right-click the Customer State attribute and select Set

as entry point.
18 Select the Customer City attribute.
19 Right-click the Customer City attribute and select Set as

entry point.
20 Select the Customer attribute.
21 Right-click the Customer attribute and select Set as

entry point.

Set the element display for the Customers user hierarchy
22 Select the Customer attribute.
23 Right-click the Customer attribute, point to Element

Display, and select Limit.
24 In the Limit window, in the Limit box, type 100.
25 Click OK.
26 In the Hierarchy Editor, select the Customer Birth Date

attribute.
27 Right-click the Customer Birth Date attribute, point to

Element Display, and select Limit.
29 Click OK.
30 In the Hierarchy Editor, select the Order attribute.
31 Right-click the Order attribute, point to Element

Display, and select Locked.
32 Select the Ship Date attribute.
33 Right-click the Ship Date attribute, point to Element

Display, and select Limit.
35 Click OK.
Configure the Customers user hierarchy for drilling
36 In the Hierarchy Editor, ensure that the Use as a drill

hierarchy check box is selected.

Save and close the Customers user hierarchy
This message window confirms that you are

making the user hierarchy available for drilling.
39 Save the user hierarchy as Customers in the Schema

Objects\Hierarchies\Data Explorer folder.
Overview—Geography (USA) User Hierarchy

Geography (USA) user hierarchy for the geography
attributes in the My Tutorial Project. You will filter this
hierarchy, so it displays data only for the USA. The following
table shows which attributes to include in the user hierarchy
and how to define them:
Geography (USA) User Hierarchy
Call Center Employee Yes Unlocked
Country Region, Call Center Yes Unlocked
Distribution Center Call Center Yes Unlocked
Employee None Yes Unlocked
Employee Birth Date Employee Yes Unlocked
Hire Date Employee Yes Unlocked

Manager Call Center Yes Unlocked
Region Call Center, Employee Yes Unlocked
Salary Employee Yes Unlocked

You should create a filter named USA with the following

condition:
Country In list (USA)
After you create this filter, apply this filter to every entry
point in the Geography (USA) user hierarchy.
You can create this filter from inside the Hierarchy

Editor. You can also exit the Hierarchy Editor, create
the filter, and then open the Geography (USA) user
hierarchy to apply the filter to its entry points.
You should configure the Geography (USA) user hierarchy

only for browsing.
Detailed Instructions—Geography (USA) User

Hierarchy
Open the Hierarchy Editor
1 On the File menu, point to New and select Hierarchy.
Select the attributes for the Geography (USA) user

hierarchy

hold CTRL and select the following attributes:
Attribute
Call Center
Country
Distribution Center
Employee
Employee Birth Date
Hire Date

Attribute
Manager
Region
Salary

objects list.
4 Click OK.
Define the browse attributes for the Geography (USA) user

hierarchy
5 In the Hierarchy Editor, select the Country attribute.
6 Right-click the Country attribute and select Define

Browse Attributes.

attributes list, select Call Center.
9 Click OK.
10 In the Hierarchy Editor, select the Region attribute.
11 Right-click the Region attribute and select Define

Browse Attributes.

attributes list, select Employee.
14 Click OK.

Set the entry points for the Geography (USA) user

hierarchy
15 In the Hierarchy Editor, select the Region attribute.
16 Right-click the Region attribute and select Set as entry

point.
17 Select the Call Center attribute.
18 Right-click the Call Center attribute and select Set as

entry point.
19 Select the Employee attribute.
20 Right-click the Employee attribute and select Set as

entry point.
Create the filter for the Geography (USA) user hierarchy
21 Select the Country attribute.

Attribute Filters.
23 In the message window, select the Don’t show this

window again check box.
This message window provides tips on using filters

on user hierarchies.
24 Click OK.
This message window prompts you to create a filter

since none exist in the project.
26 In the Filter Editor, create a filter with the following

condition:
Country In list (USA)
You can access the Country attribute from the

system hierarchy.

27 Save the filter as USA in the Public Objects\Filters folder.
28 Close the Filter Editor.
Define the attribute filters for the Geography (USA) user

hierarchy
29 In the Hierarchy Editor, select the Country attribute.

Attribute Filters.

select the USA filter.
32 Click the > button to add the filter to the Selected objects
list.
33 Click OK.
34 Repeat steps 29 to 33 for each attribute in the Geography

(USA) user hierarchy.
You need to apply the filter to every entry point.

Configure the Geography (USA) user hierarchy only for
browsing
35 In the Hierarchy Editor, clear the Use as a drill

hierarchy check box.
Save and close the Geography (USA) user hierarchy
37 Save the user hierarchy as Geography (USA) in the

Schema Objects\Hierarchies\Data Explorer folder.

Overview—Products User Hierarchy

Products user hierarchy for the product attributes in the My
Tutorial Project. The following table shows which attributes
to include in the user hierarchy and how to define them:
Products User Hierarchy
Brand Item Yes Unlocked

Catalog Item No Unlocked
Category Subcategory, Item Yes Unlocked
Item None Yes Limit of 50
Subcategory Item Yes Unlocked
Supplier Item Yes Unlocked
Warranty Item Yes Unlocked
You should configure the Products user hierarchy for drilling

as well as browsing.

Detailed Instructions—Products User Hierarchy
Since you have practiced creating several different

user hierarchies using step-by-step instructions, these
Select the attributes for the Products user hierarchy
2 In the Select Objects window, select the following

attributes to include in the user hierarchy:
Attribute
Brand
Catalog
Category
Item
Subcategory
Supplier
Warranty
3 Click OK.
Define the browse attributes for the Products user

hierarchy
4 In the Hierarchy Editor, add Item as a second browse

attribute for the Category attribute.
5 Click OK.
Set the entry points for the Products user hierarchy
6 In the Hierarchy Editor, set the Subcategory and Item

7 Remove the Catalog attribute as an entry point.

Set the element display for the Products user hierarchy
8 Set the element display for the Item attribute to a limit of

50.
9 Click OK.
Configure the Products user hierarchy for drilling
10 In the Hierarchy Editor, ensure that the user hierarchy is

configured to allow drilling.
Save and close the Products user hierarchy
11 Save the Products user hierarchy in the Schema

12 Close the Hierarchy Editor.
Overview—Time User Hierarchy

Time user hierarchy for the time attributes in the My Tutorial
Project. The following table shows which attributes to include
in the user hierarchy and how to define them:
Time User Hierarchy
Day None Yes Limit of 31

Month Day Yes Unlocked
Month of Year Month No Unlocked
Quarter Month, Day Yes Unlocked
Year Quarter, Month Yes Unlocked

You should configure the Time user hierarchy for drilling as

well as browsing.
Detailed Instructions—Time User Hierarchy
Since you have practiced creating several different

user hierarchies using step-by-step instructions, these
Select the attributes for the Time user hierarchy
2 In the Select Objects window, select the following

attributes to include in the user hierarchy:
Attribute
Day
Month
Month of Year
Quarter
Year
3 Click OK.
Define the browse attributes for the Time user hierarchy
4 In the Hierarchy Editor, add Month as a second browse

attribute for the Year attribute.
5 Click OK.

6 In the Hierarchy Editor, add Day as a second browse

attribute for the Quarter attribute.
7 Click OK.
Set the entry points for the Time user hierarchy
8 In the Hierarchy Editor, set the Quarter, Month, and Day

9 Remove the Month of Year attribute as an entry point.
Set the element display for the Time user hierarchy
10 Set the element display for the Day attribute to a limit of

31.
11 Click OK.
Configure the Time user hierarchy for drilling
12 In the Hierarchy Editor, ensure that the user hierarchy is

configured to allow drilling.
Save and close the Time user hierarchy
13 Save the Time user hierarchy in the Schema

14 Close the Hierarchy Editor.

Creating a Report in the Project
Overview
In this exercise, you will first use the Metric Editor to create
the Revenue and Units Sold metrics in the My Tutorial
Project with the following definitions:
Metric Formula Formatting
Revenue Sum(Revenue) Currency, no

decimal places
Units Sold Sum(Units Sold) Fixed, no decimal

places
You should save both metrics in the Public Objects\Metrics

folder.
After you have created these metrics, you will then use the
Report Editor to create the following report in the My
Tutorial Project:
You should save the report as Product Sales Analysis in the

Public Objects\Reports folder.

Run the report. The result set should look like the following:
In the report, drill down on the Art & Architecture

subcategory to the Item attribute. The result set should look
like the following:

In the drill report, drill across on the 500 Best Vacation

Home Plans item to the Customer Region attribute. The
result set should look like the following:
When you perform this drill, you should see that the
Geography (USA) user hierarchy does not display on
the Other directions drill menu since you did not
configure it for drilling.
After you view the report results, close all the reports.
Create the Revenue metric
1 Open the Metric Editor.
2 In the Metric Editor, on the Formula tab, in the Definition

box, create the following metric definition:
Sum(Revenue)
3 Format the metric values as currency with no decimal
places.
Save and close the Revenue metric
4 Save the metric as Revenue in the Public Objects\Metrics

folder.
5 Close the Metric Editor.

Create the Units Sold metric
6 Open the Metric Editor.
7 In the Metric Editor, on the Formula tab, in the Definition

box, create the following metric definition:
Sum(Units Sold)
You do not need to format this metric. Its value

format defaults to a fixed number with no decimal
places, which is the format you need to use.
Save and close the Units Sold metric
8 Save the metric as Units Sold in the Public

Objects\Metrics folder.
9 Close the Metric Editor.
Create the Product Sales Analysis report
10 Open the Report Editor.
11 In the Report Editor, create the following report:
Save and run the Product Sales Analysis report
12 Save the report as Product Sales Analysis in the Public

Objects\Reports folder.
13 Run the report.
14 Compare your results to the expected report in the

Overview section at the beginning of this exercise.

Drill to Item on the Product Sales Analysis report
15 In the Product Sales Analysis report, drill down on the Art

& Architecture subcategory to the Item attribute.

Drill to Customer Region on the drill report
17 In the drill report, drill across on the 500 Best Vacation

Home Plans item to the Customer Region attribute.
When you perform this drill, the Geography (USA)

user hierarchy does not display on the Other
directions drill menu since you did not configure it
for drilling.

Close all reports
19 Close all open reports.
You do not need to save the drill reports.

Lesson Summary
• The final task in the project creation workflow is to create
the user hierarchies for a MicroStrategy project.
• User hierarchies provide convenient paths for browsing

attribute data.
• User hierarchies do not have to reflect the structure of the

hierarchies in the logical data model. You define the
structure of user hierarchies based on how users need to
browse data.
• User hierarchies are not limited to directly related

attributes. You can include attributes from different
hierarchies in the same user hierarchy.
• When you create user hierarchies for browsing, they are

accessible to users throughout the project. You can access
them in the Data Explorer browser, the Object Browser
within object editors, and prompts.
• You can also configure user hierarchies as drill paths for

analyzing report data.
• You use the Hierarchy Editor to create and modify user

hierarchies.
• The primary task in creating a user hierarchy is to select

the attributes you want to include in the hierarchy.
• When you create a user hierarchy, you must save it in the

Schema Objects\Hierarchies\Data Explorer folder if you
want to make it available for browsing.
• You use the Hierarchy Editor to define user hierarchy

elements, which includes the following tasks: defining
browse attributes, setting entry points, setting element
display, defining attribute filters, and configuring a user
hierarchy for drilling.
• Browse attributes are the attributes to which you can

directly browse from any given attribute.
• Entry points are the attributes that display when you first
open a user hierarchy. You can begin browsing a user
hierarchy from any attribute that is an entry point.

• The element display setting determines the extent to

which you can browse attribute elements.
• If an attribute’s element display is unlocked, you can

browse all its elements at one time.
• If an attribute’s element display is locked, you cannot

browse its elements at all.
• If an attribute’s element display has a limit, you can

browse a specified number of elements at one time. You
can then either retrieve the next set of elements or return
to browsing the previous set of elements.
• Attribute filters on a user hierarchy control the data

displayed for the attributes to which they are applied.
Only attribute elements that match the filter conditions
display when you browse the attributes.
• You can configure user hierarchies for drilling, which

makes them available as drill paths for attributes on
reports.
• You can use a combination of settings in the Project

Configuration Editor and Hierarchy Editor to customize
the sort order used to display attributes in user
hierarchies.
• You can customize the sort order for browsing and drilling
user hierarchies.

9
INTRODUCTION TO THE
ARCHITECT GRAPHICAL
INTERFACE
Lesson Description
This lesson introduces you to Architect, a new graphical

interface that integrates many project design functions. You
can work with various schema objects within this
consolidated interface.
In this lesson, you will learn how the Architect graphical

interface compares to the Project Creation Assistant and
schema object editors, and you will learn how to access the
interface. Then, you will learn about each component of the
Architect graphical interface. You will also learn about basic
operations within Architect, such as saving project work,
performing undo and redo actions, and configuring Architect
settings. Finally, you will see a demonstration of using
Architect to modify an existing project.

9 Introduction to the Architect Graphical Interface MicroStrategy Architect: Project Design Essentials
Lesson Objectives

Describe how the Architect graphical interface differs from
the Project Creation Assistant and schema object editors,
access Architect in MicroStrategy Desktop, describe the
components of Architect, save project work in Architect,
perform undo and redo actions in Architect, describe
Architect settings, and describe how you can use Architect to
work on projects.
• Describe how the Architect graphical interface differs from

the Project Creation Assistant and schema object editors
and access Architect in MicroStrategy Desktop.
(Page 405)
• Describe the components of the Architect graphical

interface. (Page 408)
• Describe how information is saved to the metadata when

working in the Architect graphical interface. (Page 433)
• Undo and redo actions you perform in the Architect

graphical interface. (Page 435)
• Describe the settings you can configure for the Architect

graphical interface. (Page 437)
• Describe how you can use the Architect graphical interface

to work on projects. (Page 451)

MicroStrategy Architect: Project Design Essentials Introduction to the Architect Graphical Interface 9
Introduction to Architect

Describe how the Architect graphical interface differs from
the Project Creation Assistant and schema object editors and
access Architect in MicroStrategy Desktop.
MicroStrategy Architect 9.0 and above includes a new tool for

performing project design tasks called Architect. Architect is
a graphical interface that provides a more visual, freeform
approach to working on projects. Rather than using different
wizards or schema object editors to complete various project
design tasks, you work within a single consolidated interface
that enables you to access many different functions.
You can perform most project design tasks in the

Architect graphical interface. However, there are a few
functions that are not supported by Architect,
including creating project objects, mapping attributes
or facts to partitioned tables, and creating fact
extensions.
The Project Creation Assistant is the primary tool for bulk

project creation. It leads you through the process of creating a
project in a very linear, step-by-step manner. This approach
can be especially useful as you first learn how to create
MicroStrategy projects.
Similarly, the schema object editors provide dedicated

interfaces for working with specific types of schema objects.
You can access all the functions available for facts, attributes,
or user hierarchies in their respective object editors. Using
these distinct interfaces to work with schema objects can be
useful as you learn about the various components and
properties that relate to each type of object.
© 2011 MicroStrategy, Inc. Introduction to Architect 405

However, the Architect graphical interface can serve as an

alternative interface for fine-tuning MicroStrategy projects. If
you are knowledgeable about project design tasks, it can
provide a more integrated, interactive experience for working
on projects. For example, you can add new tables to a project,
modify existing facts, create a new attribute, and remove an
existing user hierarchy all within this one interface.
When you open the Architect graphical interface, it

loads the entire project schema, not just the objects
you need to modify. Therefore, if you are making only
a few changes to your project, it is generally better to
use the schema object editors.
Accessing the Architect Graphical Interface

You can easily access the Architect graphical interface at any
time to work on a project.
To access Architect:
1 In MicroStrategy Desktop, log in to the project source that

contains the project you want to modify.
2 Open the project you want to modify.
3 On the Schema menu, select Architect.
406 Introduction to Architect © 2011 MicroStrategy, Inc.

The following image shows the option for accessing Architect

on the Schema menu:
Accessing Architect from the Schema Menu
You can also access Architect from the Project

Creation Assistant when you first create a project.
© 2011 MicroStrategy, Inc. Introduction to Architect 407

Overview of Architect Components

Describe the components of the Architect graphical interface.
The Architect graphical interface consists of several

components that combine many of the functions of the
Project Creation Assistant and schema object editors. As a
result, Architect is a comprehensive interface with many
different panes and tabs. It is important to understand how
you use each component to complete various project design
tasks.
The following image shows the Architect graphical interface:

Architect Graphical Interface
408 Overview of Architect Components © 2011 MicroStrategy, Inc.

The Architect graphical interface has the following

components:
• Warehouse Tables pane
• Project Tables View tab
• Hierarchy View tab
• Properties pane
• Project objects pane
• Menu bar
• Toolbar
The following topics describe each of these components in

detail.
Warehouse Tables Pane

The Warehouse Tables pane enables you to view database
instances and their associated tables and select the tables you
want to include in a project. The following image shows the
Warehouse Tables pane:
Warehouse Tables Pane
© 2011 MicroStrategy, Inc. Overview of Architect Components 409

The Warehouse Tables pane displays only database instances

that are associated with the project. Therefore, when you first
create a project in Architect, you see only the primary
database instance for the project.
The primary database instance for a project displays in bold,

italicized text. If you have a project that is associated with
multiple database instances, the secondary database
instances display in bold text.
You can add any database instances that are available

in the project source to a project. For information on
configuring a project to use multiple database
instances, see the MicroStrategy Architect: Advanced
Project Design course.
You can expand a database instance to load the entire catalog

of associated tables. Selected tables (those included in a
project) display in bold text. Available tables (those not
included in the project) display in plain text with ghosted
icons. You can expand individual tables to view the columns
they contain. Used columns (those mapped to attributes or
facts) display in bold text. Available columns (those not
mapped to attributes or facts) display in plain text with
ghosted icons.
ByArchitect
default, when you expand a database instance,
loads both selected and available tables.
However, you can disable loading the entire catalog of
tables so that only selected tables are loaded. For
information on configuring this Architect setting, see
“Warehouse Catalog” starting on page 439.

Color Mapping for Database Instances
The expand and collapse icon beside each database instance

is outlined using a specific color. This colored indicator
visually denotes database instances and their corresponding
tables. For example, in the following image, the Tutorial Data
database instance has a purple color mapping indicator.
Therefore, the expand and collapse icons for its tables use the
same color indicator, and its table images on the Project
Tables View tab have headers with the same color:
Color Mapping Example
Color mapping enables you to better distinguish between

project tables that come from different data sources.
Architect has 10 default mapping colors that are

assigned sequentially to database instances. If you
have more than 10 database instances associated with
a project, the mapping color sequence is repeated. You
can also change the color mapping for a database
instance or create your own custom color.

Managing the Warehouse Tables Pane
You can show or hide the Warehouse Tables pane as needed.
The Warehouse Tables pane does not display at all if

you are working on the Hierarchy View tab.
To show or hide the Warehouse Tables pane:
On the toolbar, Click Show the Warehouse tables

section.
OR
On the View menu, select Show Warehouse tables.
Both the toolbar button and menu option are

toggle features. If the Warehouse Tables pane is
showing, clicking the toolbar button or selecting
the menu option hides the pane. If the pane is
hidden, clicking the toolbar button or selecting the
menu option displays the pane.
You can also dock and undock the Warehouse Tables pane. If
the pane is docked, it remains visible at all times when you
have it open. If the pane is undocked, it is hidden until you
move the pointer over the pane.
Byis visible
default, the Warehouse Tables pane is docked, so it
even when you are not using it.
To undock the Warehouse Tables pane:
1 In the Warehouse Tables pane, click Auto-Hide.

The following image shows how the Warehouse Tables pane

displays when it is undocked:
Undocked Warehouse Tables Pane
To dock the Warehouse Tables pane:
1 Move the pointer over the Warehouse Tables pane.
2 In the Warehouse Tables pane, click Auto-Hide.

Project Tables View Tab

The Project Tables View tab displays images of the tables
used in a project. It uses layers to display the tables. The All
Project Tables layer enables you to view all the tables used in
a project. This layer exists by default in every project. The
following image shows the All Project Tables layer:
Project Tables View Tab—All Project Tables Layer

Since projects can use large number of tables, it can be

difficult to view all the project tables at once. Therefore, you
can create your own custom layers to display a subset of
project tables. Layers are helpful for organizing and viewing
project tables that pertain to a particular task or are related
by the type of information they contain. The following image
shows a custom layer called Time Tables that displays only
the lookup tables that contain time-related information:
Project Tables View Tab—Custom Layer
You use the Project Tables View tab to work with tables and
create, modify, and remove facts and attributes.
You can change the display of the Project Tables View

tab by zooming in or out on tables or changing the
background color of the tab.

Viewing Links Between Project Tables
The Project Tables View tab enables you to view links that
exist between project tables based on columns, attributes,
attribute forms, or facts. When you select a column or object
in a project table, Architect automatically displays lines that
indicate links to the same column or object in other project
tables.
Architect considers two columns to be the same if they

have the same column name and data type.
For example, the following image shows the Customer Region

attribute selected in the LU_CUST_REGION table:
Attribute Link on Project Tables View Tab
The gray line indicates a link to the same attribute in the

LU_CUST_STATE table.

Viewing Relationships Between Attributes in

Project Tables
The Project Tables View tab also enables you to view

relationships that exist between attributes in project tables.
To view attribute relationships for project tables:
1 On the View menu, select Show relationships.
This menu option is a toggle feature. If the

attribute relationships are shown, selecting the
menu option removes them from view. If the
attribute relationships are not shown, selecting the
menu option displays them.
The following image shows the option for viewing attribute

relationships on the Project Tables View tab:
Option for Viewing Attribute Relationships

The following image shows the Project Tables View tab with
attribute relationships displayed:
Attribute Relationships Displayed on Project Tables View
Tab
The blue lines indicate relationships to attributes in other

project tables.
You have to create attribute relationships before you

can view them on the Project Tables View tab.
Exporting and Copying Images from the Project

Tables View Tab
The images on the Project Tables View tab provide a visual

representation of the physical columns in tables as well as the
schema objects mapped to those columns, depending on the
content you choose to display. You can easily reuse these
images in other mediums by exporting or copying them.
When you export or copy images, all the tables in the current
layer are included in the exported or copied image.

To export an image from the Project Tables View tab:
1 On the File menu, select Export Image.
2 In the Export Image window, browse to the location in

which you want to save the image.
3 In the File name box, type a name for the image.
4 In the Save as type drop-down list, select the file type you
want to use.
Architect supports all the major image file types.

5 Click Save.
The following image shows the option for exporting images

from the Project Tables View tab:
Option for Exporting Images
To copy an image from the Project Tables View tab:
1 On the Project Tables View tab, right-click an empty area

and select Copy Diagram to Clipboard.
This action copies the image to the Microsoft

Windows clipboard.

The following image shows the option for copying images

from the Project Tables View tab:
Option for Copying Images
You can insert saved images or paste copied images into

documents, spreadsheets, presentations, and so forth.
Hierarchy View Tab

The Hierarchy View tab displays all the attributes in a project
and their relationships. You use this tab to create, modify,
and remove relationships between attributes, which builds
the system hierarchy. You can also create, modify, and
remove user hierarchies on this tab.

After you define attribute relationships for the system

hierarchy, you can use the Hierarchy View tab to view the
system hierarchy in its current state. The following image
shows the system hierarchy for a project:
Hierarchy View Tab—System Hierarchy

You can also view any user hierarchies that you create. The
following image shows a user hierarchy for time-related
attributes:
Hierarchy View Tab—User Hierarchy
The Hierarchy View tab has some of the same display

functions as the Project Tables View tab. For example,
you can zoom in or out on hierarchies or change the
background color of the tab. You can also export and
copy hierarchy images.

Properties Pane
The Properties pane enables you to view and modify the
properties for attributes, facts, and tables. This pane provides
access to many of the settings that are available in
corresponding schema object editors. For example, you can
view the columns in a table, create a new form for an
attribute, or modify the column alias for a fact using the
Properties pane.
You can modify most object properties. However, certain

properties, such as the object ID and location are only for
display purposes.
The titles of properties you cannot modify generally

display in gray text. However, some properties initially
display in gray text because their availability is
dependent on changes to other properties. When these
properties become available, their display changes
from gray text to black.
The Properties pane has three tabs—Attributes, Facts, and

Tables. If you have an object selected on the Project Tables
View or Hierarchy View tabs, the Properties pane defaults to
displaying the information for that object. You can also
directly select an object that you want to view in the
Properties pane.
When you are on the Hierarchy View tab, the

Properties pane displays only the Attributes tab since
attributes are the only type of object displayed in
system or user hierarchies.
To select an object to view in the Properties pane:
1 In the Properties pane, click the appropriate tab.
2 On the appropriate tab, in the drop-down list, select the

object you want to view.

The following image shows the Properties pane with the

information for the Customer attribute displayed:
Properties Pane—Customer Attribute

Managing the Properties Pane
You can show or hide the Properties pane as needed.
To show or hide the Properties pane:
1 Click Show the properties section.
OR
On the View menu, select Show properties.
Both the toolbar button and menu option are

toggle features. If the Properties pane is showing,
clicking the toolbar button or selecting the menu
option hides the pane. If the pane is hidden,
clicking the toolbar button or selecting the menu
option displays the pane.
You can also dock and undock the Properties pane. If the
pane is docked, it remains visible at all times when you have
it open. If the pane is undocked, it is hidden until you move
the pointer over the pane.
Byvisible
default, the Properties pane is docked, so it is
even when you are not using it.
To undock the Properties pane:
1 In the Properties pane, click Auto-Hide.

The following image shows how the Properties pane displays

when it is undocked:
Undocked Properties Pane
To dock the Properties pane:
1 Move the pointer over the Properties pane.
2 In the Properties pane, click Auto-Hide.

Project Objects Pane

The Project objects pane enables you to view the number of
attributes, facts, and tables that exist in a project. You can
also view the project name and the current user.
Inobjects
Architect, if you want to view a list of the actual
you have created (rather than just the number
of objects), you can click the appropriate tab in the
Properties pane and then open the corresponding
drop-down list. This list displays all the objects of that
type (attributes, facts, or tables).
You can dock and undock the Project objects pane. If the
pane is docked, it remains visible at all times when you have
it open. If the pane is undocked, it is hidden until you move
the pointer over the pane.
Byis hidden
default, the Project objects pane is undocked, so it
unless you choose to view this pane.
To dock the Project objects pane:
1 Move the pointer over the Project objects pane.
2 In the Project objects pane, click Auto-Hide.

The following image shows how the Project objects pane

displays when it is docked:
Docked Project Objects Pane
To undock the Project objects pane:
1 In the Project objects pane, click Auto-Hide.

Menu Bar
The Architect graphical interface has a menu bar that enables
you to access a variety of functions. Many of these same
functions are also available on right-click menus and on the
toolbar. The following table describes the available menus:
Architect Menu Bar
Menu Description
File Enables you to create new attributes, attribute forms, and

facts; save your work; update the project schema; export
images; and close Architect
Edit Enables you to undo and redo actions, remove and

rename objects, create and remove layers and user
hierarchies, and copy images
View Enables you to show and hide panes and change how
you view information in Architect
Options Enables you to access configuration settings for

Architect, add database instances to projects, and
change the background color of the Project Tables View
or Hierarchy View tabs
Help Enables you to access online help and the MicroStrategy

Web site

Toolbar
The Architect graphical interface has a toolbar that enables
you to access a variety of functions. Many of these same
functions are also available on right-click menus and on the
menu bar. The following table describes each button on the
toolbar:
Architect Toolbar
Button Description
Enables you to save your work and close

Architect
Enables you to save your work and remain in

Architect
Enables you to save your work in Architect,

update the project schema, and remain in
Architect
Enables you to remove objects
Enables you to create database instance
Enables you to create attributes
Enables you to create facts
Enables you to create attribute forms
Enables you to show or hide the Warehouse

Tables pane
Enables you to show or hide the Properties pane

Architect Toolbar
Button Description
Enables you to view objects in Architect in

Normal mode
Enables you to view objects in Architect in Zoom

in mode
Enables you to view objects in Architect in Zoom

out mode
Enables you to view the aerial perspective for

objects in Architect
Enables you to auto arrange objects in Architect
Enables you to make objects in Architect fit to

the window size
Enables you to select the layer you want to view

(Project Tables View tab only)
Enables you to create a new layer (Project

Tables View tab only)
Enables you to remove the layer you are

currently viewing (Project Tables View tab only)
Enables you to select the hierarchy you want to

view (Hierarchy View tab only)
Enables you to create a new user hierarchy

(Hierarchy View tab only)
Enables you to remove the user hierarchy you

are currently viewing (Hierarchy View tab only)

Architect Toolbar
Button Description
Enables you to undo actions in Architect
Enables you to redo actions in Architect
Enables you to zoom out on objects you are

viewing in Architect
Enables you to change the zoom percentage for

viewing objects in Architect
Enables you to zoom in on objects you are

viewing in Architect
Enables you to access online help

Saving Project Work in Architect

Describe how information is saved to the metadata when
working in the Architect graphical interface.
The Architect graphical interface enables you to complete a

wide variety of tasks that would otherwise require you to use
either the Project Creation Assistant or several schema object
editors to complete. Because you can perform so many
project design tasks within this single interface, when you
make a large number of changes to projects, you may work in
Architect for an extended period of time.
Given the length of time you may work in Architect, it is

important to understand that any work you perform is not
automatically saved to the metadata. Objects that you create
or changes that you make are not saved until you either
manually save your work or you exit Architect and save your
work.
In the meantime, if your system crashes while you are

working in Architect, only the work you have saved before
this event occurs is in the metadata. For this reason, you
should save periodically as you work in Architect rather than
waiting until you are ready to exit Architect to save your
project work.
© 2011 MicroStrategy, Inc. Saving Project Work in Architect 433

To save your project work and remain in Architect:
1 Click Save.
you
You can also click Save and Update Schema if
want to save your project work and update the
project schema.
To save your project work and close Architect:
434 Saving Project Work in Architect © 2011 MicroStrategy, Inc.

Undo and Redo Actions in Architect

Undo and redo actions you perform in the Architect graphical
interface.
The Architect graphical interface enables you to undo and

redo actions that you perform within it. Architect records
most operations except for actions in which you position
objects or change how objects display. For example, if you
move a table to a different location on the Project Tables View
tab, that action is not included in the list of operations you
can undo.
You can undo any actions you have performed since the last
save. Any time you undo an action, it is added to the list of
actions that you can redo.
You can undo and redo individual actions sequentially. For

the undo function, this method affects only the last action you
performed. For the redo function, this method affects only
the last action you chose to undo.
To undo the last action you performed:
1 Click Undo.
To redo the last action you chose to undo:
1 Click Redo.
© 2011 MicroStrategy, Inc. Undo and Redo Actions in Architect 435

You can also undo and redo a series of actions. The Undo and
Redo toolbar buttons have lists that display each action
performed since the last save. For example, the following
image shows a list of actions associated with the Undo
button:
List of Undo Actions
These lists can display up to 24 actions.

Using these lists, you can choose to undo or redo multiple
actions at the same time. For example, in the image above, if
you select Modify Attribute Name Education, that action and
every action that comes before it in the list is affected.
To undo a series of actions:
1 Beside the Undo button, click the arrow and select the
final action you want to undo.
To redo a series of actions:
1 Beside the Redo button, click the arrow and select the
final action you want to redo.
436 Undo and Redo Actions in Architect © 2011 MicroStrategy, Inc.

Overview of Architect Settings

Configure the settings for the Architect graphical interface.
The Architect graphical interface has settings that you can

configure to change various behaviors.
Any changes you make to these settings apply only to

the particular project you have open in Architect.
To access the Architect settings:
1 In the Architect graphical interface, on the Options menu,

select Settings.
The following image shows the option for accessing Architect

settings:
Option for Accessing Architect Settings
The Architect settings are grouped into the following

categories:
• Configuration
• Display
• Automatic heuristic
• Metric creation
The following topics describe the individual settings in each

of these categories.
© 2011 MicroStrategy, Inc. Overview of Architect Settings 437

Configuration Settings
The following image shows the configuration settings for
Architect:
Configuration Settings for Architect
The configuration settings are divided into three

subcategories:
• Startup
• Warehouse Catalog
• Schema update
Startup
The Choose the default open view setting enables you to

select the tab that displays when you open Architect. You can
choose to view the Project Tables View tab, Hierarchy View
tab, or the tab you last used. By default, this setting displays
the Project Tables View tab.
438 Overview of Architect Settings © 2011 MicroStrategy, Inc.

Warehouse Catalog
The Disable loading warehouse catalog setting determines

whether you can load the entire catalog of tables for database
instances in Architect.
If this setting is disabled, expanding a database instance or

updating the catalog for a database instance loads all the
tables that exist within the corresponding data source. If this
setting is enabled, when you expand a database instance,
Architect loads only tables that are used by the project. Also,
you cannot update the catalog for a database instance since
the purpose of this function is to load available tables.
By default, this setting is disabled so that you have access to

all available tables. However, if you have already added the
necessary tables to your project, enabling this setting can be
beneficial since it reduces the load time.
Schema Update
The Update schema after closing Architect setting determines

whether you are prompted to update the project schema
when you close Architect.
When this setting is enabled, the Schema Update window

automatically displays when you close Architect so that you
can update the project schema. If this setting is disabled, you
do not automatically see the Schema Update window. By
default, this setting is enabled.
Ifthethisproject
setting is enabled, you are prompted to update
schema when closing Architect even if you
have not made any changes to the schema.

Display Settings
The following image shows the display settings for Architect:
Display Settings for Architect
The display settings determine what information is shown as

part of the table images on the Project Tables View tab. They
are divided into two subcategories:
• Project tables view
• Visible links
Project Tables View
This setting enables you to choose whether to display the

physical or logical view for tables on the Project Tables View
tab. The physical view shows only column names and data
types. The logical view shows both physical information and
logical information, including attributes, facts, and attribute
forms. By default, Architect displays the logical view for
project tables.

When you display the logical view for project tables, you can
also click the Advanced Options button to access more
detailed settings that control exactly how much information
is shown. The following image shows the logical view
advanced display settings:
Logical View Advanced Display Settings
The following table describes each of these settings:
Logical View Advanced Display Settings
Setting Description
Display available columns Displays columns in project tables that

on logical tables have not been mapped to an attribute or
fact
Display columns used for Displays columns in project tables that are
data internationalization used to support data internationalization
NOTE: You can enable this check box
only if you display available
columns.
Display used columns on Displays columns in project tables that
logical tables have been mapped to an attribute or fact
Display attribute forms on Displays attribute forms that map to

logical tables columns in project tables
The logical view for project tables always displays attributes

and facts. By default, it also displays available columns that
have not been mapped to attributes or facts. The other
advanced display settings are not enabled.

When you configure display settings at this level, it affects all

project tables. Most of these display properties are also
available for you to change at the table level.
Visible Links
The Maximum number of visible links per table row setting

enables you to control the number of links that can display
when you select a column, attribute, attribute form, or fact in
a project table. By default, Architect displays a maximum of
100 links for any given object.
Automatic Heuristic Settings

The following image shows the automatic heuristic settings
for Architect:
Automatic Heuristic Settings for Architect
The automatic heuristic settings are divided into three

subcategories:
• Automatic column mapping
• Automatic column recognition

• Recognize relationships
Automatic Column Mapping
The Use automatic column mapping setting determines

whether Architect automatically maps columns in tables to
existing attribute form and fact expressions as you add tables
to a project. By default, this setting is enabled.
Even when this setting is enabled, Architect does not

automatically map columns to attribute form and fact
expressions that use the Manual mapping method.
Automatic Column Recognition
This setting determines whether Architect automatically

creates facts and attributes as you add tables to a project. By
default, Architect uses automatic column recognition to
create attributes and facts based on a set of heuristics.
If you keep automatic column recognition enabled, you can

click the Advanced Options button to access settings that
enable you to provide rules for attributes and attribute forms
to help Architect recognize and name these objects. The
following image shows the automatic column recognition
advanced settings:
Automatic Column Recognition Advanced Settings

Automatic Column Recognition Advanced Settings
Setting Description
Separator Enables you to provide a value for the

separator you use between the names of
attributes and attribute forms and their
suffixes
NOTE: The default value for this setting is
an underscore (for example,
Customer_Name).
Attribute naming rule Enables you to provide suffixes that you

use for attributes and any corresponding
replacement text you want Architect to
use in attribute names
NOTE: This setting has a variety of default
values for various suffixes.
Attribute form naming rule Enables you to provide suffixes that you
use for attribute forms and any
corresponding replacement text you want
Architect to use in attribute form names
NOTE: This setting has a variety of default
values for various suffixes.
Using automatic column recognition can be a valuable time

saver. However, it is often more useful to disable automatic
column recognition at the project level and only use it for
individual tables. You should consider the characteristics of
your project environment in determining whether to keep
this setting enabled for all project tables.

Recognize Relationships
In MicroStrategy 9.0.1, this new setting determines whether

Architect automatically creates relationships between
attributes based on the design of your data. By default,
Architect recognizes and creates relationships between
attributes to build the system hierarchy.
If you keep relationship recognition enabled, you can click

the Advanced Options button to access settings that enable
you to select the rules Architect uses to recognize related
attributes. The following image shows the relationship
recognition advanced settings:
Relationship Recognition Advanced Settings

Relationship Recognition—Advanced Settings
Setting Description
Based on Primary Enables Architect to create attribute

Keys/Foreign Keys relationships based on primary and
foreign keys defined for project tables.
Any attribute defined as a foreign key on a
table is recognized as a parent to any
attributes that are primary keys on the
same table. The relationship is defined as
a one-to-many relationship.
Based on lookup tables Enables Architect to create attribute

relationships for lookup tables that do not
include primary or foreign key information.
Any attribute that uses a table as its
primary lookup table is recognized as a
child of all other attributes in the same
table that do not use it as a primary lookup
table. The relationship is defined as a
one-to-many relationship.
Based on sample data from Enables Architect to create attribute
the table relationships for attributes that exist in the
same lookup table by analyzing sample
data from the table. An attribute with fewer
distinct values is recognized as a parent of
an attribute with more distinct values. The
relationship is defined as a one-to-many
relationship.
Using the standard project creation workflow, you

automatically or manually create attributes on the Project
Tables View tab. Then, if you have relationship recognition
enabled, Architect creates the attribute relationships when
you click the Hierarchy View tab.
After Architect determines all the attribute relationships

based on the rules you selected, it performs a final analysis of
these relationships. Any relationships that it determines to be
redundant are not created.

Using relationship recognition can be a valuable time saver as

it keeps you from having to manually define all of your
attribute relationships. However, if you are familiar with your
data warehouse model and understand the relationships in
your data, you may want to create those relationships on your
own. You should consider the characteristics of your project
environment in determining whether to keep this setting
enabled.
Even if you disable relationship recognition in the

Architect settings, you can choose to automatically
recognize and create attribute relationships using the
same setting on the Hierarchy View tab.
Metric Creation Settings

The following image shows the metric creation settings for
Architect:
Metric Creation Settings for Architect

In MicroStrategy 9.0.1, you can automatically create simple

metrics for any facts that you create in the Architect graphical
interface. These settings enable you to select the aggregation
functions you want to use in creating these metrics. By
default, the Sum aggregation function is selected. If you do
not select any aggregation functions, simple metrics are not
automatically created for facts.
If you use automatic metric creation, when you create a fact,

Architect automatically creates corresponding simple metrics
for each aggregation function selected. These metrics are
saved in the Public Objects\Metrics folder using the following
naming convention: <Function> of <Fact Name>. For
example, if you choose to automatically create metrics using
the Sum aggregation function and you create a Revenue fact,
the corresponding metric is named “Sum of Revenue.”
Using automatic metric creation can be a valuable time saver

as it keeps you from having to manually define many of the
simple metrics you may need in a project. However, you
should consider the characteristics of your project
environment in determining whether you use this feature and
which aggregation functions to enable.


Demonstration of Architect

Describe how you can use the Architect graphical interface to
work on projects.
Now that you have learned how to navigate the basic

components of the Architect graphical interface, you are
ready to see how you can work on projects using this
interface.
Your instructor will provide a hands-on demonstration of

using Architect to modify an existing project.
450 Demonstration of Architect © 2011 MicroStrategy, Inc.

Lesson Summary
• Architect is a graphical interface that provides a more
visual, freeform approach to working on projects.
• The Project Creation Assistant is the primary tool for bulk

project creation. It uses a linear, step-by-step approach to
project creation, which is useful as you first learn how to
create MicroStrategy projects.
• The schema object editors provide dedicated interfaces

for working with specific types of schema objects, which
can be useful as you learn about the various components
and properties that relate to each type of object.
• You can use the Architect graphical interface as an
alternative for fine-tuning MicroStrategy projects. It
provides a more integrated, interactive experience for
working on projects if you are knowledgeable about
project design tasks.
• You can access the Architect graphical interface from the

Schema menu to work on projects.
• The Warehouse Tables pane in the Architect graphical

interface enables you to view database instances and their
associated tables and select the tables you want to include
in a project.
• The Project Tables View tab displays the tables in a

project using layers. You use this tab to work with tables
and create, modify, and remove facts and attributes.
• The Hierarchy View tab displays all the attributes in a

project and their relationships. You use this tab to create,
modify, and remove attribute relationships and user
hierarchies.
• The Properties pane enables you to view and modify the

properties for attributes, facts, and tables. This pane
provides access to many of the settings that are available
in the schema object editors.
• The Project objects pane enables you to view the number

of attributes, facts, and tables that exist in a project as well
as the project name and current user.
© 2011 MicroStrategy, Inc. Demonstration of Architect 451

• Any work you perform in the Architect graphical interface

is not automatically saved to the metadata. You should
save periodically as you work in Architect.
• You can undo and redo actions that you perform in the
Architect graphical interface.
• The Architect graphical interface has configuration,

display, automatic heuristics and metric creation settings
that you can configure to change various behaviors.
452 Demonstration of Architect © 2011 MicroStrategy, Inc.

A
MICROSTRATEGY TUTORIAL
Appendix Description
This appendix provides information on the MicroStrategy

Tutorial project, including the data model and physical
warehouse schema.

A MicroStrategy Tutorial
The MicroStrategy Tutorial Data Model

A data model is a logical map that represents the inherent
properties of enterprise data, disregarding software,
hardware, or machine performance considerations. Data
models show:
• Data elements grouped into records
• Relationships and association surrounding those records
For more detailed information about data modeling, see the

Project Design Guide.
Although the MicroStrategy Tutorial data model is included

in this section for your reference, you can also view it directly
in the product.
To view the MicroStrategy Tutorial data model:

contains the MicroStrategy Tutorial project and expand
the MicroStrategy Tutorial project.
2 On the Schema menu, point to Graphical View and select

Hierarchies.
3 In the Hierarchy Viewer, to view a different hierarchy, in

the Hierarchy drop-down list, select the hierarchy you
want to view.
4 To focus on a different entry point, in the Entry Point

drop-down list, select the entry point you want to view.
5 To view the entire hierarchy in the window, on the View

menu, select Fit in window.
You can rearrange the attributes by dragging and

dropping them. Rearranging attributes does not
affect the browse order, but it enables you to view
the hierarchy in a way that is meaningful to you.
454 The MicroStrategy Tutorial Data Model © 2011 MicroStrategy, Inc.

MicroStrategy Tutorial A
6 To return to the default view, on the View menu, select

Auto arrange.
7 To save the layout view of the hierarchy, on the File menu,

select Save layout. The next time you open the Hierarchy
Viewer, it displays the saved view.
The MicroStrategy Tutorial data model consists of the

following hierarchies:
• Geography
• Customers
• Time
• Products
© 2011 MicroStrategy, Inc. The MicroStrategy Tutorial Data Model 455

Geography Hierarchy

Customers Hierarchy
© 2011 MicroStrategy, Inc. The MicroStrategy Tutorial Data Model 457

Time Hierarchy

Products Hierarchy
The MicroStrategy Tutorial Schema

A schema is a logical and physical definition of warehouse
data elements, physical characteristics, and
interrelationships.
For more detailed information on the schema, see the Project

Design Guide.
Although the MicroStrategy Tutorial physical schema is

included in this section for your reference, you can also view
the physical or logical schema directly in the product.
© 2011 MicroStrategy, Inc. The MicroStrategy Tutorial Schema 459

To view the MicroStrategy Tutorial schema:

contains the MicroStrategy Tutorial project and expand
the MicroStrategy Tutorial project.
2 On the Schema menu, point to Graphical View and select

Tables.
3 In the Table Viewer, to change display preferences for the

physical view, on the Options menu, select any of the
following options:
– Show joins—Enables you to select whether to connect

the tables to represent the joins between the
warehouse tables
– Use circular joins—Enables you to select whether to
use circular joins
– Show column data types—Enables you to select

whether to show the data type and size for each
column
– Show table prefixes—Enables you to select whether

to display the table prefix as part of the table name
4 To switch to the logical view, on the View menu, select

Logical view.
460 The MicroStrategy Tutorial Schema © 2011 MicroStrategy, Inc.

5 To change display preferences for the logical view, on the

Options menu, select any of the following options:
– Show joins—Enables you to select whether to connect

the tables to represent the joins between the table
columns
– Use circular joins—Enables you to select whether to

use circular joins
– Show relationships—Enables you to select whether

to map the relationships between the tables
– Show relationship types—Enables you to select

whether to differentiate between one-to-one,
one-to-many, many-to-one, and many-to-many
relationships
– Show columns—Enables you to select whether to

display the warehouse columns that define each
attribute as a link between the logical and physical
views
6 To switch back to the physical view, on the View menu,

select Physical view.
7 To view the entire schema in the window, on the View

menu, select Fit in window.
You can rearrange the tables by dragging and

dropping them. Rearranging the tables does not
affect the relationships or joins, but it enables you
to view the tables in a way that is meaningful to
you.
8 To return to the default view, on the View menu, select

Auto arrange.
9 To save the layout view of the tables, on the File menu,

select Save layout. The next time you open the Table
Viewer, it displays the saved view.
10 To copy the layout view, on the File menu, select Copy as

Metafile (.wmf).

The MicroStrategy Tutorial schema is divided into the

following parts:
• Geography
• Customers
• Time
• Products
• Fact tables
• Partition mapping table

Geography Schema

Customers Schema

Time Schema

Products Schema

Fact Tables Schema
Partition Mapping Table


INDEX
A Architect graphical interface components,

overview 408
accessing the Architect graphical Architect graphical interface settings,
interface 406 overview 437
accessing the Attribute Creation Wizard
Architect graphical interface,
from the Project Creation accessing 406
Assistant 243
Architect graphical interface, Hierarchy
accessing the Attribute Creation Wizard View tab 420
from the Schema menu 245
Architect graphical interface,
accessing the Fact Creation Wizard from
introduction 405
the Project Creation Assistant 193
Architect graphical interface, menu
accessing the Fact Creation Wizard from bar 429
the Schema menu 194
Architect graphical interface, Project ob-
accessing the Warehouse Catalog from the jects pane 427
Project Creation Assistant 160
Architect graphical interface, Project Ta-
accessing the Warehouse Catalog from the bles View tab 414
Schema menu 162
Architect graphical interface, Properties
adding tables to a project, Warehouse pane 423
Catalog 165
Architect graphical interface, saving proj-
aggregate fact tables 88 ect work 433
All Project Tables layer 414 Architect graphical interface, toolbar 430
Architect and browsing 32 Architect graphical interface, undo and
Architect and drilling 30 redo actions 435
Architect and physical schema 78 Architect graphical interface, Warehouse
Architect and reporting 28 Tables pane 409
Architect and the logical data model 44 Architect settings, automatic column
Architect graphical interface 143 mapping 443
Architect settings, automatic column

Index MicroStrategy Architect: Project Design Essentials
recognition 443 rules 246

Architect settings, default view 438 Attribute Creation Wizard, selecting look-
Architect settings, loading the Warehouse up tables for attributes 256
Catalog 439 attribute creation, Attribute Creation
Architect settings, physical or logical table Wizard 248
view 440 attribute creation, Attribute Editor 271
Architect settings, project table link attribute description forms, Attribute Cre-
display 442 ation Wizard 253
Architect settings, relationship Attribute Editor 269
recognition 445 Attribute Editor, attribute form
Architect settings, schema update 439 properties 271
Architect, attribute 231 Attribute Editor, creating attribute forms
Architect, attribute form 234 and form expressions 273
Architect, automatic heuristic Attribute Editor, creating attribute
settings 442 relationships 299
Architect, basic schema objects 26 Attribute Editor, creating attributes 271
Architect, configuration settings 438 Attribute Editor, creating compound
Architect, creating schema objects 26 attributes 283
Attribute Editor, creating derived attribute
Architect, display settings 440
form expressions 277
Architect, fact 185
Attribute Editor, creating heterogeneous
Architect, metric creation settings 447 attributes 280
Architect, overview 23 Attribute Editor, creating simple attribute
Architect, populating the metadata 24 form expressions 273
Architect, roles 28 Attribute Editor, modifying attributes 287
Architect, user hierarchy 347 attribute elements, logical data model 52
architecture, MicroStrategy business attribute filters, user hierarchy 367
intelligence 24 attribute form creation, Attribute
attribute creation rules 246 Editor 273
Attribute Creation Wizard 243 attribute form display 308
Attribute Creation Wizard, creating attri- attribute form expression 240
bute description forms 253 attribute form expressions, derived 241
Attribute Creation Wizard, creating attri- attribute form expressions, simple 240
bute ID forms 249
attribute form expressions, types 240
Attribute Creation Wizard, creating attri-
attribute form properties, Attribute
bute relationships 259
Editor 271
Attribute Creation Wizard, creating
attribute form, MicroStrategy
attributes 248
Architect 234
Attribute Creation Wizard, creating com-
attribute forms 51
pound attributes 263
attribute forms, browsing 308
Attribute Creation Wizard, defining

MicroStrategy Architect: Project Design Essentials Index
attribute forms, report display 308 attributes, heterogeneous 239

attribute ID forms, Attribute Creation attributes, homogeneous 238
Wizard 249 attributes, logical data model 48
attribute key 293 attributes, types 237
attribute modification, Attribute automatic column mapping, Architect
Editor 287 settings 443
attribute modification, creating new attri- automatic column recognition, Architect
bute forms 287 settings 443
attribute modification, deleting existing at- automatic heuristic settings,
tribute forms 291 Architect 442
attribute modification, modifying attribute available columns, Warehouse Tables
keys 293 pane 410
attribute modification, modifying column available tables, Warehouse Tables
aliases 294 pane 410
attribute modification, modifying existing
attribute forms 288
attribute modification, modifying lookup B
tables 292 base fact tables 88
attribute relationship recognition, Archi- basic schema objects 26
tect settings 445 browse attributes, user hierarchy 358
attribute relationships, Attribute Creation browse forms 308
Wizard 259
browsing and MicroStrategy Architect 32
attribute relationships, Attribute
browsing sort order, user hierarchy 373
Editor 299
attribute relationships, direct 53 business intelligence architecture 24
attribute relationships, indirect 53
attribute relationships, logical data C
model 53
color mapping, Warehouse Tables
attribute relationships, many to many 54 pane 411
attribute relationships, one to many 54 column alias, attributes 294
attribute relationships, one to one 54 column alias, facts 212
attribute relationships, Project Tables column types, physical schema 80
View tab 417
columns, description 80
attribute, MicroStrategy Architect 231
columns, fact 80
attributes 26
columns, ID 80
attributes and attribute forms, logical data
columns, physical schema 80
model 50
completely denormalized schema 94
attributes in an ERD 50
completely denormalized schemas, high-
attributes, column alias 294
er-level lookup tables 95
attributes, compound 237
completely normalized schema 92

components, Architect graphical creating a logical data model, existing

interface 409 source data 59
components, logical data model 47 creating a logical data model, factors to
components, physical schema 80 consider 58
components, Project Creation creating a logical data model, identify
Assistant 140 attributes 65
compound attribute creation, Attribute creating a logical data model, identify
Creation Wizard 263 facts 63
compound attribute creation, Attribute creating a logical data model, list informa-
Editor 283 tion from the source data 62
compound attributes 237 creating a logical data model, organize
hierarchies 66
compound key, physical schema 81
creating a logical data model, steps 61
configuration settings, Architect 438
creating a logical data model, technical and
Configuration Wizard, creating the meta-
performance considerations 60
data shell 117
creating a logical data model, user report-
configuring a user hierarchy for drilling,
ing requirements 58
Hierarchy Editor 370
creating a project source 124
configuring project connectivity 123
creating a project source, Project Source
configuring the project metadata 111
Manager 124
Connectivity Configuration Wizard, creat-
creating a project, overview 111
ing the metadata DSN 112
creating attribute description forms, Attri-
copying images, Project Tables View
bute Creation Wizard 253
tab 418
creating attribute forms and form expres-
course organization 39
sions, Attribute Editor 273
creating a data warehouse schema 99
creating attribute ID forms, Attribute Cre-
creating a data warehouse schema, data ation Wizard 249
volume 100
creating attribute relationships, Attribute
creating a data warehouse schema, data- Creation Wizard 259
base maintenance 101
creating attribute relationships, Attribute
creating a data warehouse schema, factors Editor 299
to consider 99
creating attributes, Attribute Creation
creating a data warehouse schema, query Wizard 248
performance 100
creating attributes, Attribute Editor 271
creating a data warehouse schema, user re-
creating compound attributes, Attribute
porting requirements 100
Creation Wizard 263
creating a database instance 127
creating compound attributes, Attribute
creating a database instance, Database In- Editor 283
stances manager 128
creating derived attribute form expres-
creating a logical data model 58 sions, Attribute Editor 277
creating a logical data model, determine creating derived fact expressions, Fact
direct attribute relationships 65

Editor 205 data warehouse schema, creating 99

creating facts, Fact Creation Wizard 197 data warehouse schema, data volume 100
creating facts, Fact Editor 203 data warehouse schema, database
creating heterogeneous attributes, Attri- maintenance 101
bute Editor 280 data warehouse schema, query
creating heterogeneous facts, Fact performance 100
Editor 207 data warehouse schema, user reporting
creating new attribute forms, modifying requirements 100
attributes 287 database connection 127
creating new fact expressions, modifying database instance 127
facts 209 database instance, creating 127
creating projects, interfaces 138 Database Instances manager, creating a
creating schema objects 26, 133 database instance 128
creating simple attribute form expressions, database instances, color mapping 411
Attribute Editor 273 database maintenance, creating a data
creating simple fact expressions, Fact warehouse schema 101
Editor 203 default view, Architect settings 438
creating the metadata database 112 defining attribute filters, Hierarchy
creating the metadata DSN 112 Editor 367
creating the metadata DSN, MicroStrategy defining attribute form display 308
Connectivity Configuration defining browse attributes, Hierarchy
Wizard 112 Editor 358
creating the metadata DSN, ODBC Data defining rules, Attribute Creation
Source Administrator 114 Wizard 246
creating the metadata shell 117 defining rules, Fact Creation Wizard 196
creating the metadata shell, MicroStrategy defining the sort order for browsing, user
Configuration Wizard 117 hierarchy 373
creating the project in MicroStrategy Ar- defining the sort order for drilling, user
chitect, overview 37 hierarchy 376
creating the project object 140 defining the sort order, user hierarchy 372
creating user hierarchies, Hierarchy defining user hierarchy elements, Hierar-
Editor 354 chy Editor 358
custom layer 415 deleting existing attribute forms, modify-
ing attributes 291
D deleting existing fact expressions, modify-
ing facts 211
Data Explorer folder, saving user denormalization 90
hierarchies 356
denormalized schema 90
data model, logical 43
derived attribute form expressions 241
data volume, creating a data warehouse
derived attribute form expressions, creat-
schema 100

ing in the Attribute Editor 277 model 59

derived fact expressions 191 exporting images, Project Tables View
derived fact expressions, creating in the tab 418
Fact Editor 205 expression, fact 190
description columns, physical schema 80
designing the data warehouse schema,
overview 36
F
designing the logical data model, fact columns, physical schema 80
overview 36 fact creation rules 196
determine direct attribute relationships, Fact Creation Wizard 193
creating a logical data model 65 Fact Creation Wizard, creating facts 197
dimensions, logical data model 55 Fact Creation Wizard, defining rules 196
direct attribute relationships 53 fact creation, Fact Creation Wizard 197
direct attribute relationships, many to fact creation, Fact Editor 203
many 54 Fact Editor 201
direct attribute relationships, one to Fact Editor, creating derived fact
many 54 expressions 205
direct attribute relationships, one to Fact Editor, creating facts 203
one 54
Fact Editor, creating heterogeneous
direct mode, project source 124 facts 207
display settings, Architect 440 Fact Editor, creating simple fact
displaying attribute forms 308 expressions 203
docking the Project objects pane 427 Fact Editor, modifying facts 209
docking the Properties pane 426 fact expression 190
docking the Warehouse Tables pane 413 fact expressions, derived 191
drilling and MicroStrategy Architect 30 fact expressions, simple 191
drilling on a user hierarchy 370 fact expressions, types 190
drilling sort order, user hierarchy 376 fact modification, creating new fact
DSN, metadata 112 expressions 209
fact modification, deleting existing fact
expressions 211
E fact modification, Fact Editor 209
editors, schema objects 142 fact modification, modifying column
element display, limit 363 aliases 212
element display, locked 363 fact modification, modifying existing fact
element display, unlocked 363 expressions 210
element display, user hierarchy 363 fact table level 88
entity 50 fact tables, aggregate 88
entry points, user hierarchy 360 fact tables, base 88
existing source data, creating a logical data fact tables, physical schema 87

fact, MicroStrategy Architect 185 Hierarchy Editor, defining user hierarchy

factors to consider in creating a data ware- elements 358
house schema 99 Hierarchy Editor, setting element
factors to consider in creating a logical data display 363
model 58 Hierarchy Editor, setting entry points 360
facts 26 Hierarchy View tab, Architect graphical
facts, column alias 212 interface 420
facts, heterogeneous 189 hierarchy, system 311
facts, homogeneous 188 hierarchy, user 347
facts, logical data model 47 higher-level lookup tables, completely de-
normalized schemas 95
facts, types 188
homogeneous attributes 238
foreign key, physical schema 85
homogeneous facts 188
form category 272
form display, attributes 308
form expressions, attributes 240 I
form expressions, types 240 ID columns, physical schema 80
form group 283 identify attributes, creating a logical data
form, attribute 234 model 65
identify facts, creating a logical data
H model 63
indirect attribute relationships 53
heterogeneous attributes 239 interfaces, project creation 138
heterogeneous attributes, creating in the introduction, Architect graphical
Attribute Editor 280 interface 405
heterogeneous facts 189 introduction, logical data modeling 43
heterogeneous facts, creating in the Fact introduction, physical schemas 77
Editor 207
hiding the Properties pane 425
hiding the Warehouse Tables pane 412 K
hierarchies 26 key, attribute 293
hierarchies, logical data model 55 key, compound 81
Hierarchy Editor 352 key, foreign 85
Hierarchy Editor, configuring a user hier- key, primary 81
archy for drilling 370 key, simple 81
Hierarchy Editor, creating user keys, tables 81
hierarchies 354
Hierarchy Editor, defining attribute
filters 367 L
Hierarchy Editor, defining browse layer, All Project Tables 414
attributes 358

layer, custom 415 M

layers, Project Tables View tab 414
managing the project schema,
level, fact table 88 overview 38
limit, element display 363 many-to-many attribute relationships 54
link display, Architect settings 442 many-to-many relationships, relationship
links between project tables, Project Tables tables 86
View tab 416 menu bar, Architect graphical
list information from the source data, cre- interface 429
ating a logical data model 62 metadata 24
loading the Warehouse Catalog, Architect metadata database, creating 112
settings 439
metadata DSN, creating 112
locked element display 363
metadata shell 111
logical data model 43
metadata shell, creating 117
logical data model and MicroStrategy
metadata shell, MicroStrategy Configura-
Architect 44
tion Wizard 117
logical data model components 47
metadata, configuration 111
logical data model, attribute elements 52
metadata, populating 24
logical data model, attribute
relationships 53 metric creation settings, Architect 447
logical data model, attributes 48 MicroStrategy Architect and browsing 32
logical data model, attributes and attribute MicroStrategy Architect and drilling 30
forms 50 MicroStrategy Architect and physical
logical data model, creating 58 schema 78
logical data model, dimensions 55 MicroStrategy Architect and reporting 28
logical data model, example 44 MicroStrategy Architect and the logical
data model 44
logical data model, existing source data 59
MicroStrategy Architect, attribute 231
logical data model, facts 47
MicroStrategy Architect, attribute
logical data model, hierarchies 55 form 234
logical data model, steps to creating 61 MicroStrategy Architect, creating schema
logical data model, technical and perfor- objects 26
mance considerations 60 MicroStrategy Architect, fact 185
logical data model, user reporting MicroStrategy Architect, overview 23
requirements 58
MicroStrategy Architect, populating the
logical data modeling, introduction 43 metadata 24
logical table 158 MicroStrategy Architect, roles 28
Logical Table Editor 171 MicroStrategy Architect, user
logical tables versus physical tables 158 hierarchy 347
lookup tables for attributes, Attribute Cre- MicroStrategy business intelligence
ation Wizard 256 architecture 24
lookup tables, physical schema 83

MicroStrategy Configuration Wizard, cre- N

ating the metadata shell 117
normalization 90
MicroStrategy Connectivity Configuration
Wizard, creating the metadata normalized schema 90
DSN 112
moderately denormalized schema 93 O
modifying attribute keys, modifying
attributes 293 ODBC Data Source Administrator, creat-
ing the metadata DSN 114
modifying attributes, Attribute Editor 287
one-to-many attribute relationships 54
modifying attributes, creating new attri-
bute forms 287 one-to-many relationships, relationship
tables 85
modifying attributes, deleting existing at-
tribute forms 291 one-to-one attribute relationships 54
modifying attributes, modifying attribute one-to-one relationships, relationship
keys 293 tables 85
modifying attributes, modifying column organization, course 39
aliases 294 organize hierarchies, creating a logical
modifying attributes, modifying existing data model 66
attribute forms 288 overview, Architect graphical interface
modifying attributes, modifying lookup components 408
tables 292 overview, Architect graphical interface
modifying column aliases, modifying settings 437
attributes 294 overview, creating the project in Mi-
modifying column aliases, modifying croStrategy Architect 37
facts 212 overview, designing the data warehouse
modifying existing attribute forms, modi- schema 36
fying attributes 288 overview, designing the logical data
modifying existing fact expressions, modi- model 36
fying facts 210 overview, managing the project
modifying facts, creating new fact schema 38
expressions 209 overview, MicroStrategy Architect 23
modifying facts, deleting existing fact overview, project creation 111
expressions 211 overview, project design process 35
modifying facts, Fact Editor 209
modifying facts, modifying column
aliases 212
P
modifying facts, modifying existing fact performance considerations, creating a
expressions 210 logical data model 60
modifying lookup tables, modifying physical or logical table view, Architect
attributes 292 settings 440
physical schema 77

physical schema and MicroStrategy warehouse schema 36

Architect 78 project design process, designing the logi-
physical schema components 80 cal data model 36
physical schema, column types 80 project design process, managing the proj-
physical schema, columns 80 ect schema 38
physical schema, compound key 81 project design process, overview 35
physical schema, creating 99 project metadata, configuration 111
physical schema, description columns 80 project object, creating 140
physical schema, fact columns 80 Project objects pane, Architect graphical
interface 427
physical schema, fact tables 87
Project objects pane, docking 427
physical schema, foreign key 85
Project objects pane, undocking 428
physical schema, ID columns 80
project schema 134
physical schema, lookup tables 83
project schema, updating 134
physical schema, primary key 81
project source 124
physical schema, relationship tables 84
project source creation, Project Source
physical schema, simple key 81
Manager 124
physical schema, table keys 81
Project Source Manager, creating a project
physical schemas, introduction 77 source 124
physical tables versus logical tables 158 project source, creating 124
populating the metadata 24 project source, direct mode 124
primary key, physical schema 81 project source, server mode 124
profile, query 100 project table 157
project connectivity, configuration 123 project table display, Architect
project connectivity, illustration 132 settings 440
Project Creation Assistant 138 project table link display, Architect
Project Creation Assistant, accessing the settings 442
Attribute Creation Wizard 243 Project Tables View tab, Architect graphi-
Project Creation Assistant, accessing the cal interface 414
Fact Creation Wizard 193 Project Tables View Tab, exporting and
Project Creation Assistant, accessing the copying images 418
Warehouse Catalog 160 Project Tables View tab, layers 414
Project Creation Assistant, Project Tables View tab, viewing links be-
components 140 tween project tables 416
project creation interfaces 138 Project Tables View tab, viewing relation-
project creation workflow 133 ships between attributes 417
project creation, overview 111 project warehouse catalog 164
project design process, creating the project Properties pane, Architect graphical
in MicroStrategy Architect 37 interface 423
project design process, designing the data Properties pane, docking 426

Properties pane, showing or hiding 425 interface 433

Properties pane, undocking 425 saving user hierarchies 356
Properties pane, viewing objects 423 Schema menu, accessing the Attribute Cre-
properties, attribute forms 271 ation Wizard 245
Schema menu, accessing the Fact Creation
Wizard 194
Q Schema menu, accessing the Warehouse
query performance, creating a data ware- Catalog 162
house schema 100 schema object editors 142
query profile 100 schema objects 26
schema objects, basic 26
R schema objects, creating 26, 133
schema types, physical schema types 90
redo actions, Architect graphical
schema types, summary 98
interface 435
schema update, Architect settings 439
relationship recognition, Architect
settings 445 schema, completely denormalized 94
relationship tables, many-to-many schema, completely normalized 92
relationships 86 schema, denormalized 90
relationship tables, one-to-many schema, moderately denormalized 93
relationships 85 schema, normalized 90
relationship tables, one-to-one schema, physical 77
relationships 85 schema, project 134
relationship tables, physical schema 84 schema, star 96
relationships between attributes, Project selected tables, Warehouse Tables
Tables View tab 417 pane 410
removing tables from a project, Warehouse selecting lookup tables for attributes, Attri-
Catalog 168 bute Creation Wizard 256
report display forms 308 server mode, project source 124
reporting and MicroStrategy Architect 28 setting element display, Hierarchy
reporting requirements, creating a data Editor 363
warehouse schema 100 setting entry points, Hierarchy Editor 360
reporting requirements, creating a logical settings overview, Architect graphical
data model 58 interface 437
roles, MicroStrategy Architect 28 shell, metadata 111
rules, Attribute Creation Wizard 246 showing the Properties pane 425
rules, Fact Creation Wizard 196 showing the Warehouse Tables pane 412
simple attribute form expressions 240
S simple attribute form expressions, creating
in the Attribute Editor 273
saving project work, Architect graphical

simple fact expressions 191 undocking the Properties pane 425

simple fact expressions, creating in the undocking the Warehouse Tables
Fact Editor 203 pane 412
simple key, physical schema 81 unlocked element display 363
sort order, user hierarchy 372 updating the project schema 134
source data, creating a logical data updating the schema, Architect
model 59 settings 439
star schema 96 used columns, Warehouse Tables
steps to creating a logical data model 61 pane 410
structure of a logical data model, logical user hierarchies 33
data model structure 57 user hierarchies, saving 356
summary of schema types 98 user hierarchy creation, Hierarchy
system hierarchy 33, 311 Editor 354
user hierarchy elements, Hierarchy
Editor 358
T user hierarchy, attribute filters 367
table keys, physical schema 81 user hierarchy, browse attributes 358
table, logical 158 user hierarchy, defining the sort order 372
table, project 157 user hierarchy, defining the sort order for
tables 26 browsing 373
tables, adding to a project 165 user hierarchy, defining the sort order for
tables, fact 87 drilling 376
tables, lookup 83 user hierarchy, drilling 370
tables, relationship 84 user hierarchy, element display 363
tables, removing from a project 168 user hierarchy, entry points 360
technical considerations, creating a logical user hierarchy, MicroStrategy
data model 60 Architect 347
three-tier mode, project source 124 user reporting requirements, creating a
data warehouse schema 100
toolbar, Architect graphical interface 430
user reporting requirements, creating a
two-tier mode, project source 124 logical data model 58
types of attribute form expressions 240 using the Attribute Creation Wizard 243
types of attributes 237 using the Attribute Editor 269
types of fact expressions 190 using the Fact Creation Wizard 193
types of facts 188 using the Fact Editor 201
using the Hierarchy Editor 352
U using the Logical Table Editor 171
undo actions, Architect graphical using the Warehouse Catalog 160
interface 435
undocking the Project objects pane 428

V
viewing information for project tables,
Logical Table Editor 171
viewing links between project tables, Proj-
ect Tables View tab 416
viewing objects, Properties pane 423
viewing relationships between attributes,
Project Tables View tab 417
volume of data, creating a data warehouse
schema 100
W
Warehouse Catalog 160
Warehouse Catalog load, Architect
settings 439
Warehouse Catalog, adding tables to a
project 165
warehouse catalog, project 164
Warehouse Catalog, removing tables from
a project 168
Warehouse Tables pane, Architect graphi-
cal interface 409
Warehouse Tables pane, available
columns 410
Warehouse Tables pane, available
tables 410
Warehouse Tables pane, color
mapping 411
Warehouse Tables pane, docking 413
Warehouse Tables pane, selected
tables 410
Warehouse Tables pane, showing or
hiding 412
Warehouse Tables pane, undocking 412
Warehouse Tables pane, used
columns 410
workflow, project creation 133


PRJESS 901 Jan11 Color PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PRJESS 901 Jan11 Color PDF

Uploaded by

Copyright:

Available Formats

MICROSTRATEGY A RCHITECT: PROJECT DESIGN ESSENTIALS

MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition,

MicroStrategy Education Services MicroStrategy Incorporated

Preface Course Description.................................................................... 11

1. Introduction to Lesson Description ................................................................... 21

© 2011 MicroStrategy, Inc. 5

Creating the Project in MicroStrategy Architect ..................... 37

2. Designing the Logical Lesson Description ................................................................... 41

3. Designing the Data Lesson Description ................................................................... 75

6 © 2011 MicroStrategy, Inc.

4. Creating a Project in Lesson Description ................................................................. 109

5. Working with Tables Lesson Description ................................................................. 155

6. Working with Facts Lesson Description ................................................................. 183

© 2011 MicroStrategy, Inc. 7

Defining Fact Creation Rules ............................................... 196

7. Working with Lesson Description ................................................................. 229

8. Working with User Lesson Description ................................................................. 345

8 © 2011 MicroStrategy, Inc.

Creating User Hierarchies.................................................... 354

9. Introduction to the Lesson Description ................................................................. 403

A. MicroStrategy Tutorial Appendix Description.............................................................. 453

© 2011 MicroStrategy, Inc. 9

Products Schema ................................................................ 466

B. What’s New in Appendix Description.............................................................. 469

Index ......................................................................................... 479

10 © 2011 MicroStrategy, Inc.

This 2-day course covers how to design and create a

Students will learn about the role of MicroStrategy

© 2011 MicroStrategy, Inc. 11

Who Should Take This Course

• MicroStrategy Desktop: Reporting Essentials

• MicroStrategy Architect: Advanced Project Design

• MicroStrategy Advanced Data Warehousing

• Certified Project Designer

12 Who Should Take This Course © 2011 MicroStrategy, Inc.

• Describe how you use MicroStrategy Architect to populate

• Describe the purpose of a logical data model and explain

• Describe the purpose of a physical schema and explain

• Explain the tasks involved in creating a project in

• Describe how tables are used in a MicroStrategy project,

• Describe how facts are used in a MicroStrategy project,

© 2011 MicroStrategy, Inc. Course Objectives 13

• Describe how attributes and attribute forms are used in a

• Describe how user hierarchies are used in a MicroStrategy

• Describe how the Architect graphical interface differs from

14 Course Objectives © 2011 MicroStrategy, Inc.

About the Course Materials

• Course—You will achieve these overall objectives by

• Main Topic—You will achieve this secondary objective by

© 2011 MicroStrategy, Inc. About the Course Materials 15

Opportunities for Practice

The following sections within lessons provide you with

References to screen elements and keys that are the focus of

Click Select Warehouse.

16 About the Course Materials © 2011 MicroStrategy, Inc.

References to code, formulas, or calculations within

References to literal data you must type in an exercise or

References to a keyboard key or shortcut keys are in

The aggregation level is the level of calculation for the

© 2011 MicroStrategy, Inc. About the Course Materials 17

Notes and Warnings

A note icon indicates helpful information.

The following heading icons are used to indicate specific