2012 February dama chicago

Dimensional Modeling while Partnering with the Business Community 2/16/2012

Dimensional Modeling
g
while
Partnering
with the
Business Community
Laura L. Reeves
February, 2012

Agenda

• C
Current d t warehousing climate
t data h i li t

• Partnering with the business

• Focus on the data
 The Business Dimensional Model (BDM)

• Putting it all together

Copyright 2012 StarSoft Solutions, Inc. Slide 2

Copyright 2012 StarSoft Solutions, Inc. 1


Critical Challenges
• How can you deliver more….
with fewer resources?
• How can you increase the value of what
you deliver?
• What does the changing technology
landscape mean to you?
l d t ?


Reflection

• How would your business users grade
you?




Common DW Climate
• DW may fall short of business expectations
 Too hard to use

 It takes too long to get new reports or add
more data
• Disconnect between IT and the Business
 Business Perspective
– IT does not deliver what we need
– Build solutions ourselves
 IT Perspective
– Business can’t tell us what they really want
– Build it for them and expect them to use it


Time to Set A New Direction



Getting the Right Tools


What does not change?

People Data



Partner with the
Business


Strengthen Your IT Team
• Invest now in your staff
• Practice critical skills
 Listening
 Writing
 Communication
 Collaboration
• Some people will thrive, but not everyone
wants to or has aptitude to transition to
this new world.




Cultivate Problem Solvers
• Provide exposure to new
ideas and approaches
 If the only tool you have ever
used is a hammer, then
everything begins to look like a
nail.
• Encourage curiosity
• Reward creativity
• Continue to invest in
learning new technologies

Invest in Your
IT-
IT-Business Partnership
• Make conscious choices to build
partnership
 Start by changing your behavior
• IT needs to take time to learn about the
business
 Speak in business terms
 Keep technology out of the discussion
• Business needs to actively participate
 Learn basics of DW/BI
• Solicit ideas/suggestions from each other



Understand True
Business Requirements
• Gather broad business requirements
 Understand business goals, plans and
challenges
 How is success measured?
 What information is needed to help make
decisions?
• Actively collaborate
• Detailed specifications will be needed later
to flesh out specific report design,
dashboards, ETL business rules

Business
Requirements Drive…
• Decisions to jointly scope projects that
deliver business value and are achievable
 Business should drive purpose and direction
 IT evaluates feasibility and effort
• Work together to determine how
to deliver value today and into the future
 Set priorities
 Determine return on investment
• Ensure everyone understands why
you are doing this work



Focus On The Data


Delivering Data
to the Business
• Must be easy to understand
• Good query performance required
• Dimensional models specifically target these
goals
• Delivered through a variety of technologies
 Relational database
– Star or snowflake schemas
 Multi-dimensional database
– Cube
 Other proprietary databases
– Columnar
– DW appliance



The Modeling Technique
• The Business Dimensional ModelTM
• Reflect data model visually and Year

in business terms
• Ensures support for various types Quarter

of reporting and analysis
Month
• Independent of technology
p gy
• Ideal training tool for use later DAY

• Manageable approach to complex
environments

Basics of Dimensions
• Dimensions are major business categories
or groupings to describe business data
• Dimensions contain:
 Descriptive elements
 Reference data
 Attributes, hierarchies, drill paths
• Dimensions are used for:
 Selection criteria
 Report labels
 Pick list via interface



Date Dimension Example
Multiple
Fiscal Year Hierarchies Calendar
Year

Attributes
Fiscal Calendar
Quarter Quarter

Fiscal Calendar
Month Month

Fiscal
Fi l
Future Week
Week
Attribute
Day of
Holiday Day
Week

Grain for this Dimension

Complete Dimension
Documentation
ATTRIBUTE NAME BRIEF DESCRIPTION SAMPLE VALUES

Day Calendar day information was reported on. 6/31/2003, 9/1/2003

Holiday This is a future attribute to indicate that this date is considered a U.S. business Memorial Day, President’s Day
day off.

Fiscal Week The week of the fiscal year that the date rolls up to and is used for reporting FY 2003 Week 16
purposes.

Fiscal Month The month of the fiscal year that this date rolls up to and is used for reporting FY 2003-10, FY 2003-11
purposes.

Fiscal Quarter The quarter of the fiscal year that this date rolls up to and is used for reporting FY 2003-Q1, FY 2003-Q2
purposes.

Fiscal Year The year that this date rolls up to based upon the company’s fiscal calendar. FY 2003

Calendar Month The calendar month used for reporting purposes. March 2003, October 2003

Calendar Quarter The calendar quarter used for reporting purposes. CY 2003-Q1, CY 2003-Q2

Calendar Year The calendar year used for reporting purposes. CY 2003

Week The calendar week ending Saturday and is used for reporting purposes. Week Ending 11/21/1998

Day of Week Attribute to indicate the calendar day of week. Wednesday, Saturday




Basics of Facts
• Facts are the basic business events that
are measured and monitored
• Facts are typically:
 ‘Amounts’ and ‘Counts’
 Defined by more than one dimension
 Numeric (frequently, but not always)
• Facts are used as:
 Body of reports
 Part of calculations


Sales Fact Group Example
Dimension Name Facts:
Product Outlet
Dollars
D ll
Item Store Units
Price
Cost
Grain for the
Fact Group for Sales
this Dimension
Name of
Fact Group
Promo Date
Promo Day




Complete Fact Group
Documentation
AGGREGATION
FACT NAME FACT DEFINITION
RULE
Dollars The dollar amount for the Sum
Units Sold.
Units The number of consumer Sum
units sold.
Price The actual price charged for Average
this sale.
Cost The standard price factor for Average
this item sold at this store.


Dimensional Model -
The Star Schema
Product Dimension Outlet Dimension

PRODUCT KEY STORE KEY

Product Descr Store Name

Size District
Fact Table
Flavor Region
PRODUCT KEY
Package Zone
STORE KEY

PROMO KEY

DATE KEY

Dollars
Promotion Dim. Date Dimension
Units
PROMO KEY DATE KEY
Price
Promo Descr Day
Cost
Deal Weekday

Discount Holiday

Media Fiscal Period




A BDM
Case Study


BDM Example:
Period Dimension
Calendar
Fiscal Year
Year

Fiscal Calendar
Quarter Quarter

Fiscal Calendar
Month Month

Fiscal
Week
Week

Day of
Holiday Day
Week




BDM Example:
Call Center Dimension

Division

Region

Call Center
Open Date
State

Time Call Center
Call Center
Zone City


BDM Example:
Employee Dimension

Manager

Supervisor

Date of Birth

Educ.
Educ
Level

Employee Hire Date




BDM Example:
Client Dimension
Corporate
Parent
P t

Client
State
Account Client
Client
Executive City

Program
Program
Type


BDM Example:
Call Status Dimension
Disposition
Group

Disposition
Type
Disposition
Assigned By
A i dB

Call Disposition




BDM Example:
Activities Dimension

Task Category

Task
Group

Billable Flag

Task


BDM Example:
Calls Fact Group
Facts:
Period
# of Calls
Day
Call Minutes
Call
Status Client
Call Program
Disposition

Calls

Call
Center
Call Center
Activities Dimension
does not apply and is not shown Employee
Employee

Copyright 2012 StarSoft Solutions Inc. Slide 32



Hours Worked Fact Group
Call Status Dimension Facts:
Period
does not apply and is not shown Regular Hours
Day
Overtime Hours
Client
Program

Hours
Worked
Call
Activities Center
Task Call
Center
Employee
Employee

Copyright 2012 StarSoft Solutions Inc. Slide 33

Using the Model
• What are the total number of hours worked to
date f
d t for people who were hired this year?
l h hi d thi ?
• What are the total number of hours worked by
fiscal year and call center region?
• What are the total calling minutes by call
disposition grouped by category?
• What are the average number of calls for client
“Our Biggest Customer” by fiscal week?




Integration:
Conformed Dimensions

Call
Status Client
Call Program
Disposition
Hours
Calls Worked

Call
Activities
Center
Call Center Task


Translating
the BDM




Implementation of BDM
• Exploit the DB and BI tools
• Technical design driven by tools
 BI Tool is the user’s only
perspective of the DW
 Database technology helps
determine data structure design
• Every tool has its own unique
requirements, recommendations
and/or preferences


BDM Example:
Calling Facts Star Schema
Period Table
Client Table
PERIOD KEY
PROGRAM KEY
Day
Program Descr
Day of Week
Program Type
Holidays
Call Center Fact Table Client
Fiscal Week
PERIOD KEY Client City
Fiscal Month
PROGRAM KEY Client State
Fiscal Quarter
CALL DISP. KEY Account Executive
Fiscal Year
EMPLOYEE KEY Corporate Parent
Calendar Month
CALL CENTER KEY
Calendar Quarter Call Status Table
# of Calls
Calendar Year CALL DISP. KEY
Call Minutes Call Center Table
Disposition Descr
Employee Table
E l T bl CALL CENTER KEY
Disposition Type
EMPLOYEE KEY Call Center Name
Disposition Group
Employee Name Call Center City
Hire Date Call Center State
Date Of Birth Time Zone
Educ. Level Open Date
Supervisor Region
Manager Division




BDM Example:
Hours Worked Star Schema
Period Table Client Table

PERIOD KEY PROGRAM KEY
Day Program Descr

Day of Week Program Type
Holidays Client

Fiscal Week Client City
Hours Worked Fact Table
Fiscal Month Client State
PERIOD KEY
Fiscal Quarter Account Executive
PROGRAM KEY
Fiscal Year Corporate Parent
TASK KEY
Calendar Month
EMPLOYEE KEY Activities Table
Calendar Quarter
CALL CENTER KEY TASK KEY
Calendar Year
Regular Hours Call Center Table Task Descr

Employee Table Overtime Hours CALL CENTER KEY Billable Flag
EMPLOYEE KEY Call Center Name Task Group

Employee Name Call Center City Task Category
Hire Date Call Center State

Date Of Birth Time Zone
Educ. Level Open Date

Supervisor Region
Manager Division


Too Many or Too Few
Dimensions?
• Practical Guidelines for a single fact table
• Minimum 3 – 4 dimensions
 Split dimensions that are too broad
 Consider enterprise view, would that split
dimensions apart?
 Are there more dimensions that could be
included for user benefit, but not change the
number of rows in the fact table?
b f i th f t t bl ?
• Maximum 20 Dimensions
 Are these dimensions really separate?
 Walk through logical drill paths



Characteristics of Today’s
Dimensional Models
• Comprehensive and enterprise
perspective drives expanded scope for
models
• Models often have
 25+ fact tables
 15 – 30 dimensions
• Keep in mind that not all fact tables use all
of the dimensions
 In general each fact group has 5-15
dimensions

Developing and Expanding
Dimensional Models
• Design broadly
 Multiple
M lti l user groups for same data
f d t
 Next potential data sources
 Enterprise viewpoint
– Plan for conformed dimensions
• Implement in several increments
 Don t
Don’t tackle too much at one time
 Break into phases
– Each should deliver business value
 Review and update the model each time



More BDM Notation

BDM Advanced Notation
Groups of Future Attributes
• Unclear groups of attributes
 Business has not defined these yet
 To come from a new operational system
not designed yet
 Indicates where these pieces are likely to
fit into the model in the future




Derived Attributes
• Derived Attributes
 When there is not a business element with
an identifier at this level
 Used to tie together several hierarchies
– Perhaps for junk dimensions


Triggers for Type 2 SCD
• Used to identify those attributes that
MUST result in the creation of a new
version for that row in the dimension
• Helps us determine which attributes can
be type 1 and which trigger type 2




BDM Notation Summary
Dimension Derived
Attribute
Grain Attribute

Future Anchor
Attribute Attribute

Fact Group
Collection of
Slowly Attributes to be
Changing Attr
Ch i Att Defined in the
Future

1- M Relationship

M-M Relationship


Putting It All
Together




Keys to Success
• Dimensional modeling provides
the basic foundation for end user
access and analysis
• Focus on the business requirements and
the business user’s perspective
• Designs should reflect clear business
dimensions and facts
• Resulting table structures will likely be
influenced by technology


Recommended Reading

Includes
details
about
Business
Dimensional
Modeling




Recommended Reading
The Data Warehouse
Lifecycle Toolkit
y
Ralph Kimball
Margy Ross
Warren Thornthwaite
Joy Mundy
Bob Becker
John Wiley and Sons, Inc.
Second Edition

The Data Warehouse Toolkit
Ralph Kimball and Margy Ross
Second Edition

The Microsoft Data Warehouse Toolkit Star Schema: The Complete Reference
Joy Mundy and Warren Thornthwaite Chris Adamson
John Wiley and Sons, Inc. McGraw Hill

The Data Warehouse ETL Toolkit
Ralph Kimball and Joe Caserta


115 East Ogden Ave.
Suite 117-369
Naperville, IL 60563

Phone: 630.971.3782
FAX: 630.369.4740

laura@starsoftinc.com

Data Warehouse & Business Intelligence Services


2012 February dama chicago

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Ähnlich wie 2012 February dama chicago

Ähnlich wie 2012 February dama chicago (20)

Mehr von dmurph4

Mehr von dmurph4 (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

2012 February dama chicago