Page 1 of 1

Version Dimension Best Practice

Posted: Wed Sep 18, 2013 8:59 am
by SRao
We’ve Region, Location, Version and Date dimensions in our application.

Whenever business user select particular region, location, start date and end date then data will save in one version. We have 200 business users all running the data in different start and end date then data will be saved each user different version. Some time data will be over lapped across the versions and cube size it will be increase the more size. Could you please let me know how to use the version dimension for best practice?

Example #1: User A
Region: South
Location: Chennai
Start Date: 01-Jan-2009
End Date: 31-Dec-2012
Based on above input data will be saved in Version_1 in Version dimension

Example #2: User B
Region: South
Location: Chennai
Start Date: 01-Jan-2008
End Date: 31-Dec-2012
Based on above input data will be saved in Version_2 in Version dimension

Here’s same data is overlapped between two versions. How to reduce the duplicate data between the versions because of my cube size increase the
more data based on versions.

Re: Version Dimension Best Practice

Posted: Wed Sep 18, 2013 9:24 am
by Harvey
It's hard to understand your design from your description. Could you explain a little more clearly what you are doing, how the version is selected/generated, and what you mean by data overlap? A few screenshots usually helps immensely.

Re: Version Dimension Best Practice

Posted: Wed Sep 18, 2013 10:00 am
by qml
SRao wrote:a
I would say it depends on your circumstances and you'll probably get many good answers. It's a splendid question, keep 'em coming. :roll:

PS: Could one of the Admins perhaps kindly restore the original question, please?

Re: Version Dimension Best Practice

Posted: Wed Sep 18, 2013 9:13 pm
by Alan Kirk
qml wrote:
SRao wrote:a
I would say it depends on your circumstances and you'll probably get many good answers. It's a splendid question, keep 'em coming. :roll:

PS: Could one of the Admins perhaps kindly restore the original question, please?
If you think it's worth it... OK!

Re: Version Dimension Best Practice

Posted: Wed Sep 18, 2013 9:27 pm
by Steve Rowe
A lot is going to depend on what you want to do with the data.
I'm assuming that the versions are there to keep the data entry distinct for each time period. If you don't need to keep the detail that is in the different versions then you could periodically (overnight say) accumulate the data that is on all the different versions onto a single version and then delete the temp version elements or perhaps just clear the data on them.

Its difficult to be more detailed than above without knowing a lot more about why you need to have the different versions and what the data will be used for. There is no such thing as best practice in your case, you are doing something fairly unusual.

Cheers,

Re: Version Dimension Best Practice

Posted: Sat Oct 12, 2013 9:01 pm
by java_to_tm1
Steve Rowe wrote:There is no such thing as best practice in your case, you are doing something fairly unusual
Am wondering if it is really all that unusual?
If your analysis was based on a rolling last-12-month history, then your July 2013 analysis would be based on data from July 2012 to Jun 2013, and August 2013 analysis would depend on data from aug 2012 to Jul 2013. Hence an 11 month overlap between August 2013 version and July 2013 version.

Of course, the answer to the primary question (is duplicity of data acceptable or not?) depends on how much data there is: 20 cells of data, I'd really not worry about one way or the other. If you intend to store a large amount of data (anything even remotely transactional in nature), I'd suggest that you take the version dim out of the picture altogether if the time/date dimension itself could help define the slice of data you need.