1. Information from Evolving Data
Designing Slowly Changing Dimensions

2. Understanding the issue
Organization of Descriptive Data Evolves
Tampa may be in the Southern Florida one year, and Western Florida the next.
Parts may move from one Product Category to another.
Staff may transfer locations

3. Types of Slowly Changing Dimensions
As defined by Kimball:
Type 1
Update existing dimension member
Type 2
Create new record for any change
Type 3
Add fields for old values

4. Pros & Cons of each Type Type 1 Type 2 Type 3 Pro: Simple to implement
Con: Doesn’t support history
Type 2
Pro: Accurately track changes over time
Con: Complex to implement
Type 3
Pro: Some usefulness in Relational data warehouses
Con: Difficult to implement in Cubes

5. Sample BI Architecture
Sales Data
Sales Stager
Staging
Location Data
Location Stager
Location Dimension Loader
Sales Fact Loader
Data Warehouse
Cube
Processing Job

6. The Type 2 Solution
Track every change to each dimension member, and when it happened
Do this when you load dimension tables
Link facts to the correct version of dimension members at the desired point of time
Do this when you load fact tables
Dimension hierarchies are based on keys
Do this when you design the cube

7. Relational and Multidimensional Impacts
Changes must be made in both relational and multidimensional databases
Relational database must track versions of dimensional data
Cube must link facts to correct version of dimension members.

8. Relational Data Dimension table records must be date stamped
Each change to dimension member must create new record
Dimension table records must have an surrogate key
New Fact records must link to newest dimension records.
Historical Facts must link to newest key that’s older than Fact

9. Converting Staging to Dimension:
Staging Table
StoreCode
Business key
Unique
StoreName
Address
City
State
PostalCode
TimeStamp
Dimension Table
StoreKey
Surrogate key
Unique
StoreCode
Business key
StoreName
Address
City
State
PostalCode
DateStamp
Optional start & end dates

10. Dimension Loader Example
as int
= CONVERT(CHAR(8), GETDATE(), 112) ‘Example:
‘StoreKey is Identity, so there’s no need to insert it.
INSERT INTO dataWarehouse..Locations
SELECT StoreCode, StoreName, Address, City, State,
FROM staging..Locations L1
WHERE NOT EXISTS
(SELECT *
FROM Datawarehouse..Locations L2
WHERE L1. StoreCode = L2. StoreCode
AND L1. StoreName = L2. StoreName
AND L1. Address = L2. Address
AND L1. City = L2. City
AND L1. State = L2. State
AND L1. Zip = L2. Zip)

11. Converting Staging to Fact
Staging Table
SaleDate
ProductCode
LocationCode
SaleAmount
TimeStamp
Fact Table
SaleDateKey
ProductKey
LocationKey
SaleAmount
DateStamp

12. Finding the Right Foreign Key
INSERT INTO DataWarehouse..Sales
SELECT (blah blah blah) AS SaleDateKey,
(blah blah blah) as ProductKey
(SELECT MAX(LocationKey) AS LocationKey
FROM Locations L
WHERE L.StoreCode = S.StoreCode
AND L.DateStamp < S.DateStamp) AS LocationKey,
S.SaleAmount,
CONVERT(CHAR(8), GETDATE(), 112) AS DateStamp
From staging..Sales S

13. Multidimensional Data
Use a view to select dimension members.
Newest version of each Member
All versions of each Member
Not commonly used (Hierarchies look confusing)
Make sure leaf members are unique!
Options
Use key and name on leaf level
Names are not unique
Use key as leaf level, child of name level
set visible = false
Use ‘As Is’ query and use name as key
Trade fewer members for Character key

14. Locations Dimension Example 1

15. Example 1 issue:

16. Locations Dimension Example 2

17. Locations Dimension Example 3

18. Review Choose Type of Slowly Changing Dimension
Find out what your customer wants!
Manage Dimension Table Keys in Loader
Key on business code & date
Link Facts to Dimension Tables in Loader
Choose the correct key based on date
Pay attention to Dimension Leaf level
Make Keys & Names unique