1. Retail Sales is used to illustrate a first dimensional model
Chapter 2
Retail Sales is used to illustrate a first dimensional model
Design process
Case study: POS example
Star schema
Facts
Dimensions
Creating the schema in SQL Server
Factless facts
Degenerate dimensions
Extensibility
Snowflaking
Outriggers
January 2004
Ron McFadyen

2. The Dimensional Design Process
4 Step Dimensional Design Process
Select the business process, examples: invoicing, orders, inventory, general ledger, …
Declare the grain. Determine exactly what an individual fact table row represents. Examples: a line item on an order, a boarding pass to get on a flight, a student’s course registration, a monthly snapshot for a bank account.
Choose the dimensions that apply to the facts. What describes each fact. Examples: customer dimension, student dimension, course dimension, day dimension.
Identify the numeric facts that appear in the rows of the fact table.
January 2004
Ron McFadyen

3. The business process: POS retail sales
Case Study
Case Study
The business process: POS retail sales
Grain of the fact table: individual line items on a POS transaction
The dimensions: date, product, store, promotion
The facts: sales quantity, cost dollar amount, sales dollar amount, gross profit dollar amount (derivable)
January 2004
Ron McFadyen

4. A typical drawing seen in practice, in articles, …
Case Study Schema
Date
Product
Sales facts
Store
Promotion
A typical drawing seen in practice, in articles, …
January 2004
Ron McFadyen

5. Case Study Schema in Peter Chen Notation1 1
Product
Date n n
Sales facts n n n
Store
Promotion 1 1 1
Sales Transaction
Note: Sales transaction does not appear in text. Later in chapter it is discussed as a degenerate dimension
January 2004
Ron McFadyen

6. Facts can be described as additive, non-additive, semi-additive.
Case Study Fact Table
Sales facts
Sales quantity
Sales dollar amount
Cost dollar amount
Gross profit dollar amount
Additive
Facts can be described as additive, non-additive, semi-additive.
Additive: can be meaningfully summed across all dimensions
Semi-additive: …………………….. across some dimensions
Non-additive: can’t be …
The text discusses some non-additive facts that might be included in such a fact table: gross margin, unit price
January 2004
Ron McFadyen

7. Case Study Fact Table The physical table: Sales facts Date key (FK)
Product key (FK)
Store key (FK)
Promotion key (FK)
POS Transaction Number (degenerate dimension)
Sales quantity
Sales dollar amount
Cost dollar amount
Gross profit dollar amount PK
January 2004
Ron McFadyen

8. Case Study Date Dimension
Very descriptive
Easy to set criteria for queries
Easy to get headings for reports
One row for each day (this is the grain of the Date dimension)
PK is a surrogate key
Used in every star schema
Hierarchies are present
Not normalized
attribute hierarchy
Calendar week  …
Fiscal week  …
Date key (PK)
Date
Full date description
Day of week
Day number in epoch
Week number in epoch
Month number in epoch
Day number in calendar month … ….
Last day in week indicator
Holiday indicator
Weekday indicator
SQL date stamp …
Calendar week
Calendar month
Calendar year
Fiscal week
Fiscal month
Fiscal year
January 2004
Ron McFadyen

9. Case Study Product Dimension
Very descriptive
Easy to set criteria for queries
Easy to get headings for reports
One row for each product for sale, or ever sold, by the company
PK is a surrogate key. We do not use the operational PK here. Over time it may not be unique: the business may re-use keys, companies merge …
Not normalized
An attribute hierarchy
Brand  category  department
Product key (PK)
Product description
SKU number
Brand description
Category description
Department description
Package type description
Package size
Fat content
Diet type
Weight
Weight units of measure …
January 2004
Ron McFadyen

10. Case Study Drilling Down/Up
Product
Run a query to generate:
Department, sales amount, sales quantity
Now, add another attribute at a ‘lower’ level such as brand:
Department, brand, sales amount, sales quantity
What is meant by row-headers (in the text)?
Product key (PK)
Product description
SKU number (natural key)
Brand description
Category description
Department description
Package type description
Package size
Fat content
Diet type
Weight
Weight units of measure …
January 2004
Ron McFadyen

11. Case Study Store Dimension
Very descriptive
Easy to set criteria for queries
Easy to get headings for reports
One row for each store
PK is a surrogate key.
Not normalized
An attribute hierarchies
city  county  state  zip
district  region
How does the text handles the “First open date” attribute?
Store key (PK)
Store name
Store number (natural key)
Store street address
Store city
Store county
Store state
Store zip code …
Total square footage
First open date
January 2004
Ron McFadyen

12. Case Study Promotion Dimension
Very descriptive
Easy to set criteria for queries
Easy to get headings for reports
One row for each promotion
PK is a surrogate key.
Need a special row for “no promotion in effect”
Why?
Promotion key (PK)
Promotion name
Price reduction type
Promotion media type
Ad type …
January 2004
Ron McFadyen

13. A factless fact table has no measurement metrics.
Factless Fact Tables
A factless fact table has no measurement metrics.
These types of fact tables record occurrences of events.
In retail sales, one might ask
“What products were on promotion, but did not sell?”
The Sales facts table only records sales, and so it alone is not enough to answer this question.
January 2004
Ron McFadyen

14. How many rows are in Coverage? How many rows in Sales Facts?
Factless Fact Tables
Consider
Date
Product
Coverage
Store
Promotion
The Coverage table has one row for each promotion of a product at some store on a certain date.
How many rows are in Coverage?
How many rows in Sales Facts?
January 2004
Ron McFadyen

15. What is the SQL to determine:
Factless Fact Tables
Consider
Date
Product
Coverage
Store
Promotion
What is the SQL to determine:
“What products were on promotion, but did not sell?”
January 2004
Ron McFadyen

16. Degenerate Dimensions
A degenerate dimension is one where the only attribute of interest is the natural key. As a result, there is no physical dimension in the data warehouse.
e.g. Transaction number in Retail Sales
Transaction can be shown as a dimension in the logical design, but there is no Transaction table in the physical design. The fact table has a transaction number (instead of a surrogate key to a Transaction dimension)
January 2004
Ron McFadyen

17. Degenerate Dimensions
Sales facts
Date key (FK)
Product key (FK)
Store key (FK)
Promotion key (FK)
POS Transaction Number (DD)
Sales quantity
Sales dollar amount
Cost dollar amount
Gross profit dollar amount PK
Degenerate Dimension
January 2004
Ron McFadyen

18. Degenerate Dimensions
Very common in star schema designs
Orders
Invoices …
In many systems where there are “line items”, there is some interesting operational key that can tie the facts back to the operational systems: order#, invoice#, …
January 2004
Ron McFadyen

19. Extensibility of Star Schema Designs
In many cases we can add:
New dimension tables
New fact tables
New aggregates
New dimension attributes
New measurement metrics
without changing existing applications
January 2004
Ron McFadyen

20. Extensibility of Star Schema Designs
In many cases we can add dimensions to an existing design and database.
Consider Retail Sales and the new dimensions: Frequent Shopper, Clerk, Time of Day
Is the Frequent Shopper concept valid?
Is knowing who the clerk is reasonable?
Do we know the time of day for a sale?
Any way of describing a fact that is single-valued for all existing facts in the fact table, could become a dimension. What is required in the database environment to accomplish this?
January 2004
Ron McFadyen

21. Extensibility of Star Schema Designs
What is required in the database environment to extend a star schema with a new dimension?
Alter table … may be complex – at the least we are adding an attribute
Create table … create a new dimension
Load the new dimension …
Populate the new foreign key in the altered fact table
Create an ETL process for the new dimension
Modify the ETL process for the fact table
January 2004
Ron McFadyen

22. If a dimension is normalized, we say it is a snowflaked design.
Snowflaking
If a dimension is normalized, we say it is a snowflaked design.
Consider the Product dimension, and suppose we have the following functional dependencies:
January 2004
Ron McFadyen

23. The Product dimension is in _____________ normal form.
Snowflaking
Product key
SKU number
Product description
Brand key
Brand description
Category key
Category description
Department key
Department description
The Product dimension is in _____________ normal form.
January 2004
Ron McFadyen

24. Now, the Product dimension is in _____________ normal form.
Snowflaking
Date
Product
Brand
Category
Department
Sales facts
Store
Promotion
Now, the Product dimension is in _____________ normal form.
The general problem is that this complicates the user’s view of data, complicates the underlying SQL, defeats the usefulness of bit vectors, minimally decreases space requirements, and queries execute slower.
January 2004
Ron McFadyen

25. Outriggers Date Product Sales facts Date Store Promotion
Date is called an outrigger table for Store. Note there is only one Date table
Store was shown to have two dates: First open date and Last remodel date
Instead of being attribute values from the Date domain, these can be foreign keys to the Date dimension.
January 2004
Ron McFadyen

26. Outriggers Date Product Sales facts Date Store Promotion
Same table
Date
Product
A fact will join to one row of Date and one row of Store, but these two rows of Date are usually different rows.
Sales facts
Date
Store
Promotion
Outrigger
Outriggers are an acceptable variation on normalized dimensions. They are justified because they add a great deal to the expressive capability of queries.
January 2004
Ron McFadyen