[Mondrian] PAGES axis, and attribute hierarchies

[Benny Chow]

I am thinking about this from a client MDX generation perspective so the use case I am trying to solve is where a user has an attribute (Year) on an axis (scenario A) and then wants to drill down into a Year-Quarter-Month hierarchy (scenario B) within the same dimension.

For scenario A, the axis expression would look something lile:  {[Time].[Year].Members}

Where [Time] is the dimension and [Year] is the attribute

The members that come out of this query look like: [Time].[2001], [Time].[2002] ... [Time].[2011]

For scenario B, the axis expression would look something like: {[Time].[Yr-Qtr-Month].[Quarter].Members}

Where [Time] is the dimension, [Quarter] is the attribute and [Yr-Qtr-Month] is the hierarchy.

The members that come out of this query look like: [Time].[Yr-Qtr-Month].[2001].[Q1],  [Time].[Yr-Qtr-Month].[2001].[Q2] ..  [Time].[Yr-Qtr-Month].[2011].[Q4]

Is this also what you are envisioning?

Benny


________________________________
From: Julian Hyde [mailto:julianhydepentaho at speakeasy.net]
Sent: Friday, August 05, 2011 1:44 AM
To: Benny Chow
Cc: Julian Hyde; 'Mondrian developer mailing list'
Subject: Re: PAGES axis, and attribute hierarchies


On Aug 3, 2011, at 8:39 AM, Benny Chow wrote:

>> a method "Hierarchy Level.getAttributeHierarchy()". Would that be sufficient to allow analyzer to decompose hierarchies?

I think this interface would need to return a list of Hierarchies since a single attribute can participate in many hierarchies.

Not true. Attribute hierarchies are special. There is one attribute hierarchy for each attribute, and it is system generated. (The schema designer may choose to make the attribute hierarchy invisible, but the relationship is still at-most-one.)

Of course the attribute can participate in other hierarchies too.

Suppose we get back a list of hierarchies, how would we know which level in the hierarchy does the current attribute level correspond with?  From a metadata perspective, a member needs to be able to identify its dimension (Product), attribute (SKU), hierarchy (SKU attribute vs Product Hierarchy) and hierarchy level.  In Mondrian 3.3, a member really only knows its hierarchy and hierarchy level.  There's no link to tell us that levels in different hierarchies are the same attribute.  In Mondrian 4, the client would need to know this information.

For the reasons I gave above, I think the many-to-one level-to-attribute-hierarchy relationship is sufficient.

>From a client perspective, if the user changes from an attribute hierarchy into another multi-level hierarchy, many things will need to happen.  First, the hierarchy level MDX would change from for example, [Product-SKU].[SKU] to [Product-Hierarchy].[SKU].  Second, the MDX members now have to become fully qualified in the new hierarchy.  For example, [Product-SKU].[SKU-XYZ] to [Product-Hierarchy].[ManufactureX].[DeptY].[FamilyZ].[SKU-XYZ].

Yes we need a way to map members. I believe that LinkMember is the MDX function to achieve this. For example, LinkMember([Time].[Monthly].[2011].[8].[4], [Time].[Month]) returns [Time].[Month].[8].

http://msdn.microsoft.com/en-us/library/ms146058.aspx

At any point in time, the user is not allowed to put levels from the same hierarchy on different axis but they may put attributes of the same level but different hierarchies on different axis.

I agree, except that "attributes of the same level" is meaningless. Attributes belong to dimensions, not to hierarchies or levels. But yes, distinct hierarchies can be used without restriction -- e.g. you could put [Time].[Monthly].[Year] on columns and [Time].[Weekly].[Year] on rows.

A general comment. Analyzer already presents a very 'attribute-oriented' view of the world. I think the main effect on analyzer is that the MDX will be easier to generate and process. The effect on the end-user will be less emphasis on hierarchies. Say a schema contained only attribute hierarchies, no non-trivial, multi-level hierarchies. The user could use Analyzer very effectively against that schema. The one thing they would lose would be the ability to drill down from one attribute to another (say double-click on 2011 to get the quarters in 2011). In Analyzer, it would be nice to have some visual indication of whether there is an automatic drill option for a given attribute value.

Julian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110807/4c3c21cf/attachment-0001.html