[Mondrian] ValidMeasure() combined with Aggregate()

Julian Hyde jhyde at pentaho.org
Wed Nov 21 07:24:22 EST 2007


 > Julian Hyde wrote:
 > I don't understand why it is necessary to eliminate duplicate 'all'
members. Can you explain in more detail why this is necessary? 
Ajit wrote:
In aggregate evaluation 
With [Measures].[Unit Sales] and a set like this 
([Gender].[All Gender].[M],[Warehouse].[All Warehouses].[USA].[CA]), 
([Gender].[All Gender].[F],[Warehouse].[All Warehouses].[USA].[CA]), 
([Gender].[All Gender].[M],[Warehouse].[All Warehouses].[USA].[WA]), 
([Gender].[All Gender].[F],[Warehouse].[All Warehouses].[USA].[WA]) 

When we pull up the non joining Warehouse dimension, it becomes 
([Gender].[All Gender].[M],[Warehouse].[All Warehouses]), 
([Gender].[All Gender].[F],[Warehouse].[All Warehouses]), 
([Gender].[All Gender].[M],[Warehouse].[All Warehouses]), 
([Gender].[All Gender].[F],[Warehouse].[All Warehouses]) 
and we get duplicates  

Your example implies that the duplicate members are a problem when you are
evaluating sets - i.e. to display on axes. But if I understand correctly,
ValidMeasure is used when calculating a cell. I'm still wondering how this
all fits into the cell evaluation process. I would think that when mondrian
evaluates a cell in a virtual cube which doesn't depend on the [Warehouse]
dimension, it would just ignore the [Warehouse] dimension (i.e. remove it
from the evaluator's context, creating a context with N-1 members rather
than the usual N), so it doesn't matter what the value of the [Warehouse]
dimension is. Can you explain the evaluation steps in more detail?


> Would it make more sense to add it as a property of VirtualCubeMeasure, or
to add a new element VirtualCubeCubeUsage? Or the simplest thing would be to
add it to the VirtualCube itself. 

Adding it on the VirtualCube itself will rule out the possibility of having
combination of measures with and without IgnoreUnrelatedDimensions in the
same VirtualCube 

I think adding it to VirtualCubeMeasure will be fine grain and too verbose.
Adding a VirtualCubeCubeUsage could be optimal. Are there any other
attributes that we can add to this element? If there are no other attributes
then how about something like following in the VirtualCube? 


        <Cube name="Sales" /> 

        <Cube name="HR" /> 


There are no additional attributes of VirtualCubeCubeUsage right now. We
could potentially allow a cube to be used several times joining to different
dimensions (e.g. join a cube of exchange rates once on the date the order
was placed, and once on the date the order was invoiced) analogous to
including a table multiple times in a SQL WHERE clause with different
As we make the virtual cubes model more powerful, we are discovering that we
need a more fine-grained metamodel, in virtual cube dimension usages for
example, so I think this is worth doing.
I suggest
<VirtualCube name=...>
    <CubeUsage cubeName="Sales"/>
    <CubeUsage cubeName="Warehouse" ignoreUnrelatedDimensions="true" />
(VirtualCubeCubeUsage is just too verbose!) The CubeUsages and CubeUsage
elements would be optional.  If not specified, the system would create them
automatically. So it amounts to your <IgnoreUnrelatedDimensions>, but we can
extend it in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20071121/c0741bef/attachment.html 

More information about the Mondrian mailing list