Hitachi Vantara Pentaho Community Forums
Results 1 to 4 of 4

Thread: [Mondrian] PAGES axis, and attribute hierarchies

  1. #1
    Julian Hyde Guest

    Default [Mondrian] PAGES axis, and attribute hierarchies

    Benny,

    I have opened this up the mondrian-dev list, as I think it gets to the core
    of the "attribute-oriented analysis" issue. Hope you don't mind.

    See reponses inline.



    [If analyzer supported a 3rd 'PAGES' axis, users would] want to split
    levels from the same hierarchy across axis. For example, in the Product
    Hierarchy, I want Product Family on the Page axis and Product Dept on the
    Rows axis. I don't think we can do this with Mondrian 3.3.

    It's not just the PAGES axis. If you have 3 years' data to display,
    sometimes it's nice to put years on columns and months on rows. It's more
    compact, and data for the same month in different years appears
    side-by-side.

    You can do a lot of this stuff manually in mondrian 3.3. You can create a
    {Product] dimension with a [Product] hierarchy consisting of levels
    [Manufacturer], [Dept], [Family], [SKU], and single-level "attribute
    hierarchies" [Manufacturer], [Dept] etc.

    There is currently no mapping between the Dept level of the product
    hierarchy and the Dept attribute hierarchy. But let's suppose there was: a
    method "Hierarchy Level.getAttributeHierarchy()". Would that be sufficient
    to allow analyzer to decompose hierarchies?

    Note that the schema designer would have had to create those attribute
    hierarchies, and mondrian would have to deduce the mapping somehow.

    Will this be possible with Mondrian 4.0?

    Yes, Mondrian 4.0 will allow you to define 'attributes' in your schema. It
    will be easy to create a hierarchy for an attribute. In fact, it will have
    its own hierarchy unless you set "hasHierarchy=false" in the attribute
    definition.

    And, when you define a hierarchy, you will just say "I want level X based on
    attribute A, level Y based on attribute B". You've already done the work
    defining keys, sort keys, properties when you define attributes.

    I don't know yet how to expose the mapping. But I note that XMLA's
    MDSCHEMA_LEVELS rowset has a LEVEL_ATTRIBUTE_HIERARCHY_NAME column. That
    maps nicely to the getAttributeHierarchy method above.

    The SQL generation will also need to be smart enough to know that both these
    levels come from the same dimension so there should be only one join to the
    underlying dimension table.

    It should already be smart enough. (Even if you define the single-level
    hierarchies manually.) Please log a bug if it isn't.

    Julian

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  2. #2
    Benny Chow Guest

    Default Re: [Mondrian] PAGES axis, and attribute hierarchies

    >> 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. 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.

    >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]. 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.


    ________________________________
    From: Julian Hyde [mailto:jhyde (AT) pentaho (DOT) com]
    Sent: Wednesday, August 03, 2011 2:32 PM
    To: Benny Chow; 'Mondrian developer mailing list'
    Subject: PAGES axis, and attribute hierarchies

    Benny,

    I have opened this up the mondrian-dev list, as I think it gets to the core of the "attribute-oriented analysis" issue. Hope you don't mind.

    See reponses inline.

    [If analyzer supported a 3rd 'PAGES' axis, users would] want to split levels from the same hierarchy across axis. For example, in the Product Hierarchy, I want Product Family on the Page axis and Product Dept on the Rows axis. I don't think we can do this with Mondrian 3.3.
    It's not just the PAGES axis. If you have 3 years' data to display, sometimes it's nice to put years on columns and months on rows. It's more compact, and data for the same month in different years appears side-by-side.

    You can do a lot of this stuff manually in mondrian 3.3. You can create a {Product] dimension with a [Product] hierarchy consisting of levels [Manufacturer], [Dept], [Family], [SKU], and single-level "attribute hierarchies" [Manufacturer], [Dept] etc.

    There is currently no mapping between the Dept level of the product hierarchy and the Dept attribute hierarchy. But let's suppose there was: a method "Hierarchy Level.getAttributeHierarchy()". Would that be sufficient to allow analyzer to decompose hierarchies?

    Note that the schema designer would have had to create those attribute hierarchies, and mondrian would have to deduce the mapping somehow.
    Will this be possible with Mondrian 4.0?
    Yes, Mondrian 4.0 will allow you to define 'attributes' in your schema. It will be easy to create a hierarchy for an attribute. In fact, it will have its own hierarchy unless you set "hasHierarchy=false" in the attribute definition.

    And, when you define a hierarchy, you will just say "I want level X based on attribute A, level Y based on attribute B". You've already done the work defining keys, sort keys, properties when you define attributes.

    I don't know yet how to expose the mapping. But I note that XMLA's MDSCHEMA_LEVELS rowset has a LEVEL_ATTRIBUTE_HIERARCHY_NAME column. That maps nicely to the getAttributeHierarchy method above.
    The SQL generation will also need to be smart enough to know that both these levels come from the same dimension so there should be only one join to the underlying dimension table.
    It should already be smart enough. (Even if you define the single-level hierarchies manually.) Please log a bug if it isn't.

    Julian

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  3. #3
    Julian Hyde Guest

    Default Re: [Mondrian] 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


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  4. #4
    Benny Chow Guest

    Default Re: [Mondrian] PAGES axis, and attribute hierarchies

    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 (DOT) 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


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.