Enabling hierarchies, how does it affect your current model?

Welcome to this instalment of our series on upgrading to Planning Analytics. If you’re here then you probably know about the new features that PA brings such as Workspace, hierarchies and multi-threaded feeders, but you’re hesitant about whether to implement the new features due to concerns about the impact on your current mature implementation. If this describes your situation then you are in the right place!

Before reading this article you should read our upgrade checklist and guide to new server configuration parameters.

You may have heard that if you choose to hierarchies you will need to rewrite your current model? Or that you will need to replace Perspectives and roll out PAx? Both are not true!

Perspectives continues to be supported as part of Planning Analytics Local and is included with PAL installation media. So if you stay with an on-premise model there’s no change here and you can continue to use Perspectives in Excel. Replacing Perspectives with PAx is only a must if transitioning to PA in the Cloud.

If you implement hierarchies in your existing model in new cubes with new dimensions then this will have precisely zero impact on all pre-existing rules and processes. If you do implement hierarchies in existing dimensions used in cubes then this can be achieved without any impact on existing TI processes (if new hierarchies are managed in new processes). No changes will be required to any processes used for data loading and clearing as all data is held at leaf level. Moreover, existing cube rules will only be impacted if same named consolidated elements exist in multiple hierarchies.

If alternate hierarchies are implemented this can have significant performance benefits for dimension maintenance of large dimensions as dimension unwinding is unnecessary if using hierarchies (as noted here). As all leaf elements are stored in a separate “Leaves” hierarchy there is no data loss if deleting all elements from the default hierarchy. As clearing a dimension via DeleteAllElements is far simpler and quicker than unwinding this is a significant potential time saving during dimension building operations.

Irrespective of developing new cubes, all existing cubes can potentially benefit from hierarchies via new reporting and analysis possibilities of transposing multiple hierarchies from the same dimension on a single grid. This can enable new analysis requirements to be supported without need for model redesign or any duplication of data.

For new cubes the impact of hierarchies can be more profound as cubes can be designed with fewer dimensions which allow for both faster query times and reduced memory consumption (for an explanation as to why refer to this article.)

Via a few tricks with MDX it is possible to analyse results from alternate hierarchies in an active form. However, analysing hierarchies in this way is limited to filter conditions with only default hierarchies being allowed on rows or columns. For true exploration with multiple hierarchies from the same dimension stacked or arranged on both x and y axes PAx or the Workspace cube viewer is needed.

The bottom-line that implementing hierarchies in any dimensions already used in productive cubes will not break any existing reports. They will continue to work exactly as before. The only limitation is that reports in Perspectives and TM1Web will be unable to properly utilize the new hierarchies.

As noted above it is possible to implement hierarchies without needing to change any existing TurboIntegrator code as the hierarches can be managed in new independent processes. However, also as mentioned above, there is a possibility that rules may need to be changed in existing cubes to avoid ambiguous name references. This situation will occur if some specific conditions are met:

1. The cube contains C rules referencing consolidated elements in the dimensions which have had alternate hierarchies added
2. The element names specified in the C rules now exist in multiple hierarchies

This situation is obviously easy to avoid by implementing unique names for C elements across hierarchies. For more information on rules syntax for hierarchies see the articles here for a basic introduction and here for more complex use cases.

Enabling hierarchies on your existing TM1 model after upgrading to v11 of itself will not impact your model at all. It is definitely possible to “quarantine” hierarchies only to new application areas and not touch existing dimensions or cubes. However, in most cases this approach doesn’t really make sense as there is much more value to be gained by adding hierarchies to existing dimensions. As we have seen there is no requirement to change any existing TI processes when implementing hierarchies. In the majority of cases, there will also be no requirement to edit existing rules.

So ff you have an on-premise installation of TM1 have been worried about the effect on existing models on upgrading to Planning Analytics Local you can put your mind at ease. Any impacts on your model are both minor and manageable.