Kimball Forum
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Rapidly changing Monster dimension...

3 posters

Go down

Rapidly changing Monster dimension... Empty Rapidly changing Monster dimension...

Post  VK Tue Nov 17, 2009 12:49 pm

Hi Everyone,

I have a list of more than 300 attributes, which are actually part of the fact table….(basically ..these values changes for each transaction level record in fact but belongs to a single dimension).
that lot contains more than a 100 date attributes,.. around a 50 monetary values, more than 10 comments…n some flags.

If I put Date surrogate keys into fact table for all these date values …it definitely clutters…the fact.
Will that affect the performance????..the idea of linking date table with more than 100 attributes..making me feel un easy!!....

Or shall I make a Junk dimension out of all these attributes and link this with fact value …
Then the result will look like..

Attribute Value
Attr1 XXXX
Attr2 XXXX

Certainly, we cannot aggregate the monetary values across dimensions…..

But,..Is there any way…we control these monster …rapidly changing values??

not sure .. How I explained it….but,…please let me know if it needs more clarity..


Posts : 2
Join date : 2009-11-16

Back to top Go down

Rapidly changing Monster dimension... Empty Very Large Dimension

Post  Vincent Rainardi Thu Nov 19, 2009 11:57 am

Hi VK, I can't think of a business scenario where a single transaction has 100 dates, but, that aside, I think in principal you need to split that monster mart into, either a) to several marts (several fact tables), or b) still 1 mart (fact table) but split that big dimension into several dimensions (by business context).
HTH, Vincent

Vincent Rainardi

Posts : 6
Join date : 2009-02-03
Location : London

Back to top Go down

Rapidly changing Monster dimension... Empty Re: Rapidly changing Monster dimension...

Post  tim_huck Thu Nov 19, 2009 7:17 pm

You are not using the term Junk dimension as described in Kimball. To build a junk dimension, you take a group of attributes and create a dimension row for every distinct combination of the values of those attributes. The attributes grouped as one junk dimension are determined by analyzing your data and finding how many unique combinations there are for various sets of fields. Pick the sets of fields to try out based on how the business process works, though you may end putting elements together that the business doesn't consider to be clesely related, just because they make a well-behaved dimension. I like to call these "incrementally built" dimensions rather than "junk".

About dates, with so many dates it's not likely that report users will need all the features of a date dimension for every one of them. You should be able to get agreement on some subset of them where features like the day-month-quarter-year hierarchy and/or translation between fiscal and calendar dates are needed, then store the rest as dates. If you move most or all of these less important dates to new junk dimensions, you can store each one as several columns, such as date data type, year, and month. This will give you some of the benefits you get from a date dimension without so many joins and key lookups.


Posts : 8
Join date : 2009-04-09
Location : Evanston, Illinois

Back to top Go down

Rapidly changing Monster dimension... Empty Re: Rapidly changing Monster dimension...

Post  Sponsored content

Sponsored content

Back to top Go down

Back to top

- Similar topics

Permissions in this forum:
You cannot reply to topics in this forum