Dimension Modeling

http://www.LnTinfotech.com

Agenda

Question the basics

Why do we need dimension modeling?
Difference between ER / DM
How to start?
Four step Dimensional Design
Types of Grains in Fact Table
About the Modeling Techniques
Slowly Changing Dimension
Some Best Practices
Brain Storm???

Question the basics

Primary Key , Foreign Key

What is a dimensional Model?
Fact and dimensions
Normalization and De Normalization

Why do we need Dimension Modeling?

There were
Waiting for hours
100 quantities
together to execute
the coco
an analytical queryofon
cola 2 litre
the existing OLTP,
Company Back ground
bottle sold by
the sales
representative
Solomon in
Vashi,Mumbai
on 21/4/2006
and the sales
amount ,,
Any thing else
you want to
know?
With Data ware house
Non
Data ware house
practice
practice,dimension
Modeling

Difference between ER and DM

ER Model
One table per entity
Minimize data
redundancy
Optimize update
The Transaction
Processing Model

Dimension Modeling
One fact table for data
organization
Maximize
understandability
Optimized for retrieval
The data warehousing
model
Lesser Joins between
tables when compared
with the ER

How to start?
Identify
the
reporting
requiremen
t of the
client

Looks Simple Doesnt it?

Study the
source
tables
Given by
the client

Apply the
dimensiona
l
techniques
Provide
the model

Four Step Dimensional Design

Choose the Data Mart

Declare the Grain
Choose the Dimensions
Choose the Facts

Types of grains
The TRANSACTION grain,
-represents a point in space and time
The PERIODIC SNAPSHOT grain,
-represents a regular span of time repeated
over and over and
The ACCUMULATING SNAPSHOT grain,
-represents the entire life of an entity.

Modeling Techniques
Star Model View
Snow Flake View
To be noted:
Fact Less Fact View
Bridge View

Slowly Changing dimensions

Type 1 (Update)
Type 2 (Insert as New)
Type 3 (New attribute to keep track of it)

Best Practices

Avoid null keys in fact tables

Dont normalize dimension, fact tables
Join between dimension and fact tables in data
warehouse should be on surrogate keys ( not
operational codes)
Refer Kimballs Dimensional techniques
www.kimball.com
http://www.dbmsmag.com

Brain Storm
Where comes the Dimension modeling during
the entire data ware house process
Is a single model enough to take over all the
functional marts in one organization?
Any questions ????

Case Studies

Star Model
Product_ Dim
Product_Id
Other Descriptors

Customer_Dim
Sales Fact

Customer_Id
Other Descriptors

Customer_Id
Product_Id
Representative_Id
Date_Id
Quantity_Sold
Sales_Amount
Date_Dim

Representative_Dim

Date_Id
Other Descriptors

Representative_Id
Other Descriptors

Back

Snowflake Model
Customer_Dim

Product_ Dim
Product_Id
Other Descriptors

Sales Fact
Customer_Id
Product_Id
Representative_Id
Date_Id
Quantity_Sold
Sales_Amount

Customer_Id
Country_Id
Other Descriptors

Country_Dim
Country_Id
Other Descriptors

Date_Dim

Representative_Dim

Date_Id
Other Descriptors

Representative_Id
Other Descriptors
Back

Bridge Model
Diagnosis Group Helper Table
Patient Billing Fact Table
Date_Key
Patient_Key
Doctor_Key
Service_Key
Diagnosis_Group
Billed_Amount

Diagnosis_Group
Diagnosis_Key
Weighting factor

Diagnosis Dimension
Diagnosis_Key
Description
Type
Category

Bridge Model
Student_Term_ Dim
Student_Term _Id
Other Descriptors

Date_Dim

Student Course to Faculty_Dim

Student Course Fact
StudentFacultyBridge_Id
Student_Term_Id
StudentLocationBridge_Id
Institution_Id
Date_Id

StudentFacultyBridge_Id
Faculty_Id
Other Descriptors

Date_Id
Other Descriptors

Faculty_Dim
Faculty_Id
Other Descriptors

Location_Dim
Institution_Dim

Student Course to Location_Dim

Institution_Id
Other Descriptors

StudentLocationBridge_Id
Location_Id
Other Descriptors

Location_Id
Other Descriptors

Back

Fact Less Fact Model

Requirement Dim

Requirement Fact

Technology Dim

SBU Dim

Date Dim

Interview Fact
Candidate Dim

Status Dim

Accept/Decline Dim

Interview Dim

Source Dim

Reasons Dim