1. Dimensional Model January 16, 2003
Ch 5
Dimensional Model
Figure 5.3 Generating a report from a star schema
Use MS Access database in class
Jan 2003
Ron McFadyen

2. Dimensions and attribute hierachies
Store dimension
Address hierarchy
Store key
Name
Store number
Store street address
City
Store county
Store state
Store zip
Sales district
Sales region …
Store sqft
Grocery sqft
Frozen sqft
Meat sqft
Zip
State
County
City
Street address
Store
Sales area hierarchy
Region
District
Store
Jan 2003
Ron McFadyen

3. Dimensions and attribute hierarchies
Time dimension
calendar hierarchy
Date key
Date
Day of week
Week number
month
year
Fiscal week
Fiscal month
Fiscal quarter
Fiscal year …
year
month
date
fiscal hierarchy
Fiscal year
Fiscal quarter
Fiscal month
Fiscal week
Date
Jan 2003
Ron McFadyen

4. Dimensions and attribute hierarchies
Page
Figure 5.4 shows how a dimension can have several hierarchies in it.
Product dimension
Product Key
SKU
Description
Marketing brand
Marketing category
Finance brand
Finance category
Package type
Size
Flavor
Stack height
Case count
Marketing hierarchy
Finance hierarchy
Jan 2003
Ron McFadyen

5. These artificial keys serve as foreign and primary keys
Snowflake Dimensions
Hierarchies can be removed from the dimension and placed in other tables
“the low cardinality fields in the dimension … removed to separate tables and linked back into the original table with artificial keys
These artificial keys serve as foreign and primary keys
Results in the dimension being more normalized
Consider the Product dimensions shown in figures 5.4 and 5.5. What normal form are they in?
Jan 2003
Ron McFadyen

6. Snowflake Dimensions Product dimension
Page Figure 5.5 shows how a snowflaked dimension
Marketing brand key
Marketing brand
Marketing category key
Product dimension
Product Key
SKU
Description
Marketing brand key
Finance brand key
Package type
Size
Flavor
Stack height
Case count
Marketing category key
Marketing category
Marketing brand key
Finance brand
Finance category key
Finance category key
Finance category
Jan 2003
Ron McFadyen

7. Snowflaking is generally not recommended because:
Snowflake Dimensions
Snowflaking is generally not recommended because:
User presentation becomes more complex – queries require us to access more tables
Browsing of dimension rows is slower
Snowflaking does not save significant amounts of space
Snowflaking may defeat the usefulness of bitmap indexes
We’ll ignore ‘useful’ snowflaking (p 173) until later
Jan 2003
Ron McFadyen

8. Calendar subdimensions
Page
To adapt the Time/Date dimension for usage related to several countries:
Full date
Country
Date key
National Calendar n 1
Time
Holiday name
Holiday flag
The National Calendar table will have a PK comprising Date key and Country
Religious holiday flag
Jan 2003
Ron McFadyen

9. If a product is deleted, …
Managing dimensions P
The data stored in dimensions originally comes from the legacy systems. Changes that occur in the legacy system must be reflected in the data warehouse:
If a new product is being sold, it must be added to the product dimension in the warehouse.
If an old product changes, we need to reflect the changes in the product dimension in the warehouse
If a product is deleted, …
Jan 2003
Ron McFadyen

10. Managing dimensions
We’ll classify dimensions according to the frequency with which the source data changes:
Slowly changing
Rapidly changing
Jan 2003
Ron McFadyen

11. Managing slowly changing dimensions
Page
If a source field changes, and if we consider the dimension a slowly changing dimension, we have three approaches:
Type 1 Overwrite the dimension record with the new values
Type 2 Create a new dimension record with a new surrogate key value
Type 3 Create an ‘old’ field in the dimension record to store the immediately previous value
Jan 2003
Ron McFadyen

12. Overwrite the dimension record with the new values
Type 1
Overwrite the dimension record with the new values
Used whenever the old value of the attribute is of no importance
Definitely applicable if a value changes because of a correction
Jan 2003
Ron McFadyen

13. Create a new dimension record with a new surrogate key value
Type 2
Create a new dimension record with a new surrogate key value
Commonly used approach
e.g. suppose a customer moves
We may still want to associate the sales to the customer’s old address
In this case we create a new customer record with the customer’s new field values
This new customer record will have a new surrogate key
Jan 2003
Ron McFadyen

14. Type 3
Create an ‘old’ field in the dimension record to store the immediately previous value
Jan 2003
Ron McFadyen

15. Degenerate dimensions
Page
There are some dimensions for which we have no descriptive details.
This typically occurs for things like invoices, purchase orders, transactions, …
Instead of having a separate table for this dimension, the key is placed directly in the Fact table.
The primary key of the degenerate dimension logically belongs as part of the fact tables primary key
Jan 2003
Ron McFadyen

16. Used for all dimensions as primary keys
Page
Surrogate keys
Used for all dimensions as primary keys
Note that most dimensions should have a special row for “unknown”. Examine our sample Promotion dimension; there is one row for “No Promotion”
Smart Keys
A smart key is a key that is a single attribute with components that have meaning to end users
This should be avoided and broken down into distinct fields
Jan 2003
Ron McFadyen

17. Do not use as keys in dimension tables – use surrogate keys instead
Page
Production keys
Do not use as keys in dimension tables – use surrogate keys instead
Production, or legacy, keys could be reused on the operational side. The warehouse DBA has no control over those sorts of issues.
If companies merge or are acquired, duplicates could arise.
Surrogate keys get around the difficulties of using production keys in the warehouse.
Jan 2003
Ron McFadyen

18. Facts: Additive, Semi-additive, Non-additive
Page
Facts are measurements that users will apply arithmetic calculations to
What is the average of …
What is the total of …
A fact is additive if it is meaningful to add that fact over any dimension.
Consider the sales dollar amount. Consider each of the Promotion, Store, Date, Product, and Transaction dimensions. It makes sense to sum that metric over any of these.
Sales dollar amount is additive
Jan 2003
Ron McFadyen

19. Facts: Additive, Semi-additive, Non-additive
Facts that measure a level (or intensity) may not be additive.
Consider quantity on hand for a product in a warehouse at a point in time.
We could meaningfully sum this over products
We could meaningfully sum this over warehouses
But it doesn’t make sense to sum this over time. Quantity on hand is semi-additive
A fact is semi-additive if it is meaningful to sum it over some dimensions, but not all
Jan 2003
Ron McFadyen

20. Facts: Additive, Semi-additive, Non-additive
A fact is non-additive if it cannot be meaningfully summed over any dimension
Consider a fact table with student averages
Meaningful values are obtained by averaging these, not by summing them
Averages would be non-additive
Jan 2003
Ron McFadyen