[Mondrian] Course grained measure groups

Matt Campbell mcampbell at pentaho.com
Fri Feb 28 16:52:28 EST 2014

> ...I think the general approach for granularity should be the same as for dimensionality — if the measure doesn’t exist at the current attribute’s granularity, force the member to one where the measure exists. I think the effect would be very similar to ValidMeasure.
Yes, that does sound similar to ValidMeasure.  SSAS and IBM Dynamic
Cubes took the opposite approach with multi-granularity and set
attributes at lower granularity to NULL.  I guess ideally it should be
up to the schema designer whether to inherit higher level attribute
values or not.

> Now, we’d need to know that [Month] is functionally dependent on [Day]. (Do we have that?) And if [Month] and [Week] are both FD and both have a measure-group, we’d need to disambiguate. (Take whichever has the higher ordinal within the dimension, which is is presumably more granular. Week is in some sense “closer” to Day than Month. Yes this rule is somewhat arbitrary and we may revisit it in future versions.)

As far as I can tell, nothing establishes that dependence in Mondrian. 
SSAS uses attribute relationships for that purpose.  Dynamic Cubes uses
separate role-playing dimensions for each granularity, then merges the
dimensions together in a virtual cube.

>> 2)  If the join to the time dimension uses the_year & month_of_year,
>> won't measure values be inflated by the number of days?  I.e. since the
>> dim table will repeat the month_of_year value for each day in the month.
> I think this was a problem with virtual cubes also, when you joined a virtual cube at a non-leaf level. I don’t remember whether we solved it satisfactorily. The ideal solution would be to join to a select-distinct. In pseudo-SQL:
> select keys, aggregates
> from sales_by_month_by_product
> join (select distinct the_year, the_month from time_by_day)
> join product using (product_id)
> using (the_year, the_month)
> I don’t remember whether the mondrian-3 version does anything like that, or whether that is possible to do in mondrian-4.

The poor-man's approach for handling this problem is to use separate
dimension keys for the different granularities.  E.g. a month level
date_key in a date dimension table, with null values for day level
fields (alternatively choose an arbitrary day, like the first day of the
month).  That has the advantage of using a consistent key, so the shared
dimension does not need special handling, but leaves a day level #null
member with the value for that month.

More information about the Mondrian mailing list