[Mondrian] Same dimension in different axis

Julian Hyde jhyde at pentaho.com
Thu Jul 16 15:48:17 EDT 2009


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  <http://jira.pentaho.com/browse/MONDRIAN-578>
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 <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:
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
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20090716/4245164a/attachment.html 


More information about the Mondrian mailing list