Scribd
Upload
170 views40 pages

The Data WareHouse ETL Toolkit - Chapter 05

This document discusses the structure and design of dimensions in a data warehouse. It covers the basic components of a dimension including a primary key, natural keys, and descriptive attributes. It also discusses dimension types such as date/time dimensions, slowly changing dimensions, and bridge tables used to model many-to-many relationships and ragged hierarchies. The document provides guidance on modeling dimensions to support accurate analysis and flexible reporting.

Uploaded by

abacus83
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
170 views40 pages

The Data WareHouse ETL Toolkit - Chapter 05

This document discusses the structure and design of dimensions in a data warehouse. It covers the basic components of a dimension including a primary key, natural keys, and descriptive attributes. It also discusses dimension types such as date/time dimensions, slowly changing dimensions, and bridge tables used to model many-to-many relationships and ragged hierarchies. The document provides guidance on modeling dimensions to support accurate analysis and flexible reporting.

Uploaded by

abacus83
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 40

VSV Training

Chapter 5: Delivering Dimension


Tables
Prepared By: Kien Tran
Date: 09/01/2008

5.1 The Basic Structure of a


Dimension

All dimensions should be physically built to


have the minimal set of components
A primary key (surrogate)
One or more natural keys
Set of descriptive attributes

5.1 The Basic Structure of a


Dimension (cont)

5.1 The Basic Structure of a


Dimension (Problems of Generating
Intelligent or smart keys fail (surrogate key) for
Surrogate
the followingKeys)
reasons:
By denition
Performance
Data type mismatch
Dependency on source system
Heterogeneous sources

5.2 The Grain of a Dimension


Dimensional modelers frequently refer to the

grain of a dimension.

5.3 The Basic Load Plan for a


Dimension
Dimension tables are de-normalized at

tables.
If a dimension is normalized, the hierarchies
create a characteristic structure known as a
snowake

5.4 Flat Dimensions and Snowaked


Dimensions

5.4 Flat Dimensions and


Snowaked Dimensions (cont)

5.5 Date and Time Dimensions


Virtually every fact table has one or more

time-related dimension foreign keys.

5.5 Date and Time Dimensions


(cont)

5.6 Big Dimensions


The most interesting dimensions in a data

warehouse are the big, wide dimensions.


The really big dimensions almost always are
derived from multiple sources.

5.6 Big Dimensions (cont)

5.7 Small Dimensions


Many of the dimensions in a data warehouse

are tiny lookup tables with only a few records


and one or two columns.

5.8 One Dimension or Two

5.9 Dimensional Roles

5.9 Dimensional Roles (cont)

5.9 Dimensional Roles (cont)

5.10 Dimensions as Sub


dimensions of Another Dimension
we have sometimes referred to these sub

dimensions as outriggers.

5.11 Degenerate Dimensions


Fact table may contain degenerate dimension

(order number) which is not additive but more


descriptive.

5.12 Slowly Changing


Dimensions
When the data warehouse receives
notication that an existing row in a
dimension has three basic responses: Type 1,
Type 2, and Type 3 slowly changing.

5.12.1 Type 1 Slowly Changing


Dimension (Overwrite)
A simple overwrite of one or more attributes

in an existing dimension record.

5.12.2 Type 2 Slowly Changing


Dimension (Partitioning History)

The standard basic technique for accurately

tracking changes in dimensional entities and


associating them correctly with fact tables.

5.12.2 Type 2 Slowly Changing


Dimension (Partitioning History)
(cont)

5.12.2 Precise Time Stamping of a


Type 2 Slowly Changing Dimension
(cont)
To add the following ve elds to dimension

tables processed with Type 2 logic:


Calendar Date foreign key (date of change)
Row Effective DateTime (exact date-time of
change)
Row End DateTime (exact date-time of next
change)
Reason for Change (text eld)
Current Flag (current/expired)

5.12.2 Precise Time Stamping of a


Type 2 Slowly Changing Dimension
(cont)

5.12.3 Type 3 Slowly Changing


Dimension (Alternate Realities)
A new column is created (if it does not already
exist), and the old value is placed in this new
eld before the primary value is overwritten.

5.13 Hybrid Slowly Changing


Dimensions

5.14 Late-Arriving Dimension


Records and Correcting Bad Data
A late-arriving dimension record presents a

complex set of issues for the data warehouse.

5.15 Multivalued Dimensions and


Bridge Tables

5.15 Multivalued Dimensions and


Bridge Tables

5.15.1 Administering the Weighting


Factors

5.15.2 Time-Varying Bridge Tables


Newrecords for a given accountwith newbegindate stamps and end-date stamps must be
added to the bridge table whenever:
The account record undergoes a Type 2
update
Any constituent customer record undergoes a
Type 2 update
A customer is added to or deleted from the
account or
The weighting factors are adjusted

5.15.2 Time-Varying Bridge Tables

5.15.2 Time-Varying Bridge Tables

5.16 Ragged Hierarchies and


Bridge Tables
There are two main approaches to modeling a
ragged hierarchy, and both have their pluses
and minuses:
The recursive pointer.
The hierarchy bridge table

5.16 Ragged Hierarchies and


Bridge Tables (The recursive
pointer approach)

5.16 Ragged Hierarchies and


Bridge Tables (The hierarchy bridge
table approach)

5.17 Technical Note:


POPULATINGHIERARCHY BRIDGE
TABLES

5.18 Using Positional Attributes in a


Dimension to Represent Text Facts

5.19 Summary
Dimension tables are almost always much

smaller than fact tables.


Dimension tables give the data warehouse its
texture and provide the entry points into the
universe of fact table measurements.

You might also like