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,
Named Hierachies
- Steve Rowe
- Site Admin
- Posts: 2417
- Joined: Wed May 14, 2008 4:25 pm
- OLAP Product: TM1
- Version: TM1 v6,v7,v8,v9,v10,v11+PAW
- Excel Version: Nearly all of them
Named Hierachies
Technical Director
www.infocat.co.uk
www.infocat.co.uk
-
- Regular Participant
- Posts: 152
- Joined: Fri May 23, 2008 12:08 am
- OLAP Product: TM1 CX
- Version: 9.5 9.4.1 9.1.4 9.0 8.4
- Excel Version: 2003 2007
- Location: Melbourne, Australia
- Contact:
Re: Named Hierachies
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.
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
- Site Admin
- Posts: 330
- Joined: Sun May 11, 2008 4:58 pm
- OLAP Product: Any
- Version: 1.0
- Excel Version: 2020
- Location: Lytham UK
- Contact:
Re: Named Hierachies
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
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
John Hobson
The Planning Factory
The Planning Factory
- paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: Named Hierachies
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
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
-
- Posts: 32
- Joined: Wed May 28, 2008 11:41 am
- OLAP Product: TM1
- Version: 6 and 2.5 to 10.2.2
- Excel Version: 2007 2010
- Location: Northern England
- Contact:
Re: Named Hierachies
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
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