Designing OLAP Dimensions. Enabling Various Views Finance Operations Profit by Division by Country by Month by Actual/Budget Revenue by Product by Region.

Designing OLAP Dimensions

Enabling Various Views

FinanceOperations

Profitby Divisionby Countryby Monthby Actual/Budget

Revenueby Productby Regionby Sales Repby Quarter

Revenueby Customerby Industryby Channelby Week

Sales Marketing

Volumeby Plantby Shiftby Productby Day

Analysis Server

Understanding Levels and Members

Four Levels

All Category Sub-Category Product

Category Members

Bread Dairy Meat

Product Dimension

Reviewing Analysis Services Limits

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

Working with Standard Dimensions

S a n Jo se L a Jo lla

C a lifo rn ia

D e n ver

C o lo ra do

C h ica go P e o ria S p ring fie ld

Illin o is

U S A Country

State

City

Each Level Corresponds to a Dimension Table Column

All Members at a Given Level Have the Same Number of Ancestors

Can Be Star or Snowflake Dimensions

Working with Ragged Dimensions

Country

State

CityS a n Jo se L a Jo lla

C a lifo rn ia

C h ica go

Illin o is

U S A

T e l A v iv H a ifa

Is ra e l

A ll

NoStates

Variable Depth in Branches

Level Property Hide Member If

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

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

Using Member Properties

Why Member Properties?

Information Needed for Analysis that Does Not Make Sense as a New Dimension or Level

A Starting Point for Creating Virtual Dimensions

Used in MDX Queries for Analysis

Impact of Member Properties

Do Not Affect Cube Size

Do Not Significantly Affect Cube Processing Times

Are Stored in Dimension Structure Files

Creating Time Dimensions

Using the Dimension Wizard

Contains Built-In Intelligence Defines Entire Hierarchy From a Single Date/Time

Column Uses Appropriate Functions Depending on Data Source

Using a Separate Date Table

Contains Additional Date Properties Reduces Storage Space Can be Used with Multiple Fact Tables

Setting Time Dimension Properties

Some MDX Functions Use Time Dimension Properties

Third-Party Products Use Time Properties

Several Time Dimension Level Properties Exist

The Type Property Has No Effect on the Analysis Server

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:

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:

Defining the All Level

Summarizes All Data at Top Level of Dimension

Is Included by Default

Is Named All DimensionName by Default

For example, All Product

Can Be Turned Off within the Dimension Editor

Cannot Be Defined by the Member Key Column or the Member Name Column

Can Be Renamed Using the All Caption Property

Specifying a Default Member

Defining a Hierarchy

A Hierarchy Is a Set of Members and Levels within a Dimension

By Default, a Dimension Contains One Hierarchy

A Dimension Can Contain Multiple Hierarchies

Creating Multiple Hierarchies

Department Dimension

Department.Management

Region 1

Department.Region

Region 2

Department A

Department DDepartment C

Department B

Manager 1

Department B

Department DDepartment CDepartment A

Manager 2

Two Hierarchies

Overview of Parent-Child Dimensions

Are Based on a Two Column Dimension Table

Contain Levels Created by Parent-Child Relationships

Contain Unbalanced Levels

Are Created with the Dimension Wizard

Can Slow Queries that Reference Them

Structure of a Parent-Child Dimension

B lo ck

F ox

S m a rt

H u nt

H a rt K n ig h t

Jo n es W h ite

S m ithEmployee Manager

Smith <none>

Jones Smith

White Smith

Block Jones

Hart Jones

Knight Jones

Fox Hart

Hunt Hart

Smart Hunt

Loading Data To Non-Leaf Members

Steve

Eric

Mike Corey

Susan

John Diana

Beth

500 500500 500

150015001500

3000

(Steve)

(John) (Diana)

15001500

30002500 2500

9500

Members with Data

In Standard Dimensions, Only Leaf Members Can Correspond to Fact Table Data

In Parent-Child Dimensions, Leaf and Upper Level Members Correspond to Fact Table Data

The Members with Data Property Has Three Possible Settings:

Leaf Members Only

Non-leaf Data Hidden

Non-leaf Data Visible

Reviewing Analysis Services Limits

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

Creating a Grouping Level

All

Large Level

Grouping Level

A – G

H – O

O – Z

Grouping Members into Levels: Two Solutions

Analysis Services Auto-grouping

Create Intermediate Parents

Approx. Square Root of Members

Can Hide Using Visible Property

Custom Grouping Using Expressions

Custom Intermediate Parents

Use SQL Expressions