how to build your own… super model
DESCRIPTION
How to build your own… Super Model. Dimensional Modelling for Analysis Services. Darren Gosbell Principal Consultant - James & Monroe http://geekswithblogs.net/darrengosbell. Agenda. Why build a Dimensional Model? What is a Dimensional Model? Overview of some modelling techniques. - PowerPoint PPT PresentationTRANSCRIPT
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