Hitachi Vantara Pentaho Community Forums
Results 1 to 5 of 5

Thread: [Mondrian] Non collapsed AggLevel support in Mondrian

  1. #1
    Luc Boudreau Guest

    Default [Mondrian] Non collapsed AggLevel support in Mondrian

    Fellow mondrian developers,

    Yesterday, I've checked in a nifty new feature for aggregate tables. I
    called it non-collapsed AggLevel.

    Before, when using a snowflake dimension with an aggregate table, you
    needed to either include all the top levels keys inside of the
    aggregate table, or use the AggForeignKey element. The first option
    had the problem of making the aggregate table implicitly "bound" to
    that particular set of keys, The second forced the use of the key at
    the lowest level in the hierarchy. This was very unpractical so today
    we're introducing a new way to design aggregate tables.

    Non-collapsed aggregate levels are represented in your schema like so:

    <AggName name="agg_3">
    <AggFactCount column="cnt"/>
    <AggMeasure name="[Measures].[Unit Sales]" column="sls"/>
    <AggLevel name="[Time].[Year]" column="yer"/>
    <AggLevel name="[Time].[Quarter]" column="qtr"/>
    <AggLevel name="[Time].[Month]" column="mth"/>
    <AggLevel name="[Channel.Network].[Brand]" column="brn"
    collapsed="false"/>
    </AggName>

    In the example above, the level [Channel.Network].[Brand] is mapped to
    the column "brn", but its parent levels keys are not part of the
    aggregation table. At runtime, Mondrian will figure out the parent
    tables to join to and make sure that all the upper levels are included
    as well. In a scenario where the dimension is a web of snowflake
    dimension tables, this has the advantage of making the "brn" column
    re-usable for each dimension or hierarchy which uses it. Better yet,
    this also works with the automatic aggregate table recognizer.

    If you would like more information (as well as a nice diagram), you
    can get it at:

    http://perforce.eigenbase.org:8080/@...gregate_Levels

    We are planning to release this feature some time in the following
    weeks after some more testing and a few work iterations. If you are
    interested in helping us with this new feature, feel free to contact
    us.

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

  2. #2
    Nicholas Goodman Guest

    Default Re: [Mondrian] Non collapsed AggLevel support in Mondrian

    On Oct 30, 2011, at 5:14 PM, Luc Boudreau wrote:

    > aggregation table. At runtime, Mondrian will figure out the parent
    > tables to join to and make sure that all the upper levels are included
    > as well. In a scenario where the dimension is a web of snowflake
    > dimension tables, this has the advantage of making the "brn" column
    > re-usable for each dimension or hierarchy which uses it. Better yet,
    > this also works with the automatic aggregate table recognizer.


    Does this new feature require that the level that is the target of the "collapsed" AggLevel be a level with uniqueMembers="true" and is this enforced (or at least checked)? ie, without this restriction I'm not sure how you'd be able to use the table to build accurate results.

    - year
    -- qtr
    2007/Q1
    2007/Q2
    2007/Q3
    2007/Q4
    2008/Q1
    2008/Q2
    2008/Q3
    2008/Q4

    In the above case the qtr level (column) isn't unique and so if included in the aggregate table by itself, without the parent keys, it wouldn't actually allow the agg table to be used to generate accurate results. I simply can't think of any way to generate SQL that would build accurate results unless omitting the parent keys unless uniqueMembers = "true" for that level.

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

  3. #3
    Luc Boudreau Guest

    Default Re: [Mondrian] Non collapsed AggLevel support in Mondrian

    Nick,

    Thanks for the review. You are right. It was previously assumed that
    the keys needed to be unique, but as you pointed out, we already have
    means of validating it is the case. I've fixed the code and added unit
    tests to enforce this.

    Cheers!

    Luc

    On Mon, Oct 31, 2011 at 7:34 PM, Nicholas Goodman
    <ngoodman (AT) bayontechnologies (DOT) com> wrote:
    >
    > On Oct 30, 2011, at 5:14 PM, Luc Boudreau wrote:
    >
    >> aggregation table. At runtime, Mondrian will figure out the parent
    >> tables to join to and make sure that all the upper levels are included
    >> as well. In a scenario where the dimension is a web of snowflake
    >> dimension tables, this has the advantage of making the "brn" column
    >> re-usable for each dimension or hierarchy which uses it. Better yet,
    >> this also works with the automatic aggregate table recognizer.

    >
    > Does this new feature require that the level that is the target of the "collapsed" AggLevel be a level with uniqueMembers="true" and is this enforced (or at least checked)? ie, without this restriction I'm not sure how you'd be able to use the table to build accurate results.
    >
    > - year
    > -- qtr
    > 2007/Q1
    > 2007/Q2
    > 2007/Q3
    > 2007/Q4
    > 2008/Q1
    > 2008/Q2
    > 2008/Q3
    > 2008/Q4
    >
    > In the above case the qtr level (column) isn't unique and so if included in the aggregate table by itself, without the parent keys, it wouldn't actually allow the agg table to be used to generate accurate results. I simply can't think of any way to generate SQL that would build accurate results unless omitting the parent keys unless uniqueMembers = "true" for that level.
    >
    > Nick
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >

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

  4. #4
    Rolf Lear Guest

    Default Re: [Mondrian] Non collapsed AggLevel support in Mondrian

    Hi Luc.

    I am trying to figure out how much of that web-document is new, and how
    much is old... specifically in relation to the combined aggregates and
    closures side of things.

    As far as I know the combined aggregate/closure support does not work at
    all. I have reviewed documentation (years ago) similar to what you have
    linked, and found that the actual behaviour was not as documented. I
    filed a JIRA at the time, MONDRIAN-510. Does your work in this area of
    code actually fix this issue, do you know? I know there was some
    'administrative' movement recently on that JIRA (not sure what actually
    changed), but, if you are in the same 'head-space' now, it may be a good
    time to investigate the 510 issue.

    Thanks

    Rolf

    On 10/30/2011 08:14 PM, Luc Boudreau wrote:
    > Fellow mondrian developers,
    >
    > Yesterday, I've checked in a nifty new feature for aggregate tables. I
    > called it non-collapsed AggLevel.
    >
    > ....
    > If you would like more information (as well as a nice diagram), you
    > can get it at:
    >
    > http://perforce.eigenbase.org:8080/@...gregate_Levels
    >
    > ...



    --------------------------------------------------------------------------
    This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
    --------------------------------------------------------------------------
    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  5. #5
    Julian Hyde Guest

    Default Re: [Mondrian] Non collapsed AggLevel support in Mondrian

    On Oct 31, 2011, at 5:16 PM, Rolf Lear wrote:

    > I am trying to figure out how much of that web-document is new, and how
    > much is old... specifically in relation to the combined aggregates and
    > closures side of things.
    >
    > As far as I know the combined aggregate/closure support does not work at
    > all. I have reviewed documentation (years ago) similar to what you have
    > linked, and found that the actual behaviour was not as documented. I
    > filed a JIRA at the time, MONDRIAN-510. Does your work in this area of
    > code actually fix this issue, do you know? I know there was some
    > 'administrative' movement recently on that JIRA (not sure what actually
    > changed), but, if you are in the same 'head-space' now, it may be a good
    > time to investigate the 510 issue.


    I reviewed http://jira.pentaho.com/browse/MONDRIAN-510, which relates to aggregate tables with parent-child hierarchies. As I commented on the bug, I very much doubt that it is fixed by Luc's changes.

    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.