Named Hierachies

[Steve Rowe]

Named hierachies are something that has been talked of as piece of functionality that is missing from TM1 for some time. It appears that it is now in being looked at as piece of functionality that is being looked at (ref UK User conference).

Two questions then.
What would you use a named hierarchy for? I can't recall ever needing one....

I think that's becuase we already have named hierarchies, we just don't call it that. This leads to my next question.
How is a named hierachy different to the ElIsAnc functionality? Don't we already have named hierarchy functionality (even if it's scope is limited)? If I can test that an elements is somewhere below another element isn't that the first step in named hierachies?

Interested to hear from someone who has worked with an application that supports named hierachies or to hear of an example where functionality could not be delivered because named hierachies were not available in TM1.

Cheers,

[ScottW]

Every now and again there seems to be a request for generating hierarchy trees with explicitly named/fully qualified element paths. If a TM1 dimension has multiple top level hierarchies or elements appear several times within the same hierarchy then this can be quite tricky to do.

My take on this is that it wouldn't add much to TM1 in itself, but there would presumably be many advantages in compatibility with other products both OLAP and relational, MDX compliance, etc., etc.

[John Hobson]

It's not so much named heirarchies as named levels in hierarchies that I hanker after.

To be able to say !Product / Parent("product:department") or !Store / Parent("store:region") for example would be much more reliable than using elpar() type functions - especially whne the results of elpar are unpredictable when you create a dimension using TI.

J

[paulsimon]

Hi

I guess the only alternative is to use attributes to hold eg the Region for a Store, etc. This is an OK solution so long as the number of levels is not that great. The other alternative I have used is prefixing. For example in an Agent database we had several alternate hierarchies. We used a prefix for the elements of A_ at the base level, AG_ at the Agent Group level, etc. At least then, if you used ELPAR you could test whether parent number 1 was what you expected. However, in general attributes are more reliable and faster. But you probably already knew that.

An early version of 7 did have named hierarchies but then applix withdrew them.

You can use the option which from memory is called Copy Unique in the subset editor, which does give a fully qualified MDX path, but it is not pretty to look at.

Regards

Paul Simon

[Neil Watson]

Steve,

Named Hierarchies would be a great help to overcoming the usual issue of time dependant hierarchies, also talked about at the user conference but probably a larger and therefore longer implementation.
e.g.
Sales teams strucutre in May can be radically different to Sales Team structure in October.

Yes, I know I could have a top node consolidation which would read 'Sales Structure May 2008', but that doesn't necessarily help if I have a sales person who is in a different team now, as it has been said, climbing back up the Elisanc tree to find the appropriate hierarchy and then parent team, dept etc is awkward and cumbersome. (and not available natively in Excel anyway....different thread).

Obviously this can be applied to Store Groupings, Product analysis, General Ledger etc.

Food for thought

Cheers
Neil