Drill Down in an inner dimension of two nested ones
Dear Pyramid-Team,
assuming the following situation:
Two dimensions are nested in the rows of a table grid (e.g. Customers as outer dimension and Products as inner dimension).
If I now perform a drill down on an element of the inner dimension, this will affect ALL elements of the outer dimension.
Excel, however, in this case is performing the drill down for only ONE element of the outer dimension (i.e. that one, in which the drill down in the inner dimension has been triggered).
Not easy to say, which behaviour is "better", but my question now is: Is there a way to make Pyramid handle such situation like Excel? Maybe I can even choose between both types of behaviour?
Many thanks in advance.
Kind regards
Markus
6 replies
-
We don't see such behavior in Excel - it works like Pyramid. Can you upload some screen shots of what you see and what you're doing. Also, what data source etc.
-
Sorry, my fault,
I misunderstood my client's description and did not try it out before writing the post.
There are no hierarchies nested, but just two attributes of two different dimensions. For example the country attribute of the customer dimension (outer) and the product name attribute of the product dimension (inner).
If you do such thing in Excel Pivot it looks like the inner attribute was a child level of the outer attribute (screenshot). And you can even use the expand button to collapse/expand the products, as if it were a real hierarchy and you did a drill-down/roll-up (second screenshot).
In Pyramid it looks like shown in the third screenshot.
-
-
This is very similar to the new eliminations option coming in 2020.10 (its the same "ragged" querying technique). But the way it works in Excel is slightly different - in that it creates a "virutal hierarchy" - and it seems to only work on flat attributes (no regular hierarchies), it can only operate on 2 levels (not more) and cannot hide/show measures.
Pyramid's eliminations doesn't have those limitations, but it will NOT operate or feel like a virtual hierarchy. One alternative is to create a regular hierarchy in Pyramid's modeling which will give you the same ragged hierarchical expand/collapse framework on any SQL source - but this is not an option for OLAP/BW cubes and MDX.
So, I think there is an interesting incremental idea here to consider for the road map.
