Alternate drill down decision criteria

[dssd]

Is it recommended to have Alternate drill down if its is possible to do so. Essentially i have a scenario where one drill down is BU->Issuing  Area->Country->State and the other is BU->Producing Area->Country->State> How do i decide if i should keep it separate drill downs or as a n alternate drill down

[cognostechie]

The purpose of creating an alternate heirarchy is to reduce the number of categories in Transformer which improves the performance of the cube at the time a report is run and also reduces the time taken to build the cube. Reason - Every level in every dimension will have category codes associated with it when the cube is built. By creating an alternate heirarchy, you are using the same lower/lowest level. If you do not go this way and create a seperate dimension then in your case, Country and State will be present in both the dimensions which means category codes will be generated for Country and State twice because they belong to two dimensions that are seperate from each other.

The way you would decide it is if -

1> The lower levels in both the heirarchies can be the same
2> If the values from the top down can be unique (requirement of Transformer). The uniqueness here has a different meaning than the uniqueness in the database and there are ways to create MUNs in Transformer to make sure that the category coes become unique even if the data is not so.

In you scenario, I would recommend using an alternate heirarchy.

[dssd]

Thanks.. Have another question....If my application would have multiple cubes, are all based out of the same model, even if the cubes map to subject areas that are not related in a big way. For eg, if we have HR and Sales, then do they have the same model or two different models

[cognostechie]

If you are referring to the having the same Transformer Model, usually HR and Sales should be seperate models. The only time I would have multiple cubes using a common model would be when the source queries come out of the same package/IQD and that usually happens when you are dealing with the same subject area.

It is viable to have the same model in Framework Manager and publish it as seperate packages for seperate cubes. 

[dssd]

But, if its the same subject area then would we need to split the cube? this because if its the same subject area then the cube size, number of dimensions would probably be small

This also leads me to a question on when should we split cubes instead of one cube,...aah

[cognostechie]

But, if its the same subject area then would we need to split the cube? this because if its the same subject area then the cube size, number of dimensions would probably be smallThis also leads me to a question on when should we split cubes instead of one cube,...aah

Maybe in your case. It's not just about splitting the cube. You can create multiple cubes from the same model (cube groups) etc. Lot of companies have tons of data and their could be numerous situations when you would want to create multiple cubes for the same subject area. You have to determine yourself what is best in your case. While determining that, a little bit of forward thinking is also required.