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.

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 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!

• Why Do I Need a Cube & How Do I Get Started
• Dimension Design 101
• Cube Construction 101
• Cube Enhancements 101

Today, I’ll show you how to secure access to the cube. I’ll also shed a little light on what happens when you deploy a cube, and I’ll wrap up this week’s lesson by explaining different ways that people might access a cube. There is so much more to learn about cubes when you have advanced analytical needs to support, but at the conclusion of this series you will have a grasp of the important concepts which is enough to get started with simple analytical requirements.

Security

Right now, you’re the only person who can browse the cube because you’re the one who created it. Before other people can browse the cube, you need to grant them the necessary permissions. Analysis Services supports only Windows integrated security, so everyone requiring access to the cube must have a Windows account. Rather than assign permissions to individual users, you might consider creating a Windows group and assigning users to that group.

Let’s assume that you have created a Windows group called SSAS and you’re now ready to set up security for your cube. Open your project in BIDS, right-click the Roles folder, and select New Role. The default name of the role is Role, but you can change that later if you like. Open the second tab in the role designer, Membership, and click the Add button. Locate the SSAS group to add the group to the role. Then go to the Cube tab and select Read in the Access drop-down list. In most cases, this step is the only one you need to perform. After you deploy the cube, anyone in the group can browse the cube using their tool of choice (which is not BIDS; BIDS is used by developers only).

Analysis Services also allows you to apply more granular permissions. For example, you can prevent users from viewing specific members in a dimension, such as the Mountain Bikes subcategory. You even prevent users from viewing certain cell values, such as the Sales Amount Quota for the AWC Logo Cap in 2008. As you might imagine, the subject of security is pretty deep and beyond the scope of what I can cover in an introductory course in SQL University. So instead, I’ll refer you to Granting User Access for an overview of security concepts in Analysis Services. For data-driven security, take a look at Analysis Services—Data Driven Security Model.

Deployment

Throughout this course, I have asked you to deploy your project to make it available for browsing. The Deploy command in BIDS actually performs three steps for you that can be performed individually by using alternative means:

1. Build – In this step, BIDS combines all the files in your project (data source, DSV, cube, dimensions, etc.) and creates a single file that has the asdatabase extension. Essentially, it’s one giant XML file that contains all the definitions about database objects that you see as individual files in BIDS. It’s very common in production environments that developers cannot deploy objects themselves, but instead provide files and scripts for administrators to perform the deployment. If necessary, you can use the Build command in BIDS to generate the asdatabase file and deliver it to your administrator.
2. Deploy – The administrator copies the asdatabase file to a location on the server hosting Analysis Services. Then, from the Microsoft SQL Server 2008 R2\Analysis Services program group, the administrator launches Deployment Wizard. (You can learn more about the wizard at Using the Analysis Services Deployment Wizard.) This wizard steps through the process of taking the asdatabase file from its current location, and moving it to the OLAP data folder of the Analysis Services instance where the file gets “unbundled” into separate database object files, just like the ones you had in BIDS.
3. Process – The presence of the database object files is not enough to render the cube usable. Processing must take place first. Processing reads the definition files to determine how to get to the source data, how to query the data, and how to load the data into the structures that Analysis Services requires. After processing completes successfully, everyone (with permissions, of course!) can browse the cube.

Processing

You can connect to Analysis Services by using SQL Server Management Studio (SSMS), and then use Object Explorer to locate a database for processing. You can even access individual measure groups or dimensions for processing. There are different types of processing that you can do. When you’re still learning about Analysis Services, it’s generally best to do a full process of dimensions and then a full process of cubes. When you perform a full process of any dimension, each cube with which it’s associated will also require a full process and the cube will be unavailable to users during this time. As you learn more, you’ll find that you can perform other types of processing that keep the cube available, but require more thought about data preparation. An overview of processing options is available at Processing (Analysis Services – Multidimensional Data).

Usually, it’s not practical to process manually in SSMS every time that you want to refresh the cube. Most people create an Integration Services package that contains one or more Analysis Services Processing Tasks, and then schedule the package to run on a periodic basis.

User Access

Once a cube is deployed and processed, users with the appropriate permissions can connect to the cube and browse to their hearts’ content. Using what? Whatever Analysis Services client they have available. Most organizations that have Analysis Services in-house also have Microsoft Office. Users can create pivot tables to explore data in a cube. The user experience in Excel 2003 is not so great, but Excel 2007 or Excel 2010 work similarly.

Assuming you are using Excel 2007 or higher, you must create an Office Data Connection (ODC) file – or open an ODC file – first. To create the ODC file, click From Other Sources on the Data tab of the ribbon, and then select From Analysis Services. Provide the server name (or localhost) and click Next. Then select your database—My SSAS DB—and the cube—Sales—and click Next. You can use the Browse button to save the ODC file in a specific place, either a local drive for personal use or a SharePoint Data Connections library for shared use.

When you save an ODC file to SharePoint, it can be used for workbooks accessed using Excel Services, or for status indicators (aka KPIs) or Filter Web Parts in SharePoint. Working with ODC files for Analysis Services sources and configuring SharePoint to authenticate with Analysis Services correctly can be tricky. You can learn more at Plan Excel Services data sources and external connections (SharePoint Server 2010). If you’re using SharePoint 2007, refer to Plan external data connections for Excel Services instead.

Regardless of where you save the ODC file, you use it as the source for a pivot table. In fact, after following the steps above and right after saving the file, you’re prompted for the location in which a pivot table will be inserted. On the right side, you should see the PivotTable Field list which displays all the measures by measure group, followed by KPIs and dimensions. All you need to do is select checkboxes for items that you want to display in the PivotTable, such as Internet Sales Amount, and Reseller Sales Amount. Expand the KPIs folder to add the following: Value, Goal, Status, and Trend. Also add Date.Calendar. Click the plus sign next to 2008 and 2008 Q1 to drill down to months. Your pivot table will look like this:

The KPIs aren’t very interesting with this data set because the total sales in the cube always exceeds the goal except when you drill down to months. The goal comes from the FactSalesQuota and is associated with quarters, but those quarters are referenced by the first day of the quarter, such as January 1, 2008, so the goal for January shown here is really a quarterly goal. There are tricks that we can use to either hide that value at the month level or to spread the quarterly amount across months in some way, but that’s beyond the scope of this week’s lessons. Hint for the curious: you have to add expressions to the MDX Script.

The selections you make in the PivotTable Field list appear below the list as objects that you can rearrange as desired. You can move dimensions from row labels to column labels or to the report filter. You can also drag the measures in the Values box to a higher or lower position to re-sequence the measures any way you like.

Remember in a previous lesson that you added an action to the cube. Let’s see how that works now. Right-click on one of the cells in the pivot table – such as the value $1,340,244.95 at the intersection of Jan 2008 and Internet Sales Amount, then point to Additional Actions, and then click on Internet Sales Details.

The action definition shows only the columns that you defined for the drillthrough action:

Excel also has a built-in drillthrough functionality that you can launch by just by double-click a cell value—as long as it’s not a calculated measure. The difference between the built-in functionality and the drillthrough action is that you have control over the columns that appear in the drillthrough action. It’s better when there is a specific set of columns that users want to see all the time, and is useful when you have a lot of columns available in a measure group and just want to focus on a subset of columns.

Your cube is also accessible for use with other tools. If you have a Reporting Services instance, users can launch Report Builder, select the Microsoft SQL Server Analysis Services provider type to create a data source, and then create a dataset using a designer interface that lets them use drag-and-drop to select the dimensions and measures they want to include in the report. User can also create status indicators from a cube for use in lists or SharePoint dashboards by using ODC files. If users want to access cube data in PerformancePoint Services scorecards and dashboards, a separate data connection for Analysis Services must be created.

Learning More

By completing the lessons in this introductory course to Analysis Services, you have the basic knowledge necessary to build simple cubes. But there is so much more to learn! Keep an eye on this blog as I’ll post topics related to Analysis Services from time to time, and of course SQL University will offer intermediate and advanced lessons in future semesters.

If your measure group contains fewer than 20 million rows, such as our sample cube from the lessons this past week, then you don’t need to worry about scaling the cube. Most business data these days contains many millions of rows, so enhancing the cube with scalability features is often the next step. The first step towards scaling is the addition of aggregations which you can learn more about by reading Optimising Aggregations in Analysis Services 2008. Another option to use, often hand in hand with aggregations, is the implementation of partitions.

A good online resource for all things related to Analysis Services is the Analysis Services Resource Hub. If you like to learn from books, here are several that I recommend:

• Microsoft SQL Server 2008 Analysis Services 2008 Step by Step by Scott Cameron, who started his BI career with me back in 1999.
• Professional Microsoft SQL Server Analysis Services 2008 with MDX by a line-up of Microsoft folks: Sivakumar Harinath, Robert Zare, Sethu Meenakshisundaram (who later went to SAP), Matt Carroll, and Denny Guang-Yeu Lee. Denny and I shared an office once upon a time before he joined Microsoft. It was entertaining, to say the least!
• Expert Cube Development with Microsoft SQL Server 2008 Analysis Services by SQL Server MVPs and friends Marco Russo, Alberto Ferrari, and Chris Webb.
• When you’re ready for advanced (really advanced!) material, tackle Microsoft SQL Server 2008 Analysis Services Unleashed by Microsoft developers who worked on the product, Irina Gorbach, Alexander Berger, and Edward Melomed. This book is required reading if you want to become an SSAS Maestro!

• Why Do I Need a Cube & How Do I Get Started
• Dimension Design 101
• Cube Construction 101

In today’s post, I will show how you to correct problems that you discover in dimensions after you deploy the database and how to enhance the cube by adding another measure group as well as adding special features, such as key performance indicators and actions.

Step 0: Dimension Cleanup

In the previous lesson, you deployed the cube and browsed the results. Everything looked good except for category and subcategory attributes, whether individually or as levels in the Products hierarchy of the Product dimension. Your task was to figure out why you the labels didn’t display correctly and to fix it.

Now for the solution. Remember that each attribute has a KeyColumns property and a NameColumn property. Unless you specify the NameColumn explicitly, the dimension will display the value in the KeyColumns when you’re browsing that attribute in a metadata list or in the cube. To fix the problem, just set the NameColumn property to EnglishProductCategoryName for the Category attribute and set the same property for the Subcategory attribute to EnglishProductSubcategoryName.

Deploy the project, and then browse the cube again to check the results. You need to click the Reconnect button to see the labels change. You can also use the Browser tab in the dimension designer to view labels in each attribute hierarchy or user-defined hierarchy if you prefer.

Step 1: Additional Measure Group

It’s a common practice to build a cube incrementally. That means you don’t need to have all your measure groups available at the same time before you can design the cube or even to make it available to users. Today you’re going to add a third measure group for Sales Amount Quota so that the cube supports comparisons of actual sales to the quotas.

Nothing makes it into a cube or dimension without coming through the DSV, so open the DSV file in your project. Right-click on the DSV background and select Add/Remove Tables. Locate the FactSalesQuota table and add it to your DSV. The foreign key relationship to the Date dimension is added automatically. The fact table also has a relationship to the Employee dimension which we’re ignoring in this week’s lesson. After we add the fact table as an additional measure group to the cube, we’ll be able to slice and dice the quota data only by date. Be sure to rename the table to SalesQuota before continuing, just like you did for InternetSales and ResellerSales.

To add the quota data to the cube, you need to open the cube designer. In the Measures pane in the top left corner of the designer, right-click the Sales cube, and select New Measure Group. Then you can add SalesQuota.However, adding the entire measure group adds all the numeric columns as measures, so you can switch to the grid view to multi-select the unneeded columns. When finished, the Sales Quota measure group should have only one measure: Sales Amount Quota. Tip: An alternative approach would be to use the New Measure command when you right-click the cube, and then use a dialog box to select the measure that you want to add.

Be sure to set the format string to Currency. Deploy the project, and then browse the cube by adding the following measures to the grid: Sales Amount and Sales Amount Quota. Then add Date.Calendar to rows like this:

Notice anything strange here? Such as the repeating values in the Sales Amount columns? Remember from the previous lesson that Sales Amount combines values from the Reseller Sales and Internet Sales measure groups. But, you can’t slice that value by date without making another change to the cube.

You also have some other date dimensions available – Order Date, Due Date, and Ship Date – which allow you to slice by Sales Amount, but not by Sales Amount Quota. In order to calculate the variance between Sales Amount and Sales Amount Quota, you need to be able to slice both measures at once.

Step 2: Dimension Usage

The ability to slice and dice a measure by a dimension member is determined by the relationship that exists between measure groups and dimensions. That type of relationship is managed on the Dimension Usage tab of the cube designer. It’s usually inherited from the foreign key relationship found in the DSV when you use the cube wizard, but it’s ignored when you manually add a measure group. The gray box at the intersection of a dimension and measure group indicates a relationship does not exist.

To add a missing relationship, click the gray box (such as the one at the intersection of Internet Sales and Date), and click the ellipsis button that appears there. Most of the time, you define the relationship here as the Regular relationship type. The other types are for advanced scenarios that we won’t be covering in this course, but if you’re really curious, you can learn more at Dimension Relationships.

Then you specify the level of detail in the dimension that relates to the measure group. For example, the Internet Sales measure group relates to the Date dimension at the Date level. So set Granularity Attribute to Date and set Measure Group Columns to OrderDateKey. In this cube, once its deployed after adding this relationship, the use of either the Date dimension or the Order Date dimension will yield similar results.

Next, repeat the process above to add a relationship between Reseller Sales and Date. Then add a third relationship between Sales Amount Quota and Date (Order Date). (You’ll use DateKey for the Measure Group Columns value in the latter case.) That way, whether users select Date or Order Date for slicing, they can compare values between actual sales and the quotas.

Why not eliminate all the extra dates? Aren’t they confusing? Well, it depends. If users will never analyze data using Ship Dates or Due Dates, then you can safely delete the three role-playing dimensions from the cube on the cube designer page (in the bottom left corner on the Cube Structure tab). You’ll still have the Date dimension available for time-series analysis and time-based slice-and-dice. On the other hand, you might want to retain Order Date along with Date in the cube if there’s a possibility that you will add another measure group that relies on Date but has no relationship whatsoever to Order Date. (That scenario doesn’t exist in the Adventure Works sample data, incidentally.)

Step 3: Key Performance Indicator

Another way to enhance a cube is to add key performance indicators (KPIs). A KPI is a group of calculations that you use to compare a value to a target. Client tools for Analysis Services can display the results of this comparison using different images that are associated with a positive, neutral, or negative status. In addition, the KPI includes a trend calculation used to show whether the value is increasing or decreasing as compared to a previous point in time. For example, you can set up a KPI to compare sales amounts to quotas by adding the expressions on the KPIs tab of the cube designer.

Click the KPIs tab which is the fourth tab from the left. Click the New KPI button (the fifth button from the left). In the form that displays, type a name—Quota—and then add the following expression in the Value Expression box:

[Measures].[Sales Amount]

The Value Expression can also be an MDX expression that resolves to a number, but this is a simple example that relies on values found in the fact tables. Next, add the Goal Expression like this:

[Measures].[Sales Amount Quota]

In the Status Indicator drop-down list, you choose an image to represent the current result of comparing Sales Amount to Sales Amount Quota. For this cube, use Shapes. Then enter the Status expression which is used to determine which shape to display. There are three possible shapes, so you need an expression that resolves as one of three possible values which effectively mean “meeting goal”, “progressing towards goal”, and “not meeting goal.” We use 1, 0, and –1 to reflect those three values respectively. For the purposes of this lesson, assume that 1 means the sales are equal to or better than 90% of the target. Otherwise, 60% of the target is represented by a value of 0, and everything else is –1. The expression to produce these results looks like this:

iif([Measures].[Sales Amount] >= [Measures].[Sales Amount Quota] * .9, 1, iif ([Measures].[Sales Amount] >= [Measures].[Sales Amount Quota] * .6, 0, -1))

The Trend expression is similar to status because it is used to determine a shape to display, but in this case the shape is an arrow and the expression requires a comparison between one time period and another. The result of the Trend expression determines what direction the arrow points—up (or 1) for upward trends, flat (or 0) for no change in trend, and down (or –1) for downward trends. The following trend expression compares the current variance to the variance for the previous year.

Case
When IsEmpty(ParallelPeriod([Order Date].[Calendar Year].[Calendar Year],
1, [Order Date].[Calendar Year]))
Then 0
When ([Measures].[Sales Amount] – [Measures].[Sales Amount Quota]) >
((ParallelPeriod([Order Date].[Calendar Year].[Calendar Year],
1, [Order Date].[Calendar Year]), [Measures].[Sales Amount]) -
(ParallelPeriod([Order Date].[Calendar Year].[Calendar Year],
1, [Order Date].[Calendar Year]), [Measures].[Sales Amount Quota]))
Then 1
When ([Measures].[Sales Amount] – [Measures].[Sales Amount Quota]) =
((ParallelPeriod([Order Date].[Calendar Year].[Calendar Year],
1, [Order Date].[Calendar Year]), [Measures].[Sales Amount]) -
(ParallelPeriod([Order Date].[Calendar Year].[Calendar Year],
1, [Order Date].[Calendar Year]), [Measures].[Sales Amount Quota]))
Then 0
Else -1
End

We’ll see how to view KPIs in the next post in this course.

Step 4: Action

Another type of enhancement you can add to a cube is an action. There are three types of actions:

• URL action – to navigate to a specific Web page, such as a Product Catalog page for a product selected in a cube.
• Reporting action – to open a Reporting Services report, such as a Sales Order Details report for a customer selected in a cube.
• Drillthrough action – to display in an HTML page the detailed data associated with a selected measure in a cube. (The measure must come from a measure group, and cannot be a calculation.)

Go to the Actions tab of the cube designer to define actions and related properties. Click the New Drillthrough Action button in the toolbar (the sixth one from the left). Name it Internet Sales Details and select Internet Sales as the action target. In the Drillthrough Columns section, select the following columns by dimension:

• Order Date: Date
• Product: Product, Subcategory, Category
• Measures: Internet Sales Amount, Internet Order Quantity

Deploy your cube. You’ll see how to use the action in the next post.

What’s Next?

Now you have a basic but fully functioning cube. In our next lesson of the week, Cube Deployment 101, I’ll explain how to implement security and how to provide users access to your cube.

Step 1: Cube Wizard

By now, you can probably guess how to launch the cube wizard. Right-click the Cubes folder in Solution Explorer, and click New Cube. For creation method, select the Use existing tables option. Then you need to specify the measure group tables. Measure group tables are equivalent to fact tables because, after all, fact tables are simply tables that contain groups of measures (the values that people will analyze). There are two measure group tables for this cube: InternetSales and ResellerSales.On the next page of the wizard, you see a list of all columns with numeric values which are presented as candidate measures. Some of them are just foreign key columns which you can ignore. (If the wizard could figure everything out, why would we need you?)

Clear the Measures checkbox at the top, and then select the following measures from the Internet Sales measure group: Order Quantity (which you rename as Internet Order Quantity), Total Product Cost (which you should rename here as Internet Cost), Sales Amount (which you should rename as Internet Sales Amount). To rename measures here, just right-click the measure name and type in the revised name.

Next, select the following measures from the Reseller Sales measure group: Order Quantity (which you rename as Reseller Order Quantity), Total Product Cost – Reseller Sales (which you should rename as Reseller Cost), Sales Amount – Reseller Sales (which you should rename as Reseller Sales Amount).

Continuing through the wizard, you get a chance to select existing dimensions. These are the dimensions that you’ve already created—Date and Product. The wizard detected the foreign key relationships in the DSV and the existence of the dimension objects in the project.

On the next page of the wizard, it volunteers to create two more dimensions for you—Internet Sales and Reseller Sales. Clear the Dimension checkbox at the top to skip this step. The technical term for these two dimensions is degenerate dimension. There are a lot of steps required to properly configure a degenerate dimension in a cube which I won’t cover this week, and it’s not commonly used (at least not in the projects I’ve done over the past 10 years, so maybe it’s just not commonly used by me…).

At the end of the wizard steps, you get the chance to name the cube. Let’s keep the name simple: Sales. And now, when you complete the wizard, you have a cube!

Step 2: Format Strings

The first thing I always do after I create a cube is configure the format strings for the measures, so that’s what I want you to do next. It’s a good habit to develop because you’ll be browsing the cube to test it soon and it will be easier to review values if they’re already formatted.

On the Cube Structure tab of the cube designer, you can see your measures in the top left corner. Actually, you first see the measure groups, Internet Sales and Reseller Sales, which you can expand to see the measures. You can select each measure one by one and set the FormatString property individually, or you can apply the format string in bulk. Let’s do that.

Click the fifth button from the left  to show measures in a grid. Then, while you press and hold the Ctrl key, select Internet Order Quantity and Reseller Order Quantity. In the Properties window, locate the FormatString property and type #,#. That will set the quantities to display as integers with thousands separators and no decimal places. Now select the remaining measures and select Currency in the drop-down list for the FormatString property.

Step 3: Calculations

In the first post, I mentioned that one benefit of cubes is the centralization of business logic. You’ll need to learn MDX to create complex calculations, but I’ll show you how to build a simple one to whet your appetite for more! If you like to learn from books, check out MDX Step by Step. Otherwise, a good online resource begins at MDX at First Glance: Introduction to SQL Server MDX Essentials by William Pearson. Pearson has a whole series of articles that follow this introduction to MDX. Although it’s a bit dated because the language has changed a bit since the article was written (and you can  now use Management Studio to write MDX), most of the principles still apply. The main thing to know is that instead of referencing a dimension member like [Date].[CY 2005] in Dimension.Member format, you use [Date].[Calendar Year].[CY 2005] in Dimension.Hierarchy.Member format.

For your Sales cube, add a simple calculation to combine the sales for Internet and reseller sales. In the Cube Designer that displays when you close the wizard (or if necessary, double-click Sales.cube in Solution Explorer), click the Calculations tab which is the third tab from the left. Click the New Calculated Member button (the fifth button from the left). In the form that displays, type a name—[Sales Amount]—and then add the following expression:

[Measures].[Internet Sales Amount] + [Measures].[Reseller Sales Amount]

This expression does what it looks like it does – adds together the two sales amount to produce a grand total, no matter how much you are slicing and dicing the cube. (If you don’t know what that means, hang on – I’ll show you later!)

Set a format string for the calculation by selecting “Currency” in the drop-down list. Now create two more measures, Order Quantity and Cost, to combine order quantities and costs from the two measure groups like you did for sales amounts. Remember to set the format strings appropriately. Tip: You’ll need to use “#,#” instead of #,# here for Order Quantity.

Step 4: Browse

Now is a good time to do some good ol’ slice and dice to see if the cube behaves as expected and returns correct results. But first you need to deploy the changes that you made just like we did in the Dimension Design 101 lesson. Then when deployment completes successfully, click the Browser tab (the very last one) in the cube designer. From the metadata tree  on the left, drag Measures to the area of the grid labeled Drop Totals or Detail Fields Here. All the measures from the fact tables and the calculations appear in the grid.

Next, expand Order Date and drag Order Date.Calendar to the area of the grid labeled Drop Row Fields Here. That’s adding a slice to the measures. The totals for each measure are now broken up into values by year. If you expand one of the years, you’ll see more detailed slices for the quarters in the selected year.

Check out the values for your three calculations to confirm that they properly sum up the base measures for overall sales, costs, and order quantities. An MDX calculation is similar to an Excel formula because it uses relative references to determine its current value cell by cell. The difference is that you define the calculation once and you don’t have to copy it every cell – it just happens. It looks to see what’s on rows, what’s on columns, and also what’s on the filter (which is the grid area currently labeled Drop Filter Fields Here) to come up with the relative reference for each cell in the grid.

Now “dice” the data by dragging Products from the Product dimension to Drop Column Fields Here. To make it easier to see the categories, remove some measures. For example, drag Internet Order Quantity off the grid, along with the other internet and reseller measure groups so that you’re left with only Sales Amount, Cost, and Order Quantity like this:

By using hierarchies in the browser, you can drill down to month or to product – but the problem is that category and subcategory keys are shown instead of names. Oops! You’ll need to fix that to improve the cube. That’s why we browse in BIDS before we deliver the cube to users…so that we can uncover problems like this.

Your Assignment

Try to solve the problem on your own. I’ll reveal the solution in the next post, Cube Enhancements 101, and as the name implies, I’ll also show you some other enhancements we can make to the cube. Meanwhile, post a comment if you have questions or need help.

Step 0: Analysis Services Project

Before you actually start construction, you need to open Business Intelligence Development Studio—affectionately known as BIDS. You’ll find it in the Microsoft SQL Server 2008 R2 program group on your Start menu. BIDS is a Visual Studio 2008 shell that installs as one of the SQL Server Management Tools when installing SQL Server 2008 R2. You don’t need a Visual Studio license to use it.

To create a new project, open BIDS, click File->New->Project, and then select the Analysis Services Project template in the Business Intelligence Projects. Give the project a name – something creative and inspiring like My SSAS DB. Your project will later become a database on the Analysis Server, but it’s nothing like a SQL  Server database. The SSAS database has a lot more files associated with it, and stores data in a completely different way.

Step 1: Data Source

Data for your cube has to come from somewhere and the Data Source file is the first step in defining where it comes from. It’s quite literally copied from the source and placed into structures that Analysis Services manages. For this course, you’ll use the AdventureWorksDW2008R2 database as described in this week’s first lesson. To create a data source, right-click the Data Sources folder in the Solution Explorer window (which you can open from the View menu if it’s not visible), and select New Data Source. Using the wizard, you can step through the process of creating a new data source that defines the data provider, connection string, and authentication method (Windows integrated security or database login) for the source data. Nothing new here—you’ve probably done this sort of thing lots of times using similar interfaces. Bottom line is that you can access any data source with an OLE DB or .NET provider.

The Impersonation Information page of the wizard is something that you’ve probably not seen before. Here you define the account that Analysis Services uses to connect to the data source. Usually, you select the Use the service account option here. The service account is the one that is running the Analysis Services service, either a domain account or a built-in account like NETWORK SERVICE. You need to make sure that this service account has read permissions on AdventureWorksDW2008R2.

Step 2: Data Source View

Next, you create a Data Source View (DSV). The DSV lets you focus on selected tables of the source database and make changes as a logical layer without changing the physical structure of your data source, which is helpful if you have only read permissions for that source. For example, you can create logical primary keys and foreign key relationships if they do not exist in your data source. Additionally, you can enhance the data by adding a Named Calculation that uses a valid SQL expression to calculate values in a new logical column of the selected table in the Data Source View. You can also replace a table with a Named Query, which allows you to select specific columns or add derived columns to a selected table just as if you were adding a new view to the underlying data source.

To keep keep this cube relatively small and simple while you learn the basics, you’ll use only a few tables from the source database. Right-click the Data Source View folder in the Solution Explorer window, and select New Data Source View. Step through the wizard and select following tables: DimDate, DimProduct, DimProductSubcategory, DimProductCategory, FactInternetSales, and FactResellerSales.

All the primary keys and foreign key relationships are detected, so you don’t need to make any adjustments to the DSV to define those required elements. However, to get the Date dimension to work properly, you need to concatenate some columns in the DimDate table to create new derived columns. Right-click on the DimDate label in the diagram and click New Named Calculation. For the first calculation, assign a name, like Quarter, and use the following expression:

CAST(CalendarYear AS CHAR(4)) + ‘ Q’ + CAST(CalendarQuarter AS CHAR(1))

Add a second calculation named Month using the following expression:

CAST(CalendarYear AS CHAR(4)) + ‘ ‘ + LEFT(EnglishMonthName, 3)

As a final task for the DSV, rename all of the tables to remove the Dim or Fact prefix and to shorten the table names related to product, so that you have Date, Product, Subcategory, Category, InternetSales, and ResellerSales. As you create database objects in subsequent steps, names of objects will be inherited from the tables here in the DSV and it’s usually best to rename everything here to minimize the renaming effort elsewhere. Tip: When working with your own data, the ideal is to rename everything back in the source database, using views if necessary.

When finished, your DSV will be similar to the figure below. Notice the icons for your named calculations Quarter and Month as a visual cue that you’ve enhanced the DSV.

Step 3: Dimensions

The Data Source and DSV definitions are the foundation for building dimensions and cubes. In this step, you build as many dimensions as you need. You might have one table in a dimension, such as the Date table, or multiple tables (called a snowflake), such as the Product, Subcategory, and Category tables. Most cubes have many more dimensions, but you’ll get the idea of the steps involved by building the two dimensions for this lesson.

When you design a dimension, you select the relevant tables in the DSV, pick the attributes (which you know as table columns) to include in the dimension, define the behavior of these attributes, and relate each attribute to other attributes by setting properties. You use a wizard to do the basic setup of the dimension and then fine-tune the dimension design using a designer interface and the Properties window. There are a lot of properties that you can configure which can seem overwhelming when you’re new to cubes. Frankly, the default values are fine most of the time for simple cubes and need to be changed only when you’re working with more advanced scenarios. I’ll walk you through changing the most important properties in today’s lesson.

To get started, right-click the Dimensions folder in Solution Explorer, and click New Dimension. For the creation method, select Use an existing table, start with the Date table as the main table, and change the Name column to FullDateAlternateKey on the Specify Source Information page of the wizard. On the Select Dimension Attributes page, change Date Key to Date, and select the checkbox for the following attributes: CalendarYear, Quarter, and Month. Click through the rest of the wizard to wrap it up.

Now it’s time to fine-tune the dimension design in the dimension designer. First, define a hierarchy. Adding a hierarchy not only helps users navigate data more efficiently, but can also improve query performance when a hierarchy contains a natural one-to-many relationship between each level in the hierarchy from top to bottom such as exists between Year, Quarter, and Month. Just drag and drop attributes from the Attributes pane in the dimension designer to the Hierarchies pane. You can also right-click the name of the new hierarchy, select Rename, and give it a better name than Hierarchy. Maybe something like Calendar. The rule is that it must be unique across all hierarchies and attributes in your dimension. When finished, your dimension designer looks like this:

The warning symbol is there because you haven’t defined attribute relationships for the levels of the hierarchy. Attribute relationships are important for performance reasons, so do that next. Click the Attribute Relationships tab in the dimension designer. Drag Month on top of Quarter, and drag Quarter on top of Calendar Year. Now you’ve defined the one-to-many relationship from the key attribute (which is the primary key in the table) to each level in the hierarchy (and the little warning symbol is now gone on the Dimension Structure tab – go ahead and take a peek!).

Now use what you’ve learned to set up the Product dimension. When you add the dimension using the wizard, set the Name column to EnglishProductName. You’ll see that the wizard automatically includes Subcategory and Category because it sees the foreign key relationships between the three product-related tables. For attributes, select the following: Product Key (which you should rename to Product), Product Subcategory Key (which you should rename to Subcategory), and Product Category Key (which you should rename to Category).

Create a Products hierarchy in this order from top to bottom: Category, Subcategory, Product. If you go to the Attribute Relationships page, you’ll see that the attributes have the correct many-to-one sequence because the table relationships contained the necessary information. With Date, all attributes were in the same table so the designer couldn’t determine the sequencing automatically.

Tip: If you forget to select an attribute when you’re using the wizard, don’t worry. You can drag the attribute from the diagram on the Dimension Structure page to the Attributes pane at any time.

Step 4: Deploy and Test

To view a complete dimension as it will appear in a cube, you must deploy your project. Just right-click the project in Solution Explorer, and click Deploy. Each Analysis Services project becomes a database on the Analysis Services server when you use the Deploy command in BIDS the first time. In addition, the files that you see in Solution Explorer get copied to the Analysis Services server as database objects and data gets copied from the source tables into these database objects. Tip: If you don’t want to deploy to a local Analysis Services server, right-click the project in Solution Explorer, click Properties, and change the Server property on the Deployment page.

After processing is complete, you can browse each dimension in BIDS using the Browser tab of its respective dimension designer. If you closed the designer, just double-click the dimension in Solution Explorer to re-open it. Each attribute becomes a two-level  hierarchy with the top level containing an All member and the bottom level containing all the unique values found in the corresponding table column. Use the Hierarchy drop-down list to switch between hierarchies in the dimension. Here’s a fragment of the Month attribute hierarchy:

Notice anything strange? We’ll fix that in the next step. Whenever you design dimensions, you need to check each attribute hierarchy and each user hierarchy (Calendar and Products in today’s lesson) to make sure the names of each member appear correctly and in the right sort order. A member is the unique value in a hierarchy – such as 2005 Aug or 2005 Dec in the Month attribute hierarchy.

Step 5: Sort Order

The default sort order for dimension members is by name. You can sort by the key value, assuming the key is correctly defined and will produce the sort order that you want. You can also sort by another attribute in the dimension. To fix the problem above, you start by changing the key value to a composite key based on the year and the month number. Switch to the Dimension Structure tab, click Month, and then find the Key Columns property in the Properties window. If that window isn’t open, use the View menu to open it.

Click in the Key Columns box to display the ellipsis button, and then click that button. In the Key Columns list, select Month, and then click the arrow pointing left to remove the column from the list. Then double-click CalendarYear and MonthNumberOfYear to add the two columns as a composite key to the list. Click OK to close the dialog box. Now you’ll need to change the NameColumn property to Month.

Whenever you use a composite key, you must specify a name column. If you’re using only a single column as a key, that column will do double-duty as both key and name column unless you specifically define a name column.

To check the results, you’ll need to redeploy the project. Only the changes you made get deployed so it goes much faster than the initial deployment. Go to the Browser tab and click the Reconnect button (the second button on the toolbar) to re-establish communication with the server. The sort order should be correct now for the Month attribute hierarchy. The Month level of the Calendar user hierarchy will also correctly sort.

What’s Next?

Most cubes have a few more dimensions than you’re creating here, but the process is very similar so I won’t walk you through the steps. For extra credit, though, you can try adding in dimensions like Promotion or Sales Territory. As I mentioned earlier, there are a lot of properties to configure for dimensions that allow you to get specific behavior for advanced dimension structures, but the default settings are sufficient when dealing with simple dimensions such as you have in the project now. If you’re really curious, you can check out the official list of properties, but most of this won’t likely make more sense until you can put it into context with examples.

In the next post in this series, Cube Construction 101, I’ll show you how to work with the cube wizard and the cube designer. Once you get the cube built, you’ll see how the dimensions work with cubes to facilitate the slice-and-dice capability for which SSAS is famous.

P.S. If you have any trouble with today’s lesson or have questions about dimensions, post a comment.

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.