1. Examines blended and separate transaction schemas
Ch 5 Procurement
Examines blended and separate transaction schemas
Slowly changing dimensions
Type 1, 2, 3, hybrids
Jan 2004
Ron McFadyen

2. Procurement questions
What materials are purchased most frequently?
How are our vendors performing?
Delivering on time?
Jan 2004
Ron McFadyen

3. Single schema approach
Grain of one row per procurement transaction
Blended – multiple transaction types
Date
Product
Proc Trans Fact
Contract terms
Vendor
Proc trans type
Jan 2004
Ron McFadyen

4. Procurement fact table
Procurement transaction type
Purchase orders
Shipping notices
Warehouse receipts
Vendor payments …
Complexities: discounts apply to payments but not other types; Many source systems would be involved
Many possible degenerate dimensions
Jan 2004
Ron McFadyen

5. Multiple Schema approach
Purchase requisition fact
Figure 4.2
Product
Contract terms
Date
Purchase order fact
Vendor
Shipping notices fact
Received condition
Employee
Warehouse receipts fact
Discount taken
Grain of one row per procurement transaction
Vendor payments fact
Jan 2004
Ron McFadyen

6. If a product is deleted, …
Managing dimensions
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 a product changes, we need to reflect the changes in the product dimension in the warehouse
If a product is deleted, …
Jan 2004
Ron McFadyen

7. Chapter 4 deals with slowly changing dimensions
Managing dimensions
We’ll classify dimensions according to the frequency with which the source data changes:
Slowly changing
Chapter 4 deals with slowly changing dimensions
Rapidly changing
Jan 2004
Ron McFadyen

8. Managing slowly changing dimensions
If a source field changes, and if we consider the dimension a slowly changing dimension, we have three basic approaches:
Type 1 Overwrite
Type 2 Create a new dimension record
Type 3 Add a dimension column
Jan 2004
Ron McFadyen

9. 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 2004
Ron McFadyen

10. 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
Said to partition history
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
Old facts are not altered
Jan 2004
Ron McFadyen

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

12. Predictable set of changes
Hybrids
Predictable set of changes
E.g. sales organization re-assigns districts every year
Sales Rep dimension has 5 values for each of current and 4 previous district assignments
Current district
Prior1 district
Prior2 district …
Jan 2004
Ron McFadyen

13. Unpredictable changes E.g. department assignment for a product
Hybrids
Unpredictable changes
E.g. department assignment for a product
Keep two values for department:
Current and historically accurate value
Type 1, type 2 and type 3  type 6
Example on page 104
Jan 2004
Ron McFadyen

14. Used for all dimensions as primary keys
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 2004
Ron McFadyen

15. Production/Natural 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 2004
Ron McFadyen