Hi Gurus,
I have a requirement to add a few new attributes and the current dimension already has 60 attributes with 25K elements. I want to know the best practice surrounding the details. We are currently on 10.2.4 and will be on PA 2.0.4 very soon. What are the pros and cons? Specially when we can build alternate hierarchies with attributes on PA 2.0.4, I do not want to build something that can adversely effect the system. Can someone please give share their experiences?
Thanks,
Paul.
Good Practice on Attributes
-
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: Good Practice on Attributes
Hi
I suggest you search this forum on attribute hierarchies. They are probably best regarded as demo-ware. You will be better building hierarchies explicitly using the new TI functions such as HierarchyElementAdd. You essentially follow the same approach that you did with DimensionElementInsert and its related functions. You just use the ones with Hierarchy instead of Dimension and you obviously need to specify the Hierarchy as a parameter.
When I looked at our dimensions almost everything that was an attribute could be represented as a Hierarchy. However, that doesn't mean that you should not store attributes as well as hierarchies. It will depend on your particular application.
One point to debate is whether to use HierarchyDeleteAllElements or stick to unwinding the hierarchy as you probably did when using the conventional dimension approach. It is true to say that you cannot lose data as the element still exists in the dimension even if it is accidentally deleted from a hierarchy. However, if you create static subsets on Hierarchies then it will be lost from those. We will probably stick with unwinding the hierarchy and will handle orphans on a Hierarchy by Hierarchy basis.
We are building Meta Data Management tool before we really start using hierarchies. We are also waiting for development in the front end to catch up. Until you can properly pass parameters to Action Buttons in PAW we are sticking with TM1 Web. We can't see much benefit in embedding TM1 Web in PAW.
In PAX at least if you use an Exploration View, then you can definitely use one Hierarchy from a dimension on Columns and another Hierarchy from the same dimension on Rows. You can also nest Hierarchies on Rows or Columns, which potentially saves the need to build lots of alternate hierarchies in a conventional dimension to get the same result. You can also use asymmetric axes, eg next version within period but show only forecast for periods, and budget and forecast for full year. However, if you do that, then bizarrely you cannot automatically convert the exploration view to another type of report. I would have expected that if converting to a Dynamic Report (aka an Active Form) then it would just convert the column asymmetric MDX to static values but it just won't let you do the conversion.
It might be a different case if we were a greenfield site, but we have a lot of users trained in Perspectives and we want to ensure that we know about all the little quirks of PAX before we start to roll it out.
Regards
Paul Simon
I suggest you search this forum on attribute hierarchies. They are probably best regarded as demo-ware. You will be better building hierarchies explicitly using the new TI functions such as HierarchyElementAdd. You essentially follow the same approach that you did with DimensionElementInsert and its related functions. You just use the ones with Hierarchy instead of Dimension and you obviously need to specify the Hierarchy as a parameter.
When I looked at our dimensions almost everything that was an attribute could be represented as a Hierarchy. However, that doesn't mean that you should not store attributes as well as hierarchies. It will depend on your particular application.
One point to debate is whether to use HierarchyDeleteAllElements or stick to unwinding the hierarchy as you probably did when using the conventional dimension approach. It is true to say that you cannot lose data as the element still exists in the dimension even if it is accidentally deleted from a hierarchy. However, if you create static subsets on Hierarchies then it will be lost from those. We will probably stick with unwinding the hierarchy and will handle orphans on a Hierarchy by Hierarchy basis.
We are building Meta Data Management tool before we really start using hierarchies. We are also waiting for development in the front end to catch up. Until you can properly pass parameters to Action Buttons in PAW we are sticking with TM1 Web. We can't see much benefit in embedding TM1 Web in PAW.
In PAX at least if you use an Exploration View, then you can definitely use one Hierarchy from a dimension on Columns and another Hierarchy from the same dimension on Rows. You can also nest Hierarchies on Rows or Columns, which potentially saves the need to build lots of alternate hierarchies in a conventional dimension to get the same result. You can also use asymmetric axes, eg next version within period but show only forecast for periods, and budget and forecast for full year. However, if you do that, then bizarrely you cannot automatically convert the exploration view to another type of report. I would have expected that if converting to a Dynamic Report (aka an Active Form) then it would just convert the column asymmetric MDX to static values but it just won't let you do the conversion.
It might be a different case if we were a greenfield site, but we have a lot of users trained in Perspectives and we want to ensure that we know about all the little quirks of PAX before we start to roll it out.
Regards
Paul Simon