1. Dimensional Modelling III

2. Dimensional Models A denormalized relational model
Made up of tables with attributes
Relationships defined by keys and foreign keys
Organized for understandability and ease of reporting rather than update
Queried and m aintained by SQL or special purpose management tools.

3. From Relational to Dimensional
Dimensional Model
Designed from the perspective of subject
Sales
Customers
“De-normalised” data structures in blatant violation of normalisation
Used for analysis of aggregated data
OLAP : OnLine Analytical Processing
Based on data that is
Historical
May be redundant
Relational Model
Designed from the perspective of process efficiency
Marketing
Sales
“Normalised” data structures
Entity Relationship Model
Used for transactional, or operational systems
OLTP : OnLine Transaction Processing
Based on data that is
Current
Non Redundant

4. ER vs. Dimensional Models
One table per entity
Minimize data redundancy
Optimize update
The Transaction Processing Model
One fact table for data organization
Maximize understandability
Optimized for retrieval
The data warehousing model

5. Strengths of the Dimensional Model
Predictable, standard framework
Respond well to changes in user reporting needs
Relatively easy to add data without reloading tables
Standard design approaches have been developed
There exist a number of products supporting the dimensional model

6. A Transactional Database
Addresses
AddressID
Street
States
StateID
Desc
Countries
CountryID
Description
Customers
CustomerID
FirstName
LastName
OrderHeader
OrderHeaderID
FreightAmount
OrderDate
Products
ProductID
Description
Size
A simplistic transactional schema showing 7 tables relating to sales orders
OrderDetails
OrderDetailNo
Amount 6

7. A Dimensional Model : Solution 1
Customers
CustomerID
Name
Street
State
Country
Time
TimeID
Date
Month
Quarter
Year
FactSales
SalesAmount
Products
ProductID
Description
Size
Subcategory
Category
This is a star schema, (later on we will discuss snowflake schemas.) showing 4 tables that relate to the previous transactional schema
State and Country have been denormalized under Customer
Dimensions are in Blue
These are the things that we analyse “by” (eg. By Time, By Customer, By Region)
Fact is yellow
These are ususally quantitative things that we are interested in
PK is composite
{TimeID, CustomerID, ProductId}
TimeID references Time
CustomerID references Customer
ProductID references Product 7

8. A Dimensional Model : Solution 2
Customers
CustomerID
Name
Street
State
Country
Time
TimeID
Date
Month
Quarter
Year
FactSales
SalesAmount
SaleID
Products
ProductID
Description
Size
Subcategory
Category
This is a star schema, (later on we will discuss snowflake schemas.) showing 4 tables that relate to the previous transactional schema
State and Country have been denormalized under Customer
Dimensions are in Blue
These are the things that we analyse “by” (eg. By Time, By Customer, By Region)
Fact is yellow
These are ususally quantitative things that we are interested in
PK is surrogate ; SaleID
TimeID references Time
CustomerID references Customer
ProductID references Product 8

9. A Dimensional Model : Solution 2
Customers
CustomerID
Name
Street
State
Country
Time
TimeID
Date
Month
Quarter
Year
FactSales
SalesAmount
TimeID||CustomerID||ProductID
Products
ProductID
Description
Size
Subcategory
Category
This is a star schema, (later on we will discuss snowflake schemas.) showing 4 tables that relate to the previous transactional schema
State and Country have been denormalized under Customer
Dimensions are in Blue
These are the things that we analyse “by” (eg. By Time, By Customer, By Region)
Fact is yellow
These are ususally quantitative things that we are interested in
PK concataned: TimeID||CustomerID||ProductID
FKs 9

10. Extract Transform Load
Relational
Dimensional Model
Process Oriented
Subject Oriented
Transactional
Aggregate
Current
Historic
We already have the data in a data model – why create another data model…? Well…
What is currently called “Data Warehousing” or “Business Intelligence” was originally often called “Decision Support Systems”
We already have all the data in the OLTP system, why replicate it in a dimensional model?
Atomic - Summary
Supports Transaction throughput – Supports Aggregate queries
Current - Historic 10

11. 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.
Facts work best if they are additive
Dimensions allow us to “slice & dice” the facts into meaningful groups. The provide context 11

12. Fact & Dimension Tables
FACTS
Contains two or more foreign keys
Tend to have huge numbers of records
Useful facts tend to be numeric and additive
DIMENSIONS
Contain text and descriptive information
1 in a 1-M relationship
Generally the source of interesting constraints
Typically contain the attributes for the SQL answer set.

13. GB Video E-R Diagram Owner of Requestor of Holder of Name for Customer
#Cust No
F Name
L Name
Ads1
Ads2
City
State
Zip
Tel No
CC No
Expire
Rental
#Rental No
Date
Clerk No
Pay Type
CC Approval
Line
#Line No
Due Date
Return Date
OD charge
Pay type
Owner of
Video
#Video No
One-day fee
Extra days
Weekend
Title
#Title No
Name
Vendor No
Cost
Name for
Holder of

14. PK of the fact table is the cmbination of all Foreign Keys:
GB Video Data Mart
Customer
CustID
Cust No
F Name
L Name
Rental
RentalID
Rental No
Clerk No
Store
Pay Type
VideoRentalFact
LineID
OD Charge
OneDayCharge
ExtraDaysCharge
WeekendCharge
DaysReserved
DaysOverdue
LineNo
Video
VideoID
Video No
Title
TitleID
TitleNo
Name
Cost
Vendor Name
DateDim
ActualDate
DateID
SQLDate
Day
Week
Quarter
Holiday
Address
AddressID
Adddress1
Address2
City
State
Zip
AreaCode
Phone
CustID
AddressID
RentalId
VideoID
TitleID
RentalDateID
DueDateID
ReturnDateID
PK of the fact table is the cmbination of all Foreign Keys:
Due Date
Return Date
Rental Date
May also use lineid as PK or the concatenated PK

15. Fact Table Measurements associated with a specific business process
Grain: level of detail of the table
Process events produce fact records
Facts (attributes) are usually
Numeric
Additive
Derived facts included
Foreign (surrogate) keys refer to dimension tables (entities)
Classification values help define subsets

16. Dimension Tables Entities describing the objects of the process
Conformed dimensions cross processes
Attributes are descriptive
Text
Numeric
Surrogate keys
Less volatile than facts (1:m with the fact table)
Null entries
Date dimensions
Produce “by” questions

17. Business Model
As always in life, there are some disadvantages to 3NF:
Performance can be truly awful.
Most of the work that is performed on denormalizing a data model is an attempt to reach performance objectives.
The structure can be overwhelmingly complex. We may wind up creating many small relations which the user might think of as a single relation or group of data.

18. The 4 Step Design Process
Choose the Data Mart
Declare the Grain
Choose the Dimensions
Choose the Facts

19. Building a Data Warehouse from a Normalized Database
The steps
Develop a normalized entity-relationship business model of the data warehouse.
Translate this into a dimensional model. This step reflects the information and analytical characteristics of the data warehouse.
Translate this into the physical model. This reflects the changes necessary to reach the stated performance objectives.
Designing the Perfect Data Warehouse (the paper formerly known as: Data Modeling for Data Warehouses), Frank McGuff , 19

20. Structural Dimensions
The first step is the development of the structural dimensions. This step corresponds very closely to what we normally do in a relational database.
The star architecture that we will develop here depends upon taking the central intersection entities as the fact tables and building the foreign key => primary key relations as dimensions.

21. Steps in dimensional modeling
Select an associative entity for a fact table
Determine granularity
Replace operational keys with surrogate keys
Promote the keys from all hierarchies to the fact table
Add date dimension
Split all compound attributes
Add necessary categorical dimensions
Fact (varies with time) / Attribute (constant)

22. Converting an E-R Diagram
Determine the purpose of the mart
Identify an association table as the central fact table
Determine facts to be included
Replace all keys with surrogate keys
Promote foreign keys in related tables to the fact table
Add time dimension
Refine the dimension tables

23. Choosing the Mart A set of related fact and dimension tables
Single source or multiple source
Conformed dimensions
Typically have a fact table for each process

24. Fact Tables
Represent a process or reporting environment that is of value to the organization
It is important to determine the identity of the fact table and specify exactly what it represents.
Typically correspond to an associative entity in the E-R model

25. Grain (unit of analysis)
The grain determines what each fact record represents: the level of detail.
For example
Individual transactions
Snapshots (points in time)
Line items on a document
Generally better to focus on the smallest grain

26. Facts
Measurements associated with fact table records at fact table granularity
Normally numeric and additive
Non-key attributes in the fact table
Attributes in dimension tables are constants. Facts vary with the granularity of the fact table

27. Dimensions
A table (or hierarchy of tables) connected with the fact table with keys and foreign keys
Preferably single valued for each fact record (1:m)
Connected with surrogate (generated) keys, not operational keys
Dimension tables contain text or numeric attributes

28. ERD PRODUCT SKU (PK) description brand category CUSTOMER
customer_ID (PK)
customer_name
purchase_profile
credit_profile
address
ERD
ORDER-LINE
dollars_sold
units_sold
dollars_cost
ORDER
orderdate
STORE
store_ID (PK)
store_name
address
district
floor_type
CLERK
clerk_id (PK)
clerk_name
clerk_grade
PROMOTION
promotion_NUM (PK)
promotion_name
price_type
ad_type

29. DIMENSIONAL MODEL PRODUCT product_key (PK) SKU description brand
category
TIME
time_key (PK)
SQL_date
day_of_week
month
FACT
{time_key ||
store_key ||
clerk_key ||
product_key ||
customer_key ||
promotion_key} (PK)
dollars_sold
units_sold
dollars_cost
STORE
store_key (PK)
store_ID
store_name
address
district
floor_type
CUSTOMER
customer_key (PK)
customer_name
purchase_profile
credit_profile
address
CLERK
clerk_key (PK)
clerk_id
clerk_name
clerk_grade
PROMOTION
promotion_key (PK)
promotion_name
price_type
ad_type

30. Good Attributes Verbose Descriptive Complete Quality assured
Indexed (b-tree vs bitmap)
Equally available
Documented

31. Date Dimensions

33. Snowflaking & Hierarchies
Efficiency vs Space
Understandability
M:N relationships

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

35. Snowflake Schema dimSubCategory SubCategoryID Description dimCategory
ProductID
TimeID
CustomerID
SalesAmount
factSales
ProductID
CategoryID
Description
dimProduct

36. Simple DW hierarchy pattern.