how to build your own… super model

How to build your own…

Super ModelDimensional Modelling

for Analysis Services

Darren GosbellPrincipal Consultant - James & Monroe

http://geekswithblogs.net/darrengosbell

Agenda

• Why build a Dimensional Model?• What is a Dimensional Model?• Overview of some modelling

techniques.• What functionality does Analysis

Services provide to help us?

Further Reading

• “The Data Warehouse Toolkit” by Ralph Kimball & Margy Ross

• “The Data Warehouse Lifecycle Toolkit” by Ralph Kimball & Margy Ross

Why Build a Dimensional Model

OLTP System Dimensional ModelProcess Oriented Subject OrientedTransactional AggregateCurrent Historic

What is a Dimensional Model?

• A De-normalized database.• Designed for ease of querying, not

for transactional updates.• Built to support aggregate queries• Modelled around business subject

areas.

Facts & Dimensions

• There are two main types of objects in a dimensional model– Facts are quantitative measures that

we wish to analyse and report on.– Dimensions contain textual descriptors

of the business. They provide context for the facts.

A Transactional Database

OrderDetails

OrderHeaderID

ProductID

Amount

OrderHeader

OrderHeaderID

CustomerID

OrderDate

FreightAmount

Products

ProductID

Description

Size

Customers

CustomerID

AddressID

Name

Addresses

AddressID

StateID

Street

States

StateID

CountryID

Desc

Countries

CountryID

Description

A Dimensional Model

FactSales

CustomerID

ProductID

TimeID

SalesAmountProducts

ProductID

Description

Size

Subcategory

Category

Customers

CustomerID

Name

Street

State

Country

Time

TimeID

Date

Month

Quarter

Year

Star Schema

ProductIDTimeID

CustomerIDSalesAmount

factSales

ProductIDProductName

SubCategoryNameCategoryName

dimProduct

…

dimCustomer

…

dimTime

Snowflake Schema

ProductIDTimeID

CustomerIDSalesAmount

factSalesProductID

SubcategoryIDDescription

dimProduct

SubcategoryIDCategoryIDDescription

dimSubCategory

CategoryIDDescription

dimCategory

Building a Model - Facts

• You have to talk to the “business”.• Identify Facts by looking for

quantitative values that are reported.

• Make sure the granularity is “right”.

Building a Model - Dimensions

• Identify Dimensions by listening for “by” words.

• Look for related attributes that should be part of a single dimension.

• Pay attention to how “Dimensions” change over time and in relation to each other.

Slowly Changing Dimensions -Handling Changes over time

If you don’t consider changes over time yourmodel will start out like this…

… but ending up like this!

Type 1 Slowly Changing Dimension

• The simplest form• Only updates existing records• Overwrites history

Type 1 Slowly Changing Dimension

CustomerID Code Name State Gender

1 K001 Miranda Kerr NSW F

CustomerID Code Name State Gender

1 K001 Miranda Kerr VIC F

Type 2 Slowly Changing Dimension

• Allows the recording of changes of state over time

• Generates a new record each time the state changes

• Usually requires the use of effective dates when joining to facts.

Type 2 Slowly Changing Dimension

CustomerID Code Name State Gender Start End

1 K001 Miranda Kerr NSW F 1/1/09 <NULL>23/2/09

CustomerID Code Name State Gender Start End

1 K001 Miranda Kerr NSW F 1/1/09 23/2/09

2 K001 Miranda Kerr VIC F 24/2/09 <NULL>

Type 3 Slowly Changing Dimension

• De-normalized change tracking• Only keeps a limited history• Stores changes in separate columns

Type 3 Slowly Changing Dimension

CustomerID Code Name Current State

Gender Prev State

1 K001 Miranda Kerr F <NULL>VICNSW

Relationships between facts and dimensions

Regular Relationships

• Most Common relationship• Works like an inner join between the

fact and dimension

DEMORegular Relationships

Many to Many Relationships

• Allows for the situation where you want to associate more than one member from a dimension with a single fact.

Scenario

• Bank Account Transactions - each one has an Account - Accounts have one or more Customers - Each Customer has one or more Accounts

DEMOMany-to-Many Relationships

Person Account Amount

Albert #1 $1,010

Albert #2 $2,010

Betty #2 $2,010

TOTAL $5,030$3,020

Bank Accounts

Account #1$1,010

Account #2

$2,010

Albert

Betty

Bank Accounts

• The relational schema

Referenced Relationships

• Joins a dimension to a fact table through another “intermediate” dimension

DEMOReference Relationships

Reference Relationships

CustomerID FullName CityID100 Albert 1

SELECT {[Measures].[Amount]} ON Columns {[Geography].[City].&[1]} ON ROWSFROM [Balances]

TimeID200801

CustomerID100

Amount$1000

200801 101 $2000

CityID1

CityNameAdelaide

Geography

Customer

101 Betty 1

Materialized Reference Relationships

CustomerID100

FullNameAlbert

CityID1

CityID1

CityNameAdelaide

TimeID200801

CustomerID100

Amount$1000

CityID1

Fact Relationships

• Used when a table plays both the role of a dimension and a fact.

• Sometimes also known as a degenerate dimension.

DEMOFact Relationships

No Relationship

• Used for controlling calculations when you want to influence the context of the calculation without changing the context of the data.

DEMONo Relationship

Key Take Aways

• Why to build a dimensional model.• What makes up a dimensional

model.• How implement various modelling

techniques in Analysis Services (2005 & 2008).

Thank You

Darren Gosbellhttp://geekswithblogs.net/darrengosbell