MDX with Microsoft SQL Server 2008 R2 Analysis Services Cookbook — Save 50%
80 recipes for enriching your Business Intelligence solutions with highperformance MDX calculations and flexible MDX queries with Microsoft SQL Server 2008 R2 Analysis Services with this book and eBook
In this article by Tomislav Piasevoli, author of MDX with Microsoft SQL Server 2008 R2 Analysis Services Cookbook, we will take a look at some recipes on how to perform iteration. They deal with those cases when there's no other way but to iterate. However, some of the recipes also point out which calculation patterns we must recognize and thereby give up on using classic naïve iteration and use a better approach.
We will cover:
 Iterating on a set in order to reduce it
 Iterating on a set in order to create a new one
 Iterating on a set using recursion
Read more about this book 
(For more resources on Microsoft SQL Server, see here.)
Iteration is a very natural way of thinking for us humans. We set a starting point, we step into a loop, and we end when a condition is met. While we're looping, we can do whatever we want: check, take, leave, and modify items in that set. Being able to break down the problems in steps makes us feel that we have things under control. However, by breaking down the problem, the query performance often breaks down as well. Therefore, we have to be extra careful with iterations when data is concerned.
If there's a way to manipulate the collection of members as one item, one set, without cutting that set into small pieces and iterating on individual members, we should use it. It's not always easy to find that way, but we should at least try.
Iterating on a set in order to reduce it
Getting ready
Start a new query in SSMS and check that you're working on the right database. Then write the following query:
SELECT
{ [Measures].[Customer Count],
[Measures].[Growth in Customer Base] } ON 0,
NON EMPTY
{ [Date].[Fiscal].[Month].MEMBERS } ON 1
FROM
[Adventure Works]
WHERE
( [Product].[Product Categories].[Subcategory].&[1] )
The query returns fiscal months on rows and two measures: a count of customers and their growth compared to the previous month. Mountain bikes are in slicer.
Now let's see how we can get the number of days the growth was positive for each period.
How to do it...
Follow these steps to reduce the initial set:
 Create a new calculated measure in the query and name it Positive growth days.
 Specify that you need descendants of current member on leaves.
 Wrap around the FILTER() function and specify the condition which says that the growth measure should be greater than zero.
 Apply the COUNT() function on a complete expression to get count of days.
 The new calculated member's definition should look as follows, verify that it does.
WITH
MEMBER [Measures].[Positive growth days] AS
FILTER(
DESCENDANTS([Date].[Fiscal].CurrentMember, , leaves),
[Measures].[Growth in Customer Base] > 0
).COUNT  Add the measure on columns.
 Run the query and observe if the results match the following image:
How it works...
The task says we need to count days for each time period and use only positive ones. Therefore, it might seem appropriate to perform iteration, which, in this case, can be performed using the FILTER() function.
But, there's a potential problem. We cannot expect to have days on rows, so we must use the DESCENDANTS() function to get all dates in the current context.
Finally, in order to get the number of items that came up upon filtering, we use the COUNT function.
There's more...
Filter function is an iterative function which doesn't run in block mode, hence it will slow down the query. In the introduction, we said that it's always wise to search for an alternative if available. Let's see if something can be done here. A keen eye will notice a "count of filtered items" pattern in this expression. That pattern suggests the use of a setbased approach in the form of SUMIF combination. The trick is to provide 1 for the True part of the condition taken from the FILTER() statement and null for the False part. The sum of one will be equivalent to the count of filtered items.
In other words, once rewritten, that same calculated member would look like this:
MEMBER [Measures].[Positive growth days] AS
SUM(
Descendants([Date].[Fiscal].CurrentMember, , leaves),
IIF( [Measures].[Growth in Customer Base] > 0, 1, null)
)
Execute the query using the new definition. Both the SUM() and the IIF() functions are optimized to run in the block mode, especially when one of the branches in IIF() is null. In this particular example, the impact on performance was not noticeable because the set of rows was relatively small. Applying this technique on large sets will result in drastic performance improvement as compared to the FILTERCOUNT approach. Be sure to remember that in future.
More information about this type of optimization can be found in Mosha Pasumansky's blog:
Hints for query improvements
There are several ways you can avoid the FILTER() function in order to improve performance.
 When you need to filter by nonnumeric values (i.e. properties or other metadata), you should consider creating an attribute hierarchy for oftensearched items and then do one of the following:
 Use a tuple when you need to get a value sliced by that new member
 Use the EXCEPT() function when you need to negate that member on its own hierarchy (NOT or <>)
 Use the EXISTS() function when you need to limit other hierarchies of the same dimension by that member
 Use the NONEMPTY() function when you need to operate on other dimensions, that is, subcubes created with that new member
 Use the 3argument EXISTS() function instead of the NONEMPTY() function if you also want to get combinations with nulls in the corresponding measure group (nulls are available only when the NullProcessing property for a measure is set to Preserve)
 When you need to filter by values and then count a member in that set, you should consider aggregate functions like SUM() with IIF() part in its expression, as described earlier.
Read more about this book 
(For more resources on Microsoft SQL Server, see here.)
Iterating on a set in order to create a new one
There are situations when we don't want to eliminate certain members from a set, but instead execute a foreach type of loop. This is done using the GENERATE() function. In this recipe we'll show you how to create a new set of members from the existing one.
Getting ready
Start a new query in SSMS and check that you're working on the right database. Then write the following query:
SELECT
NON EMPTY
{ [Date].[Calendar].[Calendar Year].MEMBERS *
[Measures].[Sales Amount] } ON 0,
NON EMPTY
{ [Sales Territory].[Sales Territory Country].MEMBERS }
ON 1
FROM
[Adventure Works]
The query returns 4 years on columns and 6 countries on rows. This recipe shows how to get a set of best months, one for each year.
How to do it...
Follow these steps to create a new set from the initial one:
 Cut the years from columns and define a named set using them.
 Name that set Best month per year.
 Wrap that set in the Generate() function so that the set of years becomes its first argument.
 The second argument should be the TopCount() function which uses the descendants of each year on the Month level and finds the best month according to the value of the measure Sales Amount.
 Put the name of the new set on columns.
 The final query should look as follows:
WITH
SET [Best month per year] AS
Generate( [Date].[Calendar].[Calendar Year].MEMBERS,
TopCount(
Descendants( [Date].[Calendar].CurrentMember,
[Date].[Calendar].[Month],
SELF ),
1,
[Measures].[Sales Amount] )
)
SELECT
NON EMPTY
{ [Best month per year] *
[Measures].[Sales Amount] } ON 0,
NON EMPTY
{ [Sales Territory].[Sales Territory Country].MEMBERS } ON 1
FROM
[Adventure Works]  Execute the query. Notice that each year is replaced with a single month, the month with the best sales result in that year:
How it works...
The Generate() function can be thought of as a foreach loop. This means that we will iterate through each member of the initial set and assign another set instead of each member. That new set can have zero, one, or many members and this can vary during the iteration. In our example we're assigning a set with one member only, the best month in each year. That member is obtained using the TopCount() function where the first argument is months of the current year in iteration, the second argument is 1 (only one member to be returned), and the third argument is the Sales Amount measure — the criterion for deciding which month is the best. Months are obtained the standard way, using the Descendants() function.
There's more...
The CURRENTORDINAL function is a special MDX function valid only in iterations. It returns the position of the current member (or tuple, to be precise) in the set in iteration (from 0 to N, where N is the total number of members in a set). In addition to that, there's also the CURRENT function. The CURRENT function returns the current tuple in a set being iterated. Again, it's only applicable during iterations.
Both of these functions can be used to detect the current tuple and to create various calculations with the current tuple and other tuples in that set. Reversing any initial set is one example of these manipulations. Comparing the value of the current tuple with the value of the previous tuple in the set (or any one before or after) in order to isolate certain tuples is another example.
Here's how you could reverse the set of months from the previous example.
SET [Best month per year reversed] AS
Generate( [Date].[Calendar].[Calendar Year].MEMBERS
AS MySetAlias,
TopCount(
Descendants(
MySetAlias.Item( MySetAlias.Count 
MySetAlias.CurrentOrdinal
 1 ).Item(0),
[Date].[Calendar].[Month],
SELF ),
1,
[Measures].[Sales Amount] )
)
A set alias (MySetAlias in this example) is defined for the initial set. That set alias is later used for navigation. The combination of Count and CurrentOrdinal gives us members from the end of the set to its beginning, progressively, while the Item() function serves as a pointer on members in that set.
Yes, the same operation could be done simply by sorting the months by their member key, in descending order. Nevertheless, the idea of that example was to show you the principle which can be applied on any set, especially those that can't be reversed easily.
The other example mentioned above uses the Filter() function, not the Generate() function. There, tuples can be compared to each other progressively in order to see which one has the value higher than both of its neighboring members, which would signal that the current member is a relative peak. Or the opposite, whatever is more interesting in a particular case. However, the Filter() function doesn't add new members, it only limits its initial set and for that reason it is out of the scope of this recipe.
To summarize, Current() and CurrentOrdinal() are powerful functions that allow us to perform selfjoining type of operations in MDX or make use of the existing relations between dimensions and measure groups. These functions are useful not only in the Generate() function, but in other iterating functions as well, namely, the Filter() function.
Did you know
In MDX, there's no concept of the FOR loop. Iterations cannot be based on numbers (as in other languages or on other systems). They must always be based on a set. If we need to loop exactly N times, there are two basic ways we can achieve this. One is with the existing cube structure, the other is by expanding a cube with a utility dimension. The former means that we can use date dimension and take N members from its start. Or it could be some other dimension, as long as it has enough members to loop on. The latter, using the utility dimension.
Read more about this book 
(For more resources on Microsoft SQL Server, see here.)
Iterating on a set using recursion
Recursion is sometimes the best way to iterate a collection. Why? Because iterations using set functions (including the GENERATE() function) require that we loop through the whole set. But what if that set is big and we only need to find something in it? Wouldn't it be great to be able to stop the process when we've found what we wanted? Recursion enables just that – to stop when we're done.
In this recipe we're going to see how to calculate the average of an average using recursion.
Getting ready
To get started, start a new query in SSMS and check that you're working in the right database. Then write the following query:
SELECT
{ [Measures].[Order Count] } ON 0,
NON EMPTY
{ Descendants( [Date].[Fiscal Weeks].[All Periods],
1 , SELF_AND_BEFORE) } ON 1
FROM
[Adventure Works]
It returns 4 fiscal years and their total on top for the Order Count measure. Now let's see how to calculate the average daily value on the week level and the average weekly level on the year level, but based on the week level, not on the date level. In other words, each level will have the average value of members on the level immediately below.
How to do it...
Follow these steps to perform recursion over a set:
 Define a new calculated measure and name it Average of an average.
 Use the IIF() function and specify its True parameter as the initial measure (Order Count).
 The value should be returned for the leaf level, so the condition in IIF() should test exactly that using the ISLEAF() function.
 In the False parameter we should provide the calculation we want to repeat recursively. In this case it is the AVG() function used on children of the current member.
 The measure expression inside AVG() function should be the measure being defined.
 Check if the measure is defined as follows:
WITH
MEMBER [Measures].[Average of an average] AS
iif( IsLeaf( [Date].[Fiscal Weeks].CurrentMember ),
[Measures].[Order Count],
Avg( [Date].[Fiscal Weeks].CurrentMember.Children,
[Measures].[Average of an average] )
)
, FORMAT_STRING = '#,#'  Don't forget to include that measure as the second measure on columns.
 Run the query. The results will look as follows. The first row, the one with the All Periods member, will have the average yearly value as result, that is (56+84+435+195)/4=193. In turn, every year will have the average weekly value. The weekly values are not visible in this screenshot, but we can divide the Order Count values by 53, that is, by the number of weeks per year. That should give us the values for the Average of an average measure shown in the second column.
How it works...
Recursions are the most difficult iteration concept to apply. Their logic is very condensed. However, once you conquer them, you'll appreciate their power and efficiency. Let's see how that solution worked.
In order to start the recursive process, we have to specify an expression that uses the same calculated measure we're defining, thereby providing a different input parameter than the one which was being used in the current pass of recursive process. In order to stop the process, we must have a branch without the reference to that measure. On top of all that, we must perform some operation to collect values on the way. Complicated? Let's analyze our query.
Fiscal years on rows are not the leaf level of the Fiscal Weeks user hierarchy. Therefore, the expression inside the IIF() statement evaluates as False. This leads us to the part where we have to calculate the average value for each child of the current member. With a small detail, the calculation should be performed using the same measure we're evaluating!
The evaluation for the current year member cannot be completed and is therefore delayed until the calculation for all its child members (weeks in this case) is performed. One by one, each week of the year in context is passed inside the definition of this measure and evaluated.
In case of a leaf member, the Order Count measure would be evaluated and returned to the outer evaluation context. Otherwise, another turn of the child member's evaluation would occur. And so on until we would finally hit leaflevel members.
In this example, weeks are the leaf level of the hierarchy being used in the query. They would be evaluated using the True part of the condition. The True parameter is without reference to the measure we're calculating, which means the recursive path would be over. The value of the Order Count measure starting from the Week 1 of FY 2006 would be collected and saved in a temporary buffer. The same process would be repeated for all weeks of that year. Only then the average of them would be calculated and returned as a value for FY 2006. After which the process would repeat for subsequent years on rows.
Let's also mention that the value for the root member (All years) is calculated with the recursion depth of 2, meaning each year it is first evaluated as an average of its weeks and then the average of its years is calculated and returned as the final result.
There's more...
You might be wondering how does one recognize when to use recursion and when to use other types of iteration? Look for some of these pointers: relative positions, relative granulation for calculation and stop logic. If there's a mention of going back or forth from the current member in a set, but there's no fixed span, then that might be a good lead to use recursion. If there's a relative stopping point, that's another sign. Finally, if there's no explicit requirement to loop through the whole set, but moreover a requirement to stop at some point in the process, that's a definite sign to try to apply recursion as a solution to the problem.
In case no such signs exist, it's perhaps better and easier to use simple types of iterations we covered in previous recipes. The other case when you should consider straightforward iteration is when the recursion would span over more than half of the members on a particular hierarchy, that pushes the SSAS engine into the slow cellbycell mode.
Earlier versions of SSAS
SSAS 2008 and later have better support for recursion than previous versions of SSAS. Optimizations have been added to the code in form of unlimited recursion depth. Versions prior to that may suffer from memory limitations in some extreme cases.
Summary
In this article we took a look at iterations and ways to perform them.
Further resources on this subject:
 Microsoft SQL Server 2008  Installation Made Easy [Article]
 Managing Core Microsoft SQL Server 2008 R2 Technologies [Article]
 Best Practices for Microsoft SQL Server 2008 R2 Administration [Article]
 Creating a Web Page for Displaying Data from SQL Server 2008 [Article]
 Microsoft SQL Server 2008 R2: Managing the Core Database Engine [Article]
About the Author :
Tomislav Piasevoli
Tomislav Piasevoli (tomislav@piasevoli.com) is a Business Intelligence Specialist with years of experience in Microsoft SQL Server Analysis Services (SSAS). He lives in Croatia and works for SoftPro Tetral d.o.o., a company specializing in development of SSAS frontends and implementation of BI solutions.
His main interests are dimensional modeling, cube design, and MDX about which he blogs at http://tomislav.piasevoli.com. Tomislav also writes articles and speaks at regional conferences and user groups. For his contribution to the community, Microsoft awarded him with the Microsoft SQL Server MVP title.
Books From Packt
