Scribd
Upload
25 views12 pages

Dimensional Data Modeling - Lecture 3

Uploaded by

jhoncvivas
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
25 views12 pages

Dimensional Data Modeling - Lecture 3

Uploaded by

jhoncvivas
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/ 12

Dimensional Data Modeling

Lecture 3 – Dimensional Modeling


Considerations
Monster Dimensions

 Case where the dimension table is very large


(millions of rows) changes frequently and
contains a large number of attributes
 Example: Customer
 Assume there is a small set of variables that
change often Customer_Dim
•Name
•Address
•etc Sales_Fact

•Income
•Education
•Marital Status
•Etc.
2
Monster Dimensions

 Strategy: split the variables that change


frequently into own table.
 Need to ‘band’ continuous variables like salary
into ranges (20000-40000, 40000-60000, etc).
 Each variable on the new table needs to have
small number of variables.
 Need to create one row in the new table for
each combination of variables. Assume: 2
variables with 5 values each. How many rows
would be in the table?

3
Monster Dimensions

 Answer: 25 (5*5)
 The ‘base’ Customer_Dim
Customer •Cust_key
•Name Sales_Fact
Dimension table •Address
Cust_key
contains the key to •Demo_key
Demo_Key
the new table. Demo_Dim
Keys of both the •Demo_key
•Income_Range
new key and the •Education
are placed as •Marital Status

foreign keys on
fact table What happens when
customer income
changes?
4
Degenerate Dimensions

 Consider an order. What is the grain of


information we would want in a fact table?
 What information is left at the order level, other
than the information that we place in the fact
table (date, customer, product, quantity, etc.?)

5
Degenerate Dimensions

 The answer: probably only the order number.


 A degenerate dimension is one that has no
attributes other that the key value
 Strategy: make the order number an attribute
of the fact table. It will look like a dimension
key, but will not join to anything – it is just an
attribute.
 This allows us to perform analysis at the order
level (GROUP BY)
 What are some other degenerate dimensions?

6
Different types of facts

 There are multiple types: additive, semi-


additive and non-additive.
 Additive: can ‘add’ the values across all
dimensions (e.g., sales revenue).
 Semi-additive: Certain types of facts are not
‘perfectly’ additive but represent a snapshot at a
point in time (account balances, inventory
balances). These cannot be treated the same
as perfectly additive facts
 Non-additive: Some facts can be textual (non-
additive). Basically, can only count these.
Example of a non-additive fact?
7
Families of facts

 When designing a data warehouse, need to


think of the process to be supported.
 Its important to realize that this translates into a
set of related facts – a value chain. Examples:
 Inquiry  Order  Shipment Invoice  Return
Credit

8
Transaction and Snapshot Facts

 When the operations of an organization are


examined, its important to realize that most
organizations want to look at their information
on a transactional and a snapshot basis.
 Transaction basis: look at individual
transactions (inventory movement, sales, ATM
transactions, etc.). Allows analysis of patterns
of behavior (time of day analysis, market basket
analysis, etc.)

9
Transaction and Snapshot Facts

 Typically created in addition to a transaction


fact.
 Typically, create ‘snapshots’ at the end of
specific reporting periods (month-end, etc.)
 Rolling snapshot – continuously update then
‘publish’ – advantage spreads the work.
Example: monthly sales. Bank month end
account balance and monthly transaction
counts, etc.

10
Snapshot Example

ATM Activity Snapshot

A snapshot
(Foreign_Keys)
for ATM .
usage, by .
.
account, by Transaction count
month Account balance
Revenue_earned
Average_daily_balance
.
.

11
Factless Facts

 Type of fact where there is no real measure


(additive or otherwise)
 Typically factless facts related to events
 Attendance in class, for example
 Typically, add a dummy variable with value of 1
for purpose of counting

12

You might also like