Microstrategy 2 PDF

MICROSTRATEGY ARCHITECT: PROJECT DESIGN ESSENTIALS
Course Guide
Version: PRJESS-941-Mar14-Color
20002014 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, Inc. 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, Inc. 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, Inc. 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, Inc. or any such other person or entity has been advised of the possibility of such
damages, or for the claim by any other party. In addition, MicroStrategy, Inc. or any other person involved in the
creation, production, or distribution of the 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 information contained in this Course and the Software are copyrighted and all rights are reserved by
MicroStrategy, Inc. MicroStrategy, Inc. 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, Inc. 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 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 SoftwareRestricted Rights at FAR 52.227-19, as
applicable. Contractor is MicroStrategy, Inc., 1850 Towers Crescent Plaza, Tysons Corner, Virginia 22182. Rights are
reserved under copyright laws of the United States with respect to unpublished portions of the Software.
Copyright Information
All Contents Copyright 2014 MicroStrategy Incorporated. All Rights Reserved.
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, 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,127,403, 7,174,349, 7,181,417, 7,194,457, 7,197,461, 7,228,303, 7,260,577, 7,266,181,
7,272,212, 7,302,639, 7,324,942, 7,330,847, 7,340,040, 7,356,758, 7,356,840, 7,415,438, 7,428,302, 7,430,562,
7,440,898, 7,486,780, 7,509,671, 7,516,181, 7,559,048, 7,574,376, 7,617,201, 7,725,811, 7,801,967, 7,836,178, 7,861,161,
7,861,253, 7,881,443, 7,925,616, 7,945,584, 7,970,782, 8,005,870, 8,051,168, 8,051,369, 8,094,788, 8,130,918,
8,296,287, 8,321,411 and 8,452,755. Other patent applications are pending.
How to Contact Us
MicroStrategy Education Services
1850 Towers Crescent Plaza
Tysons Corner, VA 22182
Phone: 877.232.7168
Fax: 703.848.8602
E-mail: education@microstrategy.com
http://www.microstrategy.com/education
MicroStrategy Incorporated
1850 Towers Crescent Plaza
Tysons Corner, VA 22182
Phone: 703.848.8600
Fax: 703.848.8610
E-mail: info@microstrategy.com
http://www.microstrategy.com
TABLE OF CONTENTS
Preface
Course Description.................................................................... 13
Who Should Take This Course .............................................. 14
Course Prerequisites ............................................................. 14
Follow-Up Courses ................................................................ 14
Related Certifications............................................................. 14
Course Objectives ................................................................. 15
About the Course Materials ......................................................... 17
Content Descriptions ............................................................. 17
Learning Objectives ............................................................... 17
Lessons ................................................................................. 17
Opportunities for Practice ...................................................... 18
Typographical Standards ....................................................... 18
MicroStrategy Courses .......................................................... 20
Core Courses......................................................................... 20
Advanced Courses ................................................................ 21
1. Introduction to
MicroStrategy
Architect
Lesson Description ................................................................... 23

Lesson Objectives ................................................................. 24
Overview of MicroStrategy Architect............................................ 25
Populating the Metadata ........................................................ 26
Creating Schema Objects ...................................................... 28
Roles of MicroStrategy Architect ................................................. 30
MicroStrategy Architect and Reporting .................................. 30
MicroStrategy Architect and Drilling....................................... 31
MicroStrategy Architect and Browsing ................................... 34
Overview of the Project Design Process ..................................... 36
Designing the Logical Data Model ......................................... 36
2014 MicroStrategy Inc.
Table of Contents
MicroStrategy Architect: Project Design Essentials
Designing the Data Warehouse Schema............................... 37

Creating the Project in MicroStrategy Architect ..................... 37
Managing the Project Schema............................................... 38
Course Organization .............................................................. 39
Lesson Summary......................................................................... 40
2. Designing the Logical

Data Model

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............................................................................. 54
Structure of a Logical Data Model.......................................... 55
Creating a Logical Data Model .................................................... 57
Factors to Consider ............................................................... 57
Steps to Creating a Logical Data Model ................................ 60
Lesson Summary......................................................................... 65
Business Scenario: Designing the Logical Data Model ............... 67
Creating a Logical Data Model............................................... 67
3. Designing the Data

Warehouse Schema

Introduction to Physical Schemas................................................ 71
What Is a Physical Schema? ................................................. 71
Using the Physical Schema in MicroStrategy Architect ......... 72
Physical Schema Components.................................................... 73
Column Types........................................................................ 73
Table Keys ............................................................................. 74
Lookup Tables ....................................................................... 76
Relationship Tables ............................................................... 76
Fact Tables ............................................................................ 79
Schema Types............................................................................. 81
Normalized Versus Denormalized Schemas ......................... 81
Completely Normalized Schema............................................ 82
Moderately Denormalized Schema........................................ 83
Completely Denormalized Schema........................................ 84
Summary of Schema Types................................................... 88
Table of Contents
Creating a Data Warehouse Schema .......................................... 89

Factors to Consider ............................................................... 89
Lesson Summary......................................................................... 92
Business Scenario: Designing the Data Warehouse Schema..... 95
Creating a Data Warehouse Schema .................................... 95
4. Creating a Project in
MicroStrategy
Architect

Lesson Objectives ............................................................... 100
Overview of Project Creation ..................................................... 101
Configuring the Project Metadata ........................................ 101
Configuring Project Connectivity.......................................... 110
Creating the Schema Objects .............................................. 119
Updating the Project Schema .............................................. 119
Project Creation Interfaces ........................................................ 122
Project Creation Assistant.................................................... 122
Architect Graphical Interface................................................ 125
Schema Object Editors ........................................................ 126
Lesson Summary....................................................................... 127
Exercises: Creating a Project in MicroStrategy Architect .......... 129
Creating the Metadata Database ......................................... 129
Creating the DSN for the Metadata...................................... 130
Creating the Metadata Shell ................................................ 131
Creating the Project Source................................................. 132
Creating the Database Instance .......................................... 133
Creating the Project Object.................................................. 135
5. Introduction to the
Architect Graphical
Interface
Lesson Description ................................................................. 137

Introduction to Architect ............................................................. 139
Accessing the Architect Graphical Interface ........................ 140
Overview of Architect Components ........................................... 142
Warehouse Tables Pane ..................................................... 143
Project Tables View Tab ...................................................... 147
Hierarchy View Tab.............................................................. 153
Properties Pane ................................................................... 155
Architect Menu ..................................................................... 158
Toolbar................................................................................. 159
Saving Project Work in Architect ............................................... 163
Undo and Redo Actions in Architect .......................................... 164
Table of Contents
Defining Architect Settings......................................................... 165

Configuration Settings ......................................................... 166
Metric Creation Settings....................................................... 168
Advanced View Options....................................................... 169
Automatic Schema Recognition Options ............................. 170
Lesson Summary....................................................................... 174
6. Working with Tables

What Is a Project Table? ........................................................... 177
Physical Tables Versus Logical Tables ............................... 177
Adding Tables to Projects.......................................................... 179
Removing Tables from the Project....................................... 182
Using Layers for Project Tables................................................. 183
Creating Layers ................................................................... 183
Modifying Layers.................................................................. 186
Removing Layers ................................................................. 188
Viewing and Modifying Properties for Project Tables ................ 189
Display Properties for Project Tables ........................................ 193
Logical View......................................................................... 193
Physical View....................................................................... 193
Configuring Default Display Options .................................... 196
Finding Project Tables to Perform Tasks................................... 197
Lesson Summary....................................................................... 199
Exercises: Working with Tables................................................. 201
Adding Fact Tables to the Project........................................ 201
Adding Lookup Tables to the Project ................................... 204
7. Working with Facts

What Is a Fact?.......................................................................... 211
Types of Facts ........................................................................... 214
Homogeneous Facts............................................................ 214
Heterogeneous Facts .......................................................... 215
Types of Fact Expressions................................................... 216
Creating Facts ........................................................................... 219
Using Layers to Create Facts .............................................. 219
Fact Creation Methods ........................................................ 219
Creating Facts Manually ...................................................... 220
Table of Contents
Modifying Facts.......................................................................... 234

Using the Project Tables View Tab...................................... 234
Using the Properties Pane ................................................... 242
Lesson Summary....................................................................... 246
Exercises: Working with Facts................................................... 249
Creating Facts in the Project................................................ 249
Modifying Facts in the Project.............................................. 251
Adding Another Fact to the Project ...................................... 255
8. Working with
Attributes

What Is an Attribute? ................................................................. 259
What Is an Attribute Form?........................................................ 262
Types of Attributes..................................................................... 265
Compound Attributes ........................................................... 265
Homogeneous Attributes ..................................................... 266
Heterogeneous Attributes .................................................... 266
Types of Attribute Form Expressions................................... 267
Creating Attributes ..................................................................... 270
Using Layers to Create Attributes ........................................ 270
Attribute Creation Methods .................................................. 270
Creating Attributes Manually................................................ 271
Reusing Attribute Columns .................................................. 284
Modifying Attribute Forms.......................................................... 285
Defining Attribute Form Display ........................................... 297
Creating Attribute Relationships .......................................... 300
Creating Attribute Relationships Manually ........................... 301
What Is the System Hierarchy? ................................................. 306
Lesson Summary....................................................................... 308
Exercises: Working with Attributes ............................................ 311
Creating Attributes in the Project ......................................... 311
Modifying Attributes in the Project ....................................... 319
9. Working with User

Hierarchies

What Is a User Hierarchy?......................................................... 325
Creating User Hierarchies ......................................................... 330
Creating User Hierarchies.................................................... 331
Adding Attributes to User Hierarchies.................................. 332
Table of Contents
Defining User Hierarchy Elements....................................... 333

Lesson Summary....................................................................... 346
Exercises: Working with User Hierarchies................................. 349
Creating User Hierarchies in the Project.............................. 349
10. Automatic Schema

Recognition

Overview of Automatic Schema Recognition............................. 359
When to Use Automatic Schema Recognition ..................... 359
What Columns Are Mapped with Automatic Schema
Recognition? ........................................................................ 360
Heuristics for Automatic Schema Recognition..................... 361
Using Automatic Schema Recognition ...................................... 366
Creating Facts and Attributes for All Project Tables ............ 366
Creating Facts and Attributes for Selected Project Tables .. 370
Automatic Relationship Recognition .................................... 374
Lesson Summary....................................................................... 378
Exercises: Automatic Schema Recognition ............................... 381
Using Table-Level Automatic Schema Recognition............. 381
Using Project-Level Automatic Schema Recognition to Create
Customer-Related Schema Objects .................................... 385
Product-Related Schema Objects........................................ 391
Creating Customer and Product User Hierarchies............... 397
Creating a Report in the Project........................................... 404
A. MicroStrategy Tutorial Appendix Description.............................................................. 409

The MicroStrategy Tutorial Data Model ..................................... 410
Geography Hierarchy........................................................... 411
Customers Hierarchy ........................................................... 412
Time Hierarchy..................................................................... 413
Products Hierarchy .............................................................. 414
The MicroStrategy Tutorial Schema .......................................... 415
Geography Schema ............................................................. 417
Customers Schema ............................................................. 418
Time Schema....................................................................... 419
Products Schema ................................................................ 420
Fact Tables Schema ............................................................ 421
Partition Mapping Table ....................................................... 421
10
B. Other Methods for

Creating Schema
Objects
Table of Contents
Appendix Description.............................................................. 423

Project Creation Assistant and Editors ...................................... 424
Defining the Sort Order for User Hierarchies............................. 433
Index ......................................................................................... 441
11
Table of Contents
12
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 two day
MicroStrategy Developer: Reporting Essentials course.
First, 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. Next, students will learn
about the project creation process, including how to use the
Project Creation Assistant and the Architect graphical
interface. They will learn about working with tables, facts,
attributes, and user hierarchies. Finally, students will learn
how to use automatic schema recognition to enhance project
creation process.
13
Preface
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 Developer: 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
14 Who Should Take This Course
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 24)
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 70)
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 100)
Describe the Architect graphical interface and its components. Learn to use
different views, panes and Architect settings, and describe how you can use
Architect to work on projects. (Page 138)
Describe how tables are used in a MicroStrategy project and select project
tables in the MicroStrategy Architect graphical interface. (Page 176)
Describe how facts are used in a MicroStrategy project, explain the different
types of facts and fact expressions, and create and modify basic and complex
facts using the Architect graphical interface. (Page 210)
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
Architect graphical interface, and describe how the system hierarchy is
created and used in a MicroStrategy project. (Page 258)
Describe how user hierarchies are used in a MicroStrategy project, create

user hierarchies, and define user hierarchy elements using Architect
graphical interface. (Page 324)
Course Objectives
15
Preface
Describe how automatic schema recognition works and create facts,

attributes, and relationships in the Architect graphical interface using
automatic schema recognition. (Page 358)
16 Course Objectives
Preface
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:
CourseYou 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.
LessonYou 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 TopicYou 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.
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.
17
Preface
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.
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
18 About the Course Materials
Preface
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.

icon calls your attention to very important information that
Ayouwarning
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
19
Preface
Precedes a Case Study
Precedes a Business Scenario
Precedes Exercises
MicroStrategy Courses
Core Courses
Implementing MicroStrategy: Development and Deployment
MicroStrategy Web Essentials
MicroStrategy Web for Professionals
MicroStrategy Web for Reporters and Analysts
MicroStrategy Visual Insight Essentials
MicroStrategy Report Services: Dynamic Dashboards
MicroStrategy Mobile for App Developers
MicroStrategy Developer: Reporting Essentials
MicroStrategy Developer: Advanced Reporting
MicroStrategy Office Essentials
Preface
Advanced Courses
MicroStrategy Administration: Configuration and Security
MicroStrategy Administration: Application Management
MicroStrategy Engine Essentials
MicroStrategy Architect: Advanced Project Design
MicroStrategy Advanced Data Warehousing
MicroStrategy Data Mining and Advanced Analytics
Deploying MicroStrategy High Performance BI
MicroStrategy Developer: Advanced Reporting Case Studies
MicroStrategy Freeform SQL Essentials
MicroStrategy Transaction Services for Mobile App and Dashboard

Developers
MicroStrategy Web SDK: Customization Essentials
MicroStrategy Web SDK: Customizing Security
MicroStrategy Web SDK: Portal Integration
*All courses are subject to change. Please visit the MicroStrategy Web site for the latest education offerings.
21
Preface
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 to 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.
23
Introduction to MicroStrategy Architect
Lesson Objectives
After completing this lesson, you will be able to:
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:
create various types of schema objects. (Page 25)
Explain how MicroStrategy Architect supports reporting, drilling, and

browsing. (Page 30)
Describe the steps involved in the project design process. (Page 36)
24 Lesson Objectives
Overview of MicroStrategy Architect

After completing this topic, you will be able to:
create various types of schema objects.
In the MicroStrategy Developer: 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 Developer
interface.
MicroStrategy Architect enables you to perform the following tasks:
Initially populate the metadata
Create schema objects
25
Populating the Metadata

In the MicroStrategy Developer: Reporting Essentials course, you learned
about the MicroStrategy Analytics Platform architecture:
MicroStrategy Analytics Platform 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.
26 Overview of MicroStrategy Architect
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.
27
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:
TablesLogical objects that correspond to physical tables stored in the data

warehouse that you want to use in a MicroStrategy project
FactsLogical 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.
AttributesLogical 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.
HierarchiesLogical objects that enable you to group attributes to reflect

their relationships or provide convenient browsing and drilling paths in the
MicroStrategy reporting environment.
28 Overview of MicroStrategy Architect
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.
29
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

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.
30 Roles of MicroStrategy Architect
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 2011 or 2012.
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.
MicroStrategy Architect and Drilling

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
31
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.
33
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

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.
will learn more about the differences between system and user
You
hierarchies later in this course. For information on user hierarchies, see
What Is the System Hierarchy? starting on page 306.
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.
35
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.
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
36 Overview of the Project Design Process
information on logical data models, see Steps to Creating a Logical

For
Data Model starting on page 60.
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
information on schema designs, see Creating a Data Warehouse

For
Schema starting on page 89.
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.
a project without first having a logical data model in place can
Creating
complicate the task of project creation since you are essentially defining
your logical data model in MicroStrategy Architect.
a project without first having an effective data warehouse

Creating
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
37
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
information on creating a project in MicroStrategy Architect, see

For
Creating a Project in MicroStrategy Architect starting on page 99.
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
information on creating advanced schema objects in MicroStrategy

For
Architect, see the MicroStrategy Architect: Advanced Project Design
course.
38 Overview of the Project Design Process
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
39
Lesson Summary
In this lesson, you have learned:
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.
40 Lesson Summary
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.
41
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 57)
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.
data modeling is similar to multidimensional data modeling.
Logical
However, MicroStrategy Architect does not require you to explicitly
define dimensions, so this course uses the term 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.
information on the various components of a logical data model, see
For
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.
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.
44 Introduction to Logical Data Modeling
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
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
45
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
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.
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.
you are familiar with SQL, facts generally represent the numeric
Ifcolumns
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
47
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 companys 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.
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.
48 Logical Data Model Components
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
2012.
you are familiar with SQL, attributes generally represent the
Ifnon-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 (201201, 201202,
201203)
GROUP BY a11.MONTH_ID
49
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.
could have multiple hire dates if they were hired more than
Employees
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.
forms are a MicroStrategy-specific concept. For more
Attribute
information on attribute forms, see What Is an Attribute Form?
starting on page 262.
Attribute Elements
Attribute elements are the unique values of an attribute. For example, the
elements of the Year attribute could include 2010, 2011, and 2012, 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.
51
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:
DirectA 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.
IndirectTwo 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 partsa 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-oneEach 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-manyEach 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-manyEach 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).
53
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 customers 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.
information on the system hierarchy, see What Is the System
For
Hierarchy? starting on page 306. For information on user hierarchies,
see What Is a User Hierarchy? starting on page 325.
Structure of a Logical Data Model

When you put all these components togetherfacts, attributes and their
relationships, and hierarchiesyou 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
55
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.
this logical data model, all the facts are related to all the hierarchies,
Inso 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.
Developing a logical data model that meets the needs of users involves the
following tasks:
57
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.
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.
58 Creating a Logical Data Model
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.
there are application-level workarounds within
Sometimes,
MicroStrategy for missing source data that you cannot extrapolate at the
database level. For more information refer to Fact Level Extensions in
MicroStrategy Developer: 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.
59
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.
mentioned earlier, before you create the logical data model, you need
Asto 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.
61
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.
is possible for the same fact to be stored at different attribute levels
Itwithin
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.
all or most of the remaining items are attributes. You may
Generally,
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 attributesone-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.
should not assume the type of relationship that exists between two
You
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 2012, Q2
2012, Q3 2012, and Q4 2012, then the relationship between Year and
Quarter is one-to-many.
63
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.
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 relationshipsone-to-one,

one-to-many, and many-to-many.
Lesson Summary
65
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.
66 Lesson Summary
Business Scenario: Designing the 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.
a logical data model is an exercise that is open to interpretation
Creating
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.
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 illustration on the following page.
Business Scenario: Designing the Logical Data Model
67
Existing Source Data
illustration shows a very simple source system structure. In most

This
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.
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.
68 Business Scenario: Designing the Logical Data Model
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 when creating a data
warehouse schema.
69
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 71)
Describe the components of a physical schema, including various types of

columns and tables. (Page 73)
Describe the characteristics of various types of schema designs. (Page 81)
Describe the factors to consider in creating a data warehouse

schema. (Page 89)
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.
Introduction to Physical Schemas
71
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.
information on the various components of a physical schema, see
For
Physical Schema Components starting on page 73.
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.
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.
72 Introduction to Physical Schemas
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 columnsThese 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 columnsThese 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.
an attribute does not have a separate description column, the
When
ID column serves as both the ID and description.
Fact columnsThese columns store fact data. They are usually numeric.
73
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, emails, 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 keyThis type of key requires only one column to uniquely identify
each record within a table.
Compound keyThis type of key requires two or more columns to uniquely

identify each record within a table.
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.
74 Physical Schema Components
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.
75
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 attributeCategory, 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
Email 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.
a MicroStrategy project, you often treat the parent attribute in a
Inone-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 information on attribute
form, see What Is an Attribute Form? starting on page 262.
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.
77
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.
facts using attributes that have a many-to-many relationship
Analyzing
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.
79
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 detailby 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 detailby 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.
For example, consider the following lookup tables:
Normalized and Denormalized Tables
Schema Types
81
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
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
82 Schema Types
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
columnsEmployee_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
schema.
different levels.
Schema Types
83
The lookup tables in this example contain the IDs and descriptions for their
respective attributes as well as the IDs of all related higher-level attributes
within the hierarchy. For example, the LU_EMPLOYEE table has four
columnsEmployee_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
schema.
different levels.
84 Schema Types
The lookup tables in this example contain the IDs and descriptions for their
respective attributes as well as the IDs and descriptions of all related
higher-level attributes within the hierarchy. For example, the LU_EMPLOYEE
table has six columnsEmployee_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.
Schema Types
85
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.
86 Schema Types
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.
information on aggregate fact tables, see Base and Aggregate Fact
For
Tables starting on page 80.
Schema Types
87
information on star schemas and the use of aggregate fact tables

For
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 Type
Lookup Table Structure Advantages
Completely
Normalized
Schema
Contains an attributes ID
and description columns
as well as the ID column
of its immediate parent
Requires minimal
storage space and no
data redundancy
Requires more
joins for queries on
higher-level
attributes
Moderately
Denormalized
Schema
as well as the ID
columns of all related
higher-level attributes
Significantly reduces
the number of joins
necessary for queries
on higher-level
attributes
Requires slightly
more storage
space and some
data redundancy
Completely
Denormalized
Schema
as well as the ID and
description columns of all
related higher-level
attributes
Further reduces the

number of joins
necessary for queries
on higher-level
attributes
Requires
significantly more
storage space and
the greatest degree
of data redundancy
88 Schema Types
Disadvantages
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 trade-offs 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.
89
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 profilethe 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
The structure of your data warehouse schema should take 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 profilespecifically, the number of
higher-level versus detailed queries users will executecan 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
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.
90 Creating a Data Warehouse Schema
Database Maintenance
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.
91
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.
92 Lesson Summary
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.
Lesson Summary
93
94 Lesson Summary
Business Scenario: Designing the 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.
Business Scenario: Designing the Data Warehouse Schema
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.
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.
96 Business Scenario: Designing the Data Warehouse Schema
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 employees 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
Business Scenario: Designing the Data Warehouse Schema
98 Business Scenario: Designing the Data Warehouse Schema
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, Architect graphical interface, and the
schema object editors.
99
Creating a Project in MicroStrategy Architect
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 101)
Describe how to use the Project Creation Assistant, Architect graphical interface, and
schema object editors to create projects in MicroStrategy Architect. (Page 122)
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 26
empty tables known as the metadata shell. As you create a project and continue to add to
it, you populate these tables with information.
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.
101
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.
information on certified and supported database platforms for the metadata,
For
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 Wizard:
1 On the Start menu, select All Programs, select MicroStrategy Tools, and select
Connectivity Wizard.
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.
want to test the connection information that you enter, click Test. In the
IfTestyouConnection
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.
102 Overview of Project Creation
The following image shows the Driver Selection window of the MicroStrategy
Connectivity Wizard:
MicroStrategy Connectivity WizardDriver Selection Window
If the certified or supported database driver that you need to use is not available in the
MicroStrategy Connectivity 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, in the Search programs and files search box, type
C:\Windows\SysWoW64\Odbcad32.exe and press Enter.
2 In the ODBC Data Source Administrator window, click the System DSN tab.
3 On the System DSN tab, click Add.
4 In the Create New Data Source window, select the appropriate driver.
103
5 Click Finish.
6 In the next window, enter the appropriate connection information for the DSN.
name of this window and the exact settings it displays vary, depending on
The
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.
7 When you have finished entering the appropriate connection information, in the
ODBC Data Source Administrator window, click OK.
8 Close the Administrative Tools window.
The following image shows the System DSN tab of the ODBC Data Source Administrator:
ODBC Data Source AdministratorSystem 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.
105
To access the MicroStrategy Configuration Wizard:
1 On the Start menu, select All Programs, select MicroStrategy Tools, 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.
A truly empty metadata should not have existing metadata tables.
To create the metadata shell:
1 Open the MicroStrategy Configuration Wizard.

2 In the MicroStrategy Configuration Wizard, click Create 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.
DSN does not yet exist, you can create it by clicking New and then using
IfthetheMicroStrategy
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.
default, the MicroStrategy Configuration Wizard selects the script that is
Byoptimized
for your metadata database platform.
12 Click Next.
13 In the Summary window, click Finish.
bar displays at the bottom of the window to show the progress of the
ASQLstatus
script being executed. When the script finishes executing, a message
states that the configuration completed successfully.
14 Click Close.
107
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 WizardRepository Configuration: Repository Types
Window
The following image shows the Repository Configuration: Metadata Tables window of
the MicroStrategy Configuration Wizard:
MicroStrategy Configuration WizardRepository Configuration: Metadata Tables
Window
109
The following image shows the Summary window of the MicroStrategy Configuration
Wizard:
MicroStrategy Configuration WizardSummary 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 Developer.
Configuring project connectivity includes the following steps:
1 Create a project source.
2 Create a database instance, including a database connection and database login.
source and database instance that connect to the desired metadata and
Ifdataa project
warehouse already exist in MicroStrategy Developer, 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 Developer that enables you to
connect to the metadata. You can configure a project source to connect to the metadata
in one of the two ways:
DirectYou connect to the metadata in two-tier mode by specifying a DSN, login,

and password.
ServerYou 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 Developer.
You can also use the MicroStrategy Configuration Wizard to create project
sources.
To create a project source:
1 Open MicroStrategy Developer.
You do not need to log in to an existing project source.
2 In Developer, 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 a 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 a 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
111
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 Developer.
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 ManagerServer Mode Settings
The following image shows the direct mode settings in the Project Source Manager:
Project Source ManagerDirect Mode Settings
113
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 Developer. The database instance is
a configuration object you create in Developer 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 Developer.
To create a database instance and database connection:

2 In Developer, 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 a name of the database instance.
7 In the Database connection type drop-down list, select the appropriate database
connection type.
database connection type should match the database platform of the data
The
warehouse.
8 Under Database connection (default), click New.
to use an existing database connection, you can select it from the

Iflistyouandwant
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 a 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.
want to use an existing database login, you can select it from the list and
IfclickyouOK.
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 a 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.
new database instance displays in the Database Instances manager in
The
Developer.
115
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.
117
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.
project has at least one primary database instance. You can map a project to
Every
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.
119
When you make any changes to schema objectsadding, modifying, or deleting

themyou 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.
to schema object definitions are written to the metadata when you save
Changes
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.
three-tier projects, the schema is automatically updated when you stop and
For
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 Developer, 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 informationSelect this check box if you add, modify, or
delete schema objects.
Recalculate table keys and fact entry levelsSelect this check box if you
change the key structure of a table or the level at which a fact is stored.
Recalculate table logical sizesSelect 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.
table sizes determine which tables the MicroStrategy Engine uses in a

Logical
query. For information on how MicroStrategy Architect calculates logical table
sizes, see the MicroStrategy Architect: Advanced Project Design course.
Recalculate project client object cache sizeSelect this check box to update
the client object cache size for the project.
select this check box and the Use custom value option for object caches
Ifis you
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 cachesSelect 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
121
Project Creation Interfaces

schema object editors 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
Architect graphical interface
Schema object editors
The following topics describe each of these interfaces in more detail.

The Project Creation Assistant is a collection of wizards. It is also an alternative approach
to create schema objects. It uses a very linear, step-by-step approach. The primary
purpose of this tool is to create project objects.
more information about Project Creation Assistant, see the Other Methods
For
for Creating Schema Objects appendix starting on page 423.
To access the Project Creation Assistant:
1 In Developer, on the Schema menu, select Create New Project.
122 Project Creation Interfaces
The following image shows the Project Creation Assistant:

The Project Creation Assistant provides access to the following components:
Create projectEnables you to create the project object, name the project, and
configure selected project-level settings
Select tables from the Warehouse CatalogEnables 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 factsEnables you to use the Fact Creation Wizard to create basic facts
Create attributesEnables you to use the Attribute Creation Wizard to create basic
attributes
component provides an alternative interface for project creation. You
This
should use Architect graphical interface to design the schema objects.
ArchitectEnables you to open the Architect graphical interface. You can create all
the schema objects in this single interface.
123
You can access the Warehouse Catalog, Fact Creation Wizard, Attribute Creation Wizard,
and Architect graphical interface individually outside the Project Creation Assistant as
well.
In this course, you will work primarily with the Architect graphical interface.
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 a name of the project.
a project description or configuring other settings in this window is
Entering
optional.
3 Click OK.
The process of creating the initial project files takes a few minutes.
4 In the Project Creation Assistant, click OK.
action enables you to save the project and complete the rest of project
This
creation in Architect at a later time.
5 In the message window, click OK.
The following image shows the New Project window:

New Project Window
Architect Graphical Interface

The Architect graphical interface provides a more visual, freeform approach to working
on projects. It provides a consolidated interface that enables you to access a variety of
functions. It enables you to perform the following tasks:
Select the project tables
Create facts
Create attributes and their relationships
Create user hierarchies
You can create, modify, and remove schema objects or configure various settings for
these objects using this interface.
You will learn more about Architect graphical interface in this course.
125
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. You can use them as an alternative method to create or
modify schema objects. Schema object editors include Attribute Editor, Fact Editor,
Hierarchy Editor, and Logical Table Editor.
information about schema editors, see the Other Methods for Creating
For
Schema Objects appendix starting on page 423.
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 26

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 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 Developer.
A project source is the object in MicroStrategy Developer 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 Developer 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.
Lesson Summary
127
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, Architect graphical interface,
and schema object editors.
The Project Creation Assistant is a collection of wizards that provides a step-by-step

approach to project creation. It is an alternative tool for creating a project.
The Architect graphical interface provides a more visual, freeform approach to

working on projects. It is the primary tool for project creation. It enables you to create
all schema objects in a single interface.
The schema object editors provide an alternative approach to create and modify
individual schema objects one at a time. They provide access to more advanced
functions for creating more complex schema objects.
128 Lesson Summary

Exercises: Creating a Project in MicroStrategy
Architect
Over the next five lessons, you will use the Project Creation Assistant and Architect
graphical interface to create a new project source called My Tutorial Project and project
object called My Demo Project.
In this set of exercises, you will configure the metadata, create the project source and
database instance in MicroStrategy Developer, and create the project object.
Creating the Metadata Database

Overview
In this exercise, you will create an empty 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 need help.
Detailed Instructions
following instructions are for Microsoft Access 2007. The exact steps vary
The
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
1 On the Start menu, point to All Programs, point to Microsoft Office, and select
Microsoft Office Access.
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.
Exercises: Creating a Project in MicroStrategy Architect
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.
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.
You can use the detailed instructions if you want help.
Open the MicroStrategy Connectivity Wizard
1 On the Start menu, point to All Programs, point to MicroStrategy 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.
130 Exercises: Creating a Project in MicroStrategy Architect
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
1 On the Start menu, point to All Programs, point to MicroStrategy Tools, 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.
do not need to provide a login and password since you are using a
You
Microsoft Access database.
8 Click Next.
9 In the message window, click Yes.
10 In the Summary window, click Finish.
11 When the configuration is complete, click Close.
12 In the MicroStrategy Configuration Wizard, click Exit.
Creating the Project Source

Overview
In this exercise, you will use the Project Source Manager in MicroStrategy Developer 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 Developer, 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.
do not need to provide a login and password since you are using a
You
Microsoft Access database.
8 In the Confirm Login/Password window, click Yes.
9 In the Project Source Manager, click OK.
10 Keep MicroStrategy Developer open for the next exercise.
Creating the Database Instance

Overview
In this exercise, you will use the Database Instances manager in MicroStrategy Developer
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.
DSN for the MicroStrategy_Tutorial_Data data warehouse already exists on

The
your machine.
Open the Database Instances manager
1 In Developer, log in to the My Tutorial Project Source.
You can log in as Administrator with no password.

have not yet created any projects in the project source, so you should see a
You
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.

do not actually have a login and password since you are using a Microsoft
You
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 Developer open for the next exercise.
Creating the Project Object

Overview
In this exercise, you will create a new project object named My Demo Project in the My
Tutorial Project Source.
Open the Project Creation Assistant
1 In Developer, 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 Demo Project as the project name.
4 Click OK.
5 In the Project Creation Assistant, click OK.
6 In the message window, click OK.
You will continue creating this project in the exercises for subsequent lessons.
5
INTRODUCTION TO THE
ARCHITECT GRAPHICAL
INTERFACE
Lesson Description
This lesson introduces you to Architect graphical interface, a centralized graphical
interface that integrates project design functions. You can work with various schema
objects within this centralized interface. Architect graphical interface provides a visual
representation of your project as you create it, which provides an intuitive workflow.
In this lesson, you will learn about the Architect graphical interface and about each of its
components. You will also learn about project design functions, saving project work, and
Architect configuration settings.
137
Introduction to the Architect Graphical Interface
Lesson Objectives
Describe the Architect graphical interface and its components. Learn to use different
views, panes and Architect settings, and describe how you can use Architect to work on
projects.
Configure the project metadata, configure project connectivity, use the project
creation workflow to create schema objects, and update the project
schema. (Page 101)
schema object editors to create projects in MicroStrategy Architect. (Page 122)
Introduction to Architect
Describe how you can work with Architect graphical interface and access Architect in
MicroStrategy Developer.
Architect is a graphical interface that provides a visual, freeform approach to working on

projects. It provides a consolidated interface to complete various project design tasks
that enables you to access many different functions. It enables you to work with the
following schema objects:
Tables
Facts
Attributes
User Hierachies
You can create, modify, and remove schema objects or configure various settings for
these objects using this interface.
can perform most project design tasks in the Architect graphical interface.
You
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.
Architect graphical interface provides freeform drag and drop, and one dedicated
interface 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 this interface to work with schema objects can be useful as you learn about
the various components and properties that relate to each type of object.
Architect graphical interface provides an integrated, interactive experience for working
on projects. For example, you can add new tables to a project, add new facts and modify
existing facts, create a new attribute, and remove an existing user hierarchy all within
this one interface.
Project Creation Assistant is an alternative tool for bulk project creation. It is
The
a collection of wizards that leads you through the process of creating a project in a
very linear, step-by-step manner. For more information, see the Other Methods
for Creating Schema Objects appendix starting on page 423.
139
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 Developer, log in to the project source that contains the project you want to
modify.
2 Open the project you want to modify.
3 Do one of the following:
On the Schema menu, select Architect.
Or
On the project name, right-click and select Architect.
The following image shows the option for accessing Architect on the Schema menu:
Accessing Architect from the Schema Menu
can also access Architect from the Project Creation Assistant when you first
You
create a project.
140 Introduction to Architect
MicroStrategy Architect permits multiple users to access schema objects simultaneously

by providing two modes, Read Only mode and Edit mode.
The Read Only mode allows users to view schema object definitions without locking the
schema for other users. Users in Read Only mode cannot make changes to schema
objects. Additionally, users in Read Only mode cannot access schema editors that require
the ability to make updates to the project.
The Edit mode provides all capabilities of modifying schema objects and locks the
schema object from being modified by all other users. Therefore, only one user can use
edit mode for a project at a given time.
one user can open the project in the Edit mode at a time to prevent schema
Only
inconsistencies.
When opening the Architect graphical interface, a Read Only window enables you to
choose Read Only or Edit mode. Your selection enables the entire project to use that
mode. To change your mode at a later time, you can use the Schema menu Read Only
Mode option.
Read Only Window
141
Overview of Architect Components

Describe the components of the Architect graphical interface.
The Architect graphical interface consists of several components that help in designing
project and schema objects. 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
The Architect graphical interface has the following components:
Warehouse Tables pane
Project Tables View tab
142 Overview of Architect Components
Hierarchy View tab
Properties pane
Menu bar
Toolbar with two tabs
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
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.
143
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.
can add any database instances that are available in the project source to a
You
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.
By default, when you expand a database instance, Architect loads both selected and
available tables. However, you can disable loading the entire catalog of tables so that only
selected tables are loaded.
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
145
Color mapping enables you to better distinguish between project tables that come from
different data sources.
has 10 default mapping colors that are assigned sequentially to database
Architect
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.
Warehouse Tables pane does not display at all if you are working on the
The
Hierarchy View tab.
To show or hide the Warehouse Tables pane:
1 On the Home tab, in the Panels section, click Show the Warehouse tables section.
toolbar button option is a toggle feature. If the Warehouse Tables pane is

The
showing, clicking the toolbar button hides the pane. If the pane is hidden,
clicking the toolbar button or selecting the menu option displays the pane.
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 TabAll Project Tables Layer
147
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 TabCustom Layer
You use the Project Tables View tab to work with tables and create, modify, and remove
facts and attributes.
can change the display of the Project Tables View tab by zooming in or out on
You
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.
considers two columns to be the same if they have the same column
Architect
name and data type.
For example, the following image shows the Year attribute selected in the LU_YEAR
table:
Attribute Link on Project Tables View Tab
The gray line indicates links to the same attribute in the LU_MONTH, LU_YEAR,
LU_DAY, and LU_QUARTER table.
149
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 Home tab, in the View section, select Show relationships.

menu option is a toggle feature. If the attribute relationships are shown,
This
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.

have to create attribute relationships before you can view them on the Project
You
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 Home tab, in the Clipboard section, select Export Image.
151
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 TabSystem Hierarchy
153
You can also view any user hierarchies that you create. The following image shows a user
hierarchy for time-related attributes:
Hierarchy View TabUser Hierarchy
Hierarchy View tab has some of the same display functions as the Project
The
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.
titles of properties you cannot modify generally display in gray text. However,
The
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 tabsAttributes, 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.
You can search for attributes, facts, and tables using the properties pane.
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.
155
The following image shows the Properties pane with the information for the Customer
attribute displayed:
Properties PaneCustomer Attribute
To search an object using Properties pane:
1 In the Properties pane, click the appropriate tab.

2 On the appropriate tab, type in the object name you want to search and click enter
3 In the Project Tables view, a table will be highlighted that shows the object you are
searching.
you have created layers, always go to All Project Tables layer before you
Ifsearch
for an object.
you are on the Hierarchy View tab, the Properties pane displays only the
When
Attributes tab since attributes are the only type of object displayed in system or
user hierarchies.
Managing the Properties Pane

You can show or hide the Properties pane as needed.
To show or hide the Properties pane:
1 On Home tab, in the Panels section, click Show the properties section.
toolbar button is a toggle feature. If the Properties pane is showing,

This
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. By default, the Properties pane is docked.
157
Architect Menu
The Architect graphical interface has a menu that enables you to access a variety of
functions. Many of these functions are also available on right-click menus. The following
table describes the available options:
Architect Menu
Option
Description
Settings
Enables you to access configuration settings for Architect, and change the
background color of the Project Tables View or Hierarchy View tabs
Select
Database
Instance
Enables you to add database instances to projects
Close
Closes the Architect
The following image shows the Architect menu:

Architect Menu
Toolbar
The Architect graphical interface has a toolbar that has two tabsHome and Design
tabsthat enable you to access a variety of functions. Many of these functions are also
available on right-click menus. The following table describes each button on the toolbar:
Architect Toolbar
Button
Description
Enables you to edit settings, select database
instances, and to close Architect.
Enables you to save.
Enables you to undo actions in Architect
Enables you to redo actions in Architect
Enables you to remove objects
Enables you to save your work and close Architect
Enables you to save and update the project

schema nd remain in Architect
Enables you to show or hide the Warehouse Tables

pane
Enables you to show or hide the Properties pane
Enables you to view objects in Architect in Normal

mode
159
Architect Toolbar
Button
Description
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 make objects in Architect fit to the

window size
Enables you to view tables in Architect i nthe

Physical View
Enables you to view tables in Architect in the

Logical View
Enables you to collapse tables in Architect so that

only the table name is shown
Enables you to expand collapsed tables in Architect

so that the columns and schema objects are
displayed
Enables you to view how tables of data are related
through attributes by displaying attribute
relationship lines between tables
Enables you to display the tables included in the
layer selected in the drop-down list
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)
Architect Toolbar
Button
Description
Enables you to display the project tables and
hierarchies using a symmetrical layout
Enables you to display the project tables and

hierarchies using a regular layout
Enables you to display the hierarchy selected in the

drop-down list
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)
Enables you to create database instance
Enables you to create attributes
Enables you to create facts
Enables you to create an attribute form
Enables you to have Architect automatically

recognize attributes and facts for the table selected
Enables you to create attribute relationships in the

System Hierarchy dialog box
Enables you to view the Logical Size editor. You

can view and define the logical sizes for the tables
in the project
161
Architect Toolbar
Button
Description
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. 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.
To save your project work and remain in Architect:
1 On the Architect toolbar, click Save.

You can also click Save and Update Schema if you want to save your project
work
and update the project schema.
To save your project work and close Architect:
1 Click Save and Close.
Saving Project Work in Architect
163
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, or undo and redo a series of
actions. The Undo and Redo toolbar buttons have lists that display each action
performed since the last save. Using these lists, you can choose to undo or redo multiple
actions at the same time.
These lists can display up to 24 actions.

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.
164 Undo and Redo Actions in Architect
Defining Architect Settings

Configure the settings for the Architect graphical interface.
The Architect graphical interface has settings that you can configure to change various
behaviors.
changes you make to these settings apply only to the particular project you
Any
have open in Architect.
To access the Architect settings:
1 On the Architect menu, select Settings.

The following image shows the option for accessing Architect settings:
Settings Option
The Architect settings are grouped into the following categories:
Configuration
Metric Creation
The following topics describe the individual settings in each of these categories.
165
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.
Warehouse Catalog
The Disable loading warehouse catalog setting determines whether you can load the
entire catalog of tables for database instances in Architect.
166 Defining Architect Settings
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.
this setting is enabled, you are prompted to update the project schema when
Ifclosing
Architect even if you have not made any changes to the schema.
167
Metric Creation Settings

The following image shows the metric creation settings for Architect:
Metric Creation Settings for Architect
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 you can enable.
Advanced View Options

You can access additional view options in the Advanced Options window.
To access the Advanced Options window:
1 On the Home tab, in the View section, click the arrow button.
The following image shows how to access advanced view options on the Home tab:
Accessing Advanced Options Window
The following image shows the Advanced Options window:

Advanced Options Window
169
These 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 choose to access more
detailed settings that control exactly how much information is shown.
more information, see Display Properties for Project Tables starting on
For
page 193.
When you configure display settings at the project 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 Schema Recognition Options

You can access auto recognize options in the Automatic Schema Recognition window.
To access the Automatic Schema Recognition window:
1 On the Design tab, in the Auto Recognize section, click the arrow button.
The following image shows how to access the automatic schema recognition options on
the Design tab:
Accessing Automatic Schema Recognition Window
The following image shows the automatic schema recognition settings for Architect:
Automatic Schema Recognition Window
The automatic heuristic settings are divided into three subcategories:
Automatic column mapping
Automatic column recognition
Recognize Relationships
171
Automatic Column Mapping

The Use automatic column mapping setting determines whether Architect
automatically maps columns in tables to existing attribute form or fact expressions as
you add tables to a project. By default, this setting is enabled.
The Use automatic column mapping setting works in conjunction with the Automatic
mapping method at the attribute form or fact expression level.
information about manually creating attributes, see Creating Attributes
For
Manually starting on page 271. For information about manually creating facts,
see Creating Facts Manually starting on page 220.
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.
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.
this course, you will primarily learn how to create schema objects manually.
InTherefore,
you will disable automatic column recognition in the exercises at the
end of next chapter.
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.
more information, see Using Automatic Schema Recognition starting on
For
page 366.
You can enable Architect to automatically create 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.
more information, see Automatic Relationship Recognition starting on
For
page 374.
173
Lesson Summary
Architect is a graphical interface that provides a visual, freeform, interactive, and

integrated experience for working on projects.
The Project Creation Assistant is an additional tool for bulk project creation. It uses a
linear, step-by-step approach to project creation.
You can access the Architect graphical interface from the Schema menu or by
right-clicking project name.
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 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 search, view and modify the properties for
attributes, facts, and tables. This pane provides access to many settings that are
available in the schema object editors.
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.
Architect graphical interface has ability to automatically recognize schema objects.

You can disable this option to create your project manually.
174 Lesson Summary
6
WORKING WITH TABLES
Lesson Description
This lesson describes how to work with tables when creating a project in MicroStrategy
Architect graphical interface.
In this lesson, you will learn how tables are used in a MicroStrategy project. Then, you
will learn about the various functions available for working with tables in Architect.
Finally, you will learn how to perform basic project design tasks related to tables,
including adding tables to projects, removing tables from projects, using layers to
organize tables, and viewing and modifying properties for project tables.
175
Working with Tables
Lesson Objectives
Describe how tables are used in a MicroStrategy project and select project tables in the
MicroStrategy Architect graphical interface.
Describe how tables are used in a MicroStrategy project and explain the difference
between physical and logical tables. (Page 177)
Select project tables using MicroStrategy Architect graphical interface. (Page 179)
Use layers to work with project tables in the Architect graphical interface, including
creating layers to organize project tables, modifying existing layers, and removing
unused layers. (Page 183)
View and modify properties for project tables in the Architect graphical
interface. (Page 189)
Change the display properties for project tables in the Architect graphical
Use the Show Element option to find project tables in the Architect graphical
Working with Tables
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, 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.
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.
What Is a Project Table?
177
Working with Tables
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 TablesLU_CUST_STATE
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 a logical view. The physical view
displays these same columns and their data types. The logical view shows the attributes
and attribute forms in the project that are mapped to the table columns.
information on the available display views, see Display Properties for Project
For
Tables starting on page 193.
178 What Is a Project Table?
Working with Tables
Adding Tables to Projects

Select project tables using MicroStrategy Architect graphical interface.
MicroStrategy Architect graphical interface enables you to select the tables you want to
include in a MicroStrategy project from the database instance associated with the
project. Using the Warehouse Tables pane, you can add tables from a single database
instance or from multiple database instances. You can add and delete tables as you are
designing the MicroStrategy project.
can also add tables using the Warehouse Catalog. For information about the
You
Warehouse Catalog, see Other Methods for Creating Schema Objects starting on
page 423.
To associate the project with the database instance:
1 In Developer, on the Schema menu, select Create New Project.

2 In the Project Creation Assistant, select Create Project.
have to create the project object before you can select the database
You
instance and project tables.
3 In the New Project window, name the project object.
4 In the Project Creation Assistant, select Architect.
5 In the Read Only window, select Edit: This will lock all schema objects in this
project from other users.
6 Click OK.
7 In the Warehouse Database Instance window, in the drop-down list, select the
database instance you want to use for the project.
Architect retrieves the list of available tables from the database
MicroStrategy
that corresponds to the database instance you select. This database instance is
the primary data source for the project.
8 Click OK.
179
Working with Tables
The following image shows the Warehouse Database Instance window:

Warehouse Database Instance Window
Adding tables to a project is a very simple task. To manually create the schema objects,
you need to disable the automatic schema recognition before you add tables to the
project. Otherwise, Architect automatically creates facts, simple metrics, attributes, and
attribute relationships when you add tables to the project.
more information about automatic schema recognition, see the Automatic
For
Schema Recognition lesson starting on page 357.
To add tables to a project using the Architect graphical interface:
1 Open the Architect graphical interface.

2 In the Architect graphical interface, click the Project Tables View tab.
3 In the Warehouse Tables pane, expand the database instance associated with the
project.
ensure you can see Warehouse Table pane, on the Home tab, in the Panels
Tosection,
click Show the Warehouse tables section.
4 Select the table you want to add.
Drag the selected table to the Project Tables View tab.
OR
180 Adding Tables to Projects
Working with Tables
Right-click and select Add Table to Project.
Ifadd.you want to add multiple tables, hold CTRL and select the tables you want to
can also add tables from different database instances at the same time. For
You
more information, refer to the MicroStrategy Architect: Advanced Project
Design course.
6 On the Home tab, in the Auto Arrange Table Layout section, click Regular to arrange
the tables.
7 Click Save.
adding tables to the project, you can update the project schema if
After
desired.
The following image shows the Add Table to Project option:
The Add Table to Project Option
181
Working with Tables
The following image shows the Architect graphical interface with selected lookup and
fact tables added to a project:
Fact and Lookup Tables Added to the Project
Removing Tables from the Project

Removing tables from a project is a very simple task in Architect. Using the Project
Tables View tab, you can remove any table from a project.
To remove a table from the project:
1 On the Project Tables View tab, select the table you want to remove from the project.
2 Right-click the table and select Delete.
you want to remove multiple tables, hold CTRL and select the tables you want to
Ifremove.
you want to remove all project tables in the layer you are viewing, right-click an
Ifempty
area and select Select All Tables. Right-click an empty area inside the
Project Tables View tab again and select Delete.
3 Click Save.
Architect graphical interface, you cannot remove a table if the table has
Independent
objects.
182 Adding Tables to Projects
Working with Tables
Using Layers for Project Tables

Use layers to work with project tables in the Architect graphical interface, including
creating layers to organize project tables, modifying existing layers, and removing
unused layers.
The visual environment the Architect graphical interface provides makes it easy to use.
However, as you add multiple tables to a project, it becomes increasingly difficult to view
and work with all the tables at once.
Layers enable you to organize project tables into groupings based on your logical data
model. This lets you focus on just the tables you need to use for a particular task. For
example, you can create a layer that contains only the fact tables you need to create a
particular set of facts, or you can create a layer that contains only the lookup and
relationship tables you need to create the attributes that belong to a particular hierarchy
or dimension.
Based on the project creation workflow, you create individual layers as you are ready to
create the associated facts or attributes. However, since the layers functionality is based
on tables, you will learn about this concept while working with tables and use it later in
this course as you create facts and attributes.
Creating Layers
Every project has a default layer called All Project Tables. This layer shows all tables used
in the project. You can create your own custom layers as needed to organize project
tables into subsets that align with your project creation tasks. For example, in the
Customer Sales project, you may want three layersone for fact tables, one for
customer-related lookup tables, and one for time-related lookup tables.
How you create a custom layer depends on whether the tables you want to add to the
layer are already a part of the project. You can create the layer first and add the tables
directly to the layer and the project at the same time. You can also add the tables to the
project, and then create the layer and select the tables you want to include in the layer.
183
Working with Tables
To create a layer:
1 In the Architect graphical interface, click the Home tab.

2 On the Project Tables View tab, click an empty area inside the All Project Tables layer.
3 On the Home tab, in the Layer section, click Create New Layer.
4 In the MicroStrategy Architect window, in the box, type a name for the layer.
5 Click OK.
This action creates the layer and displays it on the Project Tables View tab.
6 In the Architect graphical interface, do one of the following:
If you want to add tables that are not a part of the project, in the Warehouse Tables
pane, expand the database instance that contains the tables you want to add to the
layer.
Select the tables you want to add.
Drag the selected tables to the Project Tables View tab.
action adds the selected tables to the custom layer and the All Project
This
Tables layer.
OR
If you want to add tables that are already a part of the project, on the Project Tables
View tab, right-click inside the empty layer and select Edit Layer Element.
In the Edit Layer Element window, select the check boxes for the tables you want
to add.
Click OK.
184 Using Layers for Project Tables
Working with Tables
The following image shows the option for selecting existing project tables to include in a
layer:
Option for Selecting Existing Project Tables to Include in a Layer
The following image shows the Edit Layer Element window:

Edit Layer Element Window
185
Working with Tables
The following image shows a custom layer called Fact Tables that includes all the fact
tables in the project:
Fact Tables Layer for the Project
When you create layers and save your project work in Architect, those layers are available
within that project whenever you use Architect. In this way, you can reuse the same
layers for any future work on the project.
Modifying Layers
You can modify existing layers by adding or removing tables. You add and remove
project tables using the Edit Layer Element option.
To modify a layer:
1 On the Home tab, in the Layer section, in the drop-down list, select the layer.
2 On the Project Tables View tab, right-click an empty area inside the layer and select
Edit Layer Element.
3 In the Edit Layer Element window, do one of the following:
If you want to add tables to the layer, select the check boxes for the tables you want to
add.
Working with Tables
OR
If you want to remove tables from the layer, clear the check boxes for the tables you
want to remove.
4 Click OK.
When you remove tables from a custom layer, they still remain in the project (All
Project
Tables layer).
To remove multiple project tables from a layer:
1 On the Home tab, in the Layer section, in the drop-down list, select the layer.
2 On the Project Tables View tab, do one of the following:
If you want to multiselect individual project tables, hold CTRL and select each project
table you want to remove from the layer.
OR
If you want to remove all project tables from the layer, right-click an empty area and
select Select All Tables.
3 Right-click an empty area inside the Project Tables View tab and select Remove
From Layer.
project tables from a custom layer, do not use the Delete option.
ToThisremove
action removes the table from the layer and the project.
The following image shows the option for removing all selected tables from a layer:
Option for Removing All Selected Tables from a Layer
187
Working with Tables
Removing Layers
If you no longer need to use a custom layer within a project, you can remove it. When you
remove a layer that still contains project tables, this action does not remove the tables
themselves. You can still access these project tables from the All Project Tables layer.
You cannot remove the All Project Tables layer.

To remove a layer:
1 On the Home tab, in the Layer section, in the drop-down list, select the custom layer.
2 Click Remove Current Layer.
Working with Tables
Viewing and Modifying Properties for Project

Tables
View and modify properties for project tables in the Architect graphical interface.
All project tables have properties that you can view in the Properties pane. You can also
modify many of these properties. The following table lists these properties and their
descriptions:
Properties for Project Tables
Category
Property
Description
Definition
ID
Globaly Unique Identified (GUID) that identifies the

table in the metadata
NOTE: You cannot modify this property.
Name
Logical table name
Description
Description of the logical table

NOTE: This property does not contain a value if a
description has not been entered.
Hidden
Setting that determines whether the logical table is a

hidden object
Location
Project folder location for the logical table

Database Name
Physical table name to which the logical table

corresponds
Row Count
Number of rows in the physical table

NOTE: This property does not contain a value unless
you calculate the row count for the table. You cannot
modify this property.
Viewing and Modifying Properties for Project Tables
189
Working with Tables
Properties for Project Tables

Category
Property
Description
Definition
Table Name Space
Table name space in which the physical table resides

NOTE: This property does not contain a value unless
you use table name spaces in the data warehouse.
You cannot modify this property.
Logical Size
Logical size of the table as calculated by Architect

NOTE: If you make changes to the attributes or facts
that are mapped to a table, these actions can affect
logical table size. The updated logical table size is not
displayed in the Properties pane until you update the
project schema.
Logical size locked
Setting that determines whether the logical size of a

table is locked or recalculated by Architect during
schema updates
NOTE: You generally lock logical table size if you
manually change the value to preserve this change
during schema updates.
Mapped
Attributes
Primary DB
Instance
Primary database instance for the table
Secondary DB
Instances
Secondary database instances for the table
<Attribute Name>
Column that maps to the attribute
NOTE: This property does not display unless the

table is associated to more than one database
instance.
NOTE: Each attribute mapped to the table is listed as

a separate property. This property does not display
unless the table is mapped to an attribute.
Mapped Facts <Fact Name>
Column that maps to the fact

NOTE: Each fact mapped to the table is listed as a
separate property. This property does not display
unless the table is mapped to an fact.
Member
Columns
<Column Name>
Data type of the column

NOTE: Each column in the table is listed as a
separate property.
Mapped Attributes and Mapped Facts categories display only if attributes or

The
facts are mapped to a table.
190 Viewing and Modifying Properties for Project Tables
Working with Tables
To modify the properties of a project table:

On the Project Tables View tab, select the table for which you want to modify
properties.
OR
In the Properties pane, click the Tables tab.
On the Tables tab, in the drop-down list, select the table for which you want to
modify properties.
2 In the Properties pane, modify the table properties as desired.

properties have text boxes or drop-down lists that enable you to modify
Some
their values. For other properties, selecting the property or its current value
displays the following Browse button:
Clicking this Browse button opens a window that enables you to modify the
related property.
Viewing and Modifying Properties for Project Tables
191
Working with Tables
The following image shows the Properties pane with a project table displayed:
Properties PaneProject Table
192 Viewing and Modifying Properties for Project Tables
Working with Tables
Display Properties for Project Tables

Change the display properties for project tables in the Architect graphical interface.
Architect graphical interface enables you to display tables in a logical view or a physical
view.
Logical View
By default, the logical tables on the Project Tables View tab display in the logical view
with the following information:
Available columns that have not been used
Attributes or facts that have been mapped to table columns
The following images shows default logical view of the LU_CUST_STATE table:
Logical ViewLU_CUST_STATE
Physical View
Unlike the logical view of project tables, which shows the attributes and facts to which
table columns map, the physical view of tables shows only the table columns and their
corresponding data types.
193
Working with Tables
The following images shows the physical view of the LU_CUST_STATE table:
Physical ViewLU_CUST_STATE
The physical view displays only the table columns and their data types. The icons indicate
which columns are available and which have already been used.
To display the physical view of a project table:
1 On the Project Tables View tab, right-click the table you want to display in the
physical view, point to Properties, and select Physical View.
The following image shows the option for displaying the physical view:
Option for Displaying the Physical View
194 Display Properties for Project Tables
Working with Tables
the display properties for multiple project tables, you can multiselect
Tothechange
individual project tables using CTRL and change the properties views. If you
want to change the display properties for all project tables in the layer, you can
either use right-click and select all tables and change the properties or you can use
the advanced view options.
Instead of using the right-click menu options, you can also switch between the logical
and physical views by clicking the Physical View or Logical View buttons on the Home
toolbar, as shown in the following image:
Physical View and Logical View Toolbar Buttons
195
Working with Tables
Configuring Default Display Options

When you close Architect and open it again, the project tables revert to using the default
display properties. If you want project tables to always display in a particular view, you
can configure the default display properties in the Advanced Options window, as shown
in the following image:
The Advanced Options Window
196 Display Properties for Project Tables
Working with Tables
Finding Project Tables to Perform Tasks

Use the Show Element option to find project tables in the Architect graphical interface.
You have already learned about the functions used in Architect to work with tables. You
access many of these functions either using right-click menus or the Properties pane.
Both these features require you to select a project table before you can perform a task.
You can select a project table on the Project Tables View tab or in the Properties pane.
Selecting a table in the Properties pane is simple because you have a drop-down list to
use. Selecting a table on the Project Tables View tab is easy if there are only a few tables
in the layer you are viewing. However, if your layer has a large number of tables, finding
a table can be tedious.
The Show Element option is designed to make it easy to find and select tables in the
Project Tables View tab. It eliminates the need to manually search for a table.
To find and select a project table using the Show Element option:
1 On the Home tab, in the Layer section, in the drop-down list, select any layer.
2 In the Warehouse Tables pane, under the appropriate database instance, right-click
the table you want to find and select Show Element.
action finds and selects the table on the Project Tables View tab and
This
displays it in the Properties pane as well.
Finding Project Tables to Perform Tasks
197
Working with Tables
The following image shows the Show Element option:

Show Element Option
With the table selected on the Project Tables View tab and displayed in the Properties
pane, you can now perform any tasks related to the table.
198 Finding Project Tables to Perform Tasks
Working with Tables
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.
Logical tables are stored in the Schema Objects\Tables folder.
You can use the Architect graphical interface to select the tables you want to include
in a project.
In Architect graphical interface, you cannot remove a table if the table has dependent
objects.
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.
In Architect graphical interface, every project has a default layer called All Project
Tables that contains all the tables used in a project.
You can create custom layers to organize project tables into subsets that align with
your project creation tasks.
You can modify or remove custom layers.
Lesson Summary
199
Working with Tables
You can view and modify properties for project tables in the Architect graphical
interface.
You can choose to view project tables using the logical or physical view in the
Architect graphical interface. For the logical view, you can choose to display available
columns, used columns, and attribute forms.
You can use the Show Element option in the Architect graphical interface to quickly
find tables on the Project Tables View tab.
200 Lesson Summary

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

Overview
In this exercise, you will use the Architect graphical interface to add fact tables to the My
Demo Project. You should select Tutorial Data as the database instance for the project.
Before performing any task in the project, you should disable automatic column
recognition, automatic relationship recognition, and automatic metric creation. Next,
you will create a Fact Tables layer. Finally, you will add the following tables to the Fact
Tables layer:
Fact Table Name

CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
ORDER_DETAIL
ORDER_FACT
After you have added these fact tables, continue to the next exercise to add lookup tables
to the project.
201
Launch the MicroStrategy Architect for the My Demo Project
1 In the My Tutorial Project Source, open the My Demo Project.

2 On the Schema menu, select Architect.
you see the Read Only window, ensure that Edit: This will lock all schema
Ifobjects
in this project from other users is selected and click OK.
Select Tutorial Data as the database instance
3 In the Warehouse Database Instance window, in the drop-down list, select Tutorial
Data.
4 Click OK.
Disable automatic column recognition and relationship recognition
5 In the Architect graphical interface, click the Design tab.

6 On the Design tab, in the Auto Recognize section, click the arrow button to launch the
Automatic Schema Recognition window.
202 Exercises: Working with Tables
7 In the Automatic Schema Recognition window, under Automatic column recognition,

click Do not auto recognize.
8 Under Recognize Relationships, ensure that Do not automatically create relations
is selected.
9 Click OK.
Disable automatic metric creation
10 In the Architect graphical interface, click the Architect button.
11 On the Architect menu, select Settings.

12 In the MicroStrategy Architect Settings window, click the Metric Creation tab.
13 On the Metric Creation tab, clear the Sum check box.
14 Click OK.
Create a Fact Tables layer
16 Click the Home tab.
18 In the MicroStrategy Architect window, type Fact Tables as the layer name.
19 Click OK.
203
Add fact tables to the project
20 In the Warehouse Tables pane, expand the Tutorial Data database instance to view all
the tables.
21 Drag the following tables to the Fact Tables layer on the Project Tables View tab:
Fact Table Name

CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
ORDER_DETAIL
ORDER_FACT
the tables.
23 Click Save.
a Change Comments window displays, click Do not show this screen in the
Iffuture
and click OK.
Adding Lookup Tables to the Project

Overview
In this exercise, you will use the Architect graphical interface to add lookup tables to the
My Demo Project. First, you will create the Geography and Time layers. Next, you will
add the appropriate tables to the respective layers.
Add the following tables to the Geography layer:

Lookup Table Name
LU_CALL_CTR
LU_COUNTRY
LU_DIST_CTR
LU_EMPLOYEE
LU_REGION
Add the following tables to the Time layer:

Lookup Table Name
LU_DAY
LU_MONTH
LU_MONTH_OF_YEAR
LU_QUARTER
LU_YEAR
After you have added these lookup tables, save and update the project schema.
Create layers
1 On the Home tab, in the Layers section, click Create New Layer.
2 In the MicroStrategy Architect window, type Geography as the layer name.
need to ensure that you do not have any tables in the current layer selected
You
before clicking the Create New Layer button. If you have tables selected, they
are automatically included in the new layer.
3 Repeat steps 1 and 2 to create the Time layer.
205
Add lookup tables to the project
4 In the layers drop-down list, select the Geography layer.

5 Drag the following tables in the Warehouse Tables pane to the Geography layer on
the Project Tables View tab:
Lookup Table Name
LU_CALL_CTR
LU_COUNTRY
LU_DIST_CTR
LU_EMPLOYEE
LU_REGION
the tables.
7 In the layers drop-down list, select the Time layer.
8 Drag the following tables in the Warehouse Tables pane to the Time layer on the
Project Tables View tab:
Lookup Table Name
LU_DAY
LU_MONTH
LU_MONTH_OF_YEAR
LU_QUARTER
LU_YEAR
the tables.
Save and update the project schema
10 On the Home tab, in the Save section, click Save and Update Schema.
Change Comments window may appear when you update schema. To prevent
The
this window from appearing, select the Do not show this screen in the future check
box and click OK.
11 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
12 Click Update.
207
7
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 manually create and
modify facts using Architect graphical interface.
209
Working with Facts
Lesson Objectives
Describe how facts are used in a MicroStrategy project, explain the different types of
facts and fact expressions, and create and modify basic and complex facts using the
Describe how facts are used in a MicroStrategy project. (Page 211)
Explain the difference between homogeneous and heterogeneous facts and simple and
derived fact expressions. (Page 214)
Describe how to create facts, explain the two methods of fact creation, and create facts
manually in the Architect graphical interface. (Page 219)
Modify facts in the Architect graphical interface. (Page 234)
Working with Facts
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.
What Is a Fact?
211
Working with Facts
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
namesDollar_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 metricsone 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.
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.
212 What Is a Fact?
Working with Facts
You do not have to resolve discrepancies in the data warehouse to make reporting on
such data seamless for users.
What Is a Fact?
213
Working with Facts
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.
214 Types of Facts
Working with Facts
The following illustration shows an example of a homogeneous fact:

Homogeneous Fact
The Sales fact maps to three different tablesITEM_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.
Types of Facts
215
Working with Facts
The following illustration shows an example of a heterogeneous fact:

Heterogeneous Fact
The Sales fact maps to three different tablesITEM_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.
216 Types of Facts
Working with Facts
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.
want to combine fact columns from different database tables in a derived
Iffactyouexpression,
you have to create a logical view. For information on logical views,
see the MicroStrategy Advanced Data Warehousing course.
provides a variety of out-of-the-box functions that you can use in

MicroStrategy
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.
The following illustration shows an example of a derived fact expression:

Derived Fact Expression
Types of Facts
217
Working with Facts
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.
Architect enables you to create derived fact expressions at the
MicroStrategy
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.
218 Types of Facts
Working with Facts
Creating Facts
Describe how to create facts, explain the two methods of fact creation, and create facts
manually in the Architect graphical interface.
The Architect graphical interface enables you to create facts using different methods. The
optimal method varies, depending on your project environment and the characteristics
of individual facts. The following topics describe various aspects of fact creation.
Using Layers to Create Facts

Before you create facts, you need to organize the fact tables in your project using layers.
In some instances, you may have a small number of fact tables that you can include in a
single layer. In other cases, you may want to create layers for different types of facts.
You can use any method for determining which layers to create and what fact tables to
include in each layer. However, your layers should align with how you plan to create
facts. That way, you can focus only on pertinent tables as you create facts or sets of facts.
Fact Creation Methods

There are two primary means of creating facts in the Architect graphical interface.
Manual fact creation means that you create facts on your own, deciding which columns
to use and defining the appropriate facts. This method gives you precise control over
which facts are created and how they are defined. However, it does require that you
create each individual fact one by one.
With automatic fact creation, you allow Architect to identify and create the appropriate
facts. Architect uses automatic column recognition that is based on a set of heuristics to
determine which columns are facts. After the facts are created, you can modify them
however you want. This method provides a quick and easy way to create facts that
minimizes the amount of work you have to do. However, if you use this method, you
should verify that Architect identifies the right columns as facts and creates all of the
desired facts correctly. Otherwise, you can end up with fewer facts than you need, extra
facts you do not need, or incorrectly defined facts.
Creating Facts
219
Working with Facts
The method you choose depends on the physical structure of the tables and columns in
your data warehouse and the requirements that you have for facts. If your project
environment lends itself to creating facts automatically, it can be a tremendous
timesaver. However, you need to carefully consider the characteristics of your
environment. The more exceptions or anomalies you have for a particular fact, the more
likely that it is a better candidate for manual creation.
The remainder of this lesson describes how to create facts manually. Creating facts
automatically requires that you understand how automatic column recognition works,
including the heuristics it uses to determine which columns are facts. You will learn
about these concepts later in this course.
information on creating facts automatically, see Using Automatic Schema
For
Recognition starting on page 366.
Creating Facts Manually

You can use the Architect graphical interface to create simple or derived fact expressions.
You can also create heterogeneous facts that have multiple expressions.
Creating a Simple Fact Expression

A simple fact expression maps to a single fact column in all project tables that contain
that column or in a selected project tables, depending on how you define the fact.
To create a simple fact expression and map the same column to all project tables:
1 In the MicroStrategy Architect, on the Project Tables View tab, find a project table
that contains the column to which you want to map the fact.
can use any project table since you are not mapping the fact to a particular
You
table.
2 Right-click the header of the project table and select Create Fact.
3 In the MicroStrategy Architect window, in the box, type a name for the fact.
4 Click OK.
5 In the Create New Fact Expression window, define the fact expression.
220 Creating Facts
Working with Facts
6 Click OK.
action creates a fact that maps to that column for every project table in which
This
the column occurs. The new fact automatically displays in the Properties pane.
This procedure effectively creates a homogenous fact.
The following image shows the Create Fact option:
Create Fact Option
Creating Facts
221
Working with Facts
The following image shows the Revenue fact being created in the Create New Fact
Expression window using the automatic mapping method:
Create New Fact Expression WindowRevenue Fact
222 Creating Facts
Working with Facts
The following image shows the Revenue fact defined for the TOT_DOLLAR_SALES
column in the CUSTOMER_SLS, DAY_CTR_SLS, and CITY_SUBCATEG_SLS tables:
Project Tables View TabRevenue Fact
The TOT_DOLLAR_SALES column is selected, and you can see the link between the
same columns in all three fact tables.
Creating Facts
223
Working with Facts
The following image shows the Revenue fact displayed in the Properties pane:
Properties PaneRevenue Fact
You can see that the Revenue fact maps to the TOT_DOLLAR_SALES column for both
the CITY_MONTH_SLS and the CUSTOMER_SLS fact tables.
can also quickly create facts by right-clicking the column in the table and
You
selecting Create Facts. When you create a fact using this method, the Architect
defaults the name of the fact to the column name. You can later rename the fact
using the right-click menu option or the Properties pane.
Automatic Column Mapping

When you initially create an attribute or a fact, you need to decide if the attribute form or
a fact expression maps to the same column in all project tables, or if it maps to the same
column only for specific project tables. To map a column to a form, you can use either the
Automatic or Manual mapping method at the attribute form or fact level.
By default, the mapping method is set to Automatic.

You will learn about creating attributes and attribute form expressions later in
this
course.
224 Creating Facts
Working with Facts
Using the automatic mapping method means that Architect maps the attribute form or
fact expression to that same column in any other tables that are currently a part of the
project. When you use the manual mapping method, 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 or fact.
The mapping method at the attribute form or fact expression level works in conjunction
with the Use automatic column mapping setting in the Advanced Schema Recognition
window. When you have the Use automatic column mapping setting enabled, Architect
also automatically maps the attribute form to that same column in any new table that
you add to the project after you have initially created the attribute or fact.
when this setting is enabled, Architect does not automatically map columns
Even
to attribute form and fact expressions that use the manual mapping method.
If you do not want this automatic column mapping to occur, you can either disable the
option in the Architect settings, or you can map the column to the attribute form using
the Manual mapping method.
To create a simple fact expression and map it to a column only for selected project tables:
1 In the MicroStrategy Architect, on the Project Tables View tab, right-click a header of
the project table to which you want to map the fact and select Create Fact.
3 Click OK.
5 Under Mapping method, click Manual.
information about the manual mapping method, see Automatic Schema
For
Recognition Options starting on page 170.
6 Click OK.
action creates a fact that maps to the respective column only for the
This
selected project table. The new fact automatically displays in the Properties
pane.
7 If you want to map the fact to additional tables, in the project table, right-click the
fact you just created and select Edit.
Creating Facts
225
Working with Facts
8 In the Fact Editor, on the Definition tab, in the Source tables list, select any other
table to which you want to map the fact.
9 Click OK.
This procedure effectively creates a homogenous fact.

information on modifying facts using various methods, see Modifying Facts
For
The following image shows the Cost fact being created in the Create New Fact Expression
window using the manual mapping method:
Create New Fact Expression WindowCost Fact
226 Creating Facts
Working with Facts
The following image shows the Cost fact defined for the TOT_COST column in the
CUSTOMER_SLS table:
Project Tables View TabCost Fact
You can see that the Cost fact maps to the TOT_COST column only for the
CUSTOMER_SLS fact table. Other tables that include this column are not a part of the
fact definition.
Creating Facts
227
Working with Facts
The following image shows the Cost fact displayed in the Properties pane:
Properties PaneCost Fact
Creating a Derived Fact Expression

A derived fact expression is a combination of columns, numerical constants, and
mathematical operators.
To create a derived fact expression:
1 On the Project Tables View tab, right-click a project table to which you want to map
the fact and select Create Fact.
3 Click OK.
4 In the Create New Fact Expression window, in the Available columns pane,
double-click the column or drag the column to the Fact expression box.
5 In the Fact expression box, complete the 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.
228 Creating Facts
Working with Facts
6 Click Validate to check whether the syntax of the expression is correct.

7 Under Mapping method, select the desired method for mapping the expression to the
fact.
8 Click OK.
If you select Manual mapping for the fact expression and if you want to map the
fact
to additional tables, you need to edit the fact and map it to the appropriate
tables.
The following image shows the Profit fact being created in the Create New Fact
Expression window with the ORDER_AMT ORDER_COST derived fact expression:
Create New Fact Expression WindowProfit Fact
Creating Facts
229
Working with Facts
The following image shows the Profit fact defined as the ORDER_AMT
ORDER_COST expression in the ORDER_FACT table:
Project Tables View TabProfit Fact
The following image shows the Profit fact displayed in the Properties pane:
Properties PaneProfit Fact
230 Creating Facts
Working with Facts
Creating a Heterogeneous Fact

A heterogeneous fact points to two or more different columns or sets of columns in the
tables to which it maps. It contains two or more fact expressions.
To create a heterogeneous fact:
1 On the Project Tables View tab, right-click a project table to which you want to map
the fact and select Create Fact.
3 Click OK.
steps to create a simple fact expression, see Creating a Simple Fact
For
Expression starting on page 220. For steps to create a derived fact expression,
see Creating a Derived Fact Expression starting on page 228.
5 Click OK.
6 On the Project Tables View tab, right-click the fact you just created and select Edit.
7 In the Fact Editor, on the Definition tab, click New.
8 In the Create New Fact Expression window, define the new fact expression.
9 Click OK.
10 Repeat steps 7 to 9 for each additional fact expression you want to create.
11 When you have created all the expressions for the fact, click OK to close the Fact
Editor.
Creating Facts
231
Working with Facts
The following image shows a Revenue fact that has multiple fact expressions:
Fact EditorHeterogenous Fact
The first expression is a simple fact expression that maps to the TOT_DOLLAR_SALES
column in multiple project tables. The second expression is a derived fact expression that
maps to multiple columns in the ORDER_DETAIL table: ([QTY_SOLD] *
([UNIT_PRICE] - [DISCOUNT])). The third expression is a simple fact expression that
maps to the ORDER_AMT column in the ORDER_FACT table.
Reusing Fact Columns

After you map a column in a table to a fact, that column no longer displays in the table as
an available column. However, you may need to reuse that same column as an expression
for another fact. For example, consider the following scenario:
Reusing Fact Columns
232 Creating Facts
Working with Facts
In this example, you have two facts that both use the TOT_DOLLAR_SALES column in
their definitions. If you first create the Profit fact, you use both the
TOT_DOLLAR_SALES and GROSS_DOLLAR_SALES columns in its expression. As a
result, neither of these columns would display in the table as available columns.
Now, if you want to create the Revenue fact, which also requires the
TOT_DOLLAR_SALES column, you can no longer access the column directly from the
table. You cannot right-click a used column and create a fact in the Architect graphical
interface.
To reuse a fact column to create another fact:
1 In the MicroStrategy Architect, on the Project Tables View tab, right-click the header
of a table that contains the column you want to use for the fact and select Create
Fact.
3 Click OK.
4 In the Create New Fact Expression window, define the fact expression as desired.
can access any column in a table from this window, even those that have
You
already been used for other facts.
5 Click OK.
Creating Facts
233
Working with Facts
Modifying Facts
Modify facts in the Architect graphical interface.
You can modify existing facts in the Architect graphical interface. You can change any of
the following parts of a fact:
Fact expressions
Source tables
Mapping methods
Column alias
You can modify facts either from the Project Tables View tab or the Properties pane.
While the Project Tables View tab provides access to all parts of a fact, the Properties
pane provides access only to the column alias and individual fact expressions.
Using the Project Tables View Tab

It is best to use the Project Tables View tab to modify facts when you need to perform any
of the following tasks:
Modify multiple expressions for a single fact
Modify a single fact expression for all the tables to which it maps
Create new fact expressions
Delete existing fact expressions
Modify source tables
Modify column aliases
234 Modifying Facts
Working with Facts
Modifying Fact Expressions

To modify facts from the Project Tables View tab:
1 On the Project Tables View tab, find a project table that contains the fact you want to
modify.
You can use any project table that is mapped to the fact.
2 In the project table, right-click the fact you want to modify and select Edit.
3 In the Fact Editor, on the Definition tab, click Modify.
4 In the Modify Fact Expression window, modify the fact expression as desired.
can change the source tables for fact expressions or the column alias for a
You
fact. You will learn more about column alias later in this lesson. You can also
modify or delete existing fact expressions or create new ones.
5 After you have made your changes, in the Fact Editor, click OK.
To add new fact expression to an existing fact from the Project Tables View tab:
1 In MicroStrategy Architect, on the Project Tables View tab, right-click an existing fact
in a project table in which you want to add a new fact expression and select Edit.
3 In the Create New Fact Expression window, define the new fact expression as desired.
4 Click OK.
To delete existing fact expression from a fact from the Project Tables View tab:
1 In MicroStrategy Architect, on the Project Tables View tab, right-click an existing fact
in a project table in which you want to modify or delete an existing fact expression
and select Edit.
2 In the Fact Editor, on the Definition tab, select the expression you want to delete.
3 Click Delete.
Modifying Facts
235
Working with Facts
4 Click OK.
The following image shows the option for modifying facts from the Project Tables View
tab:
Option for Modifying Facts
236 Modifying Facts
Working with Facts
The following image shows the Fact Editor for the Cost fact:
Fact EditorModifying Cost Fact
The following image shows the Modify Fact Expression window with mapping method
modified to automatic for the Cost fact:
Modify Fact Expression Window
Modifying Facts
237
Working with Facts
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.
the column alias name is used in any SQL that the MicroStrategy Engine
Since
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.
the first expression you create is a derived expression, MicroStrategy Architect
Ifcreates
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.
238 Modifying Facts
Working with Facts
To modify the column alias for an existing fact from the Project Tables View tab:
1 In MicroStrategy Architect, on the Project Tables View tab, right-click a project table
for which you want to view or modify the column alias and select Edit.
2 In the Fact Editor, click the Column Alias tab.
3 On the Column Alias tab, beside the Column used in temporary table SQL generation
box, click Select.
4 In the Column Editor - Column Selection window, do one of the following:
If you want to use an existing default column alias, in the Available columns list,
select a default column alias.
Click Modify.
You can only change the properties of custom column aliases.

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 a name for
the column alias.
you are modifying a custom column alias, if desired you can change the
Ifname.
6 In the Data type drop-down list, select the data type you want to use.
on the data type you select, you may need to configure the
Depending
precision, scale, byte length, bit length, or time scale.
7 Click OK.
8 In the Column Editor - Column Selection window, click OK.
9 Click OK to close the Fact Editor.
After closing the Fact Editor, you can update the project schema if desired.
Modifying Facts
239
Working with Facts
The following image shows the Column Alias tab in the Fact Editor:
Fact EditorColumn Alias Tab
240 Modifying Facts
Working with Facts
The following image shows the Column Editor - Column Selection window:
Column EditorColumn Selection Window
The following image shows the Column Editor - Definition window:

Column EditorDefinition Window
Modifying Facts
241
Working with Facts
Using the Properties Pane

It is best to use the Properties pane if you need to modify a single fact expression only for
a particular table. You can also use the Properties pane to modify column aliases.
Modifying Fact Expressions

To modify a fact expression from the Properties pane:
1 In the Properties pane, click the Facts tab.

2 On the Facts tab, in the drop-down list, select the fact you want to modify.
3 Under Fact Expressions, select the table for which you want to modify the fact
expression.
4 Select the expression to see the following Browse button:
this Browse button opens a window that enables you to modify the
Clicking
related property.
5 In the Modify Fact Expression window, modify the fact expression as desired.
can change the mapping method, but not the source table. Any changes
You
that you make modify the fact expression only for the selected table.
6 After you have completed making changes to the fact expression, click OK.
242 Modifying Facts
Working with Facts
The following image shows the Fact Expressions category in the Properties pane:
Fact Expressions Category
The following image shows the Modify Fact Expression window:

Modify Fact Expression Window
Modifying Facts
243
Working with Facts
Viewing and Modifying Properties for Facts

All facts have properties that you can view in the Properties pane. You can also modify
many of these properties. The following table lists these properties and their
descriptions:
Properties for Facts
Category
Property
Description
Definition
ID
GUID that identifies the fact in the metadata

Name
Name of the fact
Description
Description of the fact

Hidden
Setting that determines whether the fact is a hidden

object
Column Alias
Column alias for the fact
Location
Project folder location for the fact

NOTE: You can modify this property.
Fact
<Table Name>
Expressions
Column in the table to which the fact maps

NOTE: Each table to which the fact is mapped is listed as
a separate property.
Using the Properties pane is the quickest method to modify a column alias.
To view or modify the properties of a fact from the Properties pane:
1 In the Properties pane, click the Facts tab.

2 On the Facts tab, in the drop-down list, select the fact for which you want to view or
modify properties.
244 Modifying Facts
Working with Facts
3 In the Properties pane, click the properties you want to view or modify. View or
modify the fact properties as desired. Some properties have text boxes or drop-down
lists that enable you to modify their values. For other properties, selecting the
property or its current value displays the following Browse button:
Clicking this Browse button opens a window that enables you to modify the related
property.
Modifying Facts
245
Working with Facts
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 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 create facts in the Architect graphical interface manually or automatically.
When you create a fact manually in the Architect graphical interface, you can map it
to a column in all project tables or only selected project tables.
You can modify existing facts in the Architect graphical interface, including the
following components: fact expressions, source tables, mapping methods, and
column aliases.
You can view and modify properties for facts in the Architect graphical interface.
You can use the Create Fact right-click option 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.
246 Lesson Summary
Working with Facts
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.
Lesson Summary
247
Working with Facts
248 Lesson Summary

Exercises: Working with Facts
In this set of exercises, you will create facts in the My Demo 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 Architect Graphical interface to manually create facts in
the My Demo Project. You need to create the following facts:
Expression
Fact Name
DISCOUNT
Discount
TOT_COST
Cost
TOT_DOLLAR_SALES
Revenue
UNIT_COST
Unit Cost
UNIT_PRICE
Unit Price
TOT_UNIT_SALES
Units Sold
After you have created these facts, save and update the project schema.
Open the My Demo Project in Architect
1 In the My Tutorial Project Source, open the My Demo Project in the Architect
249
3 On the Home tab, in the Layer section, in the layers drop-down list, select the Fact
Tables layer.
4 On the Project Tables View tab, right-click the header of any table that contains the
TOT_COST expression and select Create Fact.
5 In the MicroStrategy Architect window, in the box, type Cost as the fact name.
6 Click OK.
7 In the Create New Fact Expression window, define the fact expression:
TOT_COST
8 Under Mapping method, ensure Automatic is selected.
9 Click OK.
10 Repeat steps 4 to 9 to create the following facts:
Column names
Table Name
Fact Name
DISCOUNT
ORDER_DETAIL
Discount
TOT_DOLLAR_SALES
This column is available in

most of the tables, you can
use CITY_SUBCATEG_SLS
Revenue
UNIT_COST
ORDER_DETAIL
Unit Cost
UNIT_PRICE
ORDER_DETAIL
Unit Price
TOT_UNIT_SALES
This column is available in

most of the tables, you can
use CITY_SUBCATEG_SLS
Units Sold
you can create these facts by right-clicking the appropriate column

Alternatively,
in the table and selecting Create Facts. Because this method defaults the fact
name to the mapped column name, make sure you rename the facts when
appropriate. To rename a fact, right-click it and select Rename. In the
MicroStrategy Architect window, in the box, type the fact name, and click OK.
250 Exercises: Working with Facts
Update the project schema
11 On the Home tab, in the Save section, click Save and Update Schema.
13 Click Update.
Modifying Facts in the Project

Overview
In this exercise, you will use the Architect graphical interface to modify the Cost,
Revenue, and Units Sold facts you created in the My Demo 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
QTY_SOLD * (UNIT_PRICE - DISCOUNT)
ORDER_DETAIL
ORDER_AMT
ORDER_FACT
QTY_SOLD
ORDER_DETAIL
Revenue
Units Sold
ORDER_FACT
You should use automatic mapping for all fact expressions.

After you have modified all these facts, save and update the project schema.
251
You can use the detailed instructions if you want help. There are separate sets of
instructions for the Cost, Revenue, and Units Sold facts.
Detailed InstructionsCost Fact

Create the second expression for the Cost fact
1 On the Project Tables View tab, in any project table that contains the Cost fact,
right-click Cost and select Edit.
3 In the Create New Fact Expression window, in the Source table drop-down list, select
ORDER_DETAIL.
4 In the Fact Expression box, create the following expression:
QTY_SOLD * UNIT_COST
6 Click OK.
Create the third expression for the Cost fact

ORDER_FACT.
ORDER_COST
10 Under Mapping method, keep Automatic selected.
11 Click OK.
12 In the Fact Editor, click OK.
Save your project work
13 Save the changes you have made to the project, but keep the project open in the
Architect graphical interface so you can create the next fact.
Detailed InstructionsRevenue Fact

Create the second expression for the Revenue fact
1 On the Project Tables View tab, in any project table that contains the Revenue fact,
right-click Revenue and select Edit.
ORDER_DETAIL.
QTY_SOLD * (UNIT_PRICE - DISCOUNT)
5 Under Mapping method, with Automatic selected, click OK.
Create the third expression for the Revenue fact
6 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 Use Automatic as the mapping method.

8 Click OK.
Save your project work
10 Save the changes you have made to the project, but keep the project open in the
Architect graphical interface so you can modify the next fact.
Detailed InstructionsUnits Sold Fact

Create the second expression for the Units Sold fact
1 On the Project Tables View tab, in any project table that contains the Units Sold fact,
right-click Units Sold and select Edit.
253
ORDER_DETAIL.
QTY_SOLD
6 Click OK.
8 On the Home tab, click Save and Update Schema.

10 Click Update.
Adding Another Fact to the Project

Overview
In this exercise, you will use the Architect graphical interface to create the Profit fact in
the My Demo Project. You need to create the following expressions for this fact:
Fact
Expressions
Source Tables
Profit
TOT_DOLLAR_SALES - TOT_COST
CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
QTY_SOLD * (UNIT_PRICE - DISCOUNT UNIT_COST)
ORDER_DETAIL
ORDER_AMT - ORDER_COST
ORDER_FACT
You should use automatic mapping for all fact expressions.

After you have created this fact, save and update the project schema.
you have practiced modifying several different facts using step-by-step
Since
instructions, these instructions are written at a higher level to help better test your
understanding.
1 On the Project Tables View tab, in any project table (CITY_SUBCATEG_SLS,

CUSTOMER_SLS, or DAY_CTR_SLS) that contains the TOT_DOLLARS_SALES
column, right-click the table header and select Create Fact.
TOT_DOLLARS_SALES column is already used in the Revenue fact. You
The
have to reuse this column to create the Profit fact.
2 In the MicroStrategy Architect window, in the box, type Profit as the fact name.
3 Click OK.
255
4 In the Create New Fact Expression box, create the following expression:
TOT_DOLLAR_SALES - TOT_COST
6 Click OK.
Create the second expression for the Profit fact
7 Edit the Profit fact.

8 In the Fact Editor, create a second expression:
QTY_SOLD * (UNIT_PRICE - DISCOUNT - UNIT_COST)
You can find this column in the ORDER_DETAIL table.
9 Keep Automatic as the mapping method and click OK.

Create the third expression for the Profit fact
10 In the Fact Editor, create a third expression:

ORDER_AMT - ORDER_COST
You can find these columns in the ORDER_FACT table.
11 Keep Automatic as the mapping method and click OK.

Update the project schema
13 On the Home tab, in the Save section, click Save and Close.
15 Click Update.
8
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 manually using the Architect graphical
interface. Finally, you will learn how defining attribute relationships creates the system
hierarchy for a project.
257
Working with Attributes
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 Architect graphical interface, and describe how the
system hierarchy is created and used in a MicroStrategy project.
Describe how attributes are used in a MicroStrategy project. (Page 259)
Describe how attribute forms are used in a MicroStrategy project. (Page 262)
Explain the difference between compound, homogeneous, and heterogeneous

attributes and simple and derived attribute form expressions. (Page 265)
Describe how to use layers to organize lookup and relationship tables when creating
attributes, explain the two methods of attribute creation, and create attributes
manually in the Architect graphical interface. (Page 270)
Create and modify attributes in the Architect graphical interface, including adding and
modifying attribute forms. (Page 285)
Describe how the system hierarchy is created and used in a MicroStrategy

project. (Page 306)
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.
259
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.
can also use attributes to directly define the level of aggregation for a specific
You
metric. For information on level metrics, see the MicroStrategy Developer:
Advanced Reporting course.
260 What Is an Attribute?
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 2012 since
that Year attribute element is in the filter.
261
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
Home address
Email
Birth date
Gender
262 What Is an Attribute Form?
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 email address, then the
relationship between Email and Customer is not one to one. In this case, if you want to
display all the email addresses for a single customer, you have to create Email as a
separate attribute rather than an attribute form of Customer.
you create attribute forms that have a one-to-many relationship with the
Ifattribute
they describe, only the first element displays on reports.
Second, you can use attribute forms for the following functions:
DisplayYou can choose to display different forms of an attribute on reports or in the

Data Explorer when you browse the attribute.
SortingYou can sort report data using attribute forms. You can sort using any
attribute form, not just those displayed on a report.
QualificationYou can qualify on the elements of any attribute form. You can qualify
using any attribute form, not just those displayed on a report.
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.
ID forms are the unique identifiers for attributes, they are included in the
Because
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, email, 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.
What Is an Attribute Form?
263
The following image shows a report with various attribute forms displayed for the
Customer attribute:
Customer Attribute Forms
This report displays each customers ID, last name, first name, address, and email all
under the Customer attribute header.
264 What Is an Attribute Form?
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
The Item attribute has two different columns that comprise its primary key in the
LU_ITEM tableItem_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.
Types of Attributes
265
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.
The following illustration shows an example of a homogeneous attribute:
Homogeneous Attribute
illustration above shows an example where the ID for an attribute occurs in

The
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 tablesLU_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.
266 Types of Attributes
The following illustration shows an example of a heterogeneous attribute:

Heterogeneous Attribute
illustration above shows an example where the ID for an attribute occurs in

The
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 tablesLU_REGION,
LU_CALL_CTR, and REGION_SALES. 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.
Types of Attributes
267
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.
you want to combine attribute columns from different database tables in a
Ifderived
attribute form expression, you have to create a logical view. For
information on logical views, see the MicroStrategy Advanced Data Warehousing

course.
provides a variety of out-of-the-box functions that you can use in

MicroStrategy
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 Architect:
Advanced Project Design course.
268 Types of Attributes
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.
Architect enables you to create derived attribute form expressions
MicroStrategy
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.
Types of Attributes
269
Creating Attributes
Describe how to use layers to organize lookup and relationship tables when creating
attributes, explain the two methods of attribute creation, and create attributes manually
in the Architect graphical interface.
The Architect graphical interface enables you to create attributes using different
methods. The optimal method varies, depending on your project environment and the
characteristics of individual attributes. The following topics describe various aspects of
attribute creation.
Using Layers to Create Attributes

Before you create attributes, you need to create layers to organize the lookup and
relationship tables in your project. The best method for creating these layers is to group
together tables from the same hierarchy or dimension. This strategy aligns the layers
with how you create attributes. That way, you can focus only on pertinent tables as you
create each group of related attributes.
As you create each hierarchy or dimension layer, you can create the corresponding
attributes and their relationships.
Attribute Creation Methods

As with facts, there are two primary means of creating attributes in the Architect
graphical interface:
Manual attribute creation means that you create attributes on your own, deciding
which columns to use and defining the appropriate attributes and their attribute
forms.
With automatic attribute creation, you allow Architect to identify and create the
appropriate attributes and their attribute forms.
can also use the Attribute Creation Wizard to create multiple attributes. For
You
information, see the Other Methods for Creating Schema Objects appendix
270 Creating Attributes
The remainder of this lesson describes how to create attributes manually. Creating
attributes automatically requires that you understand how automatic schema
recognition works, including the rules it uses to determine which columns are attributes
or forms. You will learn about these concepts later in this course.
information on creating attributes automatically,see Heuristics for
For
Automatic Schema Recognition starting on page 361.
Creating Attributes Manually

There are two ways to create attributes manually. You can map an attribute to the same
column in all project tables, or you can map an attribute to a column only for selected
project tables. You create attributes by first mapping the ID form, and then you can add
other forms for the attribute as needed.
information on creating additional attribute forms, see Modifying Attribute
For
Forms starting on page 290.
Creating an Attribute with a Simple Form Expression

To create an attribute with a simple form expression and map it to a column for all project
tables:
1 On the Project Tables View tab, find the project table you want to use as the primary
lookup table for the attribute.
automatically designates the table you use to create the attribute as
Architect
the primary lookup table. You can change the primary lookup table at a later
point.
2 Right-click the header of the project table and select Create Attribute.
3 In the MicroStrategy Architect window, in the box, type a name for the attribute.
4 Click OK.
5 In the Create New Form Expression window, define the ID form expression.
6 Click OK.
Creating Attributes
271
you can see the available columns in the table, right-click the table,
Topointensure
to Properties, point to Logical View, and select Display Available
Columns.
The following image shows the Create Attribute option:
Create Attribute Option
The following image shows the Region ID form being created in the Create New Form
Expression window using the automatic mapping method:
Create New Form Expression WindowRegion Attribute
The following image shows the Region attribute defined for the REGION_ID column in
the LU_REGION and LU_CALL_CTR tables:
Project Tables View TabRegion Attribute
Creating Attributes
273
The following image shows the Region attribute displayed in the Properties pane:
Properties PaneRegion Attribute
You can see that the ID form for the Region attribute maps to the REGION_ID column
for both the LU_REGION and LU_CALL_CTR lookup tables.
To create an attribute with a simple form expression and map it to a column only for
selected project tables:
1 On the Project Tables View tab, right-click the header of the project table you want to
use as the primary lookup table for the attribute and select Create Attribute.
Architect
point.
3 Click OK.
4 In the Create New Form Expression window, define the ID form expression.
5 Under Mapping method, click Manual.
more information about the mapping methods, see Automatic Column
For
Mapping starting on page 224.
6 Click OK.
action creates an attribute with an ID form that maps to that column only
This
for the selected project table. The new attribute automatically displays in the
Properties pane.
7 If you want to map the ID form for the attribute to additional tables, in the Properties
pane, under the Form 1: ID category, select the ID property.
8 In the Properties pane, beside <Edit...>, click Browse:
9 In the Modify Attribute Form window, on the Definition tab, in the Source tables list,
select any other tables to which you want to map the ID form.
10 Click OK.
information on modifying attributes using various methods, see Modifying
For
Attribute Forms starting on page 285.
Creating Attributes
275
The following image shows the ID form for the Call Center attribute being created in the
Create New Form Expression window using the manual mapping method:
Create New Form Expression WindowCall Center Attribute
The following image shows the Call Center attribute displayed in the Properties pane:
Properties PaneCall Center Attribute
You can see that the ID form for the Call Center attribute maps to the CALL_CTR_ID
column only for the LU_CALL_CTR lookup table. Other tables that include this column
are not part of the attribute form definition.
Creating Attributes
277
Creating a Derived Attribute Form Expression

To create a derived attribute form expression:
Architect
point.
3 In the Create New Form Expression window, define the ID form expression as
desired.
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.
4 Under Mapping method, click Automatic.

5 Click OK.
The following image shows the Create New Form Expression window with a derived
expression for the Days to Ship attribute:
Create New Form Expression WindowDays to Ship Attribute with Derived Form
Expression
Creating a Heterogenous Attribute

To create a heterogenous attribute:
desired.
4 Click OK.
5 On the Project Tables View tab, right-click the attribute form you just created and
select Edit.
Creating Attributes
279
6 In the Modify Form Expression window, click OK to return to the Modify Attribute
Form window.
7 In the Modify Attribute Form window, on the Definition tab, click New.
8 In the Create New Form Expression window, in the Source table list, select the source
table for the new expression.
9 In the Form expression box, define the new form expression.
10 Click OK.
11 Click OK to close the Modify Attribute Form window.
The following image shows the Modify Attribute form with multiple expressions for the
ID form of the heterogenous Day attribute:
Modify Attribute FormHeterogenous Attribute
Creating a Compound Attribute

In Architect graphical interface, 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.
To create a compound attribute:
desired.
4 Click OK.
5 On the Project Tables View tab, select the column you want to add to the attribute you
just created.
6 Drag the column to the attribute you just created.
This action creates a new description form with a DESC category.

the column is already used in another attribute, you must right-click the
Ifattribute
and add a new attribute form. In the Properties Pane, for the new
form, you then change the Category to ID. In a message window that prompts
you to create a form group, click Yes.
7 In the Properties pane, modify the Category property of the new description form to
ID.
8 In the message window that prompts you to create a form group, click Yes.
9 In the Properties pane, modify the Name property of the new form to ID.
do not have to use ID as the form group name. However, this naming
You
convention is the easiest for users to understand.
Creating Attributes
281
The following image shows the message window that prompts you to create a form
group:
Form Group Message Window
The following image shows a table with Distribution Center as a compound attribute:
Project TableDistribution Center Compound Attribute
The following image shows the Properties pane for the Distribution Center attribute with
form group:
Properties Pane of a Compound AttributeDistribution Center
Creating Attributes
283
Reusing Attribute Columns

After you map an ID column in a table to an attribute, that column no longer displays in
the table as an available column. However, you may need to reuse the same column as an
expression for another attribute. For example, consider the following scenario:
Reusing Attribute Columns
In this example, two attributes use the STATE_ID column in their definitions. If you first
create the Store State attribute, you use the STATE_ID column in its ID attribute form
expression. As a result, this column would not display in the table as an available column.
Now, if you want to create the Customer State attribute, which also requires the
STATE_ID column, you can no longer access the column directly from the table. You
cannot right-click a used column and create an attribute in the Architect graphical
interface.
an attribute column is only an issue for ID columns since you cannot
Reusing
right-click columns to create other types of attribute forms.
To reuse an attribute column to create another attribute:
1 On the Project Tables View tab, find the project table that contains the column you
like to re-use for the attribute.
2 Right-click the table and select Create Attribute.
4 Click OK.
5 In the Create New Form Expression window, define the attribute form expression as
desired.
can access any column in a table from this window, even those that have
You
already been used for other attributes.
6 Click OK.
Modifying Attribute Forms

Create and modify attributes in the Architect graphical interface, including adding and
modifying attribute forms.
You can modify existing attributes in the Architect graphical interface. You can change
any of the following parts of an attribute:
Attribute forms
Attribute form expressions
Primary lookup table
Source tables
Mapping methods
Column aliases
You can modify attributes from the Project Tables View tab or the Properties pane. They
both provide access to all parts of an attribute.
the full range of attribute functions from the Project Tables View tab,
Toyouaccess
have to change the display properties to show attribute forms within project
tables. For information on how to display attribute forms for project tables, see
Display Properties for Project Tables starting on page 193.
Creating Attribute Forms

Creating attributes in the Architect graphical interface 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.
When you first create an attribute, you create the ID form. However, most attributes will
have other forms as part of their definition. You can create additional attribute forms by
modifying attributes. You can also modify existing attribute forms.
You can create attributes with forms that have simple or derived attribute form
expressions. You can add as many attribute forms as needed to describe an attribute. You
can add attribute forms using the Project Tables View tab.
285
You cannot add attribute forms using the Properties pane.

To create new attribute form:
1 On the Project Tables View tab, find the project table that contains the attribute form
you want to add.
Attribute forms should be part of the primary lookup table for the attribute.
2 In the project table, right-click the attribute for which you want to add a form and
select New Attribute Form.
3 In the Create New Form Expression window, define the new attribute form
expression.
can define simple or derived form expression and select the mapping
You
method.
4 Click OK.
you selected Manual as the mapping method and you need to map additional
Iftables
to the form, you have to modify the attribute form. For information on
modifying attribute forms, see Modifying Attribute Forms starting on
page 290.
286 Modifying Attribute Forms
The following image shows the option for adding attribute forms:
Option for Adding Attribute Forms
287
The following image shows the Create New Form Expression with a simple form
expression for the Subcategory attribute:
Create New Form Expression
The following image shows the description (DESC) attribute form for the Employee
attribute displayed in the Architect graphical interface:
Project TableDESC Form for Employee Attribute
289
The following image shows the DESC form for the Subcategory attribute displayed in the
Properties pane:
Properties PaneDESC Form for Subcategory Attribute

You can modify existing attribute forms, including changing their attribute form
expressions, mapping methods, primary lookup tables, source tables, and column
aliases. You can modify attribute forms using either the Project Tables View tab or the
Properties pane.
To modify an attribute form from the Properties pane:
1 In the Properties pane, click the Attributes tab.

2 On the Attributes tab, in the drop-down list, select the attribute you want to modify.
3 Under the appropriate form category, select the corresponding form property.
if you are modifying an ID form, the default property name is ID.
IfForyouexample,
are modifying a description form, the default property name is DESC.
4 Select the expression to see the following Browse button:
5 Click Browse.
6 In the Modify Attribute Form window, modify parts of the attribute form as desired.
can change the source tables for attribute form expressions or the column
You
alias for an attribute form. You can modify or delete existing expressions for
the attribute form or create new ones. You can also change the primary lookup
table for the attribute.
7 After you have completed your changes to the attribute form, click OK.
291
The following image shows attribute form categories in the Properties pane:
Attribute Form Categories
Properties pane also contains properties that enable you to modify individual
The
attribute form expressions for specific tables and modify column aliases.
Modifying Column Aliases

You can also modify column aliases for existing attributes. Column aliases for attributes
work in a manner similar to column aliases for facts.
For more information, see Modifying Column Aliases starting on page 238.
To modify the column alias for an existing attribute:
1 In the Properties pane, click the Attributes tab.

2 On the Attributes tab, in the drop-down list, select the attribute for which you want to
view or modify the column alias.
3 Under the appropriate form category, select the Column Alias property to see the
following Browse button:
4 Beside the column alias expression, click Browse.

5 In the Column Editor - Column Selection window, modify existing or create new
column alias.
additional steps on modifying column aliases, refer to the procedure To
For
modify the column alias for an existing fact from the Project Tables View tab: on
page 239.
293
Viewing and Modifying Properties for Attributes

All attributes have properties that you can view in the Properties pane. You can also
modify many of these properties. The following table lists these properties and their
descriptions:
Properties for Attributes
Category
Property
Description
Definition
ID
GUID that identifies the attribute in the metadata

Name
Name of the attribute
Description
Description of the attribute

Hidden
Setting that determines whether the attribute is a hidden

object
Location
Project folder location for the attribute

Apply Security
Filters
Setting that determines whether security filters are applied

when browsing elements for the attribute
Enable
Element
Caching
Setting that determines whether elements of the attribute

are cached when browsing the attribute
Properties for Attributes

Category
Property
Description
Form
<Number>:
<Form Name>
<Form Name>
Provides the Edit option to modify the attribute form
Name
Name of the attribute form
Category
Form category for the attribute form
Format
Format that corresponds to the data type of the attribute

form
Report Sort
Setting that determines the default sort order for the

attribute form when it is displayed on reports
Browse Sort
Setting that determines the default sort order for the

attribute form when it is displayed while browsing the
attribute
Use as Browse
Form
Setting that determines if the attribute form is displayed by

default when browsing the attribute
NOTE: When you first create an attribute, the ID form
defaults to True for this property. If you add a subsequent
form (like a DESC form), the value of the new form
defaults to True, and the value of the ID form
automatically changes to False.
Use as Report
Form
Setting that determines if the attribute form is displayed by

default when showing the attribute on reports
NOTE: When you first create an attribute, the ID form
defaults to True for this property. If you add a subsequent
form (like a DESC form), the value of the new form
defaults to True, and the value of the ID form
automatically changes to False.
Form
<Number>:
<Form Name>
Geographical
Role
Setting that determines how the attribute form can be

used as geographical data with various MicroStrategy
mapping features.
Shape File
Setting that determines the shapes used to display the

attribute form on various MicroStrategy mapping features
Column Alias
Column alias for the attribute form
Supports
Multiple
Languages
Setting that determines if an attribute form is configured to

support SQL-based data internationalization
Attribute Form
Expressions
Source tables for the attribute form and the columns to

which it maps in each table
NOTE: This property is not available for ID attribute forms.
NOTE: Each table to which an attribute form expression is

mapped is listed separately for this property.
295
attribute has a set of properties for each form that are part of its definition.
An
Those properties are organized under a category name. The category name for the
first form is labeled Form 1: <Form Name>, the second is Form 2: <Form Name>,
and so forth.
To view or modify the properties of an attribute:

On the Project Tables View tab, find a project table that contains the attribute for
which you want to view or modify properties.
In the project table, select the attribute.
This action displays the attribute in the Properties pane.

OR
In the Properties pane, click the Attributes tab.
On the Attributes tab, in the drop-down list, select the attribute for which you
want to view or modify properties.
2 In the Properties pane, view or modify the attribute properties as desired.

properties have text boxes or drop-down lists that enable you to modify
Some
their values. For other properties, selecting the property or its current value
displays the following Browse button:
Clicking the Browse button opens a window that enables you to modify the
related property.
Defining Attribute Form Display

As you learned earlier, attribute forms enable you to display different type of information
about an attribute. If you create multiple forms for an attribute, you need to define which
forms are a 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.
ID forms are automatically added to the default report display and
Attribute
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.
default report display you define at the attribute level determines which forms
The
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 Properties pane:
On the Project Tables View tab, find a project table that contains the attribute for
which you want to view or modify properties.
In the project table, select the attribute.
This action displays the attribute in the Properties pane.

OR
In the Properties pane, click the Attributes tab.
On the Attributes tab, in the drop-down list, select the attribute for which you
want to view or modify properties.
2 For the appropriate form, beside the Use as Browse Form property, select the check
box to toggle between True and False.
3 Beside the Use as Report Form property, select the check box to toggle between True
and False.
297
you first create an attribute, the ID form defaults to True for this
When
property. If you add a subsequent form (like a DESC form), the value of the
new form defaults to True, and the value of the ID form automatically changes
to False.
4 Repeat steps 2 to 3 to modify the report display and browse form properties for other
attribute forms as appropriate.
The following image shows the Properties pane with an attribute form display
highlighted:
Properties PaneAttribute Form Display
299
Creating Attribute Relationships

As you create each hierarchy or dimension of attributes, the last step in building the
attributes is to create the relationships that exists between attributes identified in your
logical data model. For example, a customer hierarchy could look like the following:
Customer Hierarchy
You create attribute relationships using the Hierarchy View tab. As you create the
attribute relationships for each hierarchy or dimension, you build the system hierarchy
for the project.
Attribute Relationship Creation Methods

There are two primary means of creating attribute relationships in the Architect
Manual attribute relationship creation means that you create attribute relationships on
your own, deciding which attributes to relate and the type of relationship between them
based on your data warehouse model. This method gives you control over what
relationships are created. However, it does require that you create each attribute
relationship that you need.
Automatic attribute relationship creation means that you allow Architect to identify and
create the appropriate attribute relationships. Architect uses relationship recognition
that is based on a set of rules you select to determine whether attributes are related and
the type of relationship that exists between them. After the attribute relationships are
created, you can modify them however you want. This method provides a quick easy way
to create attribute relationships and minimizes the amount of work you have to do.
However, if you use this method, you should verify that Architect correctly identifies
related attributes and creates all of the desired relationships. Otherwise, you can end up
with incorrect, missing, or unwanted attribute relationships.
The method you choose depends on the physical structure of the tables and columns in
your data warehouse, the extent to which you want to analyze various relationships, and
your own knowledge of the data warehouse model. If you are uncertain about the
relationships you want to create and your project environment lends itself to creating
attribute relationships automatically, it can be a tremendous timesaver. However, if you
are familiar with your data warehouse model and know which attribute relationships you
want to use in a project, creating the relationships manually can be a better way of
organizing the system hierarchy.
more information on creating attribute relationships automatically, see
For
Automatic Relationship Recognition starting on page 374.
Creating Attribute Relationships Manually

If relationship recognition is disabled, when you create the attributes for a hierarchy or
dimension, they display on the Hierarchy View tab without any relationships defined.
The following image shows the attributes from the Time hierarchy on the Hierarchy View
tab:
Attributes from Time Hierarchy
image on the previous page displays the system hierarchy in its current state.
The
Before you create relationships, all attributes display as entry points. As you create
relationships, only top-level attributes that do not have parents are kept as entry
points.
301
All the attributes from the hierarchy that has been created are present, but no
relationships exist, hence they are not connected.
The Hierarchy View tab provides a click-and-drag interface that enables you to easily
draw relationships between attributes. When you select an attribute, the attributes that
are child candidates display using regular attribute icons. The attributes that are not
child candidates display using ghosted attribute icons.
For example, the following image shows the Month of Year attribute with its child
candidates identified:
Child Candidates for the Month of Year Attribute
The Month, Year, and Quarter attributes are the potential children for the Month of Year
attribute, so their icons display normally. The Day attribute is not a potential child for the
Month of Year attribute, so its icon is ghosted.
the ID forms for two attributes are in the same project table, Architect
Ifrecognizes
them as potentially being related.
To manually create an attribute relationship:
1 On the Hierarchy View tab, click the parent attribute and drag the mouse pointer to
the child attribute.
you click and drag the pointer, a line is dynamically drawn that links the
When
two attributes.
2 If you need to change the relationship type, right-click the line that shows the
relationship and select the appropriate relationship type.
One to many is the default relationship type.

3 If you need to change the relationship table, right-click the line that shows the
relationship, point to Relationship Table, and select the appropriate table.
The following image shows the relationship between the Month of Year and Month
attributes:
Relationship Between the Month of Year and Month Attributes
The relationship line indicates the type of relationshipone to one, one to many, or
many to many. If you move the pointer over the relationship line, the name of the
relationship table displays.
The following image shows the options for selecting attribute relationship types and
relationship tables:
Options for Selecting Attribute Relationship Types and Relationship Tables
303
On the Hierarchy View tab, you can also modify attribute relationships in the Children
Relations window. To modify existing relationships, right-click the attribute and select
Edit Children Relations.
The following image shows the option for modifying parent-child relationships:
Option for Modifying Child Attributes
The following image shows the Children Relations window:

Children Relations Window
You can also remove attribute relationships on the Hierarchy View tab.
305
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. While the system hierarchy serves as the default drill path used in reports
to drill up and down to directly related attributes, creating a user hierarchy configured
for drilling is a more common method for managing drilling in reports.
can create user hierarchies that enable users to efficiently browse attribute
You
data in the project. For information on user hierarchies, see the Working with
User Hierarchies lesson starting on page 323.
306 What Is the System Hierarchy?
All attributes and attribute relationships on the Hierarchy View tab comprise the system
hierarchy:
System Hierarchy
What Is the System Hierarchy?
307
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 use layers to organize lookup and relationship tables before creating the
corresponding attributes. The best method for creating these layers is to group
together tables from the same hierarchy or dimension.
308 Lesson Summary
You can create attributes in the Architect graphical interface manually or

automatically.
When you create an attribute manually in the Architect graphical interface, you can
map it to a column in all project tables or only selected project tables.
You can modify existing attributes in the Architect graphical interface, including
attribute forms, attribute form expressions, primary lookup tables, source tables,
mapping methods, and column aliases.
You can create and modify attribute forms in the Architect graphical interface.
You can view and modify properties for attributes in the Architect graphical interface.
You can use the Attribute graphical interface 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 graphical interface by assigning
two or more attributes to the ID form category, which creates a form group.
The column alias specifies the data type that the MicroStrategy Engine uses for an
attribute form when it generates SQL for temporary tables. You can modify attribute
form alias in the Architect graphical interface.
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.
Attribute relationships form links between attributes that enable you to join data
from their respective lookup tables.
You can create attribute relationships in the Architect graphical interface manually or
automatically.
You can create attribute relationships manually either using a click-and-drag

interface or using right-click menu options.
You can use relationship recognition to automatically create attribute relationships.
When you create attributes and their corresponding relationships, you build 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.
Lesson Summary
309
The system hierarchy is automatically updated any time you add, modify, or remove
attributes or attribute relationships.
The system hierarchy serves as the default drill path used in reports to drill up and
down to directly related attributes, but creating a user hierarchy configured for
drilling is a more common method for managing drilling in reports.
310 Lesson Summary

Exercises: Working with Attributes
In this set of exercises, you will create attributes in the My Demo Project.
Creating Attributes in the Project

Overview
In this exercise, you will use the Architect graphical interface to create attributes
manually in the My Demo Project. You need to create the following attributes in their
corresponding layers:
Geography Attributes
Source Tables
Column Name
Attribute Name
LU_CALL_CTR
CALL_CTR_ID
Call Center
LU_REGION
REGION_ID
Region
LU_COUNTRY
COUNTRY_ID
Country
LU_DIST_CTR
COUNTRY_ID,
DIST_CTR_ID
Distribution Center
LU_EMPLOYEE
EMP_ID
Employee
Time Attributes
Source Tables
Column Name
Attribute Name
LU_DAY
DAY_DATE
Day
LU_MONTH
MONTH_ID
Month
LU_MONTH_OF_YEAR
MONTH_OF_YEAR
Month of Year
LU_QUARTER
QUARTER_ID
Quarter
LU_YEAR
YEAR_ID
Year
Distribution Center is a compound attribute.

311
After you have created these attributes, you need to create the following description
forms for selected attributes:
You should use automatic mapping for all attribute form expressions.
Attribute Name
DESC Form Expression
Call Center
CENTER_NAME
Country
COUNTRY_NAME
Month
MONTH_DESC
Month of Year
MONTH_OF_YEAR_NAME
Quarter
QUARTER_DESC
Region
REGION_NAME
As you create the form expressions for each attribute, you can use the Properties pane to
verify that you are creating the expressions correctly and mapping them to the
appropriate tables. You should save your project work after you create each attribute.
After you have created these attributes and their respective forms, you need to manually
create the following child relationships for each attribute:
relationships should be defined on the Hierarchy View tab in the Architect
All
graphical interface. 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

Attribute Name
Child Attribute
Country
Region
Country
Distribution Center
Distribution Center
Call Center (1:1)
Call Center
Employee
Month
Day
Month of Year
Month
Quarter
Month
Region
Call Center
Year
Quarter
312 Exercises: Working with Attributes
After you have created the child relationships for these attributes, save and update the
project schema.
detailed instructions are shown only for the Call Center attribute and the
The
Distribution Center attribute. Use the same procedure to create the remaining
attributes using their respective tables and column names.
Create the Call Center attribute
3 On the Home tab, in the Layer section, in the layers drop-down list, select the
Geography layer.
4 On the Project Tables View tab, right-click the header of the LU_CALL_CTR table
and select Create Attribute.
5 In the MicroStrategy Architect window, in the box, type Call Center.
6 Click OK.
7 In the Create New Form Expression window, in the Form expression box, create the
following expression:
CALL_CTR_ID
9 Click OK.
action creates a Call Center attribute with an ID form that maps to the
This
column CALL_CTR_ID for every project table in which the column occurs.
The new attribute automatically displays in the Properties pane.
313
10 Repeat steps 4 to 9 to create the remaining attributes except for the Distribution
Center attribute in the Geography and Time layers:
Geography Attributes
Source Tables
Column Name
Attribute Name
LU_REGION
REGION_ID
Region
LU_COUNTRY
COUNTRY_ID
Country
LU_EMPLOYEE
EMP_ID
Employee
Time Attributes
Source Tables
Column Name
Attribute Name
LU_DAY
DAY_DATE
Day
LU_MONTH
MONTH_ID
Month
LU_MONTH_OF_YEAR
MONTH_OF_YEAR
Month of Year
LU_QUARTER
QUARTER_ID
Quarter
LU_YEAR
YEAR_ID
Year
you can create these attributes by right-clicking the appropriate

Alternatively,
column in the table and selecting Create Attributes. Because this method
defaults the attribute name to the mapped column name, make sure you rename
the attributes when appropriate. To rename an attribute, right-click it and select
Rename. In the MicroStrategy Architect window, in the box, type the attribute
name, and click OK.
Create a description form for the Call Center attribute
11 On the Home tab, in the Layer section, in the layers drop-down list, select the All
Project Tables layer.
12 On the Project Tables View tab, in the LU_CALL_CTR table, right-click the Call
Center attribute you created and select New Attribute Form.
13 In the Create New Form Expression window, in the Available columns list,
double-click CENTER_NAME to define it as a form expression.
15 Click OK.
you can see the attribute forms in the table, right-click the table,
Topointensure
to Properties, point to Logical Tables, and select Display Attribute
Forms.
Create description forms for the remaining attributes
16 Repeat steps 12 to 15 to create the description forms for the following attributes in
their respective lookup tables:
Attribute Name
DESC Form Expression
Country
COUNTRY_NAME
Month
MONTH_DESC
Month of Year
MONTH_OF_YEAR_NAME
Quarter
QUARTER_DESC
Region
REGION_NAME
you can create these attribute forms by dragging the appropriate

Alternatively,
column to the attribute in the lookup table.
Create a parent-child relationship for the Call Center attribute
17 Click the Hierarchy View tab.

18 On the Hierarchy View tab, select the Call Center attribute and drag the mouse
pointer towards the Employee attribute.
An arrow line indicates a relationship is created.
19 Right-click the Call Center attribute and select Edit Children Relations.
20 In the Children Relations window, in the Relationship type drop-down list, make sure
the One to Many relationship type is selected.
21 Click OK.
22 On the Home tab, in the Auto Arrange Hierarchy Layout section, click Regular to
rearrange the attributes.
315
Create parent-child relationships for the remaining attributes
23 Repeat steps 18 to 22 to create the following relationships on the Hierarchy View tab:
Attribute Name
Child Attribute
Country
Region
Month
Day
Month of Year
Month
Quarter
Month
Region
Call Center
Year
Quarter
Create the Distribution Center compound attribute
24 Click the Project Tables View tab.

25 On the Project Tables View tab, in the Layer section, in the drop-down list, select the
Geography layer.
26 On the Project Tables View tab, right-click the header of the LU_DIST_CTR table and
select Create Attribute.
27 In the MicroStrategy Architect window, in the box, type Distribution Center.
28 Click OK.
DIST_CTR_ID
31 Click OK.
32 Right-click the header of the Distribution Center attribute, select New Attribute
Form.
COUNTRY_ID
35 Click OK.
36 In the Properties pane, modify the Category property of the new description form to
ID.
37 In the MicroStrategy Architect window that prompts you to create a form group, click
Yes.
Create a parent-child relationship for the Distribution Center attribute

39 On the Hierarchy View tab, select the Distribution Center attribute and drag the
mouse pointer towards the Call Center attribute.
40 Right-click the Distribution Center attribute and select Edit Children Relations.
41 In the Children Relations window, in the Relationship type drop-down list, select the
One to One relationship type.
42 Click OK.
43 Select the Country attribute and drag the mouse pointer towards the Distribution
Center attribute.
Ensure that the relationship type is one to many.

Verify the attribute relationships
44 On the Home tab, in the Auto Arrange Hierarchy Layout section, click Regular.
317
The Geography system hierarchy should look like the following:
The Time system hierarchy should look like the following:
45 Save and update the project schema.

Modifying Attributes in the Project

Overview
In this exercise, you will modify the Day and Employee attributes you created in the My
Demo Project. You need to create or modify the following forms and expressions for
these attributes:
Attribute
Forms
Expressions
Source Tables
Use as Use as
Browse Report
Form
Form
Day
ID
ORDER_DATE
ORDER_DETAIL
Yes
Yes
LU_EMPLOYEE
Yes
Yes
First Name EMP_FIRST_NAME
LU_EMPLOYEE
No
No
Last Name EMP_LAST_NAME
LU_EMPLOYEE
No
No
SSN
LU_EMPLOYEE
Yes
No
ORDER_FACT
Employee
DESC
EMP_LAST_NAME + ,
+ EMP_FIRST_NAME
EMP_SSN
As you create or modify these attributes, you should do the following:
Use automatic mapping for all attribute form expressions
Define the Use as Browse Form and Use as Report Form properties as indicated for
each attribute
After you have modified both attributes, save and update the project schema.
You can use the detailed instructions if you want help. There is a separate set of
instructions for each attribute you modify.
Detailed InstructionsDay Attribute

2 On the Project Tables View tab, in the Layer section, in the layers drop-down list,
select the Time layer.
3 On the Project Tables View tab, in the LU_DAY table, select the Day attribute.
319
Modify the ID form for the Day attribute
4 In the Properties pane, under Form 1:ID, select ID to see the following Browse button:
5 Click Browse.
6 In the Modify Attribute Form window, on the Definition tab, click New.
7 In the Create New Form Expression window, in the Source table drop-down list,
select ORDER_DETAIL.
8 In the Form expression box, create the following expression:
ORDER_DATE
10 Click OK.
11 In the Modify Attribute Form window, click OK.
do not need to configure the Use as Browse Form and Use as Report Form
You
properties for the Day attribute, because they are automatically set to True.
Detailed InstructionsEmployee Attribute

Modify the Employee description (DESC) form
1 On the Project Tables View tab, in the Layer section, in the layers drop-down list,
select the Geography layer.
2 On the Project Tables View tab, in the LU_EMPLOYEE table, right-click the
Employee attribute and select New Attribute Form.
3 In the Create New Form Expression window, define the expression as follows:
EMP_LAST_NAME + ", " + EMP_FIRST_NAME
5 Click OK.
Create the First Name form for the Employee attribute
6 Create a new attribute form for the Employee attribute with the following
expression:
EMP_FIRST_NAME
7 Use Automatic mapping.
8 In the Properties pane, modify the Name property of the newly created form (Form 3:
None) to First Name.
Create the Last Name form for the Employee attribute
expression:
EMP_LAST_NAME
None) to Last Name.
Create the SSN form for the Employee attribute
expression:
EMP_SSN
None) to SSN.
Define the report display and browse forms for the Employee attribute
15 In the LU_EMPLOYEE table, select the Employee attribute, if not already selected.
16 In the Properties pane, under Form 2: DESC, ensure that the Use as Browse Form
and Use as Report Form properties are set to True.
17 Under Form 3: First Name, modify the Use as Browse Form and Use as Report
Form properties to False.
18 Under Form 4: Last Name, modify the Use as Browse Form and Use as Report
Form properties to False.
321
19 Under Form 5: SSN, modify the Use as Report Form property to False.
Keep the Use as Browse Form property set to True.

20 Save and close Architect graphical interface, updating the project schema.
9
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 and define user
hierarchy elements using the Architect graphical interface.
323
Working with User Hierarchies
Lesson Objectives
Describe how user hierarchies are used in a MicroStrategy project, create user
hierarchies, and define user hierarchy elements using Architect graphical
interface.
Describe how user hierarchies are used in a MicroStrategy

project. (Page 325)
Create user hierarchies in the Architect graphical interface. (Page 330)
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.
325
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.
326 What Is a User Hierarchy?
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.
327
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
328 What Is a User Hierarchy?
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
329
Creating User Hierarchies

Create user hierarchies in the Architect graphical interface.
You already learned how you can use the Hierarchy View tab to create attribute
relationships and define the system hierarchy. You can also create user
hierarchies in the Architect graphical interface from the Hierarchy View tab.
You have to perform the following steps to create a user hierarchy in the
Architect graphical interface:
1 Create the user hierarchy object.
2 Add attributes to the user hierarchy.
3 Define the user hierarchy, including the following elements:
Browse attributes
Entry points
Element display
Availability for drilling
Attribute filters
can also customize the sort order for browsing and drilling user
You
hierarchies. For more information, see Defining the Sort Order for
User Hierarchies starting on page 433.
After you created and defined user hierarchies, you have to move all the user
hierarchies to the Schema Objects\Hierarchies\Data Explorer folder to make
them available for browsing.
The following topics describe each of the steps involved in creating and
defining user hierarchies in more detail.
330 Creating User Hierarchies

When you are on the Hierarchy View tab, the Architect toolbar displays the
hierarchies drop-down list. By default, the only item in this list is the System
Hierarchy View, which displays the system hierarchy for the project. If you
want to view a user hierarchy, you have to first create it.
To create a user hierarchy:
1 On the Home tab, in the Layer section, click New Hierarchy.
2 In the MicroStrategy Architect window, in the box, type the name for the
user hierarchy.
3 Click OK.
action creates the user hierarchy and displays it on the
This
Hierarchy View tab. It also adds the user hierarchy to the hierarchies
drop-down list on the toolbar.
The following image shows the Geography user hierarchy displayed on the
Hierarchy View tab:
Geography User Hierarchy
331
Adding Attributes to User Hierarchies

When you initially create a user hierarchy, it does not contain any attributes.
The next step in creating the user hierarchy is to add the attributes you want to
include in the hierarchy.
To add attributes to a user hierarchy:
1 On the Home tab, in the Hierarchy section, in the drop-down list, select the
user hierarchy to which you want to add the attributes.
2 On the Hierarchy View tab, right-click an empty area inside the user
hierarchy and select Add/Remove attributes in Hierarchy.
3 In the Select Objects window, in the Available objects list, select the
attributes you want to add to the user hierarchy.
can use the SHIFT or CTRL keys to select multiple attributes at
You
the same time.
4 Click the > button to add the selected attributes to the Selected objects list.
5 Click OK.
The following image shows the option for adding attributes to a user hierarchy:
Option for Adding Attributes to a User Hierarchy
The following image shows the Geography user hierarchy with all the attributes
added to it:
Defining User Hierarchy Elements

After you add the attributes you want to include in a user hierarchy, the next
step is to define the various elements of the user hierarchy. These
characteristics determine the structure of the user hierarchy and how it
functions.
For all user hierarchies, you must define browse attributes and entry points.
You can also define the element display for attributes, define filters on
attributes, and configure user hierarchies for drilling.
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.
333
Browse attributes are indicated by a line that connects the two attributes.
You need to define the necessary browse attributes for each attribute in the
user hierarchy.
To define browse attributes for an attribute in a user hierarchy:
1 On the Home tab, in the hierarchies drop-down list, select the user
hierarchy you want to define.
2 On the Hierarchy View tab, do one of the following:
Click the attribute for which you want to define browse attributes and
drag the mouse pointer to another attribute in the hierarchy to which
you want to browse.
Repeat this step for each attribute you want to define as a browse
attribute.
OR
Right-click the attribute for which you want to define browse attributes
and select Define Browse Attributes.
In the Select Objects window, in the Available objects list, select the
attributes you want to use as browse attributes.
can use the SHIFT or CTRL keys to select multiple attributes at

You
the same time.
Click the > button to add the selected attributes to the Selected objects
list.
3 Click OK.
The following image shows the option for defining browse attributes:
Option for Defining Browse Attributes
The following image shows the Geography User Hierarchy with the browse
paths defined:
Geography User HierarchyBrowse Paths
335
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.
If you want to provide direct access to specific attributes in the hierarchy, you
need to 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.
You need to select attributes from the user hierarchy to serve as entry points.
To set an attribute as an entry point in a user hierarchy:
2 On the Hierarchy View tab, right-click the attribute you want to define as an
entry point and select Set As Entry Point.
action places a green check mark beside the attribute on the
This
Hierarchy View tab to indicate it is an entry point.
The following image shows the option for setting entry points:
Option for Setting Entry Points
The following image shows the Geography user hierarchy with all the attributes
set as entry points:
Geography User HierarchyEntry 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
attributes element display:
UnlockedYou can browse all the elements of an attribute at one time.
LockedYou cannot browse the elements of an attribute at all.
LimitYou 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.
337
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.
or limiting the element display for an attribute only affects how
Locking
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.
For each attribute in the user hierarchy, you have the option to change how
attribute elements display or whether they display at all.
To set the element display for an attribute in a user hierarchy:
2 On the Hierarchy View tab, right-click the attribute for which you want to
set the element display, point to Element Display, and select the
appropriate display type.
select Limit as the display type, you are prompted to provide
Iftheyounumber
of elements you want to display at one time for the
attribute.
If you select Locked as the display type, a lock icon displays on the
attribute
on the Hierarchy View tab.
The following image shows the option for setting the element display:
Option for Setting Element Display
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.
You can use a single hierarchy for browsing, drilling, or both tasks.
you configure a user hierarchy for drilling, it is displayed on the Other
Ifdirections
drill menu. For information on drilling, see the MicroStrategy
Developer: Reporting Essentials course.
You can also configure the user hierarchy as a drill path.

To configure a user hierarchy for drilling:
hierarchy you want to configure for drilling.
2 On the Hierarchy View tab, right-click an empty area inside the user
hierarchy and select Use As a Drill Hierarchy.
339
The following image shows the option for configuring a user hierarchy for
drilling:
Option for Configuring a User Hierarchy for Drilling
Show Sample Data

You can also see attribute elements of an attribute on the Hierarchy View tab.
To see the sample data:
1 On the Hierarchy View tab, select the an attribute you want to see the
attribute elements.
2 Right-click the attribute and select Show Sample Data.
3 In the Browse for attribute elements window, expand the attribute to see
the attribute elements.
In the following image, you can see the Show Sample Data option for the
Quarter attribute. After you chose to show sample data, the elements of the
Quarter attribute display in the Browse for attribute elements window:
Option for Showing Sample Data
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.
can apply any type of filter to user hierarchies. For example, you
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 2010, you see
only the data for 2010. If users perform most of their analysis on 2010 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.
filters on a user hierarchy are not a security measure to
Attribute
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.
341
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.
For each attribute in the user hierarchy, you have the option to define filters
that apply to its attribute element display.
To define filters on an attribute in a user hierarchy:
2 On the Hierarchy View tab, right-click the attribute for which you want to
define filters and select Define Attribute Filters.
3 In the Select Objects window, in the Available objects list, select the filters
you want to apply to the attribute.
can use the SHIFT or CTRL keys to select multiple filters at the
You
same time.
Filters will be available as they are created in Developer.
4 Click the > button to add the selected filters to the Selected objects list.
5 Click OK.
you define a filter on an attribute, a filter icon displays beside the
Ifattribute
on the Hierarchy View tab.
The following image shows the option for defining attribute filters:
Option for Defining Attribute Filters
The following image shows the elements of the Year attribute when you browse
without a filter:
Browsing Year Attribute Without Filter
343
The following image shows the Time user hierarchy with the filter defined for
the Year attribute:
Year Attribute with Filter
The following image shows the elements of the Year attribute with 2011 and
2012 filter defined:
Browsing Year Attribute with Filter
345
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.
You can also configure user hierarchies as drill paths for analyzing report
data.
The primary task in creating a user hierarchy is to select the attributes you
want to include in the 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 use Architect graphical interface 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.
The show sample data option displays the attribute elements of an

attribute.
346 Lesson Summary
If an attributes element display is unlocked, you can browse all its elements
at one time.
If an attributes element display is locked, you cannot browse its elements

at all.
If an attributes element display has a limit, you can browse a specified

number of elements at one time. You can 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.
Lesson Summary
347
348 Lesson Summary

Exercises: Working with User Hierarchies
In this set of exercises, you will first create two user hierarchies in the My Demo Project.
Creating User Hierarchies in the Project

In this exercise, you will use the Architect graphical interface to create user hierarchies in
the My Demo Project. You need to create the following user hierarchies:
Geography
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 have to create.
OverviewGeography User Hierarchy

In this exercise, you will use Architect graphical interface to create a Geography user
hierarchy for the geography-related attributes in the My Demo Project. The following
table shows which attributes to include in the user hierarchy and how to define them:

Attributes
Browse Attributes
Entry Point
Element Display
Call Center
Employee
Yes
Unlocked
Country
Region, Call Center
Yes
Unlocked
Distribution Center
Call Center
Yes
Unlocked
Employee
None
Yes
Unlocked
Region
Call Center, Employee
Yes
Unlocked
349
After you have created this user hierarchy, save and update the project schema.
Detailed InstructionsGeography User Hierarchy

Create the Geography user hierarchy
2 In the Architect graphical interface, click the Hierarchy View tab, if necessary.
3 On the Home tab, in the Hierarchy section, click New Hierarchy.
4 In the MicroStrategy Architect window, in the box, type Geography as the user
hierarchy name.
5 Click OK.
Add attributes to the Geography user hierarchy
6 On the Hierarchy View tab, right-click an empty area inside the user hierarchy and
select Add/Remove attributes in Hierarchy.
7 In the Select Objects window, in the Available objects list, hold CTRL and select the
following attributes:
Attribute
Call Center
Country
Distribution Center
Employee
Region
8 Click the > button to add the attributes to the Selected objects list.
9 Click OK.
350 Exercises: Working with User Hierarchies
Define the browse attributes for the Geography user hierarchy
10 On the Hierarchy View tab, in the Geography user hierarchy, right-click the Call
Center attribute and select Define Browse Attributes.
11 In the Select Objects window, in the Available objects list, select Employee.
12 Click the > button to add the Employee attribute to the Selected objects list.
13 Click OK.
14 Repeat steps 10 to 13 for the following attributes:
Attribute
Browse Attributes
Country
Region, Call Center
Distribution Center
Call Center
Employee
None
Region
Call Center, Employee
Set the entry points for the Geography user hierarchy
15 On the Home tab, in the Auto Arrange Hierarchy Layout section, click Regular to
rearrange the attributes.
may have to switch to the System Hierarchy View , then back to the
You
Geography hierarchy, for this setting to take effect.
16 In the Geography user hierarchy, right-click the Region attribute and select Set As
Entry Point.
17 Repeat step 16 for the Call Center, Employee, Country, and Distribution Center
attributes.
the element display for all the attributes in geography hierarchy is unlocked,
Since
you do not need to define element display for the attributes.
Configure the Geography user hierarchy for drilling
18 In the Geography user hierarchy, click anywhere in the empty area to deselect any
attributes you may have selected.
19 Right-click an empty space and select Use As a Drill Hierarchy.
351
20 On the Home tab, click Save and Update Schema to update the project schema.
OverviewTime User Hierarchy

In this exercise, you will use the Architect graphical interface to create a Time user
hierarchy for the time-related attributes in the My Demo Project. The following table
shows which attributes to include in the user hierarchy and how to define them:
Time User Hierarchy

Attributes
Browse Attributes
Entry Point
Element Display
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.
After you have created this user hierarchy, save and close the Architect graphical
interface and update the project schema.
Finally, in Developer, move all the user hierarchies you created from the Schema
Objects\Hierarchies folder to the Schema Objects\Hierarchies\Data Explorer folder.
Detailed InstructionsTime User Hierarchy

Following instructions are written at a higher level to help better test your
understanding.
Create Time user hierarchy
1 Create new Time user hierarchy.
Add attributes to the Time user hierarchy
2 On the Hierarchy View tab, in the Time user hierarchy, right-click an empty area and
select Add/Remove attributes in Hierarchy.
3 In the Select Objects window, select the following attributes to include in the Time
user hierarchy:
Attribute
Day
Month
Month of Year
Quarter
Year
4 Click OK.
Define the browse attributes for the Time user hierarchy
5 On the Hierarchy View tab, in the Geography user hierarchy, right-click the Month
attribute and select Define Browse Attributes.
6 In the Select Objects window, in the Available objects list, select Day.
7 Click the > button to add the Employee attribute to the Selected objects list.
8 Click OK.
9 Repeat steps 5 to 8 for the following attributes:
Attributes
Browse Attributes
Day
None
Month of Year
Month
Quarter
Month, Day
Year
Quarter, Month
353
Set the entry points for the Time user hierarchy
10 On the Hierarchy View tab, in the Time user hierarchy, set the Day, Month, Quarter,
and Year attributes as entry points.
Set the element display for the Time user hierarchy
11 In the Time user hierarchy, right-click the Day attribute, point to Element Display,
and select Limit.
12 In the Limit box, type 31.
13 Click OK.
Configure the Time user hierarchy for drilling
14 In the Time user hierarchy, click anywhere in the empty area to deselect any
attributes you may have selected.
15 Right-click an empty space and select Use As a Drill Hierarchy.
Save and close the project
16 Click Save and Close to update the project schema and to exit Architect graphical
interface.
Save the Geography and Time hierarchies in the Data Explorer folder
17 In Developer, browse to the Schema Objects\Hierarchies folder and drag the

Geography and Time hierarchies to the Data Explorer folder to make them available
for browsing.
hierarchies do not display in the Schema Objects\Hierarchies folder
The
unless you save and update schema. You may have to refresh Developer
display to view them. To refresh Developer display, browse to the Hierarchies

folder and press F5. To view the hierarchies in the Data Explorer for the
project, in the Folder List, right-click Data Explorer - My Demo Project and
select Refresh.
The Geography user hierarchy should resemble the image below:
The Time user hierarchy should resemble the image below:
355
10
AUTOMATIC SCHEMA
RECOGNITION
Lesson Description
This lesson describes how to use the automatic schema recognition function in the
Architect graphical interface to create facts, attributes, and attribute relationships
automatically.
In this lesson, you will first learn how automatic schema recognition works, including its
uses. Then, you will learn how to use automatic schema recognition to automatically
create facts and attributes for all project tables or selected project tables. Finally, you will
learn how to use automatic relationship recognition.
357
10
Automatic Schema Recognition
Lesson Objectives
Describe how automatic schema recognition works and create facts, attributes, and
relationships in the Architect graphical interface using automatic schema recognition.
Identify the two levels at which you can use automatic schema recognition, describe
when to use automatic schema recognition, explain how columns are mapped based
on the level at which you use automatic schema recognition, and describe the
heuristics Architect uses to recognize columns. (Page 359)
Create facts and attributes in the Architect graphical interface using automatic schema
recognition. (Page 366)
10
Overview of Automatic Schema Recognition

Identify the two levels at which you can use automatic schema recognition, describe
when to use automatic schema recognition, explain how columns are mapped based on
the level at which you use automatic schema recognition, and describe the heuristics
Architect uses to recognize columns.
In previous lessons, you learned how to manually create facts and attributes. However,
the Architect graphical interface also provides automatic schema recognition, which you
can use to automatically create facts and attributes in a project.
Automatic schema recognition enables Architect to evaluate the columns in a project
table, determine the types of objects they represent (fact, attribute, or attribute form),
and then create those objects or map the columns to existing objects. You can then verify
that columns are mapped to the appropriate objects (new or existing) and that those
objects are correctly defined.
Automatic schema recognition is available at the following levels:
Project levelYou enable automatic schema recognition as the default setting for the
project in Architect. When you add a table to a project, Architect automatically maps
any columns it recognizes to existing facts, attributes, or attribute forms, or it creates
new objects to which they are mapped. It also shows the preview of objects that are
being created and enables you to choose the objects you want in the project.
Project table levelYou can choose to use automatic schema recognition for
selected project tables to identify and map facts, attributes and attribute forms, or
both. When you use the automatic schema recognition function for a table, Architect
automatically maps any columns it recognizes to existing facts, attributes, or attribute
forms, or it creates new objects to which they are mapped. It also shows the preview
of objects that are being created and enables you to choose the objects you want in the
project.
When to Use Automatic Schema Recognition

Automatic schema recognition can be a very efficient means of creating facts and
attributes if your project environment is conducive to its use. The usefulness of this
function directly correlates to the characteristics of your project tables and columns.
359
10
Automatic schema recognition is optimal if the following conditions are true in your
project environment:
All or most of your column names are homogeneous across project tables.
The same column names in different project tables always reference the same fact or
attribute.
Columns are defined in a manner that enables Architect to correctly determine in

most instances what type of objects should map to the columns.
considers column names, data types, and primary and foreign key
Architect
designations, so all these characteristics are important.
You should use automatic schema recognition at the project level if you want to define
columns automatically in every project table.
You should use automatic schema recognition at the project table level if you want more
control over which tables and columns use automatic schema recognition.
Using automatic schema recognition may be problematic if any of the following
conditions are true in your project environment:
Many project tables contain columns that you do not want to define.
Many of your column names are heterogeneous across project tables.
The same column names in different project tables do not always reference the same
fact or attribute.
If your project has these characteristics, it does not mean that you cannot use automatic
schema recognition. However, it does mean that using automatic schema recognition
increases the likelihood of the following outcomes:
Columns that you do not want to use are mapped to facts or attributes.
Facts or attributes are mapped to incorrect columns.
Facts or attributes that you do not need in the project are created.
What Columns Are Mapped with Automatic Schema

Recognition?
The columns that are mapped in project tables depend on the level at which you use
automatic schema recognition.
360 Overview of Automatic Schema Recognition
10
If you are using automatic schema recognition at the project level, every column that
Architect can recognize in every table is mapped as a fact, attribute, or attribute form.
If you are using automatic schema recognition at the project table level for facts, every
column that Architect can recognize as a fact is mapped. If you are using automatic
schema recognition at the project table level for attributes, every column that Architect
can recognize as an attribute or attribute form is mapped. If you are using automatic
schema recognition at the project table level for facts and attributes, every column in the
table that Architect can recognize is mapped as a fact, attribute, or attribute form.
Heuristics for Automatic Schema Recognition

Whether you enable automatic schema recognition at the project level or only use it at
the project table level, the process maps table columns based on a set of heuristics. These
heuristics consist of the following elements:
Previous usage of columns in a project
Primary and foreign key columns
Column naming rules (suffixes)
Column data types
Content of project tables
Architect applies these heuristics to determine whether columns are facts, attributes, or
attribute forms.
Architect applies these heuristics in the order they are listed above.
The following topics describe each of these elements in more detail.
Previous Usage of Columns in a Project

The first criterion Architect applies is to check how a column has already been used in a
project. If a column has already been mapped as an expression for an existing fact or an
attribute form, Architect maps the column to the existing object.
does not automatically map columns to fact and attribute form
Architect
expressions that use the Manual mapping method.
361
10
Primary and Foreign Key Columns

The second criterion Architect applies is to check if a column is part of the primary or
foreign key for a table. If a column is designated as a primary or foreign key on the table,
Architect determines it to be an attribute. Architect uses the column names of primary
keys to determine attribute names.
For example, if you have a column called Region_ID that is a primary key on the
LU_Region table, Architect recognizes this column as an attribute and uses Region as
the primary part of the attribute name. It keeps, replaces, or removes the ID suffix
based on how you have configured this suffix in the Architect settings.
information on configuring attribute and attribute form suffixes, see Column
For
Naming Rules (Suffixes) starting on page 363.
uses this heuristic to evaluate whether columns are attributes. It does
Architect
not use this heuristic to evaluate whether columns are facts.
If you have heterogeneous column names where the column name used to reference an
attribute differs in various tables, Architect always uses the primary key column name,
not the foreign key column names. For example, consider the following scenario:
Heterogeneous Column Names for Region Attribute
The LU_REGION table contains the REGION_ID column. This column is the primary
key for the table that references the Region attribute. The LU_STATE table contains the
REG_ID column. This column is a foreign key for the table that also references the
Region attribute. In this example, the primary and foreign key column names differ, but
Architect uses Region as the attribute name because this name is used for the primary
key.
bases the attribute name on the primary key column name even if the
Architect
table that contains the primary key is not part of the project. Architect checks the
database system catalog to determine the primary and foreign key column names
for an attribute, so it is aware of the primary key column name even if you do not
use the corresponding table.
10
Column Naming Rules (Suffixes)

The third criterion Architect applies is to compare a column name to the column naming
rules (suffixes) that you provide within the Architect settings. The following image shows
where you access the column naming rules within the Architect settings:
MicroStrategy Architect SettingsAccessing Column Naming Rules
The following image shows the options for configuring column naming rules:
Column Naming Rules
363
10
The following table describes each of these 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.
Form format
In addition to naming rules, you can automatically define or

recognize attribute form format.
more information on advanced settings for automatic column recognition,

For
refer to the Project Design Guide product manual.
Column Data Types

The fourth criterion Architect applies is to check the data type of a column to determine
whether a column should be mapped to a fact or attribute. Architect recognizes columns
with the following data types as attributes:
Date
Time
TimeStamp
Architect recognizes columns with the following data types as facts:
Binary
Decimal
Double
Float
Integer
Numeric
Real
Unsigned
10
Architect looks at the data type in conjunction with other heuristics to ultimately
determine which columns are facts versus attributes.
For more information, refer to the Project Design Guide product manual.
Content of Project Tables
The last criterion Architect applies is to check the content of a project table. If Architect
cannot recognize a column in a table using criteria from the other heuristics and the table
does not have a single attribute, it considers the column an attribute.
Architect cannot recognize a column after applying all these heuristics, the
Ifcolumn
is not mapped to any object.
365
10
Using Automatic Schema Recognition

Create facts and attributes in the Architect graphical interface using automatic schema
recognition.
Now that you understand how automatic schema recognition works, you can create facts
and attributes in the Architect graphical interface using automatic schema recognition.
As you already learned, there are two levels at which you can use automatic schema
recognition. You can enable it at the project level if you want to automatically create
facts and attributes as you add tables to a project. You can also use it at the project table
level to automatically create facts and attributes for selected tables. The following topics
describe these two methods.
Creating Facts and Attributes for All Project Tables

If your project environment permits, you can automatically create facts and attributes as
you add tables to a project. This method enables you to quickly create the associated
objects for all project tables. To use this method, you have to enable automatic schema
recognition:
To enable automatic schema recognition for all project tables:
automatic schema recognition is enabled when you first open a project

Byin thedefault,
1 In Developer, open the project for which you want to enable automatic schema
recognition.
2 On the Schema menu, select Architect.
click Auto Recognize.
5 Click Advanced Options.
366 Using Automatic Schema Recognition
10
6 In the Advanced Options window, configure the naming rules for your project.
7 Click OK to close the Advanced Option window.
8 Click OK to close the Automatic Schema Recognition window.
The following images shows the setting for enabling automatic schema recognition:
Automatic Schema Recognition Window
After you enable automatic schema recognition, when you add a table to a project,
Architect automatically maps the columns it can recognize to existing facts, attributes, or
attribute forms, or it creates new objects based on those columns.
367
10
When you are adding tables to the project, the Result Preview window shows you the
attributes and facts that are being created by the Architect. You can select only those
attributes, attribute forms, and facts that are required in your project, as shown below:
Result Preview Window
For example, consider the following fact table:

Fact TableNo Columns Mapped
10
It contains both fact and attribute columns, but none of them are mapped to objects.
When you add this fact table to a project, Architect automatically maps the columns it
can recognize as shown in the following image:
Fact TableFacts and Attributes Mapped
In this case, Architect is able to recognize each column in the table as follows:
Attribute columns are mapped to an existing attributeMonth.
The other attribute columns are mapped to a new attributes created by

ArchitectCust State and Subcat.
automatically assigned the STATE_SUBCATEG_MNTH_SLS table
Architect
as a lookup table for these new attributes.
Fact columns are mapped to an existing factsRevenue, Cost, and Units Sold.
The other fact column is mapped to a new fact created by ArchitectGross Dollar
Sales.
It is important to verify that columns are mapped correctly. You can modify the facts and
attributes if you need to make changes.
For example, in this case, you would probably want to modify some of the object names
to be more user friendly. Also, you may want to remove any facts or attributes that you do
not want to use in the project.
Object Naming with Automatic Schema Recognition

When you use automatic schema recognition, Architect considers column names and
naming rules (for attributes and attribute forms) in determining the names it gives to
objects it creates.
369
10
Even without automatic schema recognition enabled, the naming behavior of the
Architect is similar. Architect automatically assigns names to the objects you create. You
can rename these objects as appropriate.
Creating Facts and Attributes for Selected Project Tables

Sometimes, your project environment may not be conducive to using automatic schema
recognition for all project tables, but you may be able to use it for selected project tables.
You can choose to automatically create facts, attributes, or both objects for a specific
project table or a group of selected project tables. To use this method, you have to disable
automatic schema recognition in the Architect settings.
To disable automatic schema recognition for all project tables:
1 In Developer, open the project for which you want to disable automatic schema
recognition.
2 In Developer, on the Schema menu, select Architect.
3 In Architect graphical interface, on the Design tab, in the Auto Recognize section,
click the arrow button.
click Do not auto recognize.
5 Click OK.
10
The following image shows the setting for disabling automatic schema recognition:
Setting for Disabling Automatic Schema Recognition
After you disable automatic schema recognition, when you add a table to a project,
Architect does not map its columns. Instead, you either map its columns manually, or
you can choose to use automatic schema recognition at the project level to map its
columns. You can decide which method to use on a table-by-table basis.
information on creating facts manually, see Creating Facts Manually
For
starting on page 220. For information on creating attributes manually, see
Creating Attributes Manually starting on page 271.
You can use automatic schema recognition on a single project table. You can also
multiselect individual project tables or use the Select All Tables option to apply
automatic schema recognition to multiple tables at one time.
multiselect individual table or use the Select All Tables option, you need
Iftoyou
right-click an empty area inside the Project Tables View tab to access the
automatic schema recognition options.
371
10
To use automatic schema recognition for a single project table:
1 In the Architect graphical interface, on the Project Tables View tab, do one of the
following:
If you want to automatically map attributes, right-click the project table, point to
Recognize, and select Attributes.
This actions maps both attributes and attribute forms.

OR
If you want to automatically map facts, right-click the project table, point to
Recognize, and select Facts.
OR
If you want to automatically map attributes and facts, right-click the project table,
point to Recognize, and select Both.
The following image shows the option for using automatic schema recognition for a
single project table:
Using Automatic Schema Recognition for a Single Project Table
10
For example, consider the following fact table:

Fact TableNo Columns Mapped
It contains both fact and attribute columns. If you disable automatic schema recognition
at the project level, you can choose to map these columns using automatic schema
recognition at the project table level, or you can manually map the columns.
this example, automatic column mapping is also disabled in the Architect
For
settings. Otherwise, columns in the table that are already used for existing facts
and attributes would be automatically mapped to those objects.
If you use automatic schema recognition to map only the facts, Architect automatically
maps the fact columns it can recognize as shown in the following image:
Fact TableFacts Mapped
image above, the table displays used columns to make it easier to see how
Inthethecolumns
are mapped to facts.
In this case, Architect is able to recognize all the fact columns in the table and maps them
to existing factsCost, Gross Total Sales, Revenue, and Units Sold.
The CUST_STATE_ID, REGION_ID, and MONTH_ID columns remain unmapped
since Architect does not recognize these attribute columns as facts.
373
10
If you use automatic schema recognition on this same fact table to map only the
attributes, Architect automatically maps the attribute columns it can recognize as shown
in the following image:
Fact TableAttributes Mapped
image above, the table displays used columns to make it easier to see how
Inthethecolumns
are mapped to attributes.
In this case, Architect is able to recognize all the attribute columns in the table and maps
them to existing attributesCust State, Month, and Region.
The TOT_DOLLAR_SALES, TOT_UNIT_SALES, TOT_COST, and
GROSS_DOLLAR_SALES columns remain unmapped since Architect does not
recognize these fact columns as attributes.
automatic schema recognition on this same fact table to map both the
Iffactsyouanduseattributes,
Architect automatically maps the columns it can recognize.
No matter which recognition option you choose, you can modify any facts or attributes
that are created if you need to make changes.
Automatic Relationship Recognition

You can have Architect automatically create attribute relationships. You can enable
relationship recognition at the project level in the Architect settings.
Architect recognizes relationships for all attributes you have created based on the rules
you select. You can choose to automatically create attribute relationships based on the
primary and foreign keys of tables, attribute columns in lookup tables, or sample data
from lookup tables.
10
When you are using automatic relationship recognition, verify all the relationships
Architect creates. If you are using automatic relationship recognition to create
relationships in your project, it does increase the likelihood of the following outcomes:
Relationships that you do not want to use in the project are created.
Relationships mapped incorrectly.
Only few attribute relationships are recognized.
You have to carefully consider the physical structure of you data warehouse and your
knowledge of the data warehouse model before using automatic relationship recognition.
To configure automatic relationship recognition in the Automatic Schema Recognition
window:
default, relationship recognition is enabled when you first open a project in the
ByArchitect
2 In the Automatic Schema Recognition window, under Recognize Relationships, click
Automatically create relations in System Hierarchy.
3 Click Advanced Options.
4 In the Advanced Options window, select the check boxes for the rules you want to use
to recognize relationships.
5 Click OK.
6 In the Automatic Schema Recognition window, click OK.
375
10
The following image shows the setting for enabling relationship recognition at the project
level:
Setting for Enabling Relationship Recognition at the Project Level
The following image shows the Advanced Options window with the rules you can use to
automatically recognize relationships:
Advanced Options WindowRules for Relationship Recognition
10
After you enable relationship recognition, you can create the attributes in your project.
Then, you can click the Hierarchy View tab for Architect to create the attribute
relationships. The Result Preview window displays the list of potential parent-child
relationships. You can select the relationships that you want to create and click OK. The
relationships that are created automatically display on the Hierarchy View tab.
You can automatically create attribute relationships at any time while working on your
project by clicking the Recognize Relationships button:
You can disable automatic relationship recognition at the project level any time while
working in the project. You can then use the Recognize Relationships button on
as-needed basis to automatically detect relationships on the Hierarchy View tab.
377
10
Lesson Summary
You can use automatic schema recognition to have Architect automatically create the
facts and attributes in a project.
If you enable automatic schema recognition at the project level, when you add a new
table to a project, Architect maps any column it recognizes to a fact, attribute, or
attribute form.
If you enable automatic schema recognition at the project table level, you can choose
to use automatic schema recognition for selected project tables to identify and map
facts, attributes and attribute forms, or both.
Automatic schema recognition is optimal if the following conditions are true in your
project environment: all or most column names are homogeneous across project
tables, the same column names in different project tables always reference the same
fact or attribute, and columns are defined in a manner that enables Architect to
correctly determine in most instances what types of objects should map to the
columns.
Using automatic schema recognition may be problematic if any of the following

conditions are true in your project environment: many project tables contain columns
you do not want to define, many column names are heterogeneous across project
tables, or the same column names in different project tables do not always reference
the same fact or attribute.
The heuristics Architect uses to automatically recognize columns consist of the

following elements: previous usage of columns in a project, primary and foreign key
columns, column naming rules (suffixes), column data types, and content of project
tables.
The first criterion Architect applies is to check how a column is already used in a
project. It maps previously used columns to the same facts or attributes.
The second criterion Architect applies is to check if a column is part of the primary or
foreign key for a table. It recognizes such columns as attributes.
The third criterion Architect applies is to compare a column name to the column
naming rules (suffixes) you provide in the Architect settings. Any suffixes you provide
automatically identify columns with corresponding suffixes as either attributes or
attribute forms.
378 Lesson Summary
10
Column naming rules have three components: the separator, attribute naming rule,
and attribute form naming rule.
The fourth criterion Architect applies is to check the data type of a column to
determine whether it should be mapped to a fact or an attribute.
The last criterion Architect applies is to check the content of a project table. If
Architect cannot recognize a column using other heuristics and the table does not
have a single attribute, it considers the column an attribute.
If you want to use automatic schema recognition at the project level, you enable
automatic schema recognition in the Architect settings and configure the naming
rules for the project.
If you want to use automatic schema recognition at the project table level, you
configure the naming rules for the project and disable automatic schema recognition
in the Architect settings. You can then choose to use automatic schema recognition on
a table-by-table basis.
Architect recognizes relationships for all attributes you have created based on the
rules you select. You can choose to automatically create attribute relationships based
on the primary and foreign keys of tables, attribute columns in lookup tables, or
sample data from lookup tables.
You can disable automatic relationship recognition at the project level any time while
working in the project. You can then use the Recognize Relationships button on
as-needed basis to automatically detect relationships on the Hierarchy View tab.
Lesson Summary
379
10
380 Lesson Summary
10

Exercises: Automatic Schema Recognition
In this set of exercises, you will add more tables to the My Demo project and use
automatic schema mapping to map their columns to new or existing facts and attributes.
Using Table-Level Automatic Schema Recognition

Overview
In this exercise, you will use the Architect graphical interface to use an existing table and
add a new lookup table in the My Demo project and use automatic schema recognition to
map some of its columns to create new attributes.
Lookup Table Name

LU_EMPLOYEE
LU_MANAGER
First, add the LU_MANAGER table to the project and perform the following task:
Use automatic schema recognition at the project table level to recognize attributes
and observe how the Manager attribute is created.
Next, locate the LU_EMPLOYEE table in the project and perform the following tasks:
Use automatic schema recognition at the project table level to recognize attributes
and observe how the Hire Date and Employee Birthday attributes are created.
do not need to create any additional attributes that map to the other
You
columns in the LU_EMPLOYEE table.
After you have completed these tasks, save and update project schema.
After saving your project work, answer the follow-up questions at the end of the detailed
instructions for this exercise.
381
10
instructions for any tasks not related to automatic schema recognition are
The
written at a higher level to better test your understanding.
3 On the Home tab, in the layers drop-down list, select the Geography layer.
Add the LU_MANAGER table to the project
4 In the Warehouse Tables pane, in the Tutorial Data database instance tables list,
right-click LU_MANAGER and select Add Table to Project.
5 In the MicroStrategy Architect window, click OK.
Create the Manager attribute
6 In the Geography layer, right-click the header of the LU_MANAGER table, point to
Recognize and select Attributes.
7 In the Result Preview window, clear the Device check box.
Keep the Manager check box selected.
8 Click OK.
Locate the LU_EMPLOYEE table in the project
9 In the Warehouse Tables pane, right-click the LU_EMPLOYEE table and select Show
Element.
382 Exercises: Automatic Schema Recognition
10
The logical view of the LU_EMPLOYEE table should look like the following:
image above shows the table with the available columns and attribute
The
forms displayed. Notice that the Manager attribute is already mapped to this
table because automatic column mapping is enabled for the project.
Create the Birth Date and Hire Date attributes
10 Right-click the header of the LU_EMPLOYEE table, point to Recognize and select
Attributes.
11 In the Result Preview window, click OK.
383
10
The logical view of the LU_EMPLOYEE table should resemble the following image:
10

Customer-Related Schema Objects
Overview
In this exercise, you will use the Architect graphical interface to add lookup tables to the
My Demo project to build customer-related schema objects.
First, you need to enable automatic schema recognition at the project level.
Next, you need to create the Customer layer. Add the following tables to the Customer
layer and observe how their columns are mapped:
Customer Attributes
Source Tables
Column Name
Attribute Name
LU_CUSTOMER
CUSTOMER_ID
Customer
LU_CUSTOMER
CUST_BIRTHDATE
Customer
Birthday
LU_CUST_CITY
CUST_CITY_ID
Customer City
LU_CUST_REGION
CUST_REGION_ID
Customer Region
LU_CUST_STATE
CUST_STATE_ID
Customer State
LU_EDUCATION
EDUCATION_ID
Education
LU_GENDER
GENDER_ID
Gender
LU_INCOME
INCOME_ID
Income
LU_PYMT_TYPE
PYMT_TYPE
Payment Type
LU_SHIPPER
SHIPPER_ID
Shipper
ORDER_DETAIL
ORDER_ID
Order
ORDER_FACT
SHIP_DATE
Ship Date
After you have added these tables to the project, rename attributes to match the names
listed in the table above.
385
10
After you have renamed the attributes in the project, complete the following tasks:
Add attribute forms for the Customer attribute as shown in the following table:
Attribute
Forms
Expressions
Source Tables
Use as
Report
Form
Use as
Browse
Form
Customer
DESC
CUST_LAST_NAME + , +
CUST_FIRST_NAME
LU_CUSTOMER
Yes
Yes
First Name
CUST_FIRST_NAME
LU_CUSTOMER
No
No
Last Name
CUST_LAST_NAME
LU_CUSTOMER
No
No
Address
ADDRESS
LU_CUSTOMER
No
Yes
Email
EMAIL
LU_CUSTOMER
No
Yes
Manually create relationships for the attributes as shown in the following table:
relationships should be defined on the Hierarchy View tab in the Architect

All
graphical interface. 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.
Attribute Name
Child Attribute
Customer
Order
Customer Birth Date
Customer
Customer City
Customer
Customer Region
Customer State
Customer State
Customer City
Education
Customer
Customer Birth Date
Customer
Gender
Customer
Income
Customer
Payment Type
Order
Ship Date
Order
Shipper
Order
Hire Date
Employee
10
Attribute Name
Child Attribute
Birth Date
Employee
Manager
Call Center (1:1)
Hire Date, Birth Date, and Manager attributes belong to the Geography
The
hierarchy. However, for simplicity, you will define their relationships while
defining customer-related attribute relationships.
After you have completed these tasks, save your project work and keep the project open
in the Architect graphical interface.
Configure automatic schema recognition at the project level


click Auto Recognize.
4 Click OK.
387
10
Add the Customer tables to the project

7 In the MicroStrategy Architect, in the box, type Customer as the layer name.
8 Click OK.
9 In the Warehouse Tables pane, select the following tables from the Tutorial Data
database instance and add them to the Customer layer in the project:
Lookup Tables
LU_CUST_CITY
LU_CUST_REGION
LU_CUST_STATE
LU_CUSTOMER
LU_EDUCATION
LU_GENDER
LU_INCOME
LU_PYMT_TYPE
LU_SHIPPER
ORDER_DETAIL and ORDER_FACT tables have already been added to

The
the project in the earlier exercises. You will find instructions to create the
Order and the Ship Date attributes later in this exercise.
10 In the Result Preview window, on the Attribute tab, keep only the following attributes
selected:
Clear check boxes for all other attributes.

Attribute Name
Customer
Customer Birth Date
Customer City
Customer Region
10
Attribute Name
Customer State
Education
Gender
Income
Payment Type
Shipper
attribute names in the Result Preview window differ from the table above.
The
You will rename these attributes later in this exercise.
11 Click the Fact tab.
12 On the Fact tab, clear all the facts.
13 Click OK.
Rename the attributes
14 Rename the attributes that do not match the names listed in the table above.
Create the description form for the Customer attribute
15 On the Project Tables View tab, select the LU_CUSTOMER table.

16 In the LU_CUSTOMER table, create a new attribute form for the Customer attribute
with the following form expression:
CUST_LAST_NAME + ", " + CUST_FIRST_NAME
17 Keep Automatic mapping method selected and click OK.
Define the report display and browse forms for the Customer attribute
18 In the LU_CUSTOMER table, select the Customer attribute, if not already selected.
19 In the Properties pane, under Form 2: DESC, ensure that the Use as Browse Form
and Use as Report Form properties are set to True.
20 Click Save.
389
10
Create the Order and Ship Date attributes
21 On the Home tab, in the Layer section, in the layers drop-down list, select the Fact
Tables layer.
22 In the ORDER_DETAIL table, use the ORDER_ID column to create the Order
attribute.
23 In the ORDER_FACT table, use the SHIP_DATE column to create the Ship Date
attribute.
Create attribute relationships

25 On the Hierarchy View tab, in the System Hierarchy View, click the Customer
attribute and drag the mouse pointer towards Order attribute.
26 Right-click the Customer attribute and select Edit Children Relations.
27 In the Children Relations window, for the Order attribute, in the Relationship type
drop-down list, make sure the One to Many relationship type is selected.
28 Click OK.
29 Repeat steps 25 to 28 to create relationships for all the other customer-related
attributes on the Hierarchy View tab:
Attribute Name
Child Attribute
Customer Birth Date
Customer
Customer City
Customer
Customer Region
Customer State
Customer State
Customer City
Education
Customer
Gender
Customer
Income
Customer
Payment Type
Order
Ship Date
Order
Shipper
Order
Hire Date
Employee
10
Attribute Name
Child Attribute
Birth Date
Employee
Manager
Call Center (1:1)
attributes while defining relationships. On the Home tab, in the Auto

Arrange
Arrange Hierarchy Layout section, click Regular.
Hire Date, Birth Date, and Manager attributes belong to the Geography
The
hierarchy. However, for simplicity, you define their relationships while
defining customer-related attribute relationships.
30 On the Home tab, click Save and Update Schema to update the project schema and
keep the project open in the Architect graphical interface.

Product-Related Schema Objects
Overview
In this exercise, you will use the Architect graphical interface to add lookup table to the
My Demo project to build product-related schema objects.
You need to ensure automatic schema recognition is enabled. Next, you need to create
the Product layer. Add the following tables to the Product layer and observe how their
columns are mapped:
Product Attributes
Source Tables
Column Name
Attribute Name
LU_BRAND
BRAND_ID
Brand
LU_CATALOG
CAT_ID
Catalog
LU_CATEGORY
CATEGORY_ID
Category
LU_ITEM
ITEM_ID
Item
391
10
Product Attributes
Source Tables
Column Name
Attribute Name
LU_SUBCATEG
SUBCAT_ID
Subcategory
LU_SUPPLIER
SUPPLIER_ID
Supplier
LU_ITEM
WARRANTY_ID
Warranty
REL_CAT_ITEM
After you have added these tables to the project, rename attributes to match the names
listed in the table above.
After you have renamed the attributes in the project, complete the following tasks:
Add attribute forms for attributes as shown in the following table:
Attribute
Forms
Expressions
Source Tables
Use as
Report
Form
Use as
Browse
Form
Item
Long DESC
ITEM_LONG_DESC
LU_ITEM
No
Yes
DESC
ITEM_NAME
LU_ITEM
Yes
Yes
Brand
DESC
BRAND_DESC
LU_BRAND
Yes
Yes
Catalog
DESC
CAT_DESC
LU_CATALOG
Yes
Yes
Category
DESC
CATEGORY_DESC
LU_CATEGORY
Yes
Yes
Subcategory
DESC
SUBCAT_DESC
LU_SUBCATEGORY
Yes
Yes
Supplier
DESC
SUPPLIER_NAME
LU_SUPPLIER
Yes
Yes
Manually create relationships for the attributes as shown in the following table:
relationships are one to many unless another type of relationship is indicated

All
in the table. Many-to-many relationships are indicated as M:M.
Attribute Name
Child Attribute
Brand
Item
Catalog
Item (M:M)
Category
Subcategory
Subcategory
Item
10
Attribute Name
Child Attribute
Supplier
Item
Warranty
Item
After you have completed these tasks, save and update project schema.
Configure automatic schema recognition at the project level

ensure the Auto Recognize option is selected.
4 Click OK.
Add the Product tables to the project
5 Click the Project Tables View tab.

8 In the MicroStrategy Architect box, type Product as the layer name.
9 In the Warehouse Tables pane, select the following tables from the Tutorial Data
database instance and add them to the Product layer in the project:
Lookup Tables
LU_BRAND
LU_CATALOG
LU_CATEGORY
393
10
Lookup Tables
LU_ITEM
LU_SUBCATEG
LU_SUPPLIER
REL_CAT_ITEM
10 In the Result Preview window, on the Attribute tab, keep only the following attributes
selected:
the check boxes for the Disc Code attribute, the None:ITEM_URL
Clear
attribute form for the Item attribute, and the None:CAT_URL attribute form
for the Catalog attribute.
Attribute Name
Brand
Catalog
Category
Item
Subcategory
Supplier
Warranty attribute is not automatically recognized by Architect. You will

The
create it later in the exercise.
attribute names in the Result Preview window differ from the table above.
The
You will rename these attributes later in this exercise.
11 Click the Fact tab.
12 On the Fact tab, clear all the facts.
13 Click OK.
Rename the attributes
14 Rename the attributes that do not match the names listed in the table above.
10
Create the Warranty attribute
15 In the LU_ITEM table, use the WARRANTY column to create the Warranty attribute.
Create the Long DESC form for the Item attribute
16 In the LU_ITEM table, create a new attribute form for the Item attribute with the
ITEM_LONG_DESC
DESC) to Long DESC.
Define the browse and report display forms for the Item attribute
19 In the LU_ITEM table, select the Item attribute, if not already selected.
20 In the Properties pane, under Form 3: Long DESC, ensure that the Use as Browse
Form property is set to True.
21 Modify the Use as Report Form property to False.
do not need to modify the browse and report display properties for the
You
remaining attributes because by default they are set to True.
22 Save and update the project schema.
Create attribute relationship for the product-related attributes

24 On the Hierarchy View tab, in the System Hierarchy View, click the Brand attribute
and drag the mouse pointer towards the Item attribute.
25 Right-click the Brand attribute and select Edit Children Relations.
26 In the Children Relations window, for the Item attribute, in the Relationship type
drop-down list, make sure the One to Many relationship type is selected.
395
10
27 Repeat steps 24 to 26 for the remaining attributes as defined in the table below:
Attribute Name
Child Attribute
Catalog
Item (M:M)
Category
Subcategory
Subcategory
Item
Supplier
Item
Warranty
Item
10
Creating Customer and Product User Hierarchies

OverviewCustomer User Hierarchy
In this exercise, you will use the Architect graphical interface to create the Customer
user hierarchy for the customer-related attributes in the My Demo Project. The following
table shows which attributes to include in the user hierarchy and how to define them:
Customer 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 City
Yes
Unlocked
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 Customer user hierarchy for drilling as well as browsing.
Detailed InstructionsCustomer User Hierarchy

Create the Customer user hierarchy
1 On the Home tab, in the hierarchies drop-down list, select System Hierarchy View,
if not already selected.
397
10
Add attributes to the Customers user hierarchy
2 On the Hierarchy View tab, using a mouse pointer, draw a rectangle that
encompasses the following attributes and their relationships:
The following tables lists all attributes in the Customer hierarchy:

Attribute
Customer
Customer Birth Date
Customer City
Customer Region
Customer State
10
Attribute
Education
Gender
Income
Order
Payment Type
Ship Date
Shipper
3 On the Home tab, click New Hierarchy.

4 In the MicroStrategy Architect window, in the box, type Customer.
5 Click OK.
Define additional browse attributes for the Customer hierarchy
6 In the Customer user hierarchy, using a mouse pointer, draw a line from the
Customer Region attribute to the Customer City attribute.
7 Using a mouse pointer, draw a line from the Customer State attribute to the
Customer attribute.
8 On the Home tab, click Regular to rearrange the attributes.
Set the entry points for the Customer user hierarchy
9 In the Customer user hierarchy, right-click the Customer Region attribute and select
Set As Entry Point.
10 Configure all remaining attributes in the Customer hierarchy as entry points except
for the Order attribute.
Set the element display for the Customer user hierarchy
11 In the Customer user hierarchy, right-click the Customer attribute, point to Element
Display, and select Limit.
12 In the Limit window, in the Limit box, type 100.
13 Click OK.
399
10
14 Repeat steps 11 to 13 for the Customer Birth Date and Ship Date attributes.
15 Right-click the Order attribute, point to Element Display, and select Locked.
do not need to perform any action on the remaining attributes since the
You
element display by default is unlocked.
Configure the Customer user hierarchy for drilling
16 In the Customer user hierarchy, click an empty area to deselect any attributes you
may have selected.
17 Right-click an empty area and select Use As a Drill Hierarchy.
18 On the Home tab, click Save and Update Schema.

The Customer user hierarchy should resemble the image below:
10
OverviewProduct User Hierarchy

In this exercise, you will use the Architect graphical interface to create a Product user
hierarchy for the product-related attributes in the My Demo Project. The following table
shows which attributes to include in the user hierarchy and how to define them:
Product User Hierarchy

Attributes
Browse Attributes
Entry Point
Element Display
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 Product user hierarchy for drilling as well as browsing.
After you have created this user hierarchy, save and update the project schema.
Detailed InstructionsProduct User Hierarchy

you have practiced creating several different user hierarchies using
Since
step-by-step instructions, these instructions are written at a higher level to help
better test your understanding.
Select the attributes and relationships for the Product user hierarchy
1 On the Home tab, in the hierarchies drop-down list, select System Hierarchy View.
401
10
2 On the Hierarchy View tab, using a mouse pointer, draw a rectangle that
encompasses the following attributes and their relationships:
The following tables lists all attributes in the Product hierarchy:

Attribute
Brand
Catalog
Category
Item
Subcategory
Supplier
Warranty
3 On the Home tab, click New Hierarchy.

4 In the MicroStrategy Architect window, in the box, type Product.
5 Click OK.
10
Define additional browse attributes for the Product hierarchy
6 In the Product user hierarchy, using a mouse pointer, draw a line from the Category
attribute to the Item attribute.
7 On the Home tab, click Regular to rearrange the attributes.
Set the entry points for the Product user hierarchy
8 In the Product user hierarchy, configure all attributes as entry points except for the
Catalog attribute.
Set the element display for the Product user hierarchy
9 In the Product user hierarchy, right-click the Item attribute, point to Element
Display, and select Limit.
10 In the Limit window, in the limit box, type 50.
11 Click OK.
Configure the Product user hierarchy for drilling
12 In the Product user hierarchy, click an empty area to deselect any attributes you may
have selected.
13 Right-click an empty area and select Use As a Drill Hierarchy.
The Product user hierarchy should resemble the image below:
403
10
14 Click Save and Close to update the project schema and exit Architect.
Save the hierarchies in the Data Explorer folder
15 In Developer, browse to the Schema Objects\Hierarchies folder and drag the

Customer and Product hierarchies to the Data Explorer folder to make them
available for browsing.
hierarchies do not display in the Schema Objects\Hierarchies folder
The
unless you save and update schema. You may have to refresh Developer
display to view them. To refresh Developer display, browse to the Hierarchies

folder and press F5. To view the hierarchies in the Data Explorer for the
project, in the Folder List, right-click Data Explorer - My Demo Project and
select Refresh.
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 Demo 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.
The Metric Editor can be found in the File menu, under New.
10
After you have created these metrics, you will use the Report Editor to create the
following report in the My Demo Project:
You should save the report as Product Sales Analysis in the Public Objects\Reports
folder.
The Report Editor can be found in the File menu, under New.
Run the report. The result set should look like the following:
405
10
In the report, drill down on the Art & Architecture subcategory to the Item attribute.
The result set should look like the following:
After you view the report results, close all the reports.
Create the Revenue metric
1 In MicroStrategy Developer, in the File menu, point to New and select Metric.
2 In the New Metric window, select Empty Metric and click OK.
3 In the Metric Editor, on the Formula tab, in the Definition box, create the following
metric definition:
Sum(Revenue)
4 Format the metric values as currency with no decimal places.
Save and close the Revenue metric
5 Save the metric as Revenue in the Public Objects\Metrics folder.

6 Close the Metric Editor.
10
Create the Units Sold metric
1 In MicroStrategy Developer, in the File menu, point to New and select Metric.
2 In the New Metric window, select Empty Metric and click OK.
3 In the Metric Editor, on the Formula tab, in the Definition box, create the following
metric definition:
Sum(Units Sold)
do not need to format this metric. Its value format defaults to a fixed
You
number with no decimal places, which is the format you need to use.
Save and close the Units Sold metric
4 Save the metric as Units Sold in the Public Objects\Metrics folder.

5 Close the Metric Editor.
Create the Product Sales Analysis report
1 In MicroStrategy Developer, in the File menu, point to New and select Report.
2 In the New Report window, select Blank Report and click OK.
3 In the Report Editor, create the report as described at the beginning of this exercise.
Save and run the Product Sales Analysis report
4 Save the report as Product Sales Analysis in the Public Objects\Reports folder.
5 Run the report.
6 Compare your results to the expected result set in the Overview section at the
beginning of this exercise.
Drill to Item on the Product Sales Analysis report
7 In the Product Sales Analysis report, drill down on the Art & Architecture
subcategory to the Item attribute.
8 Compare your results to the expected result set in the Overview section at the
beginning of this exercise.
407
10
Close all reports
9 Close all open reports.
You do not need to save the drill report.
A
MICROSTRATEGY TUTORIAL
Appendix Description
This appendix provides information on the MicroStrategy Tutorial project, including the
data model and physical warehouse schema.
409
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 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:
1 In Developer, log in to the project source that 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.
can rearrange the attributes by dragging and dropping them. Rearranging
You
attributes does not affect the browse order, but it enables you to view the
hierarchy in a way that is meaningful to you.
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
410 The MicroStrategy Tutorial Data Model
Time
Products
Geography Hierarchy
411
Customers Hierarchy
Time Hierarchy
413
Products Hierarchy
The MicroStrategy Tutorial Schema

A schema is a logical and physical definition of warehouse data elements, physical
characteristics, and interrelationships.
For 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.
To view the MicroStrategy Tutorial schema:
1 In Developer, log in to the project source that 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 joinsEnables you to select whether to connect the tables to represent the
joins between the warehouse tables
Use circular joinsEnables you to select whether to use circular joins
Show column data typesEnables you to select whether to show the data type
and size for each column
Show table prefixesEnables 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.
415
5 To change display preferences for the logical view, on the Options menu, select any of
the following options:
Show joinsEnables you to select whether to connect the tables to represent the
joins between the table columns
Use circular joinsEnables you to select whether to use circular joins
Show relationshipsEnables you to select whether to map the relationships
between the tables
Show relationship typesEnables you to select whether to differentiate between
one-to-one, one-to-many, many-to-one, and many-to-many relationships
Show columnsEnables 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.
can rearrange the tables by dragging and dropping them. Rearranging the
You
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
416 The MicroStrategy Tutorial Schema
Geography Schema
417
Customers Schema
Time Schema
419
Products Schema
Fact Tables Schema
Partition Mapping Table
421
B
OTHER METHODS FOR
CREATING SCHEMA OBJECTS
Appendix Description
This appendix provides information on alternative methods for creating schema objects
using Project Creation Assistant and editors. It also defines the sort order for user
hierarchies using the Hierarchy Editor.
423
Other Methods for Creating Schema Objects
Project Creation Assistant and Editors

You first create a project object in Project Creation Assistant. Then, you can use the
combination of wizards and editors as an alternative way for creating schema objects.
Creating schema objects using Project Creation Assistant involves the following steps:
1 Select the project tables using the Warehouse Catalog: In this interface, you first
select the database instance associated with the project, and then select the tables.
2 Create facts: Fact Creation wizard helps you create facts. Before you create a fact you
have to define the fact creation rules. For information see the MicroStrategy Project
Design Help.
3 Create attributes: Attribute Creation wizard enables you to create multiple attributes
very quickly. However, you are limited to creating basic attributes using this tool. In
this wizard, you define the creation rules, create ID, description forms, select lookup
tables, create attribute relationships, and create compound attributes. You can use
Attribute Editor to create more complex attributes. For more information see
MicroStrategy Project Design Help.
4 Create user hierarchies: You can 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.
In MicroStrategy, the following Project Creation Assistant wizards and editors could be
used as alternative ways to create a project:
Warehouse Catalog
Fact Creation Wizard
Fact Editor
Attribute Creation Wizard
Attribute Editor
Hierarchy Editor
424 Project Creation Assistant and Editors
The following image shows an example of Warehouse Catalog with select lookup and fact
tables added to a project:
Warehouse CatalogLookup and Fact Tables Added to Project
The following image shows an example of Fact Creation Wizard with selected facts
created in a project:
Fact Creation WizardFacts Created in Project
425
The following image shows an example of Fact Editor with a simple expression for the
Gross Revenue fact:
Fact EditorSimple Expression
The following image shows an example of Attribute Creation Wizard with selected
attributes created in a project:
Attribute Creation WizardAttributes Created in Project
The following image shows an example of Attribute Creation Wizard with the correct
description forms selected for each attribute:
Attribute Creation WizardDescription Forms Selected
427
The following image shows an example of Attribute Creation Wizard with the correct
lookup tables selected for each attribute:
Attribute Creation WizardLookup Tables Selected
The following image shows an example of Attribute Creation Wizard with the
relationships created for an attribute:
Attribute Creation WizardRelationships Created
The following image shows an example of Attribute Creation Wizard with a compound
attribute created:
Attribute Creation WizardCompound Attribute Created
429
The following image shows an example of Attribute Editor:

Attribute Editor
The following image shows an example of Display tab on the Attribute Editor. It is useful
to define the Report and Browse elements of attribute:
Attribute EditorDisplay Tab
431
The following image shows an example of Hierarchy Editor with Time user hierarchy,
which includes the Year, Quarter, Month, and Day attributes:
Time User Hierarchy
Defining the Sort Order for User Hierarchies

When you create user hierarchies, you can define the sort order used to display their
attributes. You cannot define the sort order in Architect graphical interface. You can
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.
sort order you define for browsing also applies to hierarchy prompts since
The
these objects are based on browsing user hierarchies.
To define the sort order for a browsing user hierarchy:
1 In Developer, 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.
433
you clear the project-level setting, the order of the attributes in the
After
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.
closing the Hierarchy Editor, you can update the project schema if
After
desired.
The following image shows the sort order setting for browsing user hierarchies in the
Project Configuration Editor:
Project Configuration EditorSort Order Setting for Browsing User Hierarchies
434 Defining the Sort Order for User Hierarchies
The following image shows the Select Objects window with a customized sort order for
the attributes in the Time user hierarchy of My Tutorial project:
Select Objects WindowCustomized Sort Order for Attributes
The attributes in the Time user hierarchy are ordered from highest to lowest rather than
alphabetically.
435
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 ExplorerCustomized Sort Order for Attributes
above, the Day attribute does not display because it is not an entry
Inpointtheforimage
the user hierarchy.
may need to refresh the user hierarchy in the Data Explorer browser to see
You
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.
you configure a user hierarchy for both browsing and drilling, you can only
Ifdefine
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 Developer, 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.
default, this check box is not selected, so you may not need to change this
Bysetting.
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.
you clear the project-level setting, the order of the attributes in the
After
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.
closing the Hierarchy Editor, you can update the project schema if
After
desired.
437
The following image shows the sort order setting for drilling user hierarchies in the
Project Configuration Editor:
Project Configuration EditorSort 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 WindowCustomized 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 ReportCustomized Sort Order for Attributes
439
INDEX
A
accessing the Architect graphical
interface 140
adding attributes to user hierarchies,
Architect 332
aggregate fact tables 80
All Project Tables layer 147
Architect and browsing 34
Architect and drilling 31
Architect and physical schema 72
Architect and reporting 30
Architect and the logical data model 44
Architect graphical interface 125
Architect graphical interface components,
overview 142
Architect graphical interface settings,
overview 165
Architect graphical interface,
accessing 140
Architect graphical interface, Hierarchy
View tab 153
Architect graphical interface,
introduction 139
Architect graphical interface, menu
bar 158
Architect graphical interface, Project ob-
jects pane 158

Architect graphical interface, Project Tables View tab 147
Architect graphical interface, Properties
pane 155
Architect graphical interface, saving project work 163
Architect graphical interface, toolbar 159
Architect graphical interface, undo and
redo actions 164
Architect graphical interface, Warehouse
Tables pane 143
Architect settings, automatic column
mapping 172
Architect settings, automatic column
recognition 172
Architect settings, default view 166
Architect settings, loading the Warehouse
Catalog 166
Architect settings, physical or logical table
view 170
Architect settings, project table link
display 170
Architect settings, relationship
recognition 165, 173
Architect settings, schema update 167
Architect, attribute 259
441
Index
Architect, attribute form 262

Architect, automatic heuristic
settings 170
Architect, basic schema objects 28
Architect, configuration settings 166
Architect, creating schema objects 28
Architect, display settings 168
Architect, fact 211
Architect, overview 25
Architect, populating the metadata 26
Architect, roles 30
Architect, user hierarchy 325
architecture, MicroStrategy business
intelligence 26
attribute columns, reusing in
Architect 284
attribute creation methods, Architect 270
Attribute Creation Wizard 270
attribute creation, automatic 270
attribute elements, logical data model 51
attribute filters, user hierarchy 341
attribute form expression 267
attribute form expressions, derived 268
attribute form expressions, simple 268
attribute form expressions, types 267
attribute form suffixes 363
attribute form, MicroStrategy
Architect 262
attribute forms 50
attribute forms, Architect 285
attribute forms, browsing 297
attribute forms, modifying in
Architect 290
attribute forms, report display 297
attribute modification, modifying column
aliases 297
attribute relationship creation methods,
Architect 300
attribute relationship creation,
442
automatic 301
attribute relationship recognition, Architect settings 165, 173
attribute relationships, creating manually
in Architect 300
attribute relationships, direct 52
attribute relationships, indirect 53
attribute relationships, logical data
model 52
attribute relationships, manual
creation 300
attribute relationships, many to many 53
attribute relationships, one to many 53
attribute relationships, one to one 53
attribute relationships, Project Tables
View tab 150
attribute suffixes 363
attribute, MicroStrategy Architect 259
attributes 28
attributes and attribute forms, logical data
model 50
attributes in an ERD 50
attributes, adding to user hierarchies 332
attributes, automatic column
mapping 281
attributes, compound 265
attributes, creating automatically for all
project tables 366
attributes, creating automatically for selected project tables 370
attributes, creating manually in
Architect 271
attributes, heterogeneous 266
attributes, homogeneous 266
attributes, logical data model 48
attributes, manual creation 270
attributes, types 265
automatic attribute creation 270
automatic attribute relationship
creation 301
automatic column mapping, Architect

settings 172
automatic column mapping,
attributes 281
automatic column mapping, facts 228
automatic column recognition 359
automatic column recognition, Architect
settings 172
automatic column recognition, column
mapping 360
automatic column recognition, enabling
for all project tables 366
automatic column recognition,
heuristics 361
automatic column recognition, levels 359
automatic column recognition, object
naming 369
automatic column recognition, optimal
project environment 359
automatic column recognition,
overview 359
automatic column recognition, using in
Architect 366
automatic column recognition, when to
use 359
automatic column, disabling for all project
tables 370
automatic fact creation 219
automatic heuristic settings,
Architect 170
automatically creating attributes, all project tables 366
automatically creating attributes, selected
project tables 370
automatically creating facts, all project
tables 366
automatically creating facts, selected project tables 370
available tables, Warehouse Tables
pane 144
Index
B
base fact tables 80
basic schema objects 28
browse attributes, user hierarchies 333
browse forms 297
browsing and MicroStrategy Architect 34
browsing sort order, user hierarchy 433
business intelligence architecture 26
C
changing display properties for project tables, Architect 193
color mapping, Warehouse Tables
pane 145
column alias, facts 238
column data types, heuristics 364
column mapping, automatic column
recognition 360
column naming rules, heuristics 363
column types, physical schema 73
columns, description 73
columns, fact 73
columns, ID 73
columns, physical schema 73
columns, reusing in Architect 232, 284
completely denormalized schema 84
completely denormalized schemas, higher-level lookup tables 85
completely normalized schema 82
components, Architect graphical
interface 142
components, logical data model 47
components, physical schema 73
components, Project Creation
Assistant 123
compound attributes 265
compound key, physical schema 74
configuration settings, Architect 166
443
Index
Configuration Wizard, creating the metadata shell 105

configuring a user hierarchy for drilling,
Hierarchy Editor 346, 349
configuring project connectivity 110, 129
configuring the project metadata 101
Connectivity Configuration Wizard, creating the metadata DSN 102
content of project tables, heuristics 365
copying images, Project Tables View
tab 151
course organization 39
creating a data warehouse schema 89
creating a data warehouse schema, data
volume 90
creating a data warehouse schema, database maintenance 91
creating a data warehouse schema, factors
to consider 89
creating a data warehouse schema, query
performance 90
creating a data warehouse schema, user reporting requirements 90
creating a database instance 114
creating a database instance, Database Instances manager 114
creating a logical data model 57
creating a logical data model, determine
direct attribute relationships 63
creating a logical data model, existing
source data 58
creating a logical data model, factors to
consider 57
creating a logical data model, identify
attributes 63
creating a logical data model, identify
facts 62
creating a logical data model, list information from the source data 61
creating a logical data model, organize
hierarchies 64
444
creating a logical data model, steps 60

creating a logical data model, technical and
performance considerations 59
creating a logical data model, user reporting requirements 57
creating a project source 111
creating a project source, Project Source
Manager 111
creating a project, overview 101
creating attribute forms, Architect 285
creating attribute relationships manually,
Architect 300
creating attributes automatically, all project tables 366
creating attributes automatically, selected
project tables 370
creating attributes manually,
Architect 271
creating attributes, using layers in
Architect 270
creating derived fact expressions, Fact
Editor 228
creating facts automatically, all project
tables 366
creating facts automatically, selected project tables 370
creating facts manually, Architect 220
creating heterogeneous facts, Fact
Editor 231
creating layers, Architect 183
creating projects, interfaces 122
creating schema objects 28, 119
creating the metadata database 102
creating the metadata DSN 102
creating the metadata DSN, MicroStrategy
Connectivity Configuration
Wizard 102
creating the metadata DSN, ODBC Data
Source Administrator 103
creating the metadata shell 105
creating the metadata shell, MicroStrategy
Configuration Wizard 105

creating the project in MicroStrategy Architect, overview 37
creating the project object 124
creating user hierarchy objects,
Architect 331
custom layer 148
D
data model, logical 43
data types of columns, heuristics 364
data volume, creating a data warehouse
schema 90
data warehouse schema, creating 89
data warehouse schema, data volume 90
data warehouse schema, database
maintenance 91
data warehouse schema, query
performance 90
data warehouse schema, user reporting
requirements 90
database connection 114
database instance 114
database instance, creating 114
Database Instances manager, creating a
database instance 114
database instances, color mapping 145
database maintenance, creating a data
warehouse schema 91
default view, Architect settings 166
defining attribute filters, Hierarchy
Editor 341
defining the sort order for browsing, user
hierarchy 433
defining the sort order for drilling, user
hierarchy 436
defining the sort order, user
hierarchy 346, 349
defining user hierarchy elements,
Architect 333
Index
denormalization 81
denormalized schema 81
derived attribute form expressions 268
derived fact expressions 217
derived fact expressions, creating in the
Fact Editor 228
description columns, physical schema 73
designing the data warehouse schema,
overview 37
designing the logical data model,
overview 36
determine direct attribute relationships,
creating a logical data model 63
dimensions, logical data model 54
direct attribute relationships 52
direct attribute relationships, many to
many 53
direct attribute relationships, one to
many 53
direct attribute relationships, one to
one 53
direct mode, project source 111
disabling automatic column recognition
for all project tables 370
display properties for project tables,
changing in Architect 193
display settings, Architect 168
drilling and MicroStrategy Architect 31
drilling on a user hierarchy 346, 349
drilling sort order, user hierarchy 436
DSN, metadata 102
E
editors, schema objects 125
element display, limit 337
element display, locked 337
element display, unlocked 337
element display, user hierarchies 337
enabling automatic column recognition for
445
Index
all project tables 366

entity 50
entry points, user hierarchies 336
existing source data, creating a logical data
model 58
exporting images, Project Tables View
tab 151
expression, fact 216
F
fact columns, physical schema 73
fact columns, reusing in Architect 232
fact creation methods, Architect 219
Fact Creation Wizard 219
fact creation, automatic 219
Fact Editor, creating derived fact
expressions 228
Fact Editor, creating heterogeneous
facts 231
Fact Editor, modifying facts 234
fact expression 216
fact expressions, derived 217
fact expressions, simple 216
fact expressions, types 216
fact modification, Fact Editor 234
fact table level 79
fact tables, aggregate 80
fact tables, base 80
fact tables, physical schema 79
fact, MicroStrategy Architect 211
factors to consider in creating a data warehouse schema 89
factors to consider in creating a logical data
model 57
facts 28
facts, automatic column mapping 228
facts, column alias 238
facts, creating automatically for all project
tables 366
446
facts, creating automatically for selected

project tables 370
facts, creating manually in Architect 220
facts, heterogeneous 215
facts, homogeneous 214
facts, logical data model 47
facts, manual creation 219
facts, types 214
facts, viewing and modifying properties in
Architect 244
finding and selecting project tables in Architect, Show Element option 197
foreign and primary key columns,
heuristics 362
foreign key, physical schema 77
form expressions, attributes 267
form expressions, types 267
form, attribute 262
forms, attributes 285
H
heterogeneous attributes 266
heterogeneous facts 215
heterogeneous facts, creating in the Fact
Editor 231
heuristics, automatic column
recognition 361
heuristics, column data types 364
heuristics, column naming rules 363
heuristics, content of project tables 365
heuristics, previous usage of columns in a
project 361
heuristics, primary and foreign key
columns 362
heuristics, suffixes 363
hiding the Properties pane 157
hiding the Warehouse Tables pane 146
hierarchies 28
hierarchies, logical data model 54
Hierarchy Editor 330

Hierarchy Editor, configuring a user hierarchy for drilling 346, 349
Hierarchy Editor, defining attribute
filters 341
Hierarchy View tab, Architect graphical
interface 153
hierarchy, system 308, 311
hierarchy, user 325
higher-level lookup tables, completely denormalized schemas 85
homogeneous attributes 266
homogeneous facts 214
I
ID columns, physical schema 73
identify attributes, creating a logical data
model 63
identify facts, creating a logical data
model 62
indirect attribute relationships 53
interfaces, project creation 122
introduction, Architect graphical
interface 139
introduction, logical data modeling 43
introduction, physical schemas 71
K
key, compound 74
key, foreign 77
key, primary 74
key, simple 74
keys, tables 74
L
layer, All Project Tables 147
layer, custom 148
Index
layers, creating attributes in Architect 270

layers, creating in Architect 183
layers, modifying in Architect 186
layers, Project Tables View tab 147
layers, removing in Architect 188
level, fact table 79
levels, automatic column recognition 359
limit, element display 337
link display, Architect settings 170
links between project tables, Project Tables
View tab 149
list information from the source data, creating a logical data model 61
loading the Warehouse Catalog, Architect
settings 166
locked element display 337
logical data model 43
logical data model and MicroStrategy
Architect 44
logical data model components 47
logical data model, attribute elements 51
logical data model, attribute
relationships 52
logical data model, attributes 48
logical data model, attributes and attribute
forms 50
logical data model, creating 57
logical data model, dimensions 54
logical data model, example 44
logical data model, existing source data 58
logical data model, facts 47
logical data model, hierarchies 54
logical data model, steps to creating 60
logical data model, technical and performance considerations 59
logical data model, user reporting
requirements 57
logical data modeling, introduction 43
logical table 177
447
Index
Logical Table Editor 183

logical tables versus physical tables 177
lookup tables, physical schema 76
M
managing the project schema,
overview 38
manual attribute creation 270
manual attribute relationship
creation 300
manual fact creation 219
manually creating attribute relationships,
Architect 300
manually creating attributes,
Architect 271
manually creating facts, Architect 220
many-to-many attribute relationships 53
many-to-many relationships, relationship
tables 78
menu bar, Architect graphical
interface 158
metadata 26
metadata database, creating 102
metadata DSN, creating 102
metadata shell 101
metadata shell, creating 105
metadata shell, MicroStrategy Configuration Wizard 105
metadata, configuration 101
metadata, populating 26
methods, attribute creation in
Architect 270
methods, attribute relationship creation in
Architect 300
methods, fact creation in Architect 219
MicroStrategy Architect and browsing 34
MicroStrategy Architect and drilling 31
MicroStrategy Architect and physical
schema 72
448
MicroStrategy Architect and reporting 30

MicroStrategy Architect and the logical
data model 44
MicroStrategy Architect, attribute 259
MicroStrategy Architect, attribute
form 262
MicroStrategy Architect, creating schema
objects 28
MicroStrategy Architect, fact 211
MicroStrategy Architect, overview 25
MicroStrategy Architect, populating the
metadata 26
MicroStrategy Architect, roles 30
MicroStrategy Architect, user
hierarchy 325
MicroStrategy business intelligence
architecture 26
MicroStrategy Configuration Wizard, creating the metadata shell 105
MicroStrategy Connectivity Configuration
Wizard, creating the metadata
DSN 102
moderately denormalized schema 83
modifying attribute forms, Architect 290
modifying attributes, modifying column
aliases 297
modifying column aliases, modifying
attributes 297
modifying facts in Architect, using the
Project Tables View tab 234
modifying facts in Architect, using the
Properties pane 242
modifying facts, Fact Editor 234
modifying layers, Architect 186
modifying properties for facts,
Architect 244
N
naming objects, automatic column
recognition 369
naming rules, heuristics 363

normalization 81
normalized schema 81
O
object naming, automatic column
recognition 369
ODBC Data Source Administrator, creating the metadata DSN 103
one-to-many attribute relationships 53
one-to-many relationships, relationship
tables 77
one-to-one attribute relationships 53
one-to-one relationships, relationship
tables 77
organization, course 39
organize hierarchies, creating a logical
data model 64
overview, Architect graphical interface
components 142
overview, Architect graphical interface
settings 165
overview, creating the project in MicroStrategy Architect 37
overview, designing the data warehouse
schema 37
overview, designing the logical data
model 36
overview, managing the project
schema 38
overview, MicroStrategy Architect 25
overview, project creation 101
overview, project design process 36
P
performance considerations, creating a
physical or logical table view, Architect
settings 170
Index
physical schema 71
physical schema and MicroStrategy
Architect 72
physical schema components 73
physical schema, column types 73
physical schema, columns 73
physical schema, compound key 74
physical schema, creating 89
physical schema, description columns 73
physical schema, fact columns 73
physical schema, fact tables 79
physical schema, foreign key 77
physical schema, ID columns 73
physical schema, lookup tables 76
physical schema, primary key 74
physical schema, relationship tables 76
physical schema, simple key 74
physical schema, table keys 74
physical schemas, introduction 71
physical tables versus logical tables 177
populating the metadata 26
previous usage of columns in a project,
heuristics 361
primary and foreign key columns,
heuristics 362
primary key, physical schema 74
profile, query 90
project connectivity, configuration 110,
129
project connectivity, illustration 118
Project Creation Assistant 122
Project Creation Assistant,
components 123
project creation interfaces 122
project creation workflow 119
project creation, overview 101
project design process, creating the project
in MicroStrategy Architect 37
project design process, designing the data
449
Index
warehouse schema 37
project design process, designing the logical data model 36
project design process, managing the project schema 38
project design process, overview 36
project metadata, configuration 101
project object, creating 124
Project objects pane, Architect graphical
interface 158
project schema 119
project schema, updating 119
project source 111
project source creation, Project Source
Manager 111
Project Source Manager, creating a project
source 111
project source, creating 111
project source, direct mode 111
project source, server mode 111
project table 177
project table display properties, changing
in Architect 193
project table display, Architect
settings 170
project table link display, Architect
settings 170
Project Tables View tab, Architect graphical interface 147
Project Tables View Tab, exporting and
copying images 151
Project Tables View tab, layers 147
Project Tables View tab, modifying facts in
Architect 234
Project Tables View tab, viewing links between project tables 149
Project Tables View tab, viewing relationships between attributes 150
project tables, creating layers in
Architect 183
450
project tables, finding and selecting in Architect using the Show Element
option 197
project tables, modifying layers in
Architect 186
project tables, removing layers in
Architect 188
Properties pane, Architect graphical
interface 155
Properties pane, modifying facts in
Architect 242
Properties pane, showing or hiding 157
Properties pane, viewing objects 155, 157
properties, facts 244
Q
query performance, creating a data warehouse schema 90
query profile 90
R
redo actions, Architect graphical
interface 164
relationship creation methods,
Architect 300
relationship creation, automatic 301
relationship recognition, Architect
settings 165, 173
relationship tables, many-to-many
relationships 78
relationship tables, one-to-many
relationships 77
relationship tables, one-to-one
relationships 77
relationship tables, physical schema 76
relationships between attributes, Project
Tables View tab 150
relationships, creating manually in
Architect 300
relationships, manual creation 300

removing layers, Architect 188
removing tables from a project, Warehouse
Catalog 183
report display forms 297
reporting and MicroStrategy Architect 30
reporting requirements, creating a data
warehouse schema 90
reporting requirements, creating a logical
data model 57
reusing attribute columns, Architect 284
reusing fact columns, Architect 232
roles, MicroStrategy Architect 30
S
saving project work, Architect graphical
interface 163
schema object editors 125
schema objects 28
schema objects, basic 28
schema objects, creating 28, 119
schema types, physical schema types 81
schema types, summary 88
schema update, Architect settings 167
schema, completely denormalized 84
schema, completely normalized 82
schema, denormalized 81
schema, moderately denormalized 83
schema, normalized 81
schema, physical 71
schema, project 119
schema, star 86
selected tables, Warehouse Tables
pane 144
server mode, project source 111
settings overview, Architect graphical
interface 165
shell, metadata 101
Index
Show Element option, finding and selecting project tables in Architect 197
showing the Properties pane 157
showing the Warehouse Tables pane 146
simple attribute form expressions 268
simple fact expressions 216
simple key, physical schema 74
sort order, user hierarchy 346, 349
source data, creating a logical data
model 58
star schema 86
steps to creating a logical data model 60
structure of a logical data model, logical
data model structure 55
suffixes, attributes and attribute
forms 363
suffixes, heuristics 363
summary of schema types 88
system hierarchy 35, 308, 311
T
table keys, physical schema 74
table, logical 177
table, project 177
tables 28
tables, creating layers in Architect 183
tables, fact 79
tables, lookup 76
tables, modifying layers in Architect 186
tables, relationship 76
tables, removing from a project 183
tables, removing layers in Architect 188
technical considerations, creating a logical
data model 59
three-tier mode, project source 111
toolbar, Architect graphical interface 159
two-tier mode, project source 111
types of attribute form expressions 267
451
Index
types of attributes 265

types of fact expressions 216
types of facts 214
U
undo actions, Architect graphical
interface 164
unlocked element display 337
updating the project schema 119
updating the schema, Architect
settings 167
used columns, Warehouse Tables
pane 144
user hierarchies 35
user hierarchies, adding attributes in
Architect 332
user hierarchies, defining browse
attributes 333
user hierarchies, setting entry points 336
user hierarchies, setting the element
display 337
user hierarchy elements, defining in
Architect 333
user hierarchy objects, creating in
Architect 331
user hierarchy, attribute filters 341
user hierarchy, defining the sort
order 346, 349
user hierarchy, defining the sort order for
browsing 433
user hierarchy, defining the sort order for
drilling 436
user hierarchy, drilling 346, 349
user hierarchy, MicroStrategy
Architect 325
user reporting requirements, creating a
data warehouse schema 90
user reporting requirements, creating a
using automatic column recognition,
452
Architect 366
using the Attribute Creation Wizard 270
using the Fact Creation Wizard 219
using the Hierarchy Editor 330
using the Logical Table Editor 183
V
viewing information for project tables,
Logical Table Editor 183
viewing links between project tables, Project Tables View tab 149
viewing objects, Properties pane 155, 157
viewing properties for facts, Architect 244
viewing relationships between attributes,
Project Tables View tab 150
volume of data, creating a data warehouse
schema 90
W
Warehouse Catalog load, Architect
settings 166
Warehouse Catalog, removing tables from
a project 183
Warehouse Tables pane, Architect graphical interface 143
Warehouse Tables pane, available
tables 144
Warehouse Tables pane, color
mapping 145
Warehouse Tables pane, selected
tables 144
Warehouse Tables pane, showing or
hiding 146
Warehouse Tables pane, used
columns 144
workflow, project creation 119

Microstrategy 2 PDF

Uploaded by

Document Information

Original Description:

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

Microstrategy 2 PDF

Uploaded by

Copyright:

Available Formats

MICROSTRATEGY ARCHITECT: PROJECT DESIGN ESSENTIALS

20002014 MicroStrategy, Incorporated. All rights reserved.

All Contents Copyright 2014 MicroStrategy Incorporated. All Rights Reserved.

MicroStrategy, MicroStrategy 6, MicroStrategy 7, MicroStrategy 7i, MicroStrategy 7i Evaluation Edition,

Lesson Description ................................................................... 23

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Designing the Data Warehouse Schema............................... 37

2. Designing the Logical

Lesson Description ................................................................... 41

3. Designing the Data

Lesson Description ................................................................... 69

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Creating a Data Warehouse Schema .......................................... 89

Lesson Description ................................................................... 99

Lesson Description ................................................................. 137

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Defining Architect Settings......................................................... 165

6. Working with Tables

Lesson Description ................................................................. 175

7. Working with Facts

Lesson Description ................................................................. 209

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Modifying Facts.......................................................................... 234

Lesson Description ................................................................. 257

9. Working with User

Lesson Description ................................................................. 323

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Defining User Hierarchy Elements....................................... 333

10. Automatic Schema

Lesson Description ................................................................. 357

A. MicroStrategy Tutorial Appendix Description.............................................................. 409

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

B. Other Methods for

Appendix Description.............................................................. 423

Index ......................................................................................... 441

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

2014 MicroStrategy Inc.

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Who Should Take This Course

MicroStrategy Developer: Reporting Essentials

MicroStrategy Architect: Advanced Project Design

MicroStrategy Advanced Data Warehousing

Certified Project Designer

14 Who Should Take This Course

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Explain the tasks involved in creating a project in MicroStrategy Architect,

Describe how attributes and attribute forms are used in a MicroStrategy

Describe how user hierarchies are used in a MicroStrategy project, create

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials

Describe how automatic schema recognition works and create facts,

2014 MicroStrategy Inc.

MicroStrategy Architect: Project Design Essentials