Tuesday 8 October 2013

SSAS: MDX True Average VS AverageOfChildren

Recently I was tasked with working on some slow performing calculations in a cube.  In the Calculation script a developer had used the DECENDANTS function, with the LEAVES flag to navigate all the way down to the bottom of several dimensions' hierarchies. He had then used AVG across the returned set for a specified measure, effectively aggregating all the way back up again.

All the developer actually wanted to do was to have a measure that returned the average value for the current member selection.  By going down to the leaf level and then backup, however, the cube is having to scan through a potentially huge volume of data to produce the answer. Inevitably this will result in degraded query performance for users.

In fact this can be a lot simpler to do than people realise.  True, SSAS 2008R2 still does not supply an inbuilt function to do this, which surprises many new users. One day maybe it will,  but in the meantime here is how I do it.

First, it should be pointed out that there is a certain "type" of averaging that SSAS does support out of the box.  If you look at the options in the AggregationFunction property for a measure you will see that, although by default set to Sum, there is also one option called AverageOfChildren. This name is very misleading.  It is not a true average as I would understand.  It is actually an average only across the Time dimension.  If you have two dates selected and are looking at the Sales Value measure you will see it averaged across those two days.  However, if you are looking at a single day, but across two sales areas, you will not see it averaged across those areas, but summed.  Confusing, but that is just what it does. Note that to enable this correctly your time dimension needs to have its Type property set to Time

If, however, you want to do a true average, you will need to create a calculated member in the calculations tab of your cube.  The calculation is very simple, for what is an average? It is the sum of the values, divided by the number of values.  The sum we have as the base measure from the fact table, say Sales Value. When we create a new measure group in the cube it automatically generates a new measure suffixed "Count".  This measure is none other than the count of values (or fact table rows) in the measure group.

Therefore the average calculation is the one measure divided by the other:

CREATE MEMBER CURRENTCUBE.[Measures].AvgSales
AS Measures.Sales / [Measures].[SalesFactCount]

Since both measures are essentially straight from the fact table, their values are stored during processing time, and benefit from aggregation design too.  As a result the AvgSales measure ought to perform very fast.




4 comments:

  1. Great article! i will be using it to get an average salary. Quick question though, how would I go about getting an average Headcount? For example If I did Measures.Headcount/[Measures].[HeadcountCount] I would always get 1. I would like to display an average of the headcount by all dimensions and not just the time dimension. I don't have enterprise so the AverageOfChildren isn't an option for me. Thanks!

    ReplyDelete
    Replies
    1. Hi Kyle, Thanks for the feedback.

      It may depend on the definition of the measure/fact column headcount.

      Headcount is likely to be a count of rows in an Employee table rather than the fact table. As such you might consider creating a measure group on top of the Employee table and base the two measures on this. To link it to the other dimensions you may need to set up a many-to-many relationship via another fact table.

      Delete
  2. Hi Kyle, Thanks for the feedback.

    It may depend on the definition of the measure/fact column headcount.

    Headcount is likely to be a count of rows in an Employee table rather than the fact table. As such you might consider creating a measure group on top of the Employee table and base the two measures on this. To link it to the other dimensions you may need to set up a many-to-many relationship via another fact table.

    ReplyDelete
  3. Thank you for your article

    ReplyDelete