Professional Documents
Culture Documents
Course Guide
Version: PRJESS-941-Mar14-Color
Copyright Information
Trademark Information
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
Table of Contents
Table of Contents
4. Creating a Project in
MicroStrategy
Architect
5. Introduction to the
Architect Graphical
Interface
Table of Contents
Table of Contents
8. Working with
Attributes
Table of Contents
10
Table of Contents
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
Project architects
Course Prerequisites
Before starting this course, you should know all topics covered in the following
course:
Follow-Up Courses
After taking this course, you might consider taking the following courses:
Related Certifications
To validate your proficiency in the content of this course, you might consider
taking the following certification:
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)
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)
Course Objectives
15
Preface
16 Course Objectives
Preface
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:
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
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
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.
19
Preface
Precedes Exercises
MicroStrategy Courses
Core Courses
Preface
Advanced Courses
*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
Lesson Objectives
After completing this lesson, you will be able to:
Describe how you use MicroStrategy Architect to populate the metadata and
create schema objects; explain how MicroStrategy Architect supports
reporting, drilling, and browsing; and describe the project design process.
After completing the topics in this lesson, you will be able to:
Describe how you use MicroStrategy Architect to populate the metadata and
create various types of schema objects. (Page 25)
Describe the steps involved in the project design process. (Page 36)
24 Lesson Objectives
25
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:
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
29
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
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.
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.
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
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.
Design a logical data model that incorporates the information users want to
see and shows how it is related
Create the data warehouse using this schema design or modify the existing
data warehouse to use this schema design
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:
37
Create the necessary schema objects for the project based on the logical
data model, mapping them to appropriate structures in the data warehouse
schema
Updating the project schema to reflect any changes you make to schema
objects
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:
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 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
After completing this lesson, you will be able to:
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.
After completing the topics in this lesson, you will be able to:
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 factors to consider when designing a logical data model and the
steps you must complete to create a logical data model. (Page 57)
42 Lesson Objectives
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.
define dimensions, so this course uses the term logical data modeling.
43
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.
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.
Facts
Attributes
Hierarchies
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:
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.
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
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
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
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:
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:
53
The following illustration shows examples of the three relation types and how
they are represented in a logical data model:
Attribute Relationships
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.
55
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:
57
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.
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.
59
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.
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
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.
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
In this lesson, you have learned:
A logical data model is a diagram that shows the information you want to
analyze in a project and how that information is related.
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.
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.
Lesson Summary
65
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
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.
67
You need to create the logical data model based on the following requirements:
The logical data model must include everything from the source data.
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.
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
After completing this lesson, you will be able to:
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)
70 Lesson Objectives
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.
71
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.
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.
Fact columnsThese columns store fact data. They are usually numeric.
73
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.
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.
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
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.
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.
77
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
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
After completing this topic, you will be able to:
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.
Schema Types
81
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.
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.
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.
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.
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.
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
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
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
Contains an attributes ID
and description columns
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
Contains an attributes ID
and description columns
as well as the ID and
description columns of all
related higher-level
attributes
Requires
significantly more
storage space and
the greatest degree
of data redundancy
88 Schema Types
Disadvantages
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
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
The structure of your data warehouse schema should take into account the
volume of data you store for each attribute in each hierarchy. Attributes and
hierarchies with greater data volumes are often better candidates for
denormalization, while you can often use a more normalized schema design for
those with lower data volumes. In such cases, joining more tables that contain
less data may be preferable to significantly increasing the size of smaller tables.
Database Maintenance
The structure of your data warehouse schema should take into account the
effort involved in maintaining whatever schema design you choose. Often,
designs that provide greater flexibility in terms of query performance and
detail also require more work to maintain.
In general, the more you denormalize a table, the more you have to do to
maintain the table. Because denormalized schemas store data redundantly,
when changes occur, there are simply more tables and columns to update. You
constantly have to balance the benefits such denormalization provides against
the maintenance burdens it creates.
For example, you may have some tables in a hierarchy that you want to
denormalize for performance reasons. However, you also know that the data in
these tables is very volatile and subject to lots of changes. In considering the
maintenance overhead this will create, you map opt to partially denormalize
the tables.
Another thing to consider with regard to database maintenance is the
complexity of your ETL process for converting data from source system
structures to the structure you are planning for the data warehouse. Because
you use source systems and data warehouses for fundamentally different
purposes, some structural changes are usually necessary to create a schema
that is optimized for analysis. However, the more you have to rekey tables,
combine data from multiple tables, or separate data into multiple tables, the
more complex the conversion becomes. At times, you may need to weigh the
benefits you will realize from these schema changes against the demands of the
ETL work required to create them.
91
Lesson Summary
In this lesson, you have learned:
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.
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.
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.
Lesson Summary
93
94 Lesson Summary
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 currently has 7 regions, 4o districts, and 1500 branches. The logical data
model must include everything from the source data.
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.
The source system contains the following minimum information for each attribute in the
Geography and Account hierarchies:
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
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
Lesson Objectives
After completing this lesson, you will be able to:
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.
After completing the topics in this lesson, you will be able to:
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)
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:
Creating the necessary schema objects using the project creation workflow
101
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.
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
105
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.
You should clear the History List Tables and Statistics Tables check boxes.
5 Click Next.
14 Click Close.
107
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
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:
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 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.
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
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.
2014 MicroStrategy Inc.
117
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.
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.
119
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.
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.
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.
121
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:
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.
The process of creating the initial project files takes a few minutes.
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.
Create facts
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.
2014 MicroStrategy Inc.
125
Lesson Summary
In this lesson, you have learned:
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.
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.
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 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.
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 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.
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.
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.
1 On the Start menu, point to All Programs, point to Microsoft Office, and select
Microsoft Office Access.
Create the empty metadata database
4 Click Browse.
Detailed Instructions
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
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.
Detailed Instructions
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
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.
Detailed Instructions
Open the Project Source Manager
Detailed Instructions
Open the Database Instances manager
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
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.
Detailed Instructions
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
You will continue creating this project in the exercises for subsequent lessons.
2014 MicroStrategy Inc.
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
Lesson Objectives
After completing this lesson, you will be able to:
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.
After completing the topics in this lesson, you will be able to:
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)
Introduction to Architect
After completing this topic, you will be able to:
Describe how you can work with Architect graphical interface and access Architect in
MicroStrategy Developer.
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.
Introduction to Architect
139
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.
Introduction to Architect
141
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
Properties pane
Menu bar
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.
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.
1 On the Home tab, in the Panels section, click Show the Warehouse tables section.
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.
The gray line indicates links to the same attribute in the LU_MONTH, LU_YEAR,
LU_DAY, and LU_QUARTER table.
149
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
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:
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.
5 Click Save.
The following image shows the option for exporting images from the Project Tables View
tab:
Option for Exporting Images
1 On the Project Tables View tab, right-click an empty area and select Copy Diagram
to 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.
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:
155
The following image shows the Properties pane with the information for the Customer
attribute displayed:
Properties PaneCustomer Attribute
1 On Home tab, in the Panels section, click Show the properties section.
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
Close
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.
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
Architect Toolbar
Button
Description
Enables you to display the project tables and
hierarchies using a symmetrical layout
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
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:
163
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.
1 Beside the Undo button, click the arrow and select the final action you want to undo.
1 Beside the Redo button, click the arrow and select the final action you want to redo.
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:
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
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.
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
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.
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
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:
Visible Links
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.
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
Recognize Relationships
171
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.
Recognize Relationships
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
In this lesson, you have learned:
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.
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
Lesson Objectives
After completing this lesson, you will be able to:
Describe how tables are used in a MicroStrategy project and select project tables in the
MicroStrategy Architect graphical interface.
After completing the topics in this lesson, you will be able to:
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
interface. (Page 193)
Use the Show Element option to find project tables in the Architect graphical
interface. (Page 197)
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:
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.
177
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
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.
8 Click OK.
179
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:
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
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
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.
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
To create a 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.
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.
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.
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
185
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.
186 Using Layers for Project 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
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.
1 On the Home tab, in the Layer section, in the drop-down list, select the custom layer.
2 Click Remove Current Layer.
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
Name
Description
Hidden
Location
Database Name
Row Count
189
Property
Description
Definition
Logical Size
Mapped
Attributes
Primary DB
Instance
Secondary DB
Instances
<Attribute Name>
Member
Columns
<Column Name>
On the Tables tab, in the drop-down list, select the table for which you want to
modify properties.
Clicking this Browse button opens a window that enables you to modify the
related property.
191
The following image shows the Properties pane with a project table displayed:
Properties PaneProject Table
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:
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
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
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
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.
197
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.
Lesson Summary
In this lesson, you have learned:
The first task in the project creation workflow is to add tables to a MicroStrategy
project.
The tables you select to use in a project are called project tables. Project tables are the
only tables in the data warehouse that MicroStrategy uses in the reporting
environment.
When you select a physical table from the data warehouse to include in a project,
MicroStrategy Architect automatically creates a corresponding logical table in the
metadata.
Physical tables store the actual data, and the MicroStrategy Engine executes report
SQL against these tables to obtain result sets.
Logical tables store information about their corresponding physical tables, including
table names, column names and data types, and schema objects associated with the
table columns. The MicroStrategy Engine uses these tables to generate the
appropriate report SQL.
You can use the 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.
Lesson Summary
199
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.
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.
After you have added these fact tables, continue to the next exercise to add lookup tables
to the project.
You can use the detailed instructions if you want help.
201
Detailed Instructions
Launch the MicroStrategy Architect for the My Demo Project
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
15 In the Architect graphical interface, click the Project Tables View tab.
16 Click the Home tab.
17 On the Home tab, in the Layer section, click Create New Layer.
18 In the MicroStrategy Architect window, type Fact Tables as the layer name.
19 Click OK.
203
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:
22 On the Home tab, in the Auto Arrange Table Layout section, click Regular to arrange
the tables.
23 Click Save.
a Change Comments window displays, click Do not show this screen in the
Iffuture
and click OK.
After you have added these lookup tables, save and update the project schema.
You can use the detailed instructions if you want help.
Detailed Instructions
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.
205
6 On the Home tab, in the Auto Arrange Table Layout section, click Regular to arrange
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
9 On the Home tab, in the Auto Arrange Table Layout section, click Regular to arrange
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:
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
Lesson Objectives
After completing this lesson, you will be able to:
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.
After completing the topics in this lesson, you will be able to:
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)
What Is a Fact?
After completing this topic, you will be able to:
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:
Project Creation Workflow
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
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.
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
Types of Facts
After completing this topic, you will be able to:
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.
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
Simple
Derived
The following topics describe both of these types of fact expressions in more detail.
The Sales fact maps directly to the Dollar_Sales column in the ITEM_SALES table,
creating a simple fact expression.
Types of Facts
217
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.
Creating Facts
After completing this topic, you will be able to:
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.
Creating Facts
219
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.
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.
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
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
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
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.
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.
2 In the MicroStrategy Architect window, in the box, type a name for the fact.
3 Click OK.
4 In the Create New Fact Expression window, define the fact expression.
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
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.
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
The following image shows the Cost fact displayed in the Properties pane:
Properties PaneCost 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.
2 In the MicroStrategy Architect window, in the box, type a name for the 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.
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
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
1 On the Project Tables View tab, right-click a project table to which you want to map
the fact and select Create Fact.
2 In the MicroStrategy Architect window, in the box, type a name for the fact.
3 Click OK.
4 In the Create New Fact Expression window, define the fact expression.
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
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.
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.
2 In the MicroStrategy Architect window, in the box, type a name for the 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
Modifying Facts
After completing this topic, you will be able to:
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.
Modify a single fact expression for all the tables to which it maps
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.
2 In the Fact Editor, on the Definition tab, click New.
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
4 Click OK.
The following image shows the option for modifying facts from the Project Tables View
tab:
Option for Modifying 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
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.
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.
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
The following image shows the Column Alias tab in the Fact Editor:
Fact EditorColumn Alias Tab
The following image shows the Column Editor - Column Selection window:
Column EditorColumn Selection Window
Modifying Facts
241
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.
The following image shows the Fact Expressions category in the Properties pane:
Fact Expressions Category
Modifying Facts
243
Property
Description
Definition
ID
Name
Description
Hidden
Column Alias
Location
Fact
<Table Name>
Expressions
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:
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
Lesson Summary
In this lesson, you have learned:
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.
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
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.
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.
You can use the detailed instructions if you want help.
Detailed Instructions
Open the My Demo Project in Architect
1 In the My Tutorial Project Source, open the My Demo Project in the Architect
graphical interface.
2014 MicroStrategy Inc.
249
2 In the Architect graphical interface, click the Project Tables View tab.
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
Revenue
UNIT_COST
ORDER_DETAIL
Unit Cost
UNIT_PRICE
ORDER_DETAIL
Unit Price
TOT_UNIT_SALES
Units Sold
11 On the Home tab, in the Save section, click Save and Update Schema.
12 In the Update Schema window, ensure the following check boxes are selected:
13 Click Update.
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
ORDER_DETAIL
ORDER_AMT
ORDER_FACT
QTY_SOLD
ORDER_DETAIL
Revenue
Units Sold
ORDER_FACT
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.
1 On the Project Tables View tab, in any project table that contains the Cost fact,
right-click Cost and select Edit.
2 In the Fact Editor, on the Definition tab, click New.
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
5 Under Mapping method, ensure Automatic is selected.
6 Click OK.
Create the third expression for the Cost fact
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.
1 On the Project Tables View tab, in any project table that contains the Revenue fact,
right-click Revenue and select Edit.
2 In the Fact Editor, on the Definition tab, click New.
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_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
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.
1 On the Project Tables View tab, in any project table that contains the Units Sold fact,
right-click Units Sold and select Edit.
2 In the Fact Editor, on the Definition tab, click New.
253
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
5 Under Mapping method, ensure Automatic is selected.
6 Click OK.
7 In the Fact Editor, click OK.
Save and update the project schema
10 Click Update.
Fact
Expressions
Source Tables
Profit
TOT_DOLLAR_SALES - TOT_COST
CITY_SUBCATEG_SLS
CUSTOMER_SLS
DAY_CTR_SLS
ORDER_DETAIL
ORDER_AMT - ORDER_COST
ORDER_FACT
Detailed Instructions
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.
255
4 In the Create New Fact Expression box, create the following expression:
TOT_DOLLAR_SALES - TOT_COST
5 Under Mapping method, keep Automatic selected.
6 Click OK.
Create the second expression for the Profit fact
13 On the Home tab, in the Save section, click Save and Close.
14 In the Update Schema window, ensure the following check boxes are selected:
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
Lesson Objectives
After completing this lesson, you will be able to:
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.
After completing the topics in this lesson, you will be able to:
Describe how attribute forms are used in a MicroStrategy project. (Page 262)
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)
What Is an Attribute?
After completing this topic, you will be able to:
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:
Project Creation Workflow
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.
What Is an Attribute?
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.
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.
What Is an Attribute?
261
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
Birth date
Gender
Income
In deciding what forms to create for an attribute, you have to consider what users intend
to do with this customer information and whether the unique characteristics of attribute
forms will meet those needs.
First, attribute forms must have a one-to-one relationship with other forms of the same
attribute. For example, if a customer has more than one 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:
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.
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.
Types of Attributes
After completing this topic, you will be able to:
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
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.
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.
Simple
Derived
The following topics describe both of these types of attribute form expressions in more
detail.
Types of Attributes
267
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.
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
After completing this topic, you will be able to:
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.
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
starting on page 423.
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.
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.
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 In the MicroStrategy Architect window, in the box, type a name for the attribute.
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
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.
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 In the MicroStrategy Architect window, in the box, type a name for the attribute.
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.
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
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.
2 In the MicroStrategy Architect window, in the box, type a name for the attribute.
3 In the Create New Form Expression window, define the ID form expression as
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
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.
2 In the MicroStrategy Architect window, in the box, type a name for the attribute.
3 In the Create New Form Expression window, define the ID form expression as
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.
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
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.
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 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.
284 Creating Attributes
You can modify existing attributes in the Architect graphical interface. You can change
any of the following parts of an attribute:
Attribute forms
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.
285
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.
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
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.
For more information, see Modifying Column Aliases starting on page 238.
To modify the column alias for an existing attribute:
293
Property
Description
Definition
ID
Name
Description
Hidden
Location
Apply Security
Filters
Enable
Element
Caching
Property
Description
Form
<Number>:
<Form Name>
<Form Name>
Name
Category
Format
Report Sort
Browse Sort
Use as Browse
Form
Use as Report
Form
Form
<Number>:
<Form Name>
Geographical
Role
Shape File
Column Alias
Supports
Multiple
Languages
Attribute Form
Expressions
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.
On the Attributes tab, in the drop-down list, select the attribute for which you
want to view or modify properties.
Clicking the Browse button opens a window that enables you to modify the
related property.
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.
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
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.
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.
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.
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
You can also remove attribute relationships on the Hierarchy View tab.
305
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.
All attributes and attribute relationships on the Hierarchy View tab comprise the system
hierarchy:
System Hierarchy
307
Lesson Summary
In this lesson, you have learned:
The third task in the project creation workflow is to create the attributes for a
MicroStrategy project and define any direct relationships between attributes.
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.
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.
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.
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.
Exercises: Working with Attributes
In this set of exercises, you will create attributes in the My Demo Project.
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
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
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
Child Attribute
Country
Region
Country
Distribution Center
Distribution Center
Call Center
Employee
Month
Day
Month of Year
Month
Quarter
Month
Region
Call Center
Year
Quarter
After you have created the child relationships for these attributes, save and update the
project schema.
You can use the detailed instructions if you want help.
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.
Detailed Instructions
1 In the My Tutorial Project Source, open the My Demo Project in the Architect
graphical interface.
2 In the Architect graphical interface, click the Project Tables View tab.
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
8 Under Mapping method, ensure Automatic is selected.
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
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.
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.
14 Under Mapping method, ensure Automatic is selected.
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
Country
COUNTRY_NAME
Month
MONTH_DESC
Month of Year
MONTH_OF_YEAR_NAME
Quarter
QUARTER_DESC
Region
REGION_NAME
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
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
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
44 On the Home tab, in the Auto Arrange Hierarchy Layout section, click Regular.
317
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
LU_EMPLOYEE
No
No
LU_EMPLOYEE
No
No
SSN
LU_EMPLOYEE
Yes
No
ORDER_FACT
Employee
DESC
EMP_LAST_NAME + ,
+ EMP_FIRST_NAME
EMP_SSN
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.
319
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
9 Under Mapping method, ensure Automatic is selected.
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.
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
4 Under Mapping method, keep Automatic selected.
5 Click OK.
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
9 Create a new attribute form for the Employee attribute with the following
expression:
EMP_LAST_NAME
10 Use Automatic mapping.
11 In the Properties pane, modify the Name property of the newly created form (Form 4:
None) to Last Name.
Create the SSN form for the Employee attribute
12 Create a new attribute form for the Employee attribute with the following
expression:
EMP_SSN
13 Use Automatic mapping.
14 In the Properties pane, modify the Name property of the newly created form (Form 5:
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.
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
Lesson Objectives
After completing this lesson, you will be able to:
Describe how user hierarchies are used in a MicroStrategy project, create user
hierarchies, and define user hierarchy elements using Architect graphical
interface.
After completing the topics in this lesson, you will be able to:
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:
Project Creation Workflow
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.
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
329
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
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.
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
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:
Geography User Hierarchy
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.
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
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, 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
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:
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, 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
1 On the Home tab, in the hierarchies drop-down list, select the user
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
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
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
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:
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, 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
In this lesson, you have learned:
The final task in the project creation workflow is to create the user
hierarchies for a MicroStrategy project.
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.
Browse attributes are the attributes to which you can directly browse from
any given attribute.
Entry points are the attributes that display when you first open a user
hierarchy. You can begin browsing a user hierarchy from any attribute that
is an entry point.
The element display setting determines the extent to which you can browse
attribute elements.
If an attributes element display is unlocked, you can browse all its elements
at one time.
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
Exercises: Working with User Hierarchies
In this set of exercises, you will first create two user hierarchies in the My Demo Project.
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.
Browse Attributes
Entry Point
Element Display
Call Center
Employee
Yes
Unlocked
Country
Yes
Unlocked
Distribution Center
Call Center
Yes
Unlocked
Employee
None
Yes
Unlocked
Region
Yes
Unlocked
349
After you have created this user hierarchy, save and update the project schema.
You can use the detailed instructions if you want help.
1 In the My Tutorial Project Source, open the My Demo Project in the Architect
graphical interface.
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.
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
Distribution Center
Call Center
Employee
None
Region
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.
2014 MicroStrategy Inc.
351
20 On the Home tab, click Save and Update Schema to update the project schema.
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.
You can use the detailed instructions if you want help.
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
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
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
Lesson Objectives
After completing this lesson, you will be able to:
Describe how automatic schema recognition works and create facts, attributes, and
relationships in the Architect graphical interface using automatic schema recognition.
After completing the topics in this lesson, you will be able to:
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
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.
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.
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.
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 that you do not need in the project are created.
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.
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.
361
10
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
The following image shows the options for configuring column naming rules:
Column Naming Rules
363
10
Description
Separator
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.
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
Date
Time
TimeStamp
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
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.
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
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:
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.
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.
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.
4 In the Automatic Schema Recognition window, under Automatic column recognition,
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
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.
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
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.
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.
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
graphical interface.
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:
Recognize Relationships
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
In this lesson, you have learned:
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.
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.
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
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.
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
Detailed Instructions
instructions for any tasks not related to automatic schema recognition are
The
written at a higher level to better test your understanding.
1 In the My Tutorial Project Source, open the My Demo Project in the Architect
graphical interface.
2 In the Architect graphical interface, click the Project Tables View tab.
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.
8 Click OK.
9 In the Warehouse Tables pane, right-click the LU_EMPLOYEE table and select Show
Element.
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.
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:
12 On the Home tab, click Save and Update Schema to update the project schema.
10
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
LU_CUSTOMER
No
Yes
Manually create relationships for the attributes as shown in the following table:
Attribute Name
Child Attribute
Customer
Order
Customer
Customer City
Customer
Customer Region
Customer State
Customer State
Customer City
Education
Customer
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
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.
You can use the detailed instructions if you want help.
Detailed Instructions
Configure automatic schema recognition at the project level
387
10
Lookup Tables
LU_CUST_CITY
LU_CUST_REGION
LU_CUST_STATE
LU_CUSTOMER
LU_EDUCATION
LU_GENDER
LU_INCOME
LU_PYMT_TYPE
LU_SHIPPER
10 In the Result Preview window, on the Attribute tab, keep only the following attributes
selected:
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
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
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
Child Attribute
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
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 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:
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:
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.
You can use the detailed instructions if you want help.
Detailed Instructions
Configure automatic schema recognition at the project level
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
14 Rename the attributes that do not match the names listed in the table above.
10
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
following expression:
ITEM_LONG_DESC
17 Use Automatic mapping.
18 In the Properties pane, modify the Name property of the newly created form (Form 3:
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
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
28 On the Home tab, click Save and Update Schema to update the project schema.
10
Browse Attributes
Entry Point
Element Display
Customer
Order
Yes
Limit of 100
Customer
Yes
Limit of 100
Customer City
Customer
Yes
Unlocked
Customer Region
Yes
Unlocked
Customer State
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.
You can use the detailed instructions if you want help.
1 On the Home tab, in the hierarchies drop-down list, select System Hierarchy View,
if not already selected.
2014 MicroStrategy Inc.
397
10
2 On the Hierarchy View tab, using a mouse pointer, draw a rectangle that
encompasses the following attributes and their relationships:
10
Attribute
Education
Gender
Income
Order
Payment Type
Ship Date
Shipper
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.
Save and update the project schema
10
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.
You can use the detailed instructions if you want help.
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:
10
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
Metric
Formula
Formatting
Revenue
Sum(Revenue)
Currency, no
decimal places
Units Sold
Sum(Units Sold)
Fixed, no decimal
places
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.
You can use the detailed instructions if you want help.
Detailed Instructions
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
10
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
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
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
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
Time
Products
MicroStrategy Tutorial
Geography Hierarchy
411
MicroStrategy Tutorial
Customers Hierarchy
MicroStrategy Tutorial
Time Hierarchy
413
MicroStrategy Tutorial
Products Hierarchy
MicroStrategy Tutorial
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
MicroStrategy Tutorial
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
MicroStrategy Tutorial
Geography Schema
417
MicroStrategy Tutorial
Customers Schema
MicroStrategy Tutorial
Time Schema
419
MicroStrategy Tutorial
Products Schema
MicroStrategy Tutorial
421
MicroStrategy Tutorial
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
Warehouse Catalog
Fact Editor
Attribute Editor
Hierarchy Editor
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 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
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
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.
different sort orders depending on whether you use it for browsing or drilling, you
must create separate user hierarchies for browsing and drilling.
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-
441
Index
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
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
444
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
2014 MicroStrategy Inc.
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
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
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
2014 MicroStrategy Inc.
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
447
Index
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
N
naming objects, automatic column
recognition 369
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
logical data model 59
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
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
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
logical data model 57
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