Getting Started with Adobe After Effects - Part 6: Motion Blur


Upload Image Close it
Select File

Career advice for the IT professional
Browse by Tags · View All
SQLServerPedia Syndication 194
SQL Server 60
SSAS 40
#SQL SERVER 19
SSIS 18
2012/Denali 17
Career 17
Denali 14
SQL Server 2012 13
MDS/MDM 12

Archive · View All
June 2011 20
August 2011 15
July 2011 15
March 2012 15
October 2011 14
September 2011 14
May 2011 13
November 2011 12
February 2012 11
April 2012 10

James Serra's Blog

Degenerate Dimensions

Nov 16 2011 12:00AM by James Serra   

Degenerate dimensions, also called fact dimensions, are standard dimensions that are constructed from attribute columns in fact tables instead of from attribute columns in dimension tables.  This is because useful dimensional data is sometimes stored in a fact table to reduce duplication, especially when you have a very large fact table.

Think of a Sales fact table that contains a PurchaseOrder field and a CarrierTrackingNumber field.  In theory, you could create a dimension table that uses the same key information as the Sales fact table and move the other two attribute columns, PurchaseOrder and CarrierTrackingNumber, to that dimension table.  However, you would be duplicating a significant portion of data and adding unnecessary complexity to the data warehouse to represent just two attributes as a separate dimension.  Instead, create a fact dimension, which is easy to do is SSAS.

Note to use fact dimensions in SSAS you must have a primary key on the fact table.  And you may want to make this dimension using ROLAP to save space.

Fact dimensions are frequently used to support drillthrough actions because the drillthrough action in SSAS requires that you select the attributes from a dimension.  So if you users want to see certain fields when they do a drillthrough, you must have those fields in a dimension.  As an example using the Sales fact table mentioned above, a user may want to search through that table for a particular Purchase Order.  Once you add the fact dimension to the cube (and probably hide it from the users), you can include any of its attributes in the drillthrough action definition.

A user may request a bunch of fields to see via drillthrough that are in the fact table but not in a dimension, such as order address, ship to address, timestamp fields, etc.  When that happens I ask the user to use the source system instead (preferably via the application that uses the source data), but sometimes they don’t have access to the source system, only the cube.  In that case, degenerate dimensions come in handy.  But realize this could greatly increase cube processing time.

An alternate approach would be to call an SSRS report via the Reporting Action instead of using a drillthrough action.

More info:

Dimension Relationships

Degenerate Dimensions in Datamarts

Kimball Design Tip #46: Another Look At Degenerate Dimensions

Data Warehousing: Degenerate Dimensions


Republished from James Serra's Blog [70 clicks].  Read the original version here [32134 clicks].

James Serra
35 · 5% · 1664
0
Liked
 
0
Lifesaver
 
0
Refreshed
 
0
Learned
 
0
Incorrect



Submit

Your Comment


Sign Up or Login to post a comment.

    Copyright © Rivera Informatic Private Ltd Contact us      Privacy Policy      Terms of use      Report Abuse      Advertising      [ZULU1097]