[Mondrian] Same dimension in different axis

Pedro Alves pedro at neraka.no-ip.org
Thu Jul 16 19:13:38 EDT 2009



This is *great* news, and will affect a lot of the development that we'll
do tomorrow.


The cdf team (cdf == community dashboard framework, a project that allows
an easy way to build dashboards in pentaho) is working on a cdf editor that
will be very closely connected to mondrian, and the engine will generate
selector, charts, tables, etc, while the user only has to drag and drop
dimensions / levels in a GUI. 


When will this be available? I don't mind working with a build from source
or even try to implement this myself.  Am I being too naive to think that
all I need is to go to the block that checks if a member is used in more
than one dimension and comment that out? :)



ps: I remember a while back Julian twitting about the possibility to use
sets in the where clause. How is the syntax? I tried it recently and still
got an error. This would be great to avoid an extra member definition with
just an aggregate();




-pedro


On Thu, Jul 16, 2009 at 12:48:17PM -0700, Julian Hyde wrote:
>    I agree. This has been on our backlog for some time. Matt Campbell has
>    been pushing for it in particular. It didn't quite make the cut for 3.1.
>    Inexplicably there was no issue logged for it -- at least, I couldn't find
>    one -- so I logged [1]http://jira.pentaho.com/browse/MONDRIAN-578.
> 
>    If we do this, there's no reason why people shouldn't start using
>    'attribute hierarchies'. Attribute hierarchies are more of a schema design
>    style than a feature. The result is that hierarchies are clustered into a
>    small number of dimensions. For example, [Gender] and [Marital Status]
>    would both become hierarchies within the [Customer] dimension.
> 
>    We did half of the work for 3.1: cleaning up how mondrian resolves
>    members, levels and hierarchies when there are multiple hierarchies, and
>    making it consistent with SSAS 2005. Without that work, using attribute
>    hierarchies would have been tricky.
> 
>    This will be in the next release of mondrian.
> 
>    Julian
> 
>    --------------------------------------------------------------------------
> 
>      From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
>      On Behalf Of Brian Vandenberg
>      Sent: Thursday, July 16, 2009 8:20 AM
>      To: Mondrian developer mailing list; Pedro Alves
>      Subject: Re: [Mondrian] Same dimension in different axis
>        I agree with Pedro on this, even with using the same dimension on
>      rows/columns.  If I want information broken out by month & day of week,
>      as it stands I'd have to settle for one of:
> 
>      * Break it out on one axis and live with it -- while I can't easily see
>      relationships between events that occur on mondays every month, there's
>      not much I can do about it otherwise.
>      * Create either a mirrored date dimension or a day of week dimension
>      ** The mirrored date dimension could easily create confusion with
>      users.  There's that saying "keep it simple, stupid".  More dimensions =
>      more complexity.
>      ** The day of week dimension would suffice, but has some problems:
>      *** requires yet another dimension key on my fact table.  If my fact
>      table has many dimensions, more than one of which I'd like to use at
>      different levels of aggregation on different axes, this bloats the fact
>      table
>      *** I would probably have to remove day of week from the date dimension,
>      which might be annoying under other circumstances where I want the date
>      dimension to have both month & day of week.  The date dimension can have
>      multiple drill-down paths, but that also creates more options for users
>      -- and users don't like too many options
>      * Just break it out on one axis, then write custom code to iterate over
>      the query results in a different sequence than presented
> 
>        For whatever reason, it's easier for people to wrap their heads around
>      few columns with many rows, than many rows and fewer columns.
>      Additionally, it'd be easier to see trends or patterns by applying the
>      day of week on a different axis from the month.
> 
>        While it's true a report or visualization would be _capable_ of
>      presenting the information in whatever way it sees fit, it'd be nice for
>      the [report/visualization] developer, and for those tech savvy users
>      with just enough knowledge to design simple queries.
> 
>        I see this as code re-use.  Why create 5 dimensions to represent the
>      same concept in different ways when one dimension would suffice if you
>      have more flexibility in its use.
> 
>      -Brian
> 
>      On Thu, Jul 16, 2009 at 4:06 AM, Pedro Alves <[2]pedro at neraka.no-ip.org>
>      wrote:
> 
>        Hey there.
> 
>        Is there a way to remove the restriction of not having the same
>        dimension
>        in more than one axis?
> 
>        I'm working on a dashboard generator that dynamically integrates with
>        mondrian, but this is a very bad restriction if I want users to apply
>        whatever filters they want. The following query is an example of the
>        type
>        of stuff I'd love to be able to do:
> 
>        select
>         Descendants([Products], [Products].[Version]) on rows,
>         Measures.[Downloads] on columns
>        >From ...
>        where
>         ([Dates].[Date].[2009-07-16],
>          [Products].[Firefox].[3.5],
>          [Download Types].[Complete])
> 
>        Instead, I need to do
> 
>        select
>         Descendants([Products].[Firefox].[3.5], [Products].[Version]) on
>        rows,
>         Measures.[Downloads] on columns
>        >From ...
>        where
>         ([Dates].[Date].[2009-07-16],
>          [Download Types].[Complete])
> 
>        In terms of plain queries this is not complicated; But in a scenario
>        where
>        the users is free to choose whatever dimensions he wants to chart
>        against
>        whatever conditions he wants to filter, my algorithm to generate the
>        query
>        gets much more complicated than I'd like
> 
>        And I don't think there's a reason for this restriction; There were
>        projects where I've defined in the mondrian schema the same dimension
>        duplicated just to be able to do what I need. Another example is here:
>        [3]http://tinyurl.com/kk9b2b . Having to define a [Time2] dimension
>        that's
>        absolutely identical to [Time] to obtain a very standard crosstab
>        information.
> 
>        Any tips appreciated
> 
>        -pedro
> 
>        _______________________________________________
>        Mondrian mailing list
>        [4]Mondrian at pentaho.org
>        [5]http://lists.pentaho.org/mailman/listinfo/mondrian
> 
> References
> 
>    Visible links
>    1. http://jira.pentaho.com/browse/MONDRIAN-578
>    2. mailto:pedro at neraka.no-ip.org
>    3. http://tinyurl.com/kk9b2b
>    4. mailto:Mondrian at pentaho.org
>    5. http://lists.pentaho.org/mailman/listinfo/mondrian

> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian


-- 
Pedro Alves
pmgalves-at-gmail.com




More information about the Mondrian mailing list