Despite its name the MDX Script Debugger doesn’t actually help you to debug individual MDX expressions or calculations. What it does is clear the MDX Script of the cube then allow you to step through each statement in the MDX Script, applying them one after the other, so you can see the cumulative effect on a query. This is only really useful when you’re working with scoped assignments because it allows you to see which cells in your query are changed with each successive assignment.

To illustrate, let’s use the Adventure Works cube. Comment out everything on the MDX Script (ie what’s on the Calculations tab) except the Calculate statement and add the following code to the bottom:

CREATE MEMBER CURRENTCUBE.MEASURES.DEMO AS 1;

SCOPE(MEASURES.DEMO);
    SCOPE([Date].[Date].MEMBERS, [Date].[Calendar Quarter].[Calendar Quarter].MEMBERS);
        THIS=2;
    END SCOPE;
    SCOPE([Date].[Calendar Year].[Calendar Year].MEMBERS);
        THIS=3;
    END SCOPE;
END SCOPE;

SCOPE([Measures].[Internet Sales Amount]);
    SCOPE([Date].[Date].MEMBERS, [Date].[Calendar Quarter].[Calendar Quarter].MEMBERS);
        THIS=2;
    END SCOPE;
    SCOPE([Date].[Calendar Year].[Calendar Year].MEMBERS);
        THIS=3;
    END SCOPE;
END SCOPE;

Then deploy your database and go to Debug menu in BIDS and click Start Debugging:

The MDX Debugger screen will then be displayed:

In the top pane you can see the Calculate statement highlighted – this is the point in the script that has been reached as you step through the code. In the bottom pane you have a browser control where you can construct a query plus four panes where you can enter your own hand-written MDX queries.

In the browser control, drag the Internet Sales Amount measure onto columns and the Calendar hierarchy from the Date dimension onto rows, until you see something like this:

You don’t see any data at the moment because the Calculate statement hasn’t been executed yet (see here for more details on what the Calculate statement does). If you hit F10 to step to the next statement in the MDX Script you’ll see the values for Internet Sales Amount appear because the Calculate statement has now been executed:

If you hit F10 again, the calculated member DEMO will be created and you can now drag it into the browser; at this point you’ll see it always returns the value 1 because none of the scoped assignments have been executed yet:

Hit F10 again until you reach the first END SCOPE statement and you’ll see the following:

You can see that MEASURES.DEMO now returns 2 for the Date, Month and Quarter level as a result of this first assignment; you can also see that only the values that have been affected by this assignment have been changed. Hit F10 some more to execute the second assignment and you’ll see that DEMO returns 3 at the Year level and the affected cells are again highlighted:

Notice how, in this case, because you’re scoping on a calculated measure only the cells you scoped on have their values changed. This is in contrast with scoped assignments on regular measures: because regular measures aggregate up, scoping on a regular measure not only affects the values in the cells you scoped on, but those values will then also be aggregated up though the cube.

To show what does happen when you scope on a regular measure, look at the next set of scoped assignments on the Internet Sales Amount measure. The first assignment scopes on the Date, Month and Quarter levels and sets their values to 2; however the Year level values now show the aggregated totals of all the quarters in the year, so if there are four quarters in a year then the year will show 4 * 2 = 8. The All level total is also similarly affected.

The final assignment sets the Year totals to 3 for the Year level; this overwrites the values that have been previously aggregated up from the Quarter level, and the Year level values are again aggregated up to the All level:

Hit F10 some more and you’ll reach the end of the MDX Script, whereupon you’ll go back to the beginning and can start all this again. Go to the Debug menu and click Stop Debugging to finish. Useful bit of functionality, isn’t it? Certainly one of the least-known features of BIDS too.

One last point – if you try to use the Debugger and hit the infamous SSAS Locale Identifier bug, check out Boyan Penev’s post here on how to solve this issue.

Fast forward to the present day and I can see a similar amount of confusion about the term “BI Semantic Model” or BISM for many of the same reasons. What is the BI Semantic Model exactly? It is… Analysis Services 2012 plus PowerPivot. Let’s be clear though: it is not just the new Analysis Services Tabular Model, although the term BISM is all too often used as if it did mean that. It’s not even a specific bit of software. Analysis Services 2012 consists of two parts, the Multidimensional Model which is the Analysis Services of cubes and dimensions that we already had in 2008 R2 and earlier versions, and the new Tabular model which is the Analysis Services of tables, relationships, in-memory storage and column store. BISM refers to both models plus PowerPivot, or rather it refers to the way that Analysis Services and PowerPivot can be used as a semantic layer on top of other data for reporting purposes.

So what’s the point of a term like BISM then if it doesn’t refer to something tangible? Why not just call Analysis Services “Analysis Services” and PowerPivot “PowerPivot”? Well there’s certainly some conceptual stuff going on here (as outlined in the Vision and Roadmap blog post) but just as we had with the term UDM I’d say there’s also some marketing-led obfuscation here as well, for three reasons:

• A single term like BISM suggests that Analysis Services 2012 and PowerPivot are a single, cohesive product, whereas the Tabular and Multidimensional models are actually very different beasts. If you’re going to be working with Analysis Services 2012 on a project the first decision you’ll have to make is which type of model to use, and if you change your mind later you’ll have to start development again from scratch and learn a lot of new skills. I hope one day that the two models will merge again but it won’t happen soon.
• Microsoft has correctly identified that many people want to do BI but were put off by the complexity of building Multidimensional models in previous versions of Analysis Services. The simplicity of the Tabular model goes a long way to solving this problem; Tabular also replaces Report Builder models which were really a just a simple semantic layer for people who didn’t like SSAS or had valid reasons to stay with relational reporting. In order not to scare off this market a new name is necessary to avoid the negative connotations that come with “Analysis Services” and “cubes”.
• Calling something a “semantic model” suggests that it’s a nice, light, thin, easy-to implement layer on top of your relational data warehouse, with no data duplication (which is often seen as a Bad Thing) involved. In actual fact anyone who has used the Multidimensional model will know you almost always use MOLAP storage which involves all the data being copied in Analysis Services; and I suspect when people start using the Tabular model they will be using it in Vertipaq mode (where again all the data gets copied into Analysis Services) rather than in DirectQuery mode (where all queries are translated to SQL which is then run against SQL Server).

Now I’m not going to suggest that there’s anything wrong with these marketing objectives – anything that sells more Analysis Services is good for me – or that the Tabular model is bad, or anything like that. All I want to do is suggest that in the SQL Server technical community we stop using the term BISM and instead refer to Analysis Services Multidimensional, Analysis Services Tabular and PowerPivot so we’re always clear about what we’re talking about in blog posts, articles, books and so on. I don’t think using the term BISM is useful in any technical context, just as the term UDM wasn’t in the past, because it is a blanket term for several different things. I also think that so many people are confused about what the term BISM actually means that it is becoming counter-productive to use it: people will not buy into the MS BI stack if they’re not really sure what it consists of.

What does everyone think about this?

WITH
MEMBER MEASURES.DEMO AS
IIF(
[Measures].[Internet Sales Amount]>7000000
, "TOO HIGH!"
, [Measures].[Internet Sales Amount])

SELECT
{[Measures].[Internet Sales Amount], MEASURES.DEMO}
ON 0,
[Date].[Calendar Year].[Calendar Year].MEMBERS ON 1
FROM [Adventure Works]

This gives you a lot of flexibility when writing calculations but it also can be a big problem when you want to extract data from a cube into another system, as anyone who has tried to do this will know.

In DAX and the Tabular model, on the other hand measures, like columns (calculated or otherwise) are strongly typed. Although you can’t see the type of a measure in SQL Server Data Tools when you create it, the automatically inferred type can be found in the MDSCHEMA_MEASURES schema rowset and which be queried as follows:

select *
from $system.mdschema_measures

If you try to use an expression for a measure like this that, as in my first example, could return text or an integer:

testtype:=IF(SUM(‘Internet Sales’[Sales Amount Value])>1000, 1, "test")
 
Then you get the error:
 
Measure ‘Internet Sales’[testtype] : The second and third arguments of function IF have different data types. This is not supported.

On balance I think I prefer having measures strongly typed, and for one thing it opens up the possibility of using the Tabular model for certain forms of ETL. I’ve already seen one customer of mine replace a CTE in TSQL by loading their data into Tabular and using the PATH functions instead, getting some significant performance benefits as a result, and I’m sure there will be plenty of other scenarios where ETL requires complex calculations to take place that the incredible performance of DAX will make loading all the data into a Tabular model (even if the final destination of the data is a relational data warehouse) a serious option.

http://social.msdn.microsoft.com/forums/en-US/sqlanalysisservices/thread/bd289ca5-0cb0-4279-8947-ffa2690bcd1e/

DependsOnDimension is really just a hint for use when designing aggregations using the Aggregation Design Wizard or the Usage Based Optimization Wizard.  Normally the aggregation design algorithm estimates the size of aggregations assuming dimesions are independent, but this property lets it know that one dimension is strongly determined by another dimension.  This should not affect your browsing experience in any way.

In Analysis Services 2000, DependsOnDimension was also used as part of the definition of virtual dimensions as a way of specifying the source for virtual dimension’s levels.

I did some quick experiments in BIDS and couldn’t see any evidence that setting this property affected what aggregations were designed by the Aggregation Design Wizard, but they weren’t exhaustive tests by any means. If you’re taking the trouble to enter row counts and set the AggregationUsage property you should probably try setting it if you have any dimensions that are very closely linked, just in case it does have an impact.

I was working with a customer the other week that had implemented Dave Fackler’s approach to handling multiple calendars using many-to-many relationships, as detailed in these two blog posts:
http://davefackler.blogspot.com/2008/05/handling-multiple-calendars-with-m2m.html
http://davefackler.blogspot.com/2008/06/handling-multiple-calendars-with-m2m.html

Now there’s absolutely nothing wrong with the design that Dave describes here – it’s a classic application for many-to-many relationships – and there aren’t any better ways of meeting this requirement. However, what I noticed when looking in Profiler at the customer’s cube was that all of the queries I was writing were resulting in reads on all of the partitions in the main measure group, even when I expected only one partition should be hit, and this was slowing the queries down a lot.

You can recreate the same problem in the version of the Adventure Works that Dave posts on his blog. Take the following query that uses the regular Adventure Works Date dimension and does not use the m2m relationship:

select {[Measures].[Reseller Sales Amount]} on 0,
{[Date].[Calendar].[Month].&[2004]&[3]}
on 1
from [Adventure Works]

When run on a cold cache, in Profiler you can see that it only results in the Reseller Sales 2004 partition being hit in the Reseller Sales measure group:

This is exactly as you’d expect. However if you request the same month (March 2004) via the Calendar dimension, which is connected to the Reseller Sales measure group via a m2m relationship and the Date dimension, you see all the partitions on Reseller Sales are hit:

select {[Measures].[Reseller Sales Amount]} on 0,
{[Calendar].[Year-Quarter-Month].[Month].&[2000200409]}
on 1
from [Adventure Works]

Not so good. But it turns out that this is an unavoidable side-effect of using many-to-many relationships: a filter on a many-to-many dimension (in this case the Calendar dimension) does not result in a filter being applied on the intermediate dimension (the Date dimension) to the measure group (Reseller Sales). Greg Galloway came across this some time ago and filed an issue on Connect which confirms that this is by design.

Given that I doubt this behaviour will be changed any time soon, the takeaway is that when you’re planning your partitioning strategy you should think twice about partitioning using a dimension that is used as an intermediate dimension in a many-to-many relationship. Otherwise you will lose all of the performance benefits of partitioning when your queries use that many-to-many relationship…

If you were wondering whether to come hopefully this will make up your mind – but given that almost 1000 SQL Server professionals from all round the world have already registered, so you’d better book fast if you want to be sure of a space. There are loads of SSAS-related sessions to choose from, including ones from Cathy Dumas, Marco Russo, Alberto Ferrari, John Tunnicliffe, Erika Bakse, Akshai Mirchandani, Stephan Stolze, Bob Duffy and, errr, me. Trust me, it’s going to be great!

(In the interests of full disclosure let me state that I know James Rowland-Jones pretty well because we’re both involved in running SQLBits, but the first I knew about his being appointed to a voting position on the PASS board were the above posts. What follows are my opinions alone, written without consultation with James or anyone else).

I completely understand why Andy and Steve are upset. I have an awful lot of respect for them and their views. From their – perfectly valid – perspective, what has happened is unfair and undemocratic. However I suspect there’s a reason for what has happened, and that reason can be found elsewhere on Andy’s blog:

For too long PASS (and SQLSaturday) have been US centric.

In my opinion the big problem with PASS is that on one hand it’s a self-described international organisation (number #3 on its list of current and future strategic objectives is to “Focus on International Growth and Consolidation”) but it is, in effect a North American user group with a North American focus, run by North Americans. As far as I know the vast majority the membership of PASS is in North America and therefore it’s not surprising that North Americans dominate the board: PASS members vote for candidates they know and can relate to, and who address their concerns. And that also, to me, explains why despite its good intentions PASS has had such problems with its international role: the only way it can be successful internationally will be if it has a genuinely international element in its leadership, but that’s clearly never going to happen while membership is so skewed towards North America. It’s a vicious circle.

You could argue that as PASS, and especially SQL Saturday, expands internationally it will attract more members from outside the US then more international candidates will make it onto the board through democratic means. Indeed, Rob Farley’s success in the recent elections could be a sign that this is happening. I certainly voted for Rob not only because I know, like and respect him but because of his stance on international issues. The problem is that even if the level of participation in PASS elections everywhere in the world reached the same level as it has reached in the US today (and even an optimist would accept that we’re still a long time away from this happening) the PASS board would still be dominated by North Americans simply because it’s the biggest single market for SQL Server. Moreover some countries and territories would never have any effective representation because they would be simply too small. The world isn’t divided into the US and ‘everywhere else’ but each SQL community has its own identity and its own challenges and deserves representation. Not every community is as lucky as Australia to have someone like Rob who is a native English speaker, has an impressive technical reputation and can spend the time and yes the money (those plane tickets to the PASS conference aren’t cheap) to become sufficiently well-known in the North American community to win a PASS election.

So why should, say, the UK SQL Server community get a voice on the board that is out of proportion with its relative size? That is what I’m arguing for and it might seem fundamentally undemocratic. However the challenge of effectively representing different, geographically distributed subcommunities inside a larger community is one that all large, diverse democracies have to deal with. Why should Rhode Island have the same number of seats in the US Senate as California? The answer is that this has to happen for the larger community to gain democratic legitimacy within the smaller subcommunities. If this doesn’t happen in PASS it risks disinterest, disengagement and at worse resentment in its non-US chapters – the smaller communities will quite rightly realise they are better off on their own because their interests are not being considered. Unfortunately I’ve already encountered a certain amount of resentment towards PASS for exactly this reason over the years I’ve been involved in the SQL community in Europe and I would hate to see that grow; it’s certainly the reason for the historic weakness of PASS in the UK.

The appointment of James and Raoul Illyés as international advisers to the PASS Board of Directors was clearly an attempt to address the problems of international engagement and break the vicious circle I describe above, and I’m sure the same motives were behind James’s appointment to a voting position. I strongly believe that this move was the only way that any traction on the international issue could be gained. But as I said I can understand why Steve and Andy are upset and that’s not acceptable either. What can be done? I suggest that if PASS is serious about becoming an international organisation then wholesale constitutional reform is necessary to ensure that international chapters have a voice and a vote. To use a US-friendly analogy, PASS needs its own Connecticut Compromise: alongside the board we need another, parallel body with equal representation for each chapter in the world. I would like to see discussion on how such reforms could take place as soon as possible, otherwise there’s a risk each SQL community in each country will end up going its own separate way and that won’t be good for anyone. Whatever our nationalities and whatever our cultural differences we all have SQL Server in common and working together will bring benefits to all of us.

evaluate
addcolumns(
DimProductCategory
, "Copy of Category Name"
, DimProductCategory[EnglishProductCategoryName])

However, in some calculations and queries I’ve been playing around with, this isn’t enough: I’ve not only needed to create a copy of the column but also to remove the original. So for example to crossjoin the DimProductCategory table with itself and get a cartesian product of all the possible combinations of Category name you can’t just do this:

evaluate
crossjoin(
summarize(
DimProductCategory
, DimProductCategory[EnglishProductCategoryName])
,
summarize(
DimProductCategory
, DimProductCategory[EnglishProductCategoryName])
)

Because you’ll get the following error:

 Function CROSSJOIN does not allow two columns with the same name ‘DimProductCategory’[EnglishProductCategoryName].

What you need to do is add the new column with AddColumns() and then use Summarize() to get a new table that only contains the values in this new column, like so:

evaluate
crossjoin(
summarize(
DimProductCategory
, DimProductCategory[EnglishProductCategoryName])
,
summarize(
addcolumns(
DimProductCategory
, "Copy of Category Name"
, DimProductCategory[EnglishProductCategoryName])
, [Copy of Category Name])
)

=DATEADD(DimDate[FullDateAlternateKey], 100, day)

What I noticed was that it only worked for some dates and not all; for example, in the screenshot above it works up to September 22nd and not afterwards. This threw me for a few minutes, and then I realised what the problem was. In fact, the reason is mentioned (though maybe not explained as well as it should be) in the documentation for the DateAdd function:

The result table includes only dates that exist in the dates column.

The reason why DateAdd was returning a value for September 22nd 2006 was that the value December 31st 2006 existed in the FullDateAlternateKey column; it was not returning anything for September 23rd 2006 because the date January 1st 2007 did not exist in FullDateAlternateKey.

In fact there was an even easier way to do what I wanted to do, since the DAX date type is really a decimal value where the integer portion is the number of days – I could just add 100 to the date, as follows:

=DimDate[FullDateAlternateKey]+100

So, not a great discovery and certainly nothing that wasn’t known about before, but I thought it was worth mentioning because I’m sure other people (as here, for example) will fall into the same trap as me.

From a technical point of view this year has been dominated by learning SSAS 2012 Tabular. I’m right in the middle of writing a book about it with Marco and Alberto, and it’ll be published sometime in the first half of next year. As usual writing a book turns out to be ten times more effort than I’d originally planned but it is undoubtedly the best way of learning a new technology: however well you think you know a product, you always find gaps in your knowledge when you have to write about it. My opinion of Tabular continues to grow the more I use it and DAX so I’m feeling very positive about the future and I’m interested to see what the uptake of it will be like after RTM. I’m also very excited to see how Microsoft’s cloud-BI strategy pans out in the next year: products like Data Explorer suggest that Microsoft is serious about this area and, more importantly, coming up with innovative new solutions to its challenges rather than just producing cloud-hosted versions of the software we’ve already got. There are going to be a lot of cool blog posts to write in 2012…

Business-wise I’ve continued to spend more and more time running training courses and a few months ago launched my new training website Technitrain to market not only my SSAS and MDX courses but those run by other well-known SQL Server pros. Our first third-party course with Christian Bolton went well, and next year we’ve got several others booked in. You can see the full course catalogue here; I’d also like to point out the new, lower prices on Jeremy Kashel’s Master Data Services course and Andy Leonard’s SSIS course. Frankly £1248 for a full week of training, let alone from someone of the calibre of Andy Leonard, is a bargain… although I’d argue it only looks that way because we’re too used to the inflated prices of most traditional training companies. More course dates will be announced very soon.

As far as the SQL community goes, I’m very busy speaking at user groups and helping to run SQLBits. The two SQLBits conferences last year in Brighton and Liverpool were great successes, and I still can’t believe we had Steve Wozniak turn up to speak at Brighton; SQLBits 10, which will be running from the 29th-31st of March next year, is already looking like it will beat all previous records for attendance (we’ve got 582 registrations at the time of writing) and will be the biggest and best yet. Next month I’ll be speaking in the UK at the Southampton SQL Server User Group on January 11th, and on January 12th I’ll be speaking at the PASS BI Virtual Chapter so I hope to see some of you there.

Anyway, that’s enough of me going on – it’s time to get back to my writing. Happy New Year everyone!