Hi all,
I'm new to TM1 and MDX, so please bear with me if I'm not phrasing this correctly, but I'm trying to create a subset using MDX that will return all 0 level elements that don't have their parent at level 1 - anyone know how to do this? I've spent the better part of the day online looking for this, but I think my lack of MDX experience is making it difficult to "see" the solution. Thanks
MDX for 0 level elements with no level 1 parent
-
- Community Contributor
- Posts: 324
- Joined: Mon Jul 02, 2012 9:39 pm
- OLAP Product: TM1
- Version: PAL 2.0.8
- Excel Version: 2016
- Location: Sydney, Australia
Re: MDX for 0 level elements with no level 1 parent
In reverse, children of an empty parent :
{FILTER({TM1FILTERBYLEVEL( {TM1SUBSETALL( [DimName] )}, 0)}, [DimName].CurrentMember.Parent.Name = '')}
{FILTER({TM1FILTERBYLEVEL( {TM1SUBSETALL( [DimName] )}, 0)}, [DimName].CurrentMember.Parent.Name = '')}
Re: MDX for 0 level elements with no level 1 parent
OK, I think I see how/why that's working, but it only returns level 0 elements that have no parent at all, correct? What about level 0's that have no level 1 parent but do have a parent at level 2,3,4, etc.? Am I missing something? It seems like there would be a way to identify the level of the element's parent (something like currentmember.parent.level.ordinal <>1 or something like that, but that's not working for me (again, I'm a total newb with TM1, so it could be I'm just not understanding the syntax or something along those lines). Thanks again
-
- MVP
- Posts: 2836
- Joined: Tue Feb 16, 2010 2:39 pm
- OLAP Product: TM1, Palo
- Version: Beginning of time thru 10.2
- Excel Version: 2003-2007-2010-2013
- Location: Atlanta, GA
- Contact:
Re: MDX for 0 level elements with no level 1 parent
TM1 has ragged hierarchies, what you are looking for is structured hierarchies. You would have to add dummy parents to fill out the missing levels.ramjam wrote:OK, I think I see how/why that's working, but it only returns level 0 elements that have no parent at all, correct? What about level 0's that have no level 1 parent but do have a parent at level 2,3,4, etc.? Am I missing something? It seems like there would be a way to identify the level of the element's parent (something like currentmember.parent.level.ordinal <>1 or something like that, but that's not working for me (again, I'm a total newb with TM1, so it could be I'm just not understanding the syntax or something along those lines). Thanks again
Last edited by tomok on Tue Sep 20, 2016 4:59 pm, edited 2 times in total.
Re: MDX for 0 level elements with no level 1 parent
Yes, sorry the part about ragged hierarchies wasn't clear in my initial post - I did not realize that was relevant. So the solution is to add a "dummy" parent to the elements that don't have a natural parent - that's what I was originally thinking I'd like to do, but that makes it a much bigger project than I was hoping. Thanks for the replies Evegney and tomok!!
- 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: MDX for 0 level elements with no level 1 parent
Hi Ramjam
What you are asking seems odd.
If you have a ragged hierarchy then by definition any level 0 element, ie the bottom of the hierarchy, that does not have a level 1 parent, also does not have a level 2 parent. Putting in dummy parents to fill out the levels is not going to help because there won't be any parents for these elements.
What are you actually trying to do? For example in my dimension build routines I typically link any base level elements that have no parent up to an Orphan consolidation and this then links to the All Hierarchies consolidation so that at least the All Hierarchies consolidation will include every element in the dimension. Therefore selecting the All Hierarchies consolidation means that I get the total of everything in the dimension. It also means that I can easily identify elements without a parent. They are the children of the Orphan consolidation. I can then go back to the business and ask what the parent should be and make the appropriate changes. That is a lot easier than having a hierarchy that does not add up with the risk of incorrect results being produced, and needing to write a complex MDX statement to identify the orphaned elements. So perhaps the real answer is to address this at the time that you build the dimension, which is probably going to be infrequent, and it therefore doesn't really need a dynamic MDX statement.
If my guess as to the reason why you want to do this is way off, and you do need to identify elements according to a level tag of some sort, then an MDX approach would be like this.
Select elements that have the tag you want, eg if you add an Attribute called Level - Just record a Filter by Attribute statement, eg filter by attribute level = 1. Save that as a subset Level1
Next write an MDX statement based on that subset {TM!FILTERBYLEVEL( { TM1DRILLDOWNDIMENSION( { [dim].[Level1] } , ALL , RECURSIVE ) } , 0 ) }
Which will get you all base level elements below the Level1 elements. Save as subset Level1_Base
Then record a simple Show All and filter by level 0 and save as a subset called Base.
Then write MDX as
{EXCEPT( { [dim].[Base] } , { [dim].[Level1_Base] } )
The EXCEPT statement gives the difference between two sets ie what is in Set A that is not in set B.
As illustrated above when building more complex MDX it can be useful to write the MDX in parts and save each part as a named subset that you can test independently and possibly re-use as a building block for other expressions.Referencing the subset in later MDX statements just needs { [Dim Name].[Subset Name] }
Regards
Paul Simon
What you are asking seems odd.
If you have a ragged hierarchy then by definition any level 0 element, ie the bottom of the hierarchy, that does not have a level 1 parent, also does not have a level 2 parent. Putting in dummy parents to fill out the levels is not going to help because there won't be any parents for these elements.
What are you actually trying to do? For example in my dimension build routines I typically link any base level elements that have no parent up to an Orphan consolidation and this then links to the All Hierarchies consolidation so that at least the All Hierarchies consolidation will include every element in the dimension. Therefore selecting the All Hierarchies consolidation means that I get the total of everything in the dimension. It also means that I can easily identify elements without a parent. They are the children of the Orphan consolidation. I can then go back to the business and ask what the parent should be and make the appropriate changes. That is a lot easier than having a hierarchy that does not add up with the risk of incorrect results being produced, and needing to write a complex MDX statement to identify the orphaned elements. So perhaps the real answer is to address this at the time that you build the dimension, which is probably going to be infrequent, and it therefore doesn't really need a dynamic MDX statement.
If my guess as to the reason why you want to do this is way off, and you do need to identify elements according to a level tag of some sort, then an MDX approach would be like this.
Select elements that have the tag you want, eg if you add an Attribute called Level - Just record a Filter by Attribute statement, eg filter by attribute level = 1. Save that as a subset Level1
Next write an MDX statement based on that subset {TM!FILTERBYLEVEL( { TM1DRILLDOWNDIMENSION( { [dim].[Level1] } , ALL , RECURSIVE ) } , 0 ) }
Which will get you all base level elements below the Level1 elements. Save as subset Level1_Base
Then record a simple Show All and filter by level 0 and save as a subset called Base.
Then write MDX as
{EXCEPT( { [dim].[Base] } , { [dim].[Level1_Base] } )
The EXCEPT statement gives the difference between two sets ie what is in Set A that is not in set B.
As illustrated above when building more complex MDX it can be useful to write the MDX in parts and save each part as a named subset that you can test independently and possibly re-use as a building block for other expressions.Referencing the subset in later MDX statements just needs { [Dim Name].[Subset Name] }
Regards
Paul Simon
-
- Community Contributor
- Posts: 324
- Joined: Mon Jul 02, 2012 9:39 pm
- OLAP Product: TM1
- Version: PAL 2.0.8
- Excel Version: 2016
- Location: Sydney, Australia
Re: MDX for 0 level elements with no level 1 parent
Merely tried to demonstrate how you can achieve it with MDX, i.e If you don't have 1st parent then by default you have no further parents. Does it make sense?What about level 0's that have no level 1 parent but do have a parent at level 2,3,4, etc.?
On the other hand if you are trying to establish child-parent relationships based on a level of the parent, you would have to go down a different avenue, as suggested by others here already.
Curious, what is the purpose of this requirement?
Thanks
ET
- qml
- MVP
- Posts: 1096
- Joined: Mon Feb 01, 2010 1:01 pm
- OLAP Product: TM1 / Planning Analytics
- Version: 2.0.9 and all previous
- Excel Version: 2007 - 2016
- Location: London, UK, Europe
Re: MDX for 0 level elements with no level 1 parent
Due to TM1's ragged hierarchies and the way in which it numbers its levels, it is entirely possible for an N element (which is always level 0) to have a parent that is on level 2 or 3, but have no parent on level 1. Take this hierarchy example:EvgenyT wrote:Merely tried to demonstrate how you can achieve it with MDX, i.e If you don't have 1st parent then by default you have no further parents. Does it make sense?
C3
..C2
....NA
....C1
......NB
NA and NB are both leaf elements, C1, C2, C3 are consolidations. According to TM1's 'classic' (i.e. pre-PM) level numbering method C3 is on level 3, C2 is on level 2, C1 is on level 1. NA and NB are both on level 0. NB has its only parent on level 1. NA has its only parent on level 2.
Due to the lack of exposure of that definition of 'level' in MDX I would suggest the best method of using it in MDX (if one really must) would be to do as Paul suggests - add an attribute that would store the level and populate it via TI so that you can reference it directly in MDX.
Kamil Arendt