April 20, 2011 at 2:57 am
Hi,
Currently a customer who wants to gather all kinds of measures from already built stars and sometimes sources that needs to be extracted and build. I'm currently building a starmodel on one of the sources and i'm thinking about to extent the functional meaning of star/cube to other measures/KPIs.
What is the best option:
* built one star in SQL and a cube in analysis (merging all the measures in SQL).
* built multiple stars in SQL and a cube in analysis (merging all the measures in cube).
* built multiple stars in SQL and multiple cubes in analysis (merging all the measures in reports?).
What is the best choice in my situation? i think i can split the different measures in measuregroups in analysis cubes. Currently i'm think about one star and one cube beacause this is very specific solution for a department with limited budget.
What do you think?
Hennie
April 20, 2011 at 3:10 am
having all sorts of measurable data in one pot(cube) is bar far a bad practice....kudos to performance management
You may consider specific cubes creation for specific reporting solutions.
Raunak J
April 20, 2011 at 3:49 am
Without knowing more about the business it is difficult to say for sure.
But I would always favour One cube and one datawarhouse to power the cube, unless there is a compelling business reason not too.
April 20, 2011 at 5:04 am
okay, i agree this is not a desireable situation to implement multiple different measures in a cube. The alternative is building multiple cubes?! That would mean you need to define the common denominator between the cubes?! So when i'm building a report on multiple cubes i need to join the different measures by the common denominator?
Hennie
April 20, 2011 at 5:26 am
What is the problem with having multiple measures per cube? surely you would not build a cube per measure.
As you have outlined one cube makes more sense, because then you use the common dimensions to link the data
April 20, 2011 at 5:30 am
The discussion boils down to the following:
1. One cube with sparse facts
2. Multi-cube with relevant facts
Raunak J
April 26, 2011 at 7:59 am
Raunak Jhawar (4/20/2011)
The discussion boils down to the following:1. One cube with sparse facts
2. Multi-cube with relevant facts
It is my opinion that a well modeled single cube with multiple and diverse measure brings great value to your client. Your client may be surprised that certain measures which are generally considered by the business users as functionally unrelated, may indeed share some common dimensionality. There is where your hidden gems are found and where your client experiences unexpected ROI. Marketing might not think there is any value in combining sales promotion data with raw material inventories and accounts receivable, but finance may want to kiss you!
When multiple business units bring seemingly un-relatable requirements to a BI effort, their only concern is that they have the tools and data required to answer their current burning questions. What they do not realize is that once their burning questions are answered, there will always be a new set of burning questions, the answers to which will uncover even more questions. This is in fact one of the reasons the client has commissioned a BI project to begin with. Otherwise, they would tell you to "just go write a report!".
Chris Umbaugh
Data Warehouse / Business Intelligence Consultant
twitter @ToledoSQL
April 27, 2011 at 3:48 am
The key issue in deciding if something can be in one cube or broken out is the granularity of the item measured. If the measures are on the same grain, or can be conformed to the same grain, they should be in the same cube to maximize the views possible (as one of the previous posters has said, sometimes seemingly unrelated items have a relationship). If the measures do not exist at the same level of granularity or cannot be conformed to that, then they must be different cubes, with a different supporting schema, or else your values would be off.
When I saw the data can be conformed, it is normally best to measure data at the atomic level to facilitate drill throughs. There are situations, however, such as when measuring against forcasts, where summarys must be created to bring the totals in line with the granularity of the forecast data.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply