Many times you’re interested in seeing values for all of the members of a particular attribute hierarchy. For example, in this query, we can see sales for all categories and for all years, including a grand total for categories and years and also years that have no sales.

SELECT
[Date].[Calendar Year].Members
 ON COLUMNS,
[Product].[Category].Members ON ROWS
FROM [Adventure Works]
WHERE [Measures].[Sales Amount]

When you use the Members function with a dimension and hierarchy, you get everything listed in the Members folder:

What if you don’t want the All Periods member to show up? Well, you could create a set like this {[Date].[Calendar].[CY 2005], [Date].[Calendar.[CY 2006], …} but that would be tedious, and it wouldn’t automatically include new members that get added to the dimension over time. Instead, you can use the Members function with the dimension, hierarchy, and level reference to skip over the All Periods like this:

SELECT
[Date].[Calendar Year].[Calendar Year].Members
 ON COLUMNS,
[Product].[Category].Members ON ROWS
FROM [Adventure Works]
WHERE [Measures].[Sales Amount]

Here we have a case of “more is less.” When we use a level reference, such as we do with the expression [Date].[Calendar Year].[Calendar Year].Members, we are providing more specific instructions to the Members function so that we can get less data. Using a level reference works with both attribute hierarchies (the ones with two levels only) and user-defined hierarchies (the ones with multiple levels and a pyramid-shaped icon).

One more little change to this query might make it better. If we don’t want to see CY 2009 and CY 2010 columns when they are empty, we add the NON EMPTY keyword in front of the set definition like this:

SELECT
NON EMPTY [Date].[Calendar Year].[Calendar Year].Members
 ON COLUMNS,
[Product].[Category].Members ON ROWS
FROM [Adventure Works]
WHERE [Measures].[Sales Amount]

What if we want to see the category sales broken down not only by year, but also by sales territory? We can combine sets on an axis using the CrossJoin function like this:

SELECT
NON EMPTY [Date].[Calendar Year].[Calendar Year].Members
 ON COLUMNS,
NON EMPTY
CrossJoin([Product].[Category].Members,
	[Sales Territory].[Sales Territory Group].[Sales Territory Group].Members)
ON ROWS
FROM [Adventure Works]
WHERE [Measures].[Sales Amount]

The CrossJoin function takes only two arguments, but you can use that expression as one argument in a second CrossJoin function to create a grouping of three dimension hierarchies on an axis. There are several ways to get the crossjoin effect which might be easier to read when you start adding more dimension hierarchies to the mix. One is the use of a “polymorphic operator” such as an asterisk * like this:

[Product].[Category].Members *
[Sales Territory].[Sales Territory Group].[Sales Territory Group].Members

The other is to create a tuple set like this:

([Product].[Category].Members,
[Sales Territory].[Sales Territory Group].[Sales Territory Group].Members)

I know I said in a previous post that a tuple is like a coordinate to a cell, and it appears in the above example that I’m violating that rule by using sets in a tuple. But Analysis Services resolves this expression as a set of tuples by taking every member of the first set (the product category members) to create a tuple with every member of the second set (sales territory group members).  That set gets placed on the rows axis and the set of calendar year members gets placed on the columns axis, and then the tuple coordinates for each intersection of a row and a column produces a new tuple definition that generates a result, such as $709,947.20 for the pseudo-tuple (All Products, Europe, CY 2005).

There are many more functions that we can use to generate sets to control what we see on rows or columns. More than I can cover in this post. (In fact, there are entire books that cover this topic. In a future post, I’ll provide some recommendations.) For now, I’ll leave you with one more function to add to your repertoire. This time we want to see only those product categories and sales territory combinations that have sales greater than $1 million in CY 2008, but we want to see their sales for all years. To do this, we use the Filter function. This should satiate your desire to use a WHERE clause in your query, which I told you in my previous post does not work like a filter as it does in a T-SQL query.

SELECT
NON EMPTY [Date].[Calendar Year].[Calendar Year].Members
 ON COLUMNS,
Filter(
	([Product].[Category].[Category].Members,
		[Sales Territory].[Sales Territory Group].[Sales Territory Group].Members),
	([Measures].[Sales Amount],[Date].[Calendar Year].&[2008])  > 1000000)
ON ROWS
FROM [Adventure Works]
WHERE [Measures].[Sales Amount]

The Filter function takes two arguments. The first is the set that you want to filter. And the second is a Boolean expression that determines which members will be in the set that the Filter function produces. In this case, I used a tuple expression to focus on the 2008 sales.  If I had used only Sales Amount, the filter would have produced a set of category/territory combinations having total sales for all years greater than $1 million.

The key concept to take away from this post is that sets go on rows and columns, and that we can control very precisely which members are in those sets by using functions and tuple sets. A very common function to use is the Members function, and it’s also common to use NON EMPTY to rid ourselves of rows or columns that contain only null values.

Preparing the Query Environment

Before I dive into writing queries, let me explain the setup. I’m using SQL Server 2008 R2 Analysis Services for these examples. You can work with earlier versions, but in some cases you will encounter date ranges that are four years earlier than the date shown in my examples. For example, instead of using Q3 2007, you would need to use Q3 2004. The measure values will remain the same. Here are links to the samples that you need to have installed:

• If using Microsoft SQL Server 2005, install the sample databases (AdventureWorks, AdventureWorksDW)
• If using a later version, download the sample databases from http://msftdbprodsamples.codeplex.com/, install the databases, and then follow the instructions at http://msftdbprodsamples.codeplex.com/wikipage?title=Installing%20Analysis%20Services%20Database to install and deploy the Analysis Services database.

Requesting a Tuple from a Cube

Okay, let’s start simple. Very, very simple. Go to SQL Server Management Studio, connect to Analysis Services, and click the MDX button on the query toolbar. An MDX query editor window will open. In the Available Databases drop-down list, select the Adventure Works database for your version of SSAS.

To retrieve a tuple from the cube named Adventure Works, you write a query like this:

SELECT FROM [Adventure Works] 
WHERE
([Product].[Product].&[359],[Date].[Date].[January 1, 2008],[Measures].[Sales Amount])

Notice the way that I refer to dimension members here. I’m no longer writing a pseudo-tuple as I did in my previous post, but am now using member unique names which tells Analysis Services the dimension and  hierarchy to which the member belongs. If you leave out the dimension and hierarchy, you will still get an answer, but no guarantee that you have the right answer if it’s possible that another dimension and hierarchy contain a member of the same name. For example, what if I have a West region and a sales person with the last name of West? Analysis Services will use one or the other to construct the tuple. The only way I can control which one is to use the dimension and hierarchy name. In fact, I switched from using Mountain-200 Black, 38 to [Product].[Product].&[359] because there are two products with the name Mountain-200 Black, 38 (due to Slowly Changing Dimensions) and I want the one that actually has sales for January 1, 2008. I can refer to members not only by name, but by the value in the key column – which in this case is the surrogate key for the dimension. I use an ampersand before the key value wrapped in brackets to specify that it’s a key column in the tuple rather than a member name .

Now let’s see the results of the query. Press F5 or the Execute button in the toolbar to see a single value appear in the Results pane.

The WHERE clause in your query contains the tuple that you want to retrieve. It does NOT behave like a WHERE clause in a SQL query, which is why I asked you nicely to forget about that other language – at least for the duration of this post. The problem with requesting a tuple this way is that the result does not include any metadata that tells me what I’m looking at. So I can enhance this query by showing one of the members of the tuple as a column label and one of the other members of the tuple as a row label, like this:

SELECT 
[Date].[Date].[January 1, 2008] ON COLUMNS,
[Product].[Product].&[359] ON ROWS
FROM [Adventure Works] 
WHERE [Measures].[Sales Amount]

Press F5 to see that the result of the query is the same, but now we have some more context for the value that displays.

The way that I like to think about the query results for this example is that it works in three phases. First, Analysis Services retrieves my request for the member on columns. Second, it retrieves my request for the member on rows. Those two steps occur completely independently of one another. Third, Analysis Services looks at the intersections produced by placing member on columns and rows and adds in the WHERE clause to produce a tuple. That’s why we get the same value in the result. It doesn’t matter which member you put on columns and which member you put on rows and which you leave in the WHERE clause. Collectively, they produce a tuple.

You don’t have to use a WHERE clause in the query. Instead, you could put everything onto an axis – either rows or columns. Essentially, you’re moving the tuple fragments out of the WHERE clause onto an axis. The tuple produced by the query parser is the same, but we get more metadata in the results to see the context of the query. For example, try this:

SELECT 
([Date].[Date].[January 1, 2008], [Measures].[Sales Amount]) ON COLUMNS,
[Product].[Product].&[359] ON ROWS
FROM [Adventure Works]

Here you see the results of the new query.

You can put any member of the tuple on either rows or columns. You can even write the query to show rows first and columns second like this:

SELECT 
[Product].[Product].&[359] ON COLUMNS,
([Date].[Date].[January 1, 2008], [Measures].[Sales Amount]) on ROWS
FROM [Adventure Works]

But the result of your query stays the same. You can have a query that only has a tuple fragment on columns like this:

SELECT 
([Date].[Date].[January 1, 2008], [Measures].[Sales Amount]) ON COLUMNS
FROM [Adventure Works]

But you cannot have a query that has a tuple fragment on rows like this:

SELECT 
([Date].[Date].[January 1, 2008], [Measures].[Sales Amount]) ON ROWS
FROM [Adventure Works]

If I don’t ask for something in a tuple explicitly by putting it on columns, on rows, or in the WHERE clause, Analysis Services plugs in the All member for the dimension and hierarchy that I didn’t include. Usually. There is an exception but we’ll save that explanation for another post. This behavior is especially helpful when you have lots of dimensions and hierarchies. Otherwise, you’d have a tuple that is  ginormous (your new technical term for the day).

Using Sets in a Query

Asking for data one tuple at a time is rather tedious. Fortunately, we can take our knowledge about query construction to the next level. Technically speaking, when we put a member on columns or rows, we were asking for a set. A set of one. When we put the tuple fragment on columns or rows, we were creating a tuple set. Another option is to explicitly create a set like this:

SELECT
{[Date].[Date].[January 1, 2008], [Date].[Date].[February 1, 2008]} ON COLUMNS,
[Product].[Product].&[359] ON ROWS
FROM [Adventure Works]
WHERE [Measures].[Sales Amount]

Whereas we use parentheses to denote a tuple, we use braces to denote a set. The order in which we define the member of the set determines the order in which the members display in the results. Try changing the sequence of members in the set to see the results.

MDX provides us with lots of functions to produce sets or to produce members that we use in sets so that we don’t have to list out members explicitly in a query. In my next post, we’ll explore some some of these functions.

As I mentioned in an earlier post, I first met Tomislav Piasevoli’s (blog|twitter) in 2008 at the PASS Summit in Seattle, and saw him again most recently again in Seattle at PASS Summit 2011. There I had the pleasure of telling him personally how much I liked his book. There are not many MDX books available, so when a new one arrives on the market, I definitely want to take a look. Now I have taught MDX classes for many years, and I think perhaps my first class was in 2002. However, it’s been so long now, I don’t recall exactly when that first class was. What I do know is that my understanding of MDX and my fluency with the language has grown by leaps and bounds since then through experience with all kinds of bleeding edge MDX, and I have tried to communicate some of my insights developed along the way to students in my classroom. MDX concepts can stretch your thinking (to put it mildly), and more so if you have to unlearn SQL concepts as well, which is true of the majority of my students. As a native English speaker, I can find it challenging at times to explain certain aspects of MDX. For all these reasons, I can fully appreciate Tomislav’s efforts to create this book and commend him for his excellent examples and explanations using a language that is not his mother tongue.

Tomislav’s book is definitely not for beginners. There is an underlying assumption that you already have some familiarity with the basics of MDX. The purpose of this book is to provide you with the tools necessary to continue building your skills. The chapters group together a series of related concepts, called recipes. You don’t need to read the book sequentially from cover to cover. Instead, you search for the desired outcome, such as handling division by zero errors (described in Chapter 1) or calculating row numbers (found in Chapter 7). Ideally, you don’t just read the recipe, but actually try out the steps yourself. I did some of my reading of this book when I was away from my laptop, and frequently found that I wanted to try out something that Tomislav mentioned. Even long-time MDX developers like myself can find interesting tidbits of information to round out their repertoire!

Each concept within a chapter is presented in a similar manner, beginning with “Getting ready” which are the steps you need to perform to set up your query. For example, you might need to work in Management Studio and set up a query as a starting point or open the Script View for a cube in Business Intelligence Development Studio. Then the next section is “How to do it…” which provides step-by-step instructions for working with a query or MDX script to accomplish the intended outcome. Then Tomislav continues with the “How it works…” section which provides background information on the key concepts for the current recipe. This section is the real meat of the book, but is nicely separated from the implementation steps if you want to jump straight to the technical details. Depending on the recipe, Tomislav also includes additional sections, such as “There’s more…” to provide alternative solutions or to point you to helpful links on the Internet such as whitepapers and blog articles providing more insight, and “See also…” to cross-reference you to another recipe in the book that covers a closely related concept.  Where applicable, he also includes information about how the techniques in the recipe behave differently in earlier versions of Analysis Services.

Chapter 1: Elementary MDX Techniques

Don’t let the word Elementary fool you into thinking you can learn entry-level MDX from this chapter. As I mentioned earlier, this book is not for beginners. There are good techniques here and a few basics, such as a great explanation of the FORMAT_STRING property and troubleshooting its use. However, I would consider the majority of these techniques to be elementary only as compared to the other techniques found later in the book. For example, the WHERE clause is one of those things that I see people really get into a tangle over (because they can’t forget their T-SQL), and Tomislav demonstrates using it to implement a logical OR on members from different hierarchies and a logical AND for members from the same hierarchy. One of my favorite sections in this chapter is the coverage of alternatives for the FILTER() function, which can cause performance problems. Use this chapter to get grounded with some foundational concepts, then strap on your seatbelt before diving into the rest of the book!

Chapter 2: Working with Time

Time is something that every cube has. Or at least every cube that I’ve ever met. I can’t imagine a cube without one (even if it’s called Date) because often business analysis is comparing one period to another or monitoring trends over time. Tomislav starts with the basics of the YTD() function but delves into variations on the theme and points out pitfalls to avoid. He moves on to parallel periods, moving averages, and finding last dates with data, among other time-related topics. A useful recipe in this chapter is the use of string functions to calculate a date, as I see this requirement a lot when working with Reporting Services reports that use Analysis Services as a source. A good case for working with a single-member named set rather than a calculated member is also made in this chapter.

Chapter 3: Concise Reporting

A report in this chapter means a pivot table used in some front-end tool for Analysis Services, and not Reporting Services exclusively. The goal of this chapter is to reduce the size of the pivot table, and thereby improve performance. I would characterize this chapter as one that helps you find the best or the worst members in a group, whether in a hierarchy, among siblings, or among descendants. Tomislav starts off the chapter with a recipe to get the top N members. In this recipe, Tomislav includes a great explanation of what can go wrong when you use the TopCount() function. Well, it’s not a matter of it behaving incorrectly because it’s doing what you ask. The problem is that many people misunderstand how the TopCount() function behaves under certain conditions and Tomislav delves deeply into the behavior here. He then builds on these ideas throughout the chapter and introduces alternatives for finding and displaying the best and the worst.

Chapter 4: Navigation

Hierarchies in a dimension are extremely useful for a number of reasons, one of which is navigation. The chapter begins with some simple queries that use Boolean logic to test the context of a current member on the row axis, and then expands to use scoping in the MDX script or use a query (using CELL CALCULATION) to determine if members are in the same branch of a hierarchy. Are you confused about when to use the Exists() function and the EXISTING keyword? Tomislav covers them both in this chapter in a variety of contexts. Also, having advocated on behalf of a named set in a previous chapter, Tomislav explores the pros and cons of named sets more fully in this chapter.

Chapter 5: Business Analytics

This chapter covers several techniques that are encountered less frequently (depending on who you ask, I suppose) than those covered up to this point in the book. For example, the chapter begins with linear regression which I’ve never had to use in 10 years of writing MDX. But I said the same about the Correlation() function once upon a time and I now use it frequently in a current project, so my feeling is that you never know when you’ll need to use a seemingly obscure function. Because these analytical functions are used less commonly, the amount of information available through Books Online or elsewhere on the Internet is pretty slim. Therefore, having this chapter’s working examples at your fingertips is invaluable. Also covered in this chapter is adjusting forecasts based on periodic cycles, alternative approaches to expense allocations, finding slow-moving inventory items, categorizing customers, and ABC analysis (which is an application of Pareto analysis).

Chapter 6: When MDX is Not Enough

In this chapter, Tomislav makes the case that when an MDX approach gets overly complicated, it’s time to look at making changes to the dimension or cube design. For example, he says, “Every time you catch yourself using functions like Except(), Filter(), or similar() too often in your calculations, you should step back and consider whether that’s a repeating behavior and whether it would pay off to have an attribute to separate the data you’ve been separating using MDX calculations.” He also explains how and why to create a placeholder measure in the cube to use with assignments in the MDX script. Utility dimensions for unit conversion or for time-based calculations are also covered in this chapter.

Chapter 7: Context-aware Calculations

Understanding context is an important aspect of MDX development. As Tomislav explains in the introduction to this chapter, context can be unpredictable based on what a user might select to place on rows and columns, or it can be partially known when you expect a particular measure or hierarchy to be used, or it can be completely known. The trick is to produce a calculation that behaves correctly regardless of context, which can be made trickier based on a combination of factors that Tomislav describes. The recipes in this chapter help you explore context from a number of, um, contexts, starting with how to know how many columns and rows will be in a query’s result set, how to determine which axis contains measures, how to determine what has been placed on an axis, among other useful techniques.

Chapter 8: Advanced MDX Topics

Now frankly I considered several of the recipes up to this point to be advanced, so I had to chuckle at the title of this chapter. Let’s just say these recipes are more complex! In this chapter, you’ll find techniques for working with parent-child hierarchies and displaying random values for sampling purposes. Hopefully, you’re avoiding the use of parent-child hierarchies and random sampling is not a common request in reports, so this section of the chapter is interesting primarily from an academic viewpoint. But then we move to complex sorts – a very useful subject indeed. Tomislav provides several examples and highlights potential problem areas. Also in this chapter is a recipe for recursively calculating cumulative values.

Chapter 9: On the Edge

Tomislav uses this chapter to collect topics that don’t neatly fit into the earlier chapters. Here he covers Analysis Services stored procedures (which are nothing like T-SQL stored procedures, by the way), as well as using the OPENQUERY() and OPENROWSET() functions for calling MDX from a T-SQL statement. He also introduces Dynamic Management Views (DMVs) for documenting and monitoring cubes, and shows how to use SQL Server Profiler to capture MDX queries. Last, he shows how to use the DRILLTHROUGH command.

If you’re an MDX developer, whether brand new or experienced, you will find lots of good information in this book and practical examples of how and why to implement specific techniques. I definitely recommend that you add it to your library, in whatever format you prefer. It’s available in paperback, PDF, ePub and Mobi from the publisher and in Kindle format from Amazon.

Regardless of which year it was, Tomislav was seated at table during a Birds of a Feather lunch talking to several people about MDX, and he made a comment about the Axis function which I thought was very interesting. To be honest, I don’t remember what he said specifically, but it intrigued me enough to jot it down to pursue at a later time. It turned out not to be helpful for whatever MDX problem I was faced with at the time, but I kept the note to myself in my smartphone, which transferred over to the next two smartphones I’ve owned since then. My experience with MDX is that there are a handful of MDX functions that we who are inclined to write MDX use quite often. For an interesting, but entirely unscientific, analysis of function popularity, see this 2005 post from Mosha Pasumansky, “What are the popular MDX functions?” Although the post is a bit dated, I think it’s still valid. When I look at the top list of functions, I do indeed use many of those functions frequently (although NonEmptyCrossJoin is deprecated and I now use the NonEmpty function instead).

This year, I finally found a situation where I found the Axis function to be useful. Basically, this function gives us a way to “see” what’s currently on rows or columns. The situation facing me was  to come up with a way to create a calculation based on values found in two columns in a pivot table. More specifically, each column could be a different time period. So the calculation might be comparing Q1 and Q2 of a particular year, or it might be Q1 of one year and Q2 of another year. But we would not know in advance which two time periods would be involved. I built a calculation to count how many date members were on the columns axis and return a null if there were more than two, otherwise to do the math. I’ll provide the details for this in a separate post, but there are other scenarios in which this function is useful as Tomislav explains in this SQLBits session (recording freely accessible, slides and samples downloadable): Universal calculated measures in MDX queries.

That encounter with Tomislav is just one example of many that highlights the value of attending the PASS Summit. It’s not just what you learn by attending the sessions, but also what you learn in casual conversations with experts. Opportunities abound for these conversations, whether at a Birds of a Feather table or in the hallway or at one of the many evening events. (Hint: Asking questions during SQLKaraoke is probably not a good time.) People who are at PASS – both speakers and non-speakers alike – are there because they’re passionate about what they do. If you plan to go and it’s your first time, the best advice I can give is Don’t Be Shy! Talk to someone, anyone, everyone! You won’t regret it.

It’s only a few more short weeks until Erika and I head out to this year’s summit. I’ve got to finalize my demos for my preconference workshop on MDX, DAX, and DMX and for my half-day session with Denny Cherry, So How Does the BI Workload Impact the Database Engine?. I think all I need to do is show up for my panel session, Are You a Linchpin?

Meanwhile, I’m going to be reading Tomislav’s new book to see what other gems he has to share, and I’ll post a review when I finish the book. Stay tuned!

Before you undertake MDX, you should know something about Analysis Services and cubes. Earlier this year, I presented a series of posts as part of SQL  University to introduce you to this topic:

• Why Do I Need a Cube and How Do I Get Started?
• Dimension Design 101
• Cube Construction 101
• Cube Enhancements 101
• Cube Deployment 101

Before we dive into using MDX later this week, let’s start with perhaps the most fundamental concept that you need to understand – location, location, location.

Build On What You Know

You’ve probably used an Excel spreadsheet at some point and are familiar with using cell references to create formulas. For example, in the spreadsheet below, if I want to perform a calculation that includes the sales for the product “Mountain-200 Black, 38” on 1/1/2008, I would use the formula =B2. The letter B stands for the column reference and the number 2 stands for the row reference. It’s a two-dimensional cell reference.

“OK,” you’re thinking. “I got that. Rudimentary Excel. What does that have to do with MDX?” Bear with me a little bit longer and I’ll connect the dots for you.

Now consider that I have two sheets in a workbook with a similar layout. One sheet for 2008 sales and one sheet for 2007 sales. I want to calculate total sales for the same product in January. In this case, I can use the formula =’Sales 2008’!B2 + ‘Sales 2007’!B2. I’ve added a third dimension, the sheet name, to the cell references to tell Excel where to find the data for the calculation.

Let’s continue expanding on this concept:

• For four dimensions, let’s assume that I have a separate workbook for different stores and I want to combine the sales for all stores for the same product and same month across the two years. My formula would now look like this – ‘[Store A.xlsx]Sales 2008’!B2 + ‘[Store B.xlsx]Sales 2008’!B2 + ‘[Store A.xlsx]Sales 2007’!B2 + ‘[Store B.xlsx]Sales 2007’!B2.
• For five dimensions, I might use different folders on the same drive to store workbooks by promotion. So now each workbook reference would look something like this: ‘[C:\Top Customer Promotion\Store A.xlsx]Sales 2008’!B2.
• Moving on to six dimensions, I can reference workbooks on different drives.
• For seven dimensions, I can reference workbooks on different servers.

Now I’m going to get a bit silly, but just use your imagination with me for a moment because I can’t really do this. It’s just expanding the concept of location. Here goes… I can reference workbooks on different servers on different floors (eight dimensions), in different buildings (nine dimensions), on different streets (ten dimensions), in different cities (eleven dimensions), in different states (twelve dimensions), in different countries (thirteen dimensions), on different planets (fourteen dimensions) in different universes (fifteen dimensions)!

Okay, I’ve probably gone a bit too far with this example, and technically speaking, I wouldn’t make each of these aspects of a location into a separate dimension from an Analysis Services point of view. But I want you to get the idea that I can use location references in my Excel formulas to be very precise about which data to include in the formula. Excel understands relative references and absolute references. If you don’t tell it otherwise, it’s going to assume that you want a relative reference. That is, use the current cell, column, sheet,  or whatever that happens to be “current” for the cell in which you are typing the formula unless you give it explicit instructions to use a different cell, columns, sheet, or whatever.

And Now for the Tuple

Now let’s bring this back to MDX. A key concept in MDX is the tuple. I say tuh-ple because I learned it that way and I’m too old to change. (Think quintuple, sextuple, octuple – et cetera. The letter u is short the way that I learned.) Some people say too-ple, and that’s okay too. The beauty of reading a blog post is that you can read it with whichever pronunciation you prefer and my pronunciation won’t get in your way!

Let’s move our sales data from Excel into an Analysis Services cube. I’ve simplified the product name because the tire size in there seems to distract people. So “Mountain-200 Black, 38” becomes “Mountain-200 Black.”

To get data from a cube, I need to ask for that data in the form of a tuple. A tuple consists of one member from every dimension. So in my two dimensional representation of cube data above, the tuple to get sales for the Mountain-200 Black product in January would be (Mountain-200 Black, 1/1/2008).

Actually, that’s what I call a pseudo-tuple because it’s not exactly the way we would write it in MDX, but I don’t want you to get distracted by the details. For now, let’s focus on the concepts of a tuple.

Tuples are like coordinates that you learned in geometry. If you have a graph with two dimensions, x and y, you represent a point by using the coordinate (x,y). In geometry, order matters – the x must come before the y. But with tuples, order does NOT matter. We can write your example above as either (Mountain-200 Black, 1/1/2008) or (1/1/2008, Mountain-200 Black) and get the same answer: $66,095.71.

Now in our cube, most dimensions have an All level. And that counts as a cell, too. So we can create a tuple (All Products, All Dates) to get the grand total sales: $4,831,250.71.

If we have two kinds of measures in our sales, Sales Amount and Order Quantity, then that adds a third dimension to our cube. So our tuple changes accordingly to include the new dimension: (Mountain-200 Black, 1/1/2008, Sales Amount).

In summary, a tuple is just a location in a cube. We use it to tell Analysis Services where to find the data that we want. Using MDX functions, we can describe sets of tuples that we want to access “as is” or use in formulas. In my next post, I’ll explain how to write simple MDX queries using this concept of tuples.

As part of that session, I told a story of how I came to appreciate the use of ASSP for a client project in which I had to dynamically construct MDX queries on the fly using T-SQL stored procedures and pass the resulting query into an OPENQUERY function. The problem that I had in that situation was the limitation imposed by the OPENQUERY function – I  had to write my MDX query in 8000 characters or less! Erika and I worked out all kinds of ways to live within that constraint before we tried ASSPs, but ultimately the complexity of these queries kept pushing over the query string over the limit and thus began our adventures with ASSP. I’ll add a post on this technique to my series on Using Dynamic MDX in Reporting Services soon. (The first post describes the use of StrToMember() and StrToSet() and the second post shows how to use MDX in a dynamic OLE DB query.

I had a few extra minutes of time in my session, so I thought I’d show the audience “the rest of the story” by demonstrating how I could use the OPENQUERY function with the ASSP that I created earlier in the session. I  had the OPENQUERY working on my laptop just a few minutes before the session started, but in preparing Erika’s laptop, I didn’t think about setting up a linked server to Analysis Services in advance. No worries – I’ll just do it live! Well, my memory failed me on how to fill out the New Linked Server dialog box in Management Studio, so I asked the audience if anyone knew what to do and the reply I got was, “It’s a mystery!” (It took me a few times to realize that’s what they said – I was suffering from the “SQL plague” and my ears were really plugged up!)

Nothing a little search engine won’t resolve, right? Well, I turned up a few hits (like the Books Online entry Adding a Linked Server), but nothing was particularly helpful for interpreting which parameters are really needed and which are optional – especially when I was on the spot! So my post today is my contribution to resolving the mystery. Of course, now that I’m offstage and working on my replaced hard drive and with a much less congested head, I was able to set up a linked server quite quickly.

To set up a linked server for Analysis Services, follow these steps:

1. Connect to the Database Engine in Management Studio.
2. Expand Server Objects, right-click Linked Servers, and click New Linked Server.
3. Define a name for the linked server, and set the following options as shown in the screenshot below:

• Provider: Microsoft OLE DB Provider for Analysis Services 10.0
• Product name: MSOLAP.4
• Data source: (the name of your server)
• Catalog: (the name of the Analysis Services database)

To test the linked server, you can write a query like this:

select * from openquery(AdventureWorksOLAP, ‘select [Measures].[Sales Amount] on columns from [Adventure Works]‘)

A couple of things to note – This query is executed as a database engine query, not as an MDX query. The first argument of the OPENQUERY is the name of your linked server.

As an independent consultant, I don’t get to interact regularly with my peers, so I love the reunion aspect of PASS. And now that I’ve started following people on Twitter, my universe of colleagues has expanded even more, and I was delighted to meet the people behind the avatars.

The joy of PASS is not limited to those of us who have attended for many years. As I was sitting in the airport last Friday, I recognized an attendee who was a first-timer and asked about his experience. He replied that it exceeded expectations. He was so anxious to get back to work to put what he learned into practice. He felt that the value of the knowledge that he is bringing back to the office from PASS was so much greater than the price of the conference. Now that’s a ringing endorsement if I ever heard one.

There is so much more that could be said about PASS, and many in the community have already posted their thoughts on Twitter and on their blogs. There has been quite a stir in the business intelligence community this past week about the future of Analysis Services, about which I will comment in a future post. Today, however, I will focus on a few follow-up comments and links to resources related to activities in which I participated last week.

Getting Started In Blogging And Technical Speaking

Kendal Van Dyke (blog| twitter) presented a session with tips for getting started in either of blogging or speaking. He invited a panel of experts to join him, including myself, Rob Farley (not pictured below) (blog| twitter), Aaron Bertrand (blog | twitter), Buck Woody (blog | twitter), Todd McDermid (blog| twitter), Mike Walsh (blog | twitter), Thomas LaRock (blog | twitter), Ted Krueger (blog | twitter), Patrick LeBlanc (blog | twitter), Andy Warren (blog | twitter), and Brent Ozar (blog | twitter).

Photo courtesy of Brent Ozar

Who had control of this very interactive session? You’ll have to buy the PASS Summit DVD to find out!

I waited patiently for my turn to speak. With a room full of speakers, getting your own turn can be a challenge! I heard a few attendees express concern that they didn’t know what to write about, or that someone else has covered the topic. My response to this concern is that everyone has a unique take on a topic, and that’s why T-SQL Tuesday is such a great way both to learn and to contribute. T-SQL Tuesday was started by Adam Mechanic (blog | twitter) and gives everyone with an opinion (and who doesn’t have one?) or a specific experience to add to the topic. You can see the first invitation to T-SQL Tuesday here to see how it all started and the most recent T-SQL Tuesday posts hosted by Paul Randal (blog | twitter). The best way to keep tabs on who’s hosting the next round is to follow the #TSQL2sDay hash tag on Twitter.

Unfortunately, I didn’t get to hang out for the entire presentation, because I had to move on to the…

Women in Technology Panel

I was honored to participate as a panelist for this year’s Women in Technology luncheon. It was well attended, and I heard so many positive comments after the event from both men and women. I drew inspiration from my fellow panelists as well as the stories shared with me by other women attending PASS this year. You can view a recording of the event here if you’re a registered member of PASS (which is free to join).

It’s so difficult to say what the right answer is for increasing the numbers of women in technology. The numbers are diminishing at a deplorable rate (as I discussed in a previous post). It seems to me that to foster change we need to start laying the groundwork with our children. By “our children”, I mean society in general, not me specifically, although I have tried do my part! On the one hand, I don’t recommend forcing children into a career path that they can’t embrace enthusiastically. On the other hand, I believe that one reason that girls don’t pursue technology as an option is lack of exposure to the possibilities. Lynn Langit (blog | twitter) is a role model for showing kids (not just girls!) how to explore these possibilities through www.teachingkidsprogramming.org. Check it out!

Along these lines, I proposed that maybe – as great a community as PASS is – we should collectively think about what we can do for our kids. Someone tweeted that I suggested we should bring our daughters to SQLSaturday, but actually I wondered aloud if we could do something similar to SQLSaturday that focused on the kids (and not just girls). Maybe we could get some sponsors to help, too?

Demystifying MDX in Reporting Services

In this session, I explained some of the nuances of working with MDX in Reporting Services. I have posted my demo reports here.

In addition, you might want to refer back to some of my recent posts about using dynamic MDX in Reporting Services: Part 1 and Part 2.

If you’re not familiar with MDX, I presented Session 07: Intro to MDX for 24 Hours of Pass: Summit Preview which you can view if you have a free PASS membership. MDX is not going away any time soon, contrary to recent rumors, so invest some time learning it if you plan to work with real Analysis Services cubes, which will continue to have their place in the BI stack for several years to come.

Real World Analysis Services Stored Procedures

This topic drew a larger audience than I expected as it’s a fairly specialized topic. For years, I never needed to use Analysis Services Stored Procedures (ASSP), avoiding it because folklore said so due to performance hits. However, some things just can’t be done any other way and I ran into such things this past year. To date, I haven’t found much written about ASSP other than BOL, but you can find some excellent examples to download at CodePlex. Plus I’ve uploaded the very simple (non-production-ready) C# example that I used in my session demonstration for you to peruse.

What’s Next?

So now that I’ve completed all the training and Webcasts and conference sessions that I’ve been focused on the last couple of months (with one exception – Delivering Information with Reporting Services, a free Webcast at 12 pm Pacific on Wednesday, November 17), I plan to get back to a more regular blogging schedule. There are certainly plenty of topics on my “to do” list!

But what if you want to change the structure of the query itself? A parameter won’t help with that. Instead, you need to create the query string at run-time. However, the Analysis Services data source in Reporting Services doesn’t allow you to use an expression to define the query string. That’s okay- I’ll just do an end run around that problem. I’ll use an OLE DB provider to connect to my cube and then I can build up the query string by using an expression. In this post, I walk you through the process.

The context for this demonstration is a report that allows the user to specify the sets that appear on rows and columns of a matrix and to select one measure. It’s a very simple example that focuses on the dataset construction, and doesn’t spend as much time on the beautification of the report. Hopefully, it will give you some ideas to leverage for your own reports.

Create a data source

First, I need to create an OLE DB source. In the Type drop-down list, I select “OLE DB” and then I provide a connection string like this:

Provider=MSOLAP.4;Data Source=.;Initial Catalog="Adventure Works DW 2008R2"

The Edit button allows you to use a UI to generate the string if you don’t want to remember how to construct it manually.



Parameters

This set of steps is necessary to create the lists from which the user makes the selection. In my very simple example, I have created two parameters – Rows and Columns – and hard-coded possible lists. You can do more interesting things here, of course. Just make sure that the user can’t make the same selection for both parameters – whether you enforce that by manually providing the values or by doing something clever with a dynamically generated list based on a query.

I created the Measure parameter with the following values:

I created the Columns parameters like this:

And the Rows parameters like this:

Dataset

Although the ultimate goal is to produce a dynamic MDX query, it’s actually easier to start the design of the dataset using a static query and then to switch it out later. By using a static query, the fields for the dataset are autogenerated. The less work I have to do, the better.

Now one thing about dynamic MDX in Reporting Services is the need to make sure the number of fields in the dataset are the same each and every time. Therefore I need to structure the query differently than I would if I were to write it for a “normal” Analysis Services client. That is, I need to rewrite a query like this:

select

non empty [Date].[Calendar Year].[Calendar Year].Members on columns,

non empty [Product].[Category].[Category].Members on rows

from [Adventure Works]

where [Measures].[Sales Amount]

select

[Measures].[Sales Amount] on columns,
non empty
([Product].[Category].[Category].Members,
[Date].[Calendar Year].[Calendar Year].Members)
on rows
from [Adventure Works]

and produces a result like this:

with
member [Measures].[Measure] as [Measures].[Sales Amount]
member [Measures].[RowValue] as [Product].[Category].CurrentMember.Name
member [Measures].[ColumnValue] as [Date].[Calendar Year].CurrentMember.Name
select {[Measures].[Measure], [Measures].[RowValue], [Measures].[ColumnValue]} on columns,
non empty ([Product].[Category].[Category].Members, [Date].[Calendar Year].[Calendar Year].Members) on rows
from [Adventure Works]

To get a result like this:

Matrix

I like to test things out before I start introducing more complexity. So my next step is to add a matrix layout to the report design, and put fields into the layout and apply a little formatting as shown below.

One extra step related to formatting is required in my example. I have three possible measures, each of which uses a different format string. If I were displaying detail records, I could use the formatted_value cell property as an extended property in the textbox expression, replacing Fields!Measure.Value with Fields!Measure.FormattedValue. However, the use of a matrix here doesn’t work with that approach, so… I need to create a conditional expression to set the Format property correctly:

=Switch(Parameters!Measure.Label = "Sales Amount", "C2", Parameters!Measure.Label = "Order Quantity", "N0",

Parameters!Measure.Label = "Gross Profit Margin", "P2")

Then I preview the report to make sure all is well, which it is.

Query expression – step 1

Now it’s time to do the deed – convert the query string to an expression. To do this, I open Dataset Properties and click the expression button (fx) next to the Query box.

The first step is just to enclose the query in double-quotes and prefix with an equal sign and to eliminate all the line feeds in the query. The expression needs to be one long string. If you really must add line feeds to make it easier to read, you can set up the expression like this:

="with"

+ " member [Measures].[Measure] as [Measures].[Sales Amount]"

+ " member [Measures].[RowValue] as [Product].[Category].CurrentMember.Name"

+ " member [Measures].[ColumnValue] as [Date].[Calendar Year].CurrentMember.Name"

+ " select {[Measures].[Measure], [Measures].[RowValue], [Measures].[ColumnValue]} on columns,"

+ " non  empty ([Product].[Category].[Category].Members, [Date].[Calendar Year].[Calendar Year].Members) on rows"

+ " from [Adventure Works]"

Just make sure to allow for a space between words on separate lines. I put it at the beginning of each new line so that I can see it easily. I then preview the report again to make sure that the expression works before I add in the next layer of complexity.

Query expression – step 2

Next I plug in parameter values in the appropriate sections of the query, like this:

="with"
+ " member [Measures].[Measure] as " + Parameters!Measure.Value
+ " member [Measures].[RowValue] as"
+ " " + Split(Parameters!Rows.Value,"]")(0) + "]" + Split(Parameters!Rows.Value,"]")(1)+ "].CurrentMember.Name"
+ " member [Measures].[ColumnValue] as"
+ " " + Split(Parameters!Columns.Value,"]")(0) + "]"
+ Split(Parameters!Columns.Value,"]")(1)+ "].CurrentMember.Name"
+ " select {[Measures].[Measure], [Measures].[RowValue], [Measures].[ColumnValue]} on columns,"
+ " non  empty (" + Parameters!Rows.Value + ", " + Parameters!Columns.Value + ") on rows"
+ " from [Adventure Works]"

Then I preview again. Here’s the report with the default parameter settings: products on rows, dates on columns, and sales amount as the measure.

And here’s the report with sales territory on rows, business type on columns, and gross profit margin as the measure.

Mission accomplished!

· Impose greater control over the sets that you want to add to the rows axis by using set functions.

· Add query-scoped named sets to the query in addition to calculated members. (Calculated members can also be added in the graphical query designer, but not named sets.)

· Build dynamic MDX queries.

When would you need a dynamic MDX query? Whenever you want to modify the query based on a condition known only at run-time, typically based on a parameter value. If you’re using the graphical query designer, you can auto-generate the report parameter’s query for available values by selecting the Parameter checkbox. When the user selects a value during report execution, Reporting Services passes the unique name for the selection to the query and all is well. However, there might be situations when the user selection doesn’t come from the cube, so you must find a way to convert the parameter value into a value that will work with the query.

In a series of posts, I will explore the available options for working with dynamic MDX queries in Reporting Services. By dynamic MDX, I mean that the query can be different each time it executes. In this post, I cover the use of StrToMember() and StrToSet() functions in parameters.

A very common scenario is the requirement to pass dates into a query. If you have a date filter for the report, do you really want users to navigate through a list of dates from the cube as shown below?

This list of dates – even if it’s arranged hierarchically by month, quarter, and year – is what you get when you build the parameter directly from the date hierarchy in the query designer as shown below.

Wouldn’t a more user-friendly experience allow the user to select a data from a calendar control? I can do this by changing the auto-generated report parameter’s data type to a Date/Time data type and clear the “Allow multiple values” check box. I must also change the Available Values setting for the parameter to None. I can set the default value to “No default value” to force the user to make a selection, or do something nice like define an expression to set a date, like =Today().

So far, so good. But the problem now is that the date data type returned by the calendar control cannot be used by the MDX query without some intervention. I need to change the Parameter Value mapped to the query parameter in the Dataset Properties to an expression, like this:

=”[Date].[Calendar].[Date].[" + Format(CDate(Parameters!DateCalendar.Value), "MMMM d, yyyy") + "]“

The expression that you use to convert a date like 2/1/2008 to a valid unique name in your Date dimension might look different. My example is specific to the Adventure Works 2008 R2 cube, which requires the date member to look like this: [Date].[Calendar].[Date].[February 1, 2008].

That’s fine so far, but the result of this expression is a string and the MDX query requires a member or a set. The autogenerated query already makes this change for you fortunately. However, if you’re creating your query manually, you should understand what it’s doing, especially if you need to make changes to it.

The autogenerated query looks like this before I make changes:

SELECT NON EMPTY { [Measures].[Sales Amount] } ON COLUMNS,
NON EMPTY { ([Product].[Category].[Category].ALLMEMBERS ) }
DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS
FROM ( SELECT ( STRTOSET(@DateCalendar, CONSTRAINED) ) ON COLUMNS
FROM [Adventure Works])
WHERE ( IIF( STRTOSET(@DateCalendar, CONSTRAINED).Count = 1, 
STRTOSET(@DateCalendar, CONSTRAINED), [Date].[Calendar].currentmember ) ) 
CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS

I prefer to simplify the query as shown below – removing the text highlighted in red text above. The function does what it says – changes the string (represented by the parameter @DateCalendar) into a set object. I remove the WHERE clause from the query as the FROM clause adequately restricts the query results to cell values related to the selected date. If I need the dimension properties in the report to display something or if I need the cell properties for report formatting, I’ll include only the ones I need, but for this example I have removed them all from the query.

SELECT NON EMPTY { [Measures].[Sales Amount] } ON COLUMNS,
NON EMPTY { ([Product].[Category].[Category].ALLMEMBERS ) } ON ROWS
FROM ( SELECT ( STRTOSET(@DateCalendar, CONSTRAINED) ) ON COLUMNS
FROM [Adventure Works])

You could change the StrToSet() function to a StrToMember() function and get the same result. It’s not harmful to leave StrToSet() as it is. It just returns a set of one member in this case-the date from the calendar control which is a valid set. The CONSTRAINED flag is used to prevent an injection attack and requires the expression to resolve to a valid member before the query executes.

One challenge that often confounds people working with MDX queries in the generic query designer is the inability to copy and paste the query into Management Studio for testing when parameters are in the query as shown above. The MDX query editor doesn’t support parameters. Teo Lachev (blog | twitter) posted some advice for working with parameterized MDX queries in Management Studio which I encourage you to check out.

In my next post, I’ll explain how to use the OLE DB for OLAP provider with dynamic MDX to create a dataset.

When I first learned MDX, I didn’t learn it the way that I explained it today. Consequently, I struggled for a long time until the proverbial light bulb turned on in my head about how to think about the language. I hope that my explanation saves you some of the grief that I experienced, although I can’t promise that you aren’t going to have (and lose) a few wrestling matches as you build up your MDX muscles.

As promised, I have sample queries that illustrate the concepts that I discussed today. Before you can run the queries, I assume that you have both a SQL Server 2008 R2 database instance and an Analysis Services instance. You will need to download and install the AdventureWorks 2008 R2 sample database. Then open the Intro to MDX solution included in the zip file and deploy the project to create the simple cube for the queries. Then open the MDX files in SQL Server Management Studio. You can run the entire script, and thereby execute multiple queries, or run one at a time by highlighting the query text as described in the header of each MDX file. These queries and the SSAS solution might work with earlier versions of SQL Server, but is untested.

Download the zip file containing the queries and SSAS solution here.

If you plan to attend the PASS Summit 2010 in Seattle, be sure to see my session, Demystifying MDX in Reporting Services, where I explain how to use MDX with Reporting Services. There are a few differences from the query structure that I described today that you’ll need to know.