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

Private Dimensions 8 Working with Standard Dimensions 11 Lab A: Creating a Standard Dimension 24 Lab B: Creating a Snowflake Dimension 28 Working with Parent-Child Dimensions 32 Lab

Contents

Overview 1

Understanding Dimension Basics 2

Shared vs Private Dimensions 8

Working with Standard Dimensions 11

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

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

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® file2074A_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

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

Demonstration:

5 Minutes

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

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

Overview

! 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

In this module, you will learn

about the Dimension Editor

and how to use it to create

and manage dimensions

# Understanding Dimension Basics

! Enabling Various Views

! 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

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

Enabling Various Views

Finance

Operations Profit

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

Understanding Levels and Members

! 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

Describing Familial Relationships

Region

Central

IL MO East

NY MA

Dimension

Children Siblings

Ancestors

of IL and MO Parents

Region Central

IL

MO East

NY

MA

Following are definitions of relationships that apply to the above hierarchical

structure:

Region is a parent of Central and East Central is the parent of IL and

MO East is the parent of NY and MA

Central and East are siblings In addition, IL and MO are siblings, and NY

and MA are siblings

Central and East are children of Region The states are children of their

region parents

so on, continuing up the branch until the topmost member of the dimension

is reached The ancestors of MO are Central and Region

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

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

! 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

• 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

Reviewing Analysis Services Limits

Limits Items

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 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

# 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

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

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

Important

Working with Private Dimensions

! Created and Used within Single Cube

! Maintained in Cube Editor, Not Dimension Editor

! 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

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

Important

Working with Standard Dimensions

San Jose La Jolla

! 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

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

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

# Basic Level Properties

! Identifying Uniqueness of Members

! 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

Assigning Member Keys and Names

$ Determines the members included in a level

$ Usually comes from a single dimension table 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

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

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

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

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

Tip

Identifying Uniqueness of Members

$ 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

$ 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

! 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

Important

Creating Members from Expressions

! Add Flexibility When Defining Levels

! Are Created from One or More Columns in a Single Table

Name Column in the Dimension Editor

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

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

Working with Ragged Dimensions

Country State City

San Jose La Jolla

California

Chicago Illinois USA

Tel Aviv Haifa

Israel All

No States

! Variable Depth in Branches

! Level Property Hide Member If

Many dimensions do not have the same number of levels at each dimension branch One reason for the varying depths of levels is that some branches may not have members that exist at all levels

For example, the State dimension has the following levels:

! Country

! State

! City USA contains two states, California and Illinois, with the cities of the two

states existing at the City level Alternatively, Israel does not contain any states and only contains two cities, Tel Aviv and Haifa In this example, the State

dimension is ragged because no states are found below Israel or above Tel

Aviv and Haifa

A ragged dimension contains at least one member whose parent belongs to a hierarchy that is more than one level above the child Ragged dimensions therefore contain branches with varying depths

The property Hide Member If works in standard dimensions to give

dimensions a ragged appearance to users

Topic Objective

To introduce ragged

hierarchies and how to

define them in regular

dimensions

Lead-in

Many dimensions do not

have the same number of

levels at each dimension

branch Ragged dimensions

contain branches with

varying depths

Delivery Tip

Ask students if they can

think of other dimension

situations in which

hierarchies are ragged

Point out that it is the

asymmetrical appearance of

a dimension that makes it

ragged, not the storage of a

dimension on the server