How to build your own… Super Model Dimensional Modelling for Analysis Services Darren Gosbell Principal Consultant - James & Monroe

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 SystemDimensional Model Process OrientedSubject Oriented TransactionalAggregate CurrentHistoric

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 SalesAmount Products ProductID Description Size Subcategory Category Customers CustomerID Name Street State Country Time TimeID Date Month Quarter Year

Star Schema ProductID TimeID CustomerID SalesAmount factSales ProductID ProductName SubCategoryName CategoryName dimProduct … dimCustomer … dimTime

Snowflake Schema ProductID TimeID CustomerID SalesAmount factSales ProductID SubcategoryID Description dimProduct SubcategoryID CategoryID Description dimSubCategory CategoryID Description 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 your model 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 CustomerIDCodeNameStateGender 1K001Miranda KerrNSWF CustomerIDCodeNameStateGender 1K001Miranda KerrVICF

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 CustomerIDCodeNameStateGenderStartEnd 1K001Miranda KerrNSWF1/1/09 23/2/09 CustomerIDCodeNameStateGenderStartEnd 1K001Miranda KerrNSWF1/1/0923/2/09 2K001Miranda KerrVICF24/2/09

Type 3 Slowly Changing Dimension De-normalized change tracking Only keeps a limited history Stores changes in separate columns

Type 3 Slowly Changing Dimension CustomerIDCodeNameCurrent State GenderPrev State 1K001Miranda KerrF VIC NSW

Relationships between facts and dimensions

Regular Relationships Most Common relationship Works like an inner join between the fact and dimension

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

DEMO Many-to-Many Relationships

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

Bank Accounts The relational schema

Referenced Relationships Joins a dimension to a fact table through another “intermediate” dimension

DEMO Reference Relationships

CustomerIDFullNameCityID 100Albert1 SELECT {[Measures].[Amount]} ON Columns {[Geography].[City].&[1]} ON ROWS FROM [Balances] TimeID CustomerID 100 Amount $ $2000 CityID 1 CityName Adelaide Geography Customer 101Betty1

Materialized Reference Relationships CustomerID 100 FullName Albert CityID 1 1 CityName Adelaide TimeID CustomerID 100 Amount $1000 CityID 1

Fact Relationships Used when a table plays both the role of a dimension and a fact. Sometimes also known as a degenerate dimension.

DEMO Fact Relationships

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

DEMO No 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 Gosbell