When writing a book like this which focuses on all the new stuff, it’s easy to get caught up in minutiae. As I begin to wind down the writing process for this book, I thought it would be interesting to step back and consider which enhancements I thought were particularly helpful for the package development process. There are certainly other enhancements that are helpful too, but the following list includes the ones that are special favorites of mine because they address problems that I encounter most often during my own package development or when teaching students about SSIS.

In no particular order, here is my list:

1. Interface overhaul. Business Intelligence Development Studio (BIDS) is now SQL Server Data Tools (SSDT), but that’s not the important part. Inside SSDT, the Toolbox window now includes a Favorites folder into which you can place components that you use regularly. I find that people can spend a lot of time hunting through the list of available components, so this feature can really help you out when there’s only a handful of components that you use in every package. There are several other changes to the interface, such as zoom control, and icons to specify whether a component succeeded or failed during package execution that improve the development experience as well.
2. Shared Connection Managers. The idea of building something once for reuse many times is not new, and yet until now you’ve had to add the same connection managers to package after package, which turns into a rather tedious task if a change was required to each package’s connection manager. Now you can set up a connection manager once and reference it in multiple packages. As an added bonus when you use a Cache Connection Manager that you share between a parent and child package, the two packages share the same cache which optimizes performance for lookups against the same source in both packages.
3. Undo and Redo. How many times have you made a change to a package and then instantly regretted it? I bet it’s happened at least once! Fortunately, the Undo button is now enabled so you can reverse that change, and the Redo button is available also in case you change your mind afterwards.
4. Resolve References Editor. Managing metadata in the data flow pipeline is a concept with which many beginners struggle, especially when they make a change early in the data flow that has a ripple effect across the downstream components and causes metadata errors.  Now SSIS includes a Resolve References Editor that you can use to quickly resolve the mapping of input and output columns between components. You can use it to check that columns are mapped to one another properly, and also to see which columns remain unmapped.
5. Variable scope. Here’s another commonly encountered problem. How many times have you added a variable only to realize later that you inadvertently assigned its scope to a task rather than to the package? Your only option was to delete the variable and add a new one while taking care to set the scope correctly. The new SSIS creates new variables at the package scope by default, and allows you to move an existing variable to a different scope.
6. Left() function. In previous versions, you can use the Right() function or the Substring() function to work with portions of  a string, but there was no Left() function until the SQL Server 2012 release. Hooray!
7. ReplaceNull() function. A very common task in data warehousing is to replace NULL values with some value. This new function just simplifies that task.
8. Project deployment model and parameters.Working with SSIS projects and deployment is a completely new way of setting up packages to work in a new environment in SQL Server 2012, whether test or production. When you combine this deployment model with the use of parameters, you use parameters instead of configuration files to set run-time values for expressions. Most people didn’t understand what to do with configuration files, so this will be a welcome change indeed for that group. Even if you did work successfully with configuration files, you will likely still find it easier to set up parameters than configuration files.

You can download the upcoming ebook to get more details about the items in my list above. Specifically, Chapter 6 covers Integration Services and is available now in the first draft of the ebook. And come back to visit this blog often – I’ll be providing more details in the coming weeks about each of these items that space did not permit me to include in the ebook.

Meanwhile, you might also like these resources about SSIS and the upcoming release:

• The SSIS product development team provides posts from time to time to elaborate on various aspects of the product. You can use the Denali tag on the blog site to focus on the the new features of 2012.
• Jamie Thomson has a comprehensive list of changes with screen shots, which after all are worth more than a thousand words!
• Jamie also posted an excellent walk-through of the level of detail that package execution can log in the SSIS catalog.
• Last, but not least, Jamie has published a reporting pack that helps you monitor logging in the SSIS catalog.

I think my list of favorite enhancements is heavily biased by my experiences this week working with a new SSIS 2008 r2 developer. Perhaps you have a different set of favorites. If so, share your thoughts! Which SSIS features do you like best in the SQL Server 2012 release?

Then one day I received an email explaining that I had been mentioned by SQL_Joker on Twitter and could I make some time for a phone conversation to talk about a potential business opportunity? Well, that email got my curiosity piqued about this Twitter business, so I set up an account so that I could see for myself what the fuss was all about, and the rest – as they say – is history!

1. Get help with a problem. Whether you’re independent like me, working in a small shop, or out of resources in a big organization, there are people out there who might be able to help. Sometimes weird things happen and you need a fresh perspective for troubleshooting. Or you’ve been asked to start working with a different aspect of SQL Server and need a nudge in the right direction. With SQL Server professionals around the globe, someone out there is probably able to help. Don’t worry if no one knows who you are and isn’t following you – that will come with time. All you need to do is compose a tweet and add a hashtag at the end of your request – like #sqlhelp, #ssashelp, #ssishelp, or #ssrshelp. If you need more that 140 characters, then break your tweet into 2 parts and add 1/2 and 2/2 to each part. Before you tweet, you can use the search feature in Twitter to see tweets using these hashtags and learn what kinds of questions get answered. Obviously, it’s not the best way to get help for complex problems.
2. Learn new things. Technology keeps changing and it can be challenging to stay current. As you learn who’s who in the SQL Server community, you can follow them to get breaking news, or thoughts about trends, or resources of interest. Don’t know who to follow? Start by watching who answers questions for the #sqlhelp and other hashtags, click the name, and click the Follow button. If you like what they tweet, do nothing but continue to watch the tweets. If you don’t like what they tweet, you can always Unfollow later. If you explore Twitter more deeply, you can also see who a person follows and who follows them. You might see some names you recognize as conference speakers, bloggers, and authors of magazine articles and books. Cast a wide net.
3. Develop friendships with people who share common interests. Those of us in the SQL Server community have SQL Server in common. Often, the way we met one another was at conferences and that’s the only time we interacted from year to year. But with Twitter, we can continue the conversation. And with more conversation, the more we get to know one another and the friendships develop. And for those who can’t get to a conference, they can participate vicariously as many of us tweet interesting things that we hear and see. I’ve had Twitter exchanges with many people long before I met them, and some whom I’ve never met. So don’t feel like you have to know someone personally before you engage. Just be polite and friendly. Ask questions or offer up something you’ve learned. Before long, if you play nicely, you’ll be amazed at how you’ve been assimilated into the family.
4. Have a laugh. We work hard and take our jobs seriously. Well, most of us do! But, seriously, we need a break from time to time, even if just for a few minutes. Every now and then, someone will come up with a topic and people begin to riff on that. You’ll see things like movies or books with names adapted to something meaningful and humorous only to those in the SQL Server community. You’ll just have to keep your eyes peeled to see what I mean.
5. Work the network. As you get to know people on Twitter, you’ll find that you can get help in other ways besides the technical stuff. Maybe you need to find a job, or maybe you know of a job opening at your company. Twitter is a great way to share the need and someone might be able to help. I’ve heard lots of great stories of people getting connected in this way. Of course, having relationships built first is important. But this network of ours is not just about jobs. If you’re traveling some place new, or thinking about buying some new gadget, or need inspiration for a new way to fix something for dinner, someone in the community has an opinion that you might find useful.

Books

• SQL Server 2008 MDX Step by Step, Bryan C. Smith, C. Ryan Clay, Hitachi Consulting (Microsoft Press, 2009). This book is useful for beginners, and leads you through the key concepts of MDX as the name implies…step by step. Although it’s written for SQL Server 2008, you will find it useful for SQL Server 2008 R2 as well and, although I haven’t tested it, it should work for SQL Server 2012.
• MDX with SQL Server 2008 R2 Analysis Services Cookbook, Tomislave Piasevoli (Packt Publishing, 2011). I really like this book, as you might surmise from my review, and picked up a few tips myself. However, you’re not going to start learning MDX with this book. I recommend that you first read the Step by Step or some of the online resources first to get the most value from it.
• MDX Solutions, 2^nd edition. George Spofford, Sivakumar Harinath, Christopher Webb, and Dylan Hai Huang (Wiley, 2006). Although this book is focused on SQL Server 2005, much of it still applies to 2008 and later versions as the language remains largely intact. However, I must say this is not a book for beginners. There is lots of useful information here, but you will find it more useful if you already have a good grasp of the basics.
• Practical MDX Queries for Microsoft SQL Server Analysis Services 2008, Art Tennick (McGraw-Hill, 2010). I haven’t read this book yet, but it’s in my queue to read this year. If you’ve read it, I invite you to add a comment to this post with your impression.

 Online Resources

• Stairway to MDX Series, I have long recommended Bill Pearson’s (@Bill_Pearson) online writings, such as MDX Essentials at Database Journal, and of course must heartily recommend his latest endeavor at SQL Server Central.
• MDX Studio. This resource is not one designed to teach you MDX, but I include it as a tool that you can use to improve your MDX as it is a tool that you can use to identify problems  in your query and to capture statistics for your query if you’re attempting to improve performance. Mosha, the developer of this tool, also developed an online version for formatting and analysis.

Blogs

• Mosha Pasumansky is one of the architects responsible for the MDX language, so what better resource could you ask for? He’s no longer at Microsoft, but fortunately his legacy persists at SQLBlog.com with many posts dedicated to providing insights into MDX.
• Chris Webb (@Technitrain) is a coauthor of the second edition of the MDX Solutions mentioned above and writes frequently about  MDX. He has some very creative ideas that I have found useful in some of the more bleeding edge projects I have worked on.
• Another terrific MDX online resource is Marco Russo (@MarcoRus). Marco and Chris Webb (along with Alberto Ferrari) co-authored Expert Cube Development with Microsoft SQL Server 2008 Analysis Services which I recommend if you want to learn more about developing the cubes that we use as a source for MDX queries.
• Boyan Penev (@BoyanPenev) also writes on SSAS topics that you might find helpful for improving your MDX skills
• Greg Galloway has some interesting studies on MDX at his blog.
• SSAS-info, run by Vidas Matelis (@VidasM) is a great aggregation site that includes MDX topics.
• And of course, I have my own series which will expand over time, so keep checking back here for everything I write on MDX.

Whitepapers/Best Practices

• Identifying and Resolving MDX Query Performance Bottlenecks. MDX performance is partly dependent on the choices you make when constructing the query and partly dependent on the cube structure. This whitepaper explains how to determine where to focus your attention for resolving query performance issues.
• Analysis Services 2008 Performance Guide. Here you’ll find some good information about avoiding MDX functions that cause performance problems. You can use this whitepaper in conjunction with the performance bottleneck whitepaper to ferret out the problems you might be experiencing with slow queries.
• Analysis Services Query Performance Top 10 Best Practices. As you build your MDX skills, it’s a very good idea to keep best practices in mind. This is  a nice quick reference to have handy.

You might do this during cube development to test out calculation syntax before adding it to the cube, or you might do this only when you need to run a one-time query to answer a specific question or test the cube. You can even use this technique for Reporting Services reports or with  other tools. But I have to recommend that, wherever possible, you should put calculations inside a cube which would render moot what I’m about to show you.  Why? So you don’t have to reinvent the wheel each time you need a calculation. One of the reasons we build cubes is to centralize business logic, which includes calculations. That said, some calculations can’t go in the cube. Whatever your reason, there will likely come a time that you’ll need a calculation added to your query, so the point of this post is to prepare you for that time.

We’ll start with an analogy in Excel, using a percent of total calculation as shown below. The formula consists of a numerator to get the sales amount on the current row and a denominator that references the total sales amount in cell B2. We use the terms relative reference and absolute reference to describe the values in the numerator and the denominator, respectively. So for Road-250 Black, 44 on row 4, we have a formula =B4/$B$2, where B4 is a relative reference and $B$2 is the absolute reference. As we paste the formula into rows 2, 3, and 5, the formula changes to =B2/$B$2, =B3/$B$2, and B5/$B$2.

We can get similar behavior in an MDX query by using tuples. I can create one tuple as an expression (the term we use in Analysis Services that corresponds to a formula in Excel) for the numerator, and a second tuple as an expression for the numerator. Let’s create a query that has a calculation for the numerator and denominator separately, and then a third calculation for the final calculation so that we can see the results independently.

First, I like to create the query with placeholders, just to get the query structure straight before I introduce anything else that might compromise the query as I add complexity. Not that this example is complex, but it’s a good habit to develop. Start simple, and build up from there. It’s too easy to mess yourself up with a stray comma or parenthesis. Note that we add in each expression in a WITH clause that precedes the SELECT statement, and that we add the expressions as measures. Then we can use them just like a measure that comes from the cube in the SELECT statement.

WITH
MEMBER [Measures].[Numerator] AS NULL
MEMBER [Measures].[Denominator] AS NULL
MEMBER [Measures].[Pct of Total] AS NULL
SELECT
{[Measures].[Sales Amount],[Measures].[Numerator],[Measures].[Denominator],[Measures].[Pct of Total]}
ON COLUMNS,
[Product].[Category].Members ON ROWS
FROM [Adventure Works]

Now let’s update the numerator expression by replacing NULL with [Measures].[Sales Amount]. You can see below that the query result simply repeats the sales amount value from the first column in the second column. Let’s review what we know about tuples from Location, Location, Location. When the query resolves the tuple for the second column, the current measure – [Measures].[Numerator] – doesn’t really exist in the cube, but its expression redirects to [Measures].[Sales Amount] which then gets combined with the category member on each row to produce a tuple which in turn resolves as a value retrieved from the cube. Just like the tuples for each value in the first column. This tuple is like the relative reference we saw in the Excel example – Sales Amount varies according to the row.

Next let’s update the denominator expression by replacing NULL with a tuple expression: ([Measures].[Sales Amount], [Product].[Category].[All Products]). This time the query results shown below repeat the tuple value that we see at the intersection of the first column and first row. When the query resolves the tuple for the third column, both the measure in the tuple and the category member come from the expression. Thus, we get a constant value for each row in the third column. This tuple is like the absolute value in the Excel example.

So let’s ponder tuple behavior in query results again for a moment. Simply put, a tuple resolves as by combining the current column member, the current row member, and whatever members are in the WHERE clause (aka the slicer). If a member on rows, on columns, or in the WHERE clause is a calculated member, then whatever member the calculated member references in the expression will be overridden in the current row, column, or slicer member. If the expression is complex – that is, composed of operations on multiple tuples – then the contents of each tuple is evaluated independently. Thus, in the percent of total calculation, we have the numerator changing dynamically as row members change but the denominator remaining constant.

Putting the pieces together, we get the final query as shown below. Notice the FORMAT_STRING property added to the Pct of Total expression to get a percentage format. It’s not necessary for Numerator or Denominator because the use of Sales Amount directly (rather than as part of a computation) results in the use of the currency format string as defined for the measure in the cube.

WITH
MEMBER [Measures].[Numerator] AS [Measures].[Sales Amount]
MEMBER [Measures].[Denominator] AS ([Measures].[Sales Amount], [Product].[Category].[All Products])
MEMBER [Measures].[Pct of Total] AS [Measures].[Numerator] / [Measures].[Denominator], FORMAT_STRING='Percent'
SELECT
{[Measures].[Sales Amount],[Measures].[Numerator],[Measures].[Denominator],[Measures].[Pct of Total]}
ON COLUMNS,
[Product].[Category].Members ON ROWS
FROM [Adventure Works]

Compounding the delay is the fact that I’m currently in my remote Alaskan home and the Internet situation is still getting ironed out. It has taken me over 20 minutes just to get this simple little explanation post put out there for you. (It’s PAINfully slow, but at least I have a beautiful view while I wait!) Besides, you should be doing something else as the year winds down! I promise there will be more to come. Either as soon as my Internet speeds up or when I get back to the mainland – whichever comes first!

Wishing you a very Happy New Year!

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.

Background

Today’s post was inspired by a problem I encountered on the first day of the BI Immersion class. To make things easier for folks to have a working environment in which to try out the topics we discuss during the BI Immersion class, I recommend they get a freely available VHD with the entire Microsoft BI stack installed and configured. It’s evaluation software so it only works for a limited time, but it should be enough time for learning until you get your own permanent environment set up. Also, it’s not quite the entire BI stack, but we fix that during class by adding PowerPivot for SharePoint and adding another Reporting Services instance in SharePoint integrated mode. (Side note: Adding PowerPivot for SharePoint to an existing farm can be challenging – may need to do some fiddling to get it working.)

The Problem

As I was demonstrating Reporting Services (native mode) using the aforementioned VHD, I noticed that the Data Feed button was missing from the HTML Viewer toolbar. Yet, it was there in the toolbar when using Reporting Services in SharePoint integrated mode. You use this button to export data to PowerPivot for Excel – or any application that can consume an ATOM data feed. Where did the button go?

The Solution

My guess is that this VHD was not created from scratch using SQL Server 2008 R2, but rather migrated from an earlier version and somehow the RSReportServer.config file didn’t update properly. When I looked at the file for clues about the data feed button, I noticed that a rendering extension was missing. I added it back in as shown below (see the highlighted text), then opened up Report Manager to look at a report. Hooray – the button is back!

(Sorry about the lack of wrapping – I’ll fix it later. Have to get to class!)

<Render>
<Extension Name="XML" Type="Microsoft.ReportingServices.Rendering.DataRenderer.XmlDataReport,Microsoft.ReportingServices.DataRendering"/>
<Extension Name="NULL" Type="Microsoft.ReportingServices.Rendering.NullRenderer.NullReport,Microsoft.ReportingServices.NullRendering" Visible="False"/>
<Extension Name="CSV" Type="Microsoft.ReportingServices.Rendering.DataRenderer.CsvReport,Microsoft.ReportingServices.DataRendering"/>
<Extension Name="PDF" Type="Microsoft.ReportingServices.Rendering.ImageRenderer.PDFRenderer,Microsoft.ReportingServices.ImageRendering"/>
<Extension Name="RGDI" Type="Microsoft.ReportingServices.Rendering.ImageRenderer.RGDIRenderer,Microsoft.ReportingServices.ImageRendering" Visible="False"/>
<Extension Name="HTML4.0" Type="Microsoft.ReportingServices.Rendering.HtmlRenderer.Html40RenderingExtension,Microsoft.ReportingServices.HtmlRendering" Visible="False"/>
<Extension Name="MHTML" Type="Microsoft.ReportingServices.Rendering.HtmlRenderer.MHtmlRenderingExtension,Microsoft.ReportingServices.HtmlRendering"/>
<Extension Name="EXCEL" Type="Microsoft.ReportingServices.Rendering.ExcelRenderer.ExcelRenderer,Microsoft.ReportingServices.ExcelRendering"/>
<Extension Name="RPL" Type="Microsoft.ReportingServices.Rendering.RPLRendering.RPLRenderer,Microsoft.ReportingServices.RPLRendering" Visible="False" LogAllExecutionRequests="False"/>
<Extension Name="IMAGE" Type="Microsoft.ReportingServices.Rendering.ImageRenderer.ImageRenderer,Microsoft.ReportingServices.ImageRendering"/>
<Extension Name="WORD" Type="Microsoft.ReportingServices.Rendering.WordRenderer.WordDocumentRenderer,Microsoft.ReportingServices.WordRendering"/>
<Extension Name="ATOM" Type="Microsoft.ReportingServices.Rendering.DataRenderer.AtomDataReport,Microsoft.ReportingServices.DataRendering" Visible="false"/>
</Render>

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.