TM1 Forum

Hi,

I am trying to understand how hierarchies change the approach to building TM1 models.

I have an example of the 'old way' and wondered if in the world of hierarchies this old way was, well, old!

So in the example I have 2 cubes, CubeA and CubeB.

They have matching dimension except in CubeB there is a dimension called, Codes, which
is not in CubeA and in CubeA there is a dimension called CodeType which is not in CubeB.

Now in the Codes dimension there are thousands of elements and in the CodeType dimension there are only 4 elements.

I now create a rule in CubeA to bring in a value from CubeB and I need to match the CodeType dimension with the Codes dimension.
To achieve this I build 4 new rollups (consolidations) in the Codes dimension, so I create 4 consolidations, one for
each of the elements in CodeType and link the Codes elements to these consolidations.

That way I can now reference the !CodeType in the DB to CubeB, so something like

['Value']=N: DB('CubeB', !Year, !Version, 'All_Units', !CodeType, 'balance');

So in the above rule !CodeType does not exist in CubeB but because it exists as a consolidation in dimension Codes I can use this method
to retrieve the values.

So is this method still valid or does the new hierarchies in Planning Analytics make this method out of date?

And are there any good articles which can describe the difference that hierarchies bring to developing models?

Maren

You can still use this approach, but it would make more sense to just have 1 cube and ditch the rules and feeders. You add the Codes dimension to the cube. You have a couple of hierarchies in that dimension:
- the leaves (automatically by PA)
- a total with all leaves below
- a total with the 4 code types as consolidated children, containing the leaves as their children

You won’t gain a lot more from hierarchies in this case, since you are not likely to cross the code types with another attribute of the codes. If you would, hierarchies can give interesting new insights.

Lastly, hierarchies would also be beneficial when for instance, codes can change types over time. With time stamped hierarchies, you could analyse changes over time in an easy way. You drag the correct hierarchies in the view and you’re done.

The one cube approach did make more sense, thanks for your advice Wim