Tài liệu Module 4: Building Dimensions Using the Dimension Editor ppt

Contents
Overview 1
Understanding Dimension Basics 2
Shared vs. Private Dimensions 8
Working with Standard Dimensions 11
Basic Level Properties 13
Lab A: Creating a Standard Dimension 24
Lab B: Creating a Snowflake Dimension 28
Working with Parent-Child Dimensions 32
Lab C: Creating a Parent-Child Dimension 38
Review 45

Module 4: Building
Dimensions Using the
Dimension Editor


BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Information in this document is subject to change -without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, the only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, BackOffice, MS-DOS, Windows, Windows NT, <plus other appropriate product
names or titles. Replace this example list with list of trademarks provided by copy editor.
Microsoft is listed first, followed by all other Microsoft trademarks in alphabetical order. > are
either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other
countries.

<This is where mention of specific, contractually obligated to, third party trademarks, which are
added by the Copy Editor>

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

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


Module 4: Building Dimensions Using the Dimension Editor iii

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Instructor Notes
Dimensions are the fundamental beginning point for building an online
analytical processing (OLAP) cube in Microsoft

®
SQL Server
™
2000 Analysis
Services. Cubes contain multiple dimensions, which may be either shared or
private, star or snowflake, regular or parent-child.
In this module, students learn how to build dimensions by using the Dimension
Editor. You dissect the building blocks of dimensions for students in detail.
When they have completed this module, students will feel comfortable with all
aspects of dimension interfaces.
In the labs, students create two dimensions by using the Dimension Editor and
two dimensions by using the Dimension Wizard. Students perform various
dimension enhancements, such as updating the Member Key Column
property, defining sort order, adding levels, and creating member properties.
After completing this module, students will be able to:
!
Understand dimension fundamentals.
!
Know when to use shared and private dimensions.
!
Describe the characteristics of standard dimensions.
!
Add level properties to dimensions.
!
Develop parent-child dimensions.

Materials and Preparation
This section lists the required materials and preparation tasks that you need to
teach this module.
Required Materials

To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file

2074A_04.ppt

Preparation Tasks
To prepare for this module, you should:
!
Read all the student materials.
!
Read the instructor notes and margin notes.
!
Complete the demonstration.
!
Practice the lecture presentation and demonstration.
!
Complete the labs.
!
Review the Trainer Preparation presentation for this module on the Trainer
Materials compact disc.
!
Review any relevant white papers that are located on the Trainer Materials
compact disc.
Presentation:
60 Minutes

Labs:

60 Minutes
iv Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY




Demonstration: Creating a Star Schema Dimension

You can create dimensions quickly and easily by using the Dimension Wizard.
While the Dimension Wizard is a useful tool for many situations, the
Dimension Editor and the Cube Editor are the primary tools for defining and
modifying dimensions.
The following demonstration procedures provide information that will not fit in
the margin notes or are not appropriate for student notes.
!
To create a new database and define a data source
1. Open Analysis Manager and double-click the local server.
2. In Analysis Manager, right-click the local server, click New Database, type
Module 04 in the Database name box, and then click OK.
3. Double-click Module 04 to expand the database.
4. Right-click the Data Sources folder, and then click New Data Source.
5. On the Provider tab of the Data Link Properties dialog box, click
Microsoft OLE DB Provider for SQL Server, and then click Next.
6. Type localhost in the server name box, click Use Windows NT Integrated
security, click Module 04 in the Select the database on the server list, and
then click OK.

!

To create a new dimension
1. In the Module 04 database, right-click the Shared Dimensions folder, point
to New Dimension, and then click Editor.
2. Click State as the dimension table in the Choose a Dimension Table dialog
box, and then click OK.
The left side of the Dimension Editor is divided into two panes. The upper
left pane contains the dimension tree that displays levels as you design the
dimension. The lower left pane contains dimension properties. If you click
the Properties button, the Properties pane disappears or reappears,
depending on whether the pane is showing after you open the Dimension
Editor.
3. In the Properties pane, the current name of the dimension is <New>. Type
State as the name, and then press ENTER.
The name of the dimension appears in the dimension tree.
4. Drag State_Name from the State table in the Schema pane onto the name
of the State dimension in the dimension tree.
This creates a new level in the dimension.
5. Click the State Name level in the dimension tree, type State in the Name
box on the Properties pane, and then press ENTER.
6. Click the Data tab at the bottom of the Schema pane. Double-click All
State and view the members in the State dimension.
7. On the toolbar, click Save, and then close the Dimension Editor.

Demonstration:
5 Minutes
Module 4: Building Dimensions Using the Dimension Editor v

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Other Activities

Difficult Questions
Below are difficult questions that students may ask you during the delivery of
this module and answers to the questions. These materials delve into subjects
that are within the scope of the module but are not specifically addressed in the
content of the student notes.
1. How many dimensions are typically included in cubes?
Normal users cannot digest more than six or seven dimensions in an
OLAP report. For this reason, cube designers restrict the number of
dimensions in cubes based on user comprehension more often than
system limitations. Cubes typically contain four to ten dimensions in
production systems.
2. How does Analysis Services handle data sources for cubes that do not
contain a dimension, because the dimension information is stored in another
system?
You must have all dimension tables and fact tables existing in a single
relational data source before creating dimensions and cubes. If the
dimension exists in a separate system, you can use Data Transformation
Services (DTS) to move the dimension from the other system to the
source database. You must also be sure that the cube fact table contains
keys that map to the dimension table.
3. What options are available for sorting members, other than sorting by the
Member Key Column or the Member Name Column properties?
If neither the Member Key Column nor the Member Name Column of
a dimension provides the correct sort order, you can use a third column
to control the sort order. Simply add that column as a member
property to the level you want to sort. Member properties for a level
automatically appear in the Order by property list. If you build the
dimension by using the Dimension Wizard, it gives you the option to
select any column from the dimension table to define the sort order, and
then the wizard automatically creates the member property for you.

4. What is the best practice for defining members based on expressions?
Use expressions as a last resort for defining members. The best practice
for updating members is to update the data source so that all systems
describe members in the same manner. However, you may have
difficulties updating the source database due to administrative policies
against such a practice or other external issues. Defining expressions in
the Dimension Editor allows you to update members without updating
the source database.
5. How can users view the default member of a dimension?
When you browse the cube in the Cube Browser, the dimensions in the
filter area default to a single member. This member is known as the
default member.

vi Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Module Strategy
Use the following strategy to present this module:
!
Understanding Dimension Basics
Introduce dimensions and the role they play in cube design. Describe how
various user communities define and use dimensions. Define levels and
members and how they relate to each other. Review dimension and level
system limitations.
!
Shared vs. Private Dimensions
Describe shared dimensions, focusing on their characteristics and when to
incorporate them into cubes. Define private dimensions, comparing them to
shared dimensions throughout the discussion. Finish the shared dimension

and private dimension discussion with a summary statement of when to use
each type.
!
Working with Standard Dimensions
Define standard dimensions, focusing on the use of columns to determine
dimension levels. Demonstrate the creation of dimensions by using the
Dimension Editor.
!
Basic Level Properties
Describe the use of Member Key Columns and Member Name Columns
when creating dimensions. Discuss how you sort members in levels based
upon the key or the name. Introduce creating expressions in Member Key
Columns and Member Name Columns to change members. Focus on the
rules for creating valid expressions. Define ragged dimensions and how to
implement them in standard, balanced dimensions. Define snowflake
dimensions and compare them to star schema dimensions. Explain the
importance of the All level and discuss situations when not to use it in a
dimension. Define the default member and describe situations in which to
change it from its original setting.
!
Working with Parent-Child Dimensions
Introduce parent-child dimensions by giving an example of a situation in
which a parent-child dimension is used. Describe the structure of a parent-
child dimension. Explain that parent-child dimensions can have values in
the fact table at both the leaf level and at a parent level. Introduce the
Members with Data property and describe the three values it can have.
Explain that there are different options for displaying the levels in a parent-
child dimension, and finish up with a description of how the Skipped
Levels Column property allows you to create ragged hierarchies in parent-
child dimensions.

Module 4: Building Dimensions Using the Dimension Editor 1

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Overview
!
Understanding Dimension Basics
!
Shared vs. Private Dimensions
!
Working with Standard Dimensions
!
Basic Level Properties
!
Working with Parent-Child Dimensions



Dimensions are the fundamental beginning point for building an online
analytical processing (OLAP) cube in Microsoft
®
SQL Server
™
2000 Analysis
Services. Cubes contain multiple dimensions, which may be either shared or
private, star or snowflake, regular or parent-child.
After completing this module, you will be able to:
!

Understand dimension fundamentals.
!
Know when to use shared and private dimensions.
!
Describe the characteristics of standard dimensions.
!
Add level properties to dimensions.
!
Develop parent-child dimensions.


Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the Dimension Editor
and how to use it to create
and manage dimensions.
2 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


#
##
#

Understanding Dimension Basics

!
Enabling Various Views
!
Understanding Levels and Members
!
Describing Familial Relationships
!
Reviewing Analysis Services Limits


A dimension contains levels and members organized into hierarchies. It
categorizes the numeric measures stored in a cube. A dimension provides users
with a great number of combinations and intersections with which to analyze
data. Each dimension describes an aspect of the users’ business and provides
intuitive and simple access to data. You design and build each dimension based
upon the business processes required by users.
A cube requires that you define at least one dimension in its schema. Each cube
can have up to 128 dimensions, depending on the business needs of the user
community.
In OLAP cubes, dimensions:
!
Provide a descriptive or analytical view of the key measures in the cube,
typically organized around one or more categories relevant to the business.
!
Are shared across multiple cubes that may differ across user communities.
Examples of commonly shared dimensions are geography, product, time,
customer, and scenario.
!
Contain varying degrees of summarization, called levels, by which data is
viewed. The levels, organized into hierarchies, are frequently described as

drill-down paths for the user in search of more specific answers.
Topic Objective
To introduce the concepts of
dimensions, levels, and
members.
Lead-in
A dimension contains levels
and members organized into
hierarchies. It categorizes
the numeric measures
stored in a cube.
Module 4: Building Dimensions Using the Dimension Editor 3

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


Enabling Various Views
Finance
Operations
Profit
by Division
by Country
by Month
by Actual/Budget
Revenue
by Product
by Region
by Sales Rep
by Quarter
Revenue

by Customer
by Industry
by Channel
by Week
Sales
Marketing
Volume
by Plant
by Shift
by Product
by Day
Analysis Server


OLAP cubes answer business questions for summarized data—for example,
what were revenues for all drink products in the northeast region in the second
quarter?
The above illustration shows an Analysis Server and four cubes accessed by
four separate user communities—Finance, Sales, Marketing, and Operations.
Each of the four groups views a different set of cube data because each group
has different business needs. The dimensions defined for each user community
categorize the measures of the cube. Every measure is analyzed in terms of
every dimension in the cube.
An important word used to introduce each dimension is the word by. For
example, the Marketing users need to see Revenue:
!
By Customer
!
By Industry
!

By Channel
!
By Week
Marketing users can report on Revenue as it applies to any of the above
dimensions.
Topic Objective
To illustrate how different
groups of users use
dimensions.
Lead-in
Each of the four groups
contains a different view of
cube data defined by a user
community.
Delivery Tips
Describe each user
community as the slide
builds the groups one by
one.

Ask students to describe the
important business
processes and underlying
databases that they work
with. Then ask the students
to describe the dimensions
that would apply to the
processes or databases.
4 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Understanding Levels and Members
!
Product Dimension
!
Four Levels: All, Category, Sub-Category, Product
!
Category Members: Bread, Dairy, Meat


Dimensions consist of members organized into levels. This organization gives
users access to data at different levels of detail. The above illustration shows a
dimension, Product that contains the levels All, Category, Sub-Category, and
Product. Each level consists of members—for example, the Category level
consists of the members Bread, Dairy, and Meat.
When defining dimensions, you must understand which levels the users require.
In addition, you must determine the tables containing levels and members in the
relational data source.
In most cases, dimensions have different degrees of summarization or levels,
enabling drilling down and drilling up.
In a multidimensional database, levels:
!
Define the hierarchy of a dimension.
!
Are organized by degrees of summarization. For example, Country, State,
City, and Zip Code might each be levels in a Region dimension.
Users and their required business questions determine the number of
dimensions and the number of levels in a dimension.
Topic Objective

To review the terms level
and member and to explain
the importance of levels and
members in dimension
design.
Lead-in
Dimensions consist of
members, organized into
levels, and give users
access to data at different
levels of detail.
Review dimension level and
members. Quiz students on
the levels and members.
Module 4: Building Dimensions Using the Dimension Editor 5

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Describing Familial Relationships
Region
Central
IL
MO
East
NY
MA
Dimension
Children
Siblings
Ancestors

of IL and MO
Parents
Descendants
of Region
Cousins


Users and OLAP developers must be able to describe members and their
relationships to other members in dimensions. Analysis Services uses terms
such as parent, child, and sibling to describe relationships between members.
Consider the following hierarchical structure:
Region
Central
IL
MO
East
NY
MA
Following are definitions of relationships that apply to the above hierarchical
structure:
!
Dimension. The dimension in this example is Region.
!
Parents. A parent has at least one child member immediately below it.
Region is a parent of Central and East. Central is the parent of IL and
MO. East is the parent of NY and MA.
!
Siblings. A sibling is a member with the same parent as another child.
Central and East are siblings. In addition, IL and MO are siblings, and NY
and MA are siblings.

!
Children. A child is a member that has a parent immediately above it.
Central and East are children of Region. The states are children of their
region parents.
!
Ancestors. The ancestors of a member include its parent, grandparent, and
so on, continuing up the branch until the topmost member of the dimension
is reached. The ancestors of MO are Central and Region.
Topic Objective
To define key terms related
to dimension familial
relationships.
Lead-in
Users and OLAP developers
must be able to describe
members and their
relationships to other
members in dimensions.
Delivery Tips
Present this build slide by
introducing one familial term
at a time. As each term
appears, define the term
and describe how the term
applies to the members in
the example.
The dimension terms
appear in the following
order:
1. Dimension

2. Parents
3. Siblings
4. Children
5. Ancestors of IL and MO
6. Descendants of Region
7. Cousins

Stress that members are
cousins only when they exist
at the same relative position
below their parents.
Key Point
These familial terms are
used in most OLAP
database tools, and not only
in Analysis Services.
6 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
Descendants. The descendants of a member include all members that exist
below that member in the hierarchy. For example, the descendants of
Region are all members in the dimension at all levels of detail.
!
Cousins. Member 1 is a cousin of Member 2 if the following are true:
• Member 1 and Member 2 exist at the same level in a dimension.
• The parents of Member 1 and Member 2 are siblings.
• Member 1 and Member 2 exist at the same relative position below their
parents.

In the above example, IL and NY are cousins because they exist at the same
level, their parents are siblings, and they both are defined as the first child
below their parents.

Module 4: Building Dimensions Using the Dimension Editor 7

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Reviewing Analysis Services Limits
LimitsItems
24 charactersLength of dimension name
64,000Members per parent
64Levels per dimension
256Levels per cube
128Dimensions per cube
65,535Levels per database
65,535Dimensions per database


When designing dimensions and cubes, you need to understand the
programmable limits of Analysis Services. In most cases, the limits far exceed
real-world requirements. However, cube requirements sometimes need changes
because of dimension and level limits.

Users typically cannot understand OLAP reports and front-end
applications with more than six or seven dimensions represented. Therefore,
user confusion affects cube design more often than the Analysis Services
dimension limits.

The following table lists some of the programmable limits of Analysis Services.

Items Limits

Dimensions per database 65,535
Levels per database 65,535
Dimensions per cube 128
Levels per cube 256
Levels per dimension 64
Members per parent 64,000
Length of dimension name 24 characters



Topic Objective
To review all dimension and
level limits related to cube
building.
Lead-in
When designing dimensions
and cubes, it is important to
understand the
programmable limits of
Analysis Services.
Delivery Tips
Use the slide to present the
limits one at a time.

Ask students if any of the
limits will cause problems
for them.

Students often mention the
dimension name length as a
potential limiting factor.
Note
8 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


#
##
#

Shared vs. Private Dimensions
!
Working with Shared Dimensions
!
Working with Private Dimensions


Dimensions are defined as either shared or private at the time they are created.
Understanding the difference between the two dimension types is crucial to
building practical and well-designed OLAP database models.
This section describes the characteristics of shared and private dimensions and
explains when to use each type when you design the cube dimensions.
Topic Objective
To introduce the concepts of
shared and private
dimensions.
Lead-in

Dimensions are defined as
either shared or private at
the time they are created.
The goal of this section is to
explain the differences
between shared and private
dimensions, and for
students to understand
when to use one dimension
type versus the other.
Module 4: Building Dimensions Using the Dimension Editor 9

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Working with Shared Dimensions
!
Created Once and Shared by One or More Cubes in a
Database
!
Cannot Be Changed to Private
!
Maintained in Dimension Editor
!
Administered in One Place
!
Cause All Cubes Using that Dimension to be
Unavailable for Querying After Rebuilding Structure
!
Identified by a Sharing Hand Icon:

You define most dimensions in cubes as shared. Any number of cubes in a
database can share these dimensions. Because you create, process, and maintain
shared dimensions in one place, shared dimensions simplify administration and
synchronization where dimensions are used across multiple cubes. There is no
major disadvantage to creating many shared dimensions.
The following list contains the characteristics of shared dimensions:
!
You create shared dimensions once, and one or more cubes in a database
share them. You cannot share a dimension across multiple databases.

You can copy and paste shared dimensions to other databases,
assuming the new databases contain the dimension source table or tables.

!
Once you define a dimension as shared, you cannot change it to private, and
vice versa.
!
You maintain shared dimensions in the Dimension Editor, where you can
apply various dimension properties and actions.
!
You modify shared dimensions in one place—the Shared Dimension folder
in Analysis Manager.
!
When you rebuild a shared dimension, all cubes containing the dimension
become unavailable to clients. You must then reprocess the cubes before
users can continue to access cube data.

It may be unacceptable in the business environment for a cube to
become unavailable every time another user community updates a shared

dimension. If so, define the dimension as private. You process private
dimensions individually in their cubes, and therefore other cubes are not
affected.

!
You identify shared dimensions in the Analysis Manager interface by the
sharing hand icon.
Topic Objective
To examine the
characteristics of shared
dimensions.
Lead-in
You define most dimensions
in cubes as shared. You
create, process, and
maintain shared dimensions
in one place, and this can
help simplify dimension
administration and
synchronization.
Note
Importan
t
10 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Working with Private Dimensions
!
Created and Used within Single Cube

!
Maintained in Cube Editor, Not Dimension Editor
!
Cannot Be Changed to Shared
!
Rebuilt Automatically with Cube Process
!
Identified by Dimension Icon:


Private dimensions are dimensions used by only one cube. You use private
dimensions when only one cube requires that particular view or dimension.
The following are characteristics of private dimensions:
!
You create and use private dimensions within a single cube.
!
When maintaining private dimensions, you access the dimension properties
in the Cube Editor, not the Dimension Editor.
!
After you define a dimension as private, you cannot change it to shared, and
vice versa.
!
You rebuild private dimensions automatically when the cube is processed.
Processing private dimensions does not affect other cubes.

Define the dimensions as private if it is unacceptable for the
cube to be unavailable to the users due to another user group rebuilding a
common shared dimension.

!

You identify private dimensions in the Analysis Manager interface by the
dimension icon. Note the absence of a hand.
Topic Objective
To examine the
characteristics of private
dimensions.
Lead-in
Private dimensions are
dimensions used by only
one cube.
Key Point
Define the dimensions as
private if it is unacceptable
for the cube to be
unavailable to the users due
to another user group
rebuilding a common shared
dimension.
Be sure to summarize
shared and private
dimensions at this point in
the lecture.
Im
p
ortan
t

Module 4: Building Dimensions Using the Dimension Editor 11

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Working with Standard Dimensions
San Jose La Jolla
California
Denver
Colorado
Chicago Peoria Springfield
Illinois
USA
Country
State
City
!
Each Level Corresponds to a Dimension Table Column
!
All Members at a Given Level Have the Same Number of
Ancestors


Analysis Services dimensions retrieve members from one or more dimension
tables. You define a dimension as standard when each level corresponds to a
column in the dimension table or to an expression based on a column. In the
dimension in the above illustration, the three levels—Country, State, and
City—correspond to dimension table columns in the source database.
In a standard dimension, each member of a dimension hierarchy has the same
number of ancestors as any other member at the same level.
For example, La Jolla has two ancestors, California and USA. Because this
dimension is a standard dimension, Chicago has two ancestors also, Illinois
and USA. Standard dimensions are considered balanced because all the
dimension branches have the same number of levels.

Standard dimensions are defined as being either star or snowflake schema
dimensions. A star schema dimension builds its structure from a single
dimension table. A snowflake schema dimension builds its structure from
multiple dimension tables.
Topic Objective
To define standard
dimensions and to illustrate
standard dimension
balanced levels.
Lead-in
Define a dimension as
standard when each level
corresponds to a column in
the dimension table.
Delivery Tip
Cover the information
presented in the student
manual by using the
Geography dimension in
the slide. Explain the
balanced hierarchy, and
how each level maps to a
column in one or more
tables.
12 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Demonstration: Creating a Star Schema Dimension

You create dimensions quickly and easily by using the Dimension Wizard.
While the Dimension Wizard is a useful tool for many situations, the
Dimension Editor and the Cube Editor are the primary tools for defining and
modifying dimensions.
In this demonstration, you will learn how to create a standard star schema
dimension by using the Dimension Editor instead of the Dimension Wizard.

Topic Objective
To demonstrate the
Dimension Editor and to
create a star schema
dimension.
Lead-in
In this demonstration, you
will learn how to create a
regular star schema
dimension by using the
Dimension Editor instead of
the Dimension Wizard.
Delivery Tip
The steps for this
demonstration are included
in the Instructor Notes.

Lab A, Creating a Standard
Dimension, repeats the
demonstration steps. If
students follow along with
you in your demonstration,

let them know that they can
skip some of the procedures
in lab A.
Module 4: Building Dimensions Using the Dimension Editor 13

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#
##
#

Basic Level Properties
!
Assigning Member Keys and Names
!
Identifying Uniqueness of Members
!
Creating Members from Expressions
!
Working with Ragged Dimensions
!
Understanding Snowflake Dimensions
!
Defining the All Level
!
Specifying a Default Member


Many properties exist to design and enhance dimensions. A few of the
properties can be set in the Dimension Wizard as you initially create

dimensions. However, the Dimension Editor contains all properties available
for dimensions and their levels.
Because the full range of capabilities are available, application designers spend
a significant amount of time in the Dimension Editor, as opposed to the
Dimension Wizard, working with these properties.
This section describes a few commonly used properties:
!
Member Key and Member Name Columns
!
Member Keys Unique and Member Names Unique properties
!
Expressions used in the Member Key and Member Name Columns
!
The Hide Member If property that is used to create ragged dimensions
!
Snowflake dimensions
!
The All Level property
!
The Default Member property
You can find these properties in the Dimension Editor and use them to enhance
dimensions and levels.
Topic Objective
To introduce some basic
level properties.
Lead-in
Now we will cover some
basic dimension and level
properties that are available
in the Dimension Editor.

Tell students that they will
get hands-on experience
with these properties in the
first two labs.
14 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Assigning Member Keys and Names
!
Defining the Member Key Column
$
Determines the members included in a level
$
Usually comes from a single dimension table column
!
Defining the Member Name Column
$
Provides names for members at a level
$
Can be different from the Member Key Column
!
Sorting Members in a Level
$
Order by key
$
Order by name
$
Order by member property

When you select dimension levels in the Dimension Editor and Dimension
Wizard, Analysis Services keeps track of the columns used to define the levels.
The Member Key Column and the Member Name Column define each
dimension level. The two columns determine the population of levels with
members and the appearance of members to users.
Defining the Member Key Column
On the Basic tab of the Properties pane, the Member Key Column identifies
the members of a level by specifying where the key comes from in the source
relational database management system (RDBMS).
Characteristics of the Member Key Column include the following:
!
The Member Key Column determines the members included in a level.
!
The Member Key Column usually specifies an RDBMS column containing
member keys in table.column format.
!
The Member Key Column can be any valid SQL expression involving one
or more columns from the same table. The expression must be understood
by the source RDBMS.
!
When populating the children of a parent with members, the Analysis
Server uses the SQL command SELECT DISTINCT on the Member Key
Column. Therefore, you do not see duplicate member values below the
parents—you only see the distinct members.
!
For optimization reasons, the Member Key Column of the lowest level
should be the dimension primary key—the numeric key that uniquely
defines each member in the dimension table. This key also acts as the
foreign key in the source fact table.

Topic Objective
To introduce the Member
Key Column and the
Member Name Column
and explain how the two
properties define the sort
order of members.
Lead-in
Two important properties of
dimension levels are the
Member Key Column and
the Member Name
Column.
Delivery Tips
Describe the Member Key
Column and Member
Name Column by going to
the Dimension Editor and
showing students the
properties and how to
update them.

Consider introducing these
topics in the previous
demonstration as you build
the State dimension. If you
choose to deliver these
concepts in the previous
demonstration, use this slide
to review the terms, asking

students for their definitions.
Key Point
When populating the
children of a parent with
members, the Analysis
Server uses the SQL
command SELECT
DISTINCT on the Member
Key Column. Therefore,
you do not see duplicate
member values below the
parents—you see only the
distinct members.
Module 4: Building Dimensions Using the Dimension Editor 15

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Defining the Member Name Column
On the Basic tab of the Properties pane, you will find the Member Name
Column property. It contains the name of the RDBMS column that provides
member names for that level.
Characteristics of the Member Name Column include the following:
!
By default, the Member Name Column is the same as the Member Key
Column.
!
The Member Name Column is useful in situations where the Member Key
Column does not contain data that is meaningful to users.
For example, users are often more familiar with descriptions than with
codes. Therefore, if the Member Key Column contains codes, you update

the Member Name Column with descriptions. The users see only the
Member Name Column descriptions, and the codes are stored internally.
!
The Member Name Column can be any valid SQL expression involving
one or more columns. The columns must be from the same table as the
Member Key Column, and the expression must be understood by the
source RDBMS.
For example, if a table named Customer contains the columns
Customer_ID and Customer_Name, you would probably rather see names
than identification numbers when you query the customer dimension. In this
case, the Member Key Column would be Customer_ID and the Member
Name Column would be Customer_Name.
The SQL Expressions for the properties in this example are shown in the
following table.

Property SQL Expression

Member Key Column “Customer”.”Customer_ID”
Member Name Column “Customer”.”Customer_Name”

Sorting Members in a Level
The Order By property on the Advanced tab of the Properties pane designates
whether dimension members are sorted in ascending order based on the
Member Key Column or the Member Name Column. The two options for
Order By settings are Key, indicating Member Key Column, and Name,
indicating Member Name Column.
If neither the Member Key Column nor the Member Name Column of a
dimension provides the correct sort order, you can use a third column to control
the sort order. Simply add that column as a member property to the level you
want to sort. Member properties for a level automatically appear in the Order

By property’s drop-down list.

For more information on member properties, see module 5, “Using
Advanced Dimension Settings,” in course 2074A, Designing and Implementing
OLAP Solutions with Microsoft SQL Server 2000.

By default, the setting of Order By is Name, which means that member names
determine the sort order of members in a level.
Note
16 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

There are two main reasons to change the Order By setting:
!
Even though the Member Key Column and the Member Name Column
are the same by default, you may create errors in sorting if the member key
is numeric and Order By is set to Name. If Order By is set to Name, the
level treats the data as text rather than numeric and sorts the members
accordingly.
!
If the Member Name Column is different from the Member Key Column
and you want to sort items by the Member Key Column, you can change
the Order By setting to Key.
Perform the following steps to sort members by the Member Key Column:
1. Select the level in the dimension tree view.
2. In the Properties pane, click the Advanced tab.
3. Click the Order By box, and then click Key.

If you build the dimension by using the Dimension Wizard, it gives you

the option to select any column from the dimension table to define the sort
order, and then the wizard automatically creates the member property for you.



Ti
p

Module 4: Building Dimensions Using the Dimension Editor 17

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY


Identifying Uniqueness of Members
!
Member Keys Unique
$
Works with the Member Key Column
$
Is set as a dimension or level property
$
Affects cube processing performance with True setting
$
Cannot be set within a parent-child dimension
!
Member Names Unique
$
Works with the Member Name Column
$
Is set as a dimension or level property

$
Affects member naming in MDX with True setting


As a rule, two member keys that roll up to one parent must be distinct. Direct
siblings require unique keys. If you have a two-level hierarchy consisting of
city and country, you cannot have two Cairo children below Egypt.
However, member keys do not need to be unique across an entire level of a
dimension. For example, we may have two cities named Cairo, but they each
roll up to a unique county. For example, the level can contain Cairo, Egypt and
Cairo, USA.
The Advanced tab of the Properties pane contains two properties that work
with the Member Key Column and the Member Name Column
respectively—Member Keys Unique and Member Names Unique.
Member Keys Unique
Analysis Services allows non-unique keys for a level or a dimension.
The following are characteristics of the Member Keys Unique property:
!
You can set the Member Keys Unique property for an entire dimension or
a particular level.
!
Setting the property to Yes improves performance for cube processing,
particularly for the lowest level of a dimension.
!
The Member Keys Unique property is not available for a parent-child
dimension—for the dimension or any level in the dimension—because
member keys must be unique in parent-child dimensions.
!
The property is also unavailable for all first levels of a dimension. The
reason is that all first level members have either only one parent—All

dimension_name—or the members do not have a parent because the All
level is disabled.
!
If you set a level as unique, and the data at the level is not unique, the
dimension is not valid and your dimension and cube fail to process.
Topic Objective
To describe the two
settings, Member Keys
Unique and Member
Names Unique, that
determine the uniqueness of
members in an entire
dimension or a single level.
Lead-in
The Advanced tab of the
Properties pane contains
two properties that
collaborate with the
Member Key Column and
the Member Name
Column—Member Keys
Unique and Member
Names Unique.
18 Module 4: Building Dimensions Using the Dimension Editor

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

!
Analysis Server will not trap the mistake in the Dimension Editor unless
you browse the dimension. Therefore, it is recommended that you browse

the dimension when setting levels as unique to verify that the dimension is
valid.
Member Names Unique
In addition to the Member Key Column, the Member Name Column can also
be required to be unique.
The following are characteristics of the Member Names Unique property:
!
You can set the Member Names Unique property for an entire dimension,
a particular level, or for direct siblings.
!
When the Member Names Unique property of a level or a dimension is set
to Yes, the names in the defined levels are not fully qualified with all
ancestor names. The naming convention affects how you identify members
in MDX calculations and queries.

Having members with the same name can lead to confusion for
users. For example, if a user looks at a January report, and there are January
members in the years 2000, 2001, and 2002, the user does not know the year in
which January exists.

Im
p
ortan
t

Module 4: Building Dimensions Using the Dimension Editor 19

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Creating Members from Expressions

!
Add Flexibility When Defining Levels
!
Are Created from One or More Columns in a Single
Table
!
Are Defined in the Member Key Column and Member
Name Column in the Dimension Editor
!
Act as RDBMS Pass-Through Functions
!
Must be Valid RDBMS Syntax


In many situations, the source RDBMS database does not format data perfectly
for the dimensions or levels that you want to build in the cube. By creating
members from expressions, you can address shortcomings in the RDBMS data.
The following characteristics describe expressions used to create members:
!
The creation of members from expressions adds flexibility to the design.
!
You create expressions from one or more columns in a single dimension
table.
!
You create expressions by typing them directly into the Member Key
Column and the Member Name Column boxes in the Dimension Editor.
The Dimension Editor does not provide an interface to graphically build
expressions. No interface exists in the Dimension Wizard to define a
dimension level from anything other than a single column.

If you are changing an expression and a syntax error occurs, the
last valid Member Key Column or Member Name Column value
reappears, erasing the invalid expression.

!
The expression processes as part of the SQL SELECT statement at
dimension processing time. This is known as a pass-through function.
!
Because the expression is a pass-through function to the RDBMS system,
any SQL function valid for the SELECT statement and recognized by the
RDBMS system can be used as an expression.



Topic Objective
To discuss expressions and
how they are used to define
members in dimensions.
Lead-in
By using expressions for
Member Key Columns or
Member Name Columns,
you add flexibility to the
design, addressing
shortcomings in the
relational database
management system
(RDBMS) data.
Delivery Tips
Focus on the rules

associated with creating
expressions for members.

Mention to students that the
boxes in which you type
expressions are not user
friendly. Use an editor, such
as Microsoft
®
Notepad, to
create the expressions
before copying and pasting
them into the boxes in the
Dimension and Cube
Editors.
Caution