dimenion modelling 2

Confidential © L&T Infotech 22 Oct 07 |1 |usha v

Dimensional Modeling


• Some 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

Agenda


Question the basics

Fact and dimensionsFact Table : It is the primary table where the numeric performance

measures of the business are storedDimension Tables : These are integral companions to a fact table. They

contain textual descriptors of the business.A measure (e.g. sales amount, qty, etc) – It is numeric measurement in a

fact table.Each measure depends on a set of dimensions (e.g. sales volume as a

function of product, time, and location)Each dimension can have a set of associated attributes

• For each dimension, the set of associated attributes can be structured as a hierarchy Normalization and De Normalization

Some Basics


Example of measures & attributes

DateMonthYear

Date Dimension

CustIdCustNameCustCityCustCountry

Customer Dimension

Sales Fact Table

Date

Product

Store

Customer

unit_sales

dollar_sales

schilling_sales

ProductNoProdNameProdDescCategoryQOH

Product Dimension

StoreIDCityStateCountryRegion

Store Dimension

Measures

Attributes


Examples of dimension hierarchies

StoreStore type

City Region

Customer City State Country


• 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

ER Model• One table per entity• Minimize data

redundancy• Optimize update• The Transaction

Processing Model

ER Modeling vs Dimensional Modeling


Identify the

reporting requiremen

t of the client Study the

source tables

Given by the client

Apply the dimensiona

l techniques

Provide the model

Steps leading to modeling


Choose the Data Mart Declare the Grain Choose the Dimensions Choose the Facts

Four Step Modeling Process


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.

Types of Grains


Star Model View• A single object (fact table) in the middle connected to a

number of dimension tables

Snow Flake View• A refinement of star schema where the dimensional

hierarchy is represented explicitly by normalizing the dimension tables

Fact Less Fact View Bridge View

Modeling Techniques


Type 1 (Update) Type 2 (New record) Type 3 (New attribute)

Slowly Changing Dimensions


Avoid null keys in fact tables Don’t normalize dimension, fact tables Join between dimension and fact tables in

data warehouse should be on surrogate keys ( not operational codes)

Refer Kimball’s Dimensional techniques www.kimball.com

http://www.dbmsmag.com

Best Practices


Product_ Dim

Product_IdOther Descriptors Sales Fact

Customer_IdProduct_Id

Representative_IdDate_Id

Quantity_SoldSales_Amount

Date_Dim

Date_IdOther Descriptors

Representative_Dim

Representative_IdOther Descriptors

Customer_Dim

Customer_IdOther Descriptors

Star Model


Star Schema with data

customer custId name address city53 joe 10 main sfo81 fred 12 main sfo

111 sally 80 willow la

product prodId name pricep1 bolt 10p2 nut 5

store storeId cityc1 nycc2 sfoc3 la

sale oderId date custId prodId storeId qty amto100 1/7/97 53 p1 c1 1 12o102 2/7/97 53 p2 c1 2 11o105 3/8/97 111 p1 c3 5 50


Multidimensional Cube

sale Product Client Date Amtp1 c1 1 12p2 c1 1 11p1 c3 1 50p2 c2 1 8p1 c1 2 44p1 c2 2 4

day 2c1 c2 c3

p1 44 4p2 c1 c2 c3

p1 12 50p2 11 8

day 1

Fact relation 3-dimensional cube

Back


Sales Fact

Customer_IdProduct_Id

Representative_IdDate_Id

Quantity_SoldSales_Amount

Customer_Dim

Customer_IdCountry_Id

Other Descriptors

Product_ Dim

Product_IdOther Descriptors

Representative_Dim

Representative_IdOther Descriptors

Date_Dim


Country_Dim

Country_IdOther Descriptors

Back

Snow Flakes Model


Diagnosis Dimension

Diagnosis_KeyDescription

TypeCategory

Patient Billing Fact Table

Date_KeyPatient_KeyDoctor_KeyService_Key

Diagnosis_GroupBilled_Amount

Diagnosis Group Helper Table

Diagnosis_GroupDiagnosis_Key

Weighting factor

Bridge Table


Student Course Fact

StudentFacultyBridge_IdStudent_Term_Id

StudentLocationBridge_IdInstitution_Id

Date_Id

Student Course to Faculty_Dim

StudentFacultyBridge_IdFaculty_Id

Other Descriptors

Student_Term_ Dim

Student_Term _IdOther Descriptors

Institution_Dim

Institution_IdOther Descriptors

Date_Dim


Faculty_Dim

Faculty_IdOther Descriptors

Back

Student Course to Location_Dim

StudentLocationBridge_IdLocation_Id

Other Descriptors

Location_Dim

Location_IdOther Descriptors

Bridge Table (contd.)


Requirement Fact

Interview Fact

• Status Dim

Date Dim SBU Dim

Candidate Dim

Requirement Dim

Accept/Decline Dim

Source Dim

Technology Dim

Reasons Dim

Interview Dim

Factless Fact

Thank You

dimenion modelling 2

Documents