January 25, 2008 08:25 PM

Data Warehousing: Rapidly Changing Monster Dimensions

Split monster dimensions and band frequently changing attributes
Rating: (0)
SQL Server Magazine
InstantDoc ID #97653

Executive Summary:
You'll need to plan carefully when dealing with monster dimensions because they consume large amounts of maintenance time and CPU cycles. You can manage rapidly changing monster dimensions by splitting the stable and hot attributes and then linking them through a fact table. You can also manage rapidly changing monster dimensions by banding the hot attributes, which is wh...

...This article is for paid Professional Members only.

Already a Professional Member? Please log in now:

NOT A PROFESSIONAL MEMBER? YOU CHOOSE:

Professional Membership

Monthly

Annual

VIP Membership

Monthly

Annual

Add a Comment

Hi,
In figure 2 how would you get data from the cube as of a particular date.
Example 1: I want to know the current count of customer from the fact table which should be 8 but its going to return 20 since there are 20 records.
Example 2: Number of customer as of 2007 which only returns 4 since only 4 records were added to the fact table in 2007 as those were the only customer who had updates.

Thanks.

Vamsi8/25/2008 5:06:38 PM


Although I have played with the monster dimension you discuss, I have settled on a couple of different approaches instead. If the things that describe the dimension item are finite, like a billing plan that is changeable, I may settle on a wide fact tables containing many dimension keys to describe a fewer number of facts. To me, splitting out descriptors by subject into new dimensions such as "salary", "geo", or "education" makes it easier for analysts to interpret at query time and supports a natural migration into an OLAP environment. Alternately, if it is a major data load, like from a market research firm, I will treat the combination of descriptors as one or more fact-less fact tables and use a conformed dimension to join them to an additive fact at query time. This is not dissimilar from what you propose except that it is going through the dimension rather than behaving as a peer. I even call it Fact.Demographics.

Vince3/13/2008 5:29:25 PM


You must log on before posting a comment.

Are you a new visitor? Register Here
GOOGLE LINKS
SPONSORED LINKS
FEATURED LINKS