Non Empty Behavior is a very good optimization method you can use with your calculated measures. It allows you to define a list of measures that their emptiness defines the emptiness of your calculated measure. To understand this, look at the picture (taken from the MSDN):

This is the calculation expressions pane from the Calculations tab in the cube designer. From MSDN:

“The measures you specify in the Non-empty behavior list are used to resolve NON EMPTY queries in MDX. When you specify one or more measures in the Non-empty behavior list, Analysis Services treats the calculated member as empty if all the specified measures are empty. If the Non-empty behavior property is blank, Analysis Services must evaluate the calculated member itself to determine whether the member is empty.”

This is not new. NEB is quite old feature in SSAS. The new thing (at least for me) is that NEB can also be used in Panorama formulas! For example, M1+M2 /*NONEMPTY_BEHAVIOR={M1,M2}*/ will apply M1 & M2 as NEB. You can see more Panorama optimization methods here.

Let’s say that I work in number of jobs. In every job I got some tasks that I need to do. The fact table looks like this:

Summarizing the “Tasks To Do” column will get the total tasks that I need to do. Summarizing the “Tasks Completed” column will get the tasks that I did. Note that in the Therapist job I didn’t get any tasks.
In the OLAP cube, I created a calculated measure which is the percent of the completed tasks (for every job or for any other dimension). The problem is: What is the answer in case that there are no any tasks to do? Some will say 0% and some will say 100%. That’s why a text measure such as “There are no tasks” can be a perfect solution for this kind of problem. This is the calculation of the calculated measure:

Create Member CurrentCube.[Measures].[Completed Percentage] as
IIF(IsEmpty([Measures].[Tasks To Do]),
null,
IIF([Measures].[Tasks To Do] = 0),
-1,
[Measures].[Completed Tasks] / [Measures].[Tasks To Do]
)
)
,format_string = “#,##0%;\T\h\e\r\e\ \a\r\e\ \n\o\ \t\a\s\k\s;0%”;

In the Panorama’s view, the format of the measure must be “General”. Otherwise, the view won’t show the format string with the text

Here are some useful tips when learning MDX. Even experienced MDX programmers may find interest in these:

• If you were a code programmer in your past, you can relax: MDX don’t care about capitalization.
• Don’t even try to skip an axis: It’s impossible and it is meaningless. Use the predefined names for the axis, such as: columns, rows, pages, etc.
• You’re new to MDX and the whole OLAP gives you a headache? Try to imagine this as a hypercube. It can help you a lot.
• When writing large queries, pay attention to the “readability” of your MDX. Use the Monospace fonts whenever possible.
• Do NOT think of SQL when learning or working with MDX. Although the syntaxes may look alike, these languages are totally different when you get to know them.
• .Members will give you all regular members. .AllMembers will also include calculated members.
• An expression like [Time].Members won’t work if the Time dimension has multiple hierarchies.
• The asterisk (*) can replace the CrossJoin function. It may improve readability of the code.
• When using Order() function, you can specify a sorting criteria which is not shown in the result grid.

Don’t believe it? Okay, let’s play!

If you don’t know much about MDX, these are the rules of your game:

1. Your pawns are called “Members”. Each member has a name, e.g. [Harry Potter] (get used to the square brackets limiting names in MDX).
a. Each member may also have a value depending on the current members on other dimensions. E.g. the value of [Harry Potter] from the “Customer” dimension might be “2″, indicating the two tooth pastes Harry bought, i.e. the current member of dimension “Product” is “Tooth Paste”, and the “Measure” is “Product Count” rather than “Money payed”.
b. You may have a neutral member, called: [Measures].CurrentMember.

2. A group of members is called “Set”. Sets may have names, e.g. [Set A]. Sets may contain members or other sets, by wrapping them with curly brackets, using the following syntax: “{[Member1], [Member2], [Set1]}”. The empty set syntax is “{}”

3. You may generate a new set by iterating a set and performing operation on each of its members, using this syntax: “Generate ([Set], Operation ([Set].Current))”. E.g. if [Set] contains “{[USA], [Canada]}”, then “Generate ([Set], [Set].Current.Children)” will generate a new set with the states which are the children of each country, namely “{[California], [Washington], …, [British Columbia], [Yukon], …}”

4. Filter a set by a certain condition: “Filter ([Set], Condition)”. E.g. “Filter ([Customers], [Customers].Current > 2)” will filter out [Harry Potter], as its value is “2″, and the filter leaves only customers whose value is larger than “2″.

5. Instant-If syntax: “Iif (Condition, True-Expression, False-Expression)” means that if condition is met, then True-Expression is returned, otherwise, False-Expression is returned. E.g. what would return: “Iif ([Harry Potter] = 2, 1, 0)”? That’s right, since [Harry Potter] has a value “2″, the condition is met, and “1″ is returned, being the true-expression.

6. Use StrToSet(”…”) to convert a string into a set. E.g. StrToSet(”{[M1]}”) will convert the string to a set with single member [M1].

Memorize these rules, as they will be erased from this blog within 5 seconds…

Just kidding… Now the challenge:
You have one condition and 2 sets, [True Set] and [False Set]. You should return [True Set] if the condition is met, otherwise return [False Set].

Have a clue…? Recognize any rules with true/false expressions? … For example … rule #5…?

Well, that’s easy, you say. You propose:
“Iif (Condition, [True Set], [False Set])”

Good for you, it’s just that Instant-If shouldn’t return sets, only numbers, strings, or members.

Excuse me? You tried it and it worked?

You tried it on Yukon, right? Yukon (apart from being a territory in Canada), is the nickname of Microsoft Analysis Services (AS) 2005. However, it won’t work on the older version, AS 2000.

Any solution…? Like bypass the Instant-If/set situation by some conversion…? As mentioned in rule … #6?

Huray! You propose using StrToSet(…). But how…?

That’s right: StrToSet ( Iif (Condition, “[True Set]“, “[False Set]“))
The instant-if returns a string, and whatever string is returned, is immediately converted to a set.

That’s a jolly good answer, but still, there are MDX dialects which don’t support StrToSet, like SAP BW. Besides, what if the sets are huge? Conversion might be time & memory consuming.

Any other ideas…? Other rules with conditions…? Like … rule #4?

Great! You propose: Filter ([True Set], Condition)
You claim that if the condition is met – all members of [True Set] will pass the filter.

Alas, it’s very time consuming! Applying the condition on *all* members? Think of an improvement for the condition to be calculated only once (you’re in the right track, though).

Tough, huh…? Any rules you haven’t used …? For example … rule #3?

Ok, you suggest using “Generate” (by elimination, huh?). But do you know how?

Suppose you use “Generate” to generate [True Set] all at once, but only if the condition is met.
“Generate” is capable of generating [True Set] all at once, but it doesn’t do conditions. It iterates sets.

How can we benefit from that?

Let’s look at this phrase: Generate ([Set], [True Set])

This will generate [True Set] for each member in [Set]. So, if [Set] has only one member – [True Set] will be generated once. If set is empty – [True Set] won’t be generated.

Hey, this is exactly what we need. Can you smell the solution coming…?
We should control the number of members in the set: 1 for generating [True Set], 0 otherwise – depending on our condition. And what would be better for that purpose than our beloved … Filter?

Now we’re really close:
Generate (Filter ([Set], Condition), [True Set])

We use Filter to control the number of members in [Set]: 1 member for generating [True Set]; 0 members for generating an empty set.

But what is this [Set]?

Okay, it should contain only one member, but we don’t really care which. In other words, it should be neutral.

Rings a bell…? Any forgotten sub-rule…? Like … #1b?

Eureka! Using a set containing the neutral member { [Measures].CurrentMember }, The full answer is:
Generate (Filter ( { [Measures].CurrentMember }, Condition), [True Set])

This will generate [True Set] only once, and only if condition is met.

And what about [False Set]?

Answer: Lest use the opposite condition “Not Condition”:
Generate (Filter ( { [Measures].CurrentMember }, NOT Condition), [False Set])

Finally, how do we combine these 2 together?

Well, that’s easy: since both phrases generate sets (the first generates [True Set] or empty set, the second generates [False Set] or empty set);
And since a set may contain other sets, let’s wrap them with curly brackets:

{
Generate (Filter ( { [Measures].CurrentMember }, Condition), [True Set])
,
Generate (Filter ( { [Measures].CurrentMember }, NOT Condition), [False Set])
}

Whenever condition is met – [True Set] will be generated be the first phrase. Since the second phrase uses opposite condition – it will necessarily not be met, and an empty set will be generated consequently, leaving only [True Set]. If the condition is not met – only [False Set] will be generated, as you can figure.

Check Mate!!!

In that case you might probably think that supporting one OLAP platform’s MDX means you’ve covered them all…. Is that the case?

nope!

The main objective of standardization is to make this happen (supporting all OLAP providers with zero effort). However, each implementer of the standard might interpret the standard “slightly” different.

How much does “slightly” mean?

Let’s look at an example for such a “slight” difference between Microsoft and SAP BW as an example. Think about the “Filter” MDX function;

Suppose you’re analyzing the sales amount of year 1997 across the various states in the US, such as California (CA), Oregon (OR) and Washington (WA):

1997

——

CA 70
OR 40
WA 20

Now, if you want to see only states which sold more than $30K. The MDX statement produced by your BI tool (such as Panorama NovaView) should be something like:

Filter (

{CA,OR,WA} ,

Year.1997 > 30

)

The filter function accepts 2 arguments: the first is a set of members – in our case the states, and the second is a numeric expression.

The filter iterates the members of the set, and check for each member if the numeric expression returns positive. If not – the member is filtered out from the set.

In our case, filter iterates the states and leaves only states which sold more than 30 in 1997 (that leaves CA and OR in our case):

1997

——

CA 70

OR 40

Now, suppose you want to see the same data, but divided to gender – Male (M) and Female (F):

1997

—–

M

CA 31

OR 17

WA 12

F

CA 29

OR 23

WA 8

Have you noticed that this is the same data? If you sum up M and F you’ll get the same results as before (e.g. for CA 31+29 = 50).

What if we apply the same filter we used before on this new table (or “cross-tab”, as we call it)?

We can easily see that the only number above 30 is CA in the context of Male (31). Let’s mark it as (M, CA) – which is called a “Tuple”.

Now, in the Microsoft world, if we used the same filter function we used before, we would get only this tuple – (M, CA).

However, SAP BW has a “slightly” different interpretation of the “Filter” function:

It ignores context!

In other words: it’s not aware of the Male/Female we nested before our states, and calculates the filter condition according to the sales amount seen in the first table.

That means that we’ll see CA and OR in the context of both Male and Female – so we’ll see many values lesser than 30, which we wanted to filter out.

SAP BW rationale states that if you want the filter condition to be calculated in the context of a certain “dimension” (in our case the gender dimension), you should explicitly add the dimension’s current-member to the condition:

Filter (

{CA,OR,WA} ,

(Year.1997, Gender.CurrentMember) > 30

)

This will order BW to calculate the values of Male, then of Female, and produce correct results.

Ok – you say – but that’s not *that* complicated.

Maybe so, but that’s just one small example. The above solution works only for a small portion of the cases. In other cases you would use the “Sum” function in order to add a member to context, or replacing “Count of Filter” with “Sum of IIF” – and other things you wouldn’t want to know about. Plus, you need a pretty “rough” mechanism to even understand which dimensions are found in your context! You would go through all that effort just to overcome the “slight” difference of “Filter”….

And let me tell you something, this is just one tiny example… there are many other functions and so many differences….

So this is my life, I learn and optimize our MDX support to be able to work across platforms. Hope to get some feedback on this note.

So the invention of MDX (Multi Dimensional Expressions) is really the key cornerstones in the world of BI especially since its establishment  as a standard query language for OLAP servers. MDX has three powerful concepts embedded in it. These concepts together are what make MDX unique and allow users to ask complex multi dimensions questions.

First and foremost is the ability to handle multiple dimensions simultaneously. Like in SQL, elements from Customers, Products and Time can be grouped together. The power of MDX is the ability to run complex expressions on each of the combinations, who are my top 5 Customers/Products/Periods? Who are the poorest? More power is reveled when a subtle change to the MDX is made and the entire expressions now refer to a different Geography, Reseller or Employee. MDX made BI exploration as powerful as it could get.

The second most important element of MDX is the hierarchy manipulations. As BI consumers we constantly move between analyzing highly aggregated values and drilling down to the focus areas. MDX is very good at both. It allows navigation inside big hierarchies with operations like Descendents and Ancestors. Most of the Set Theory operations like Union and Intersect are available and complex rules can be combined to assist users in navigation. An example is “please drill to the products that start with A till F and are manufactures in USA”.

As the semantic layer is becoming richer with metadata information, in many cases the analysis process combines fact table numbers with metadata. The ability to combine both is very powerful and in my opinion this is MDX’s third important element. In SSAS 2005 this is referred to Dimension Attributes and Member Properties. In SAP world it is called Navigational and Display Attributes. No matter what the name is, in MDX it’s fairly the same and powerful combinations can be created. An example would be “Top 5 Customers for each product that is manufactured in the USA and weight over 5 kilos”.

As BI technologies evolve so is MDX. I feel that MDX is standing these days at a crossroad.  Two of the main players that support MDX (Microsoft and SAP) are pushing it to different directions. Each company is interpreting the specification so to minimize its disadvantages, and is adding new sections to show its strength. In any case it would be interesting to see what will MDX next “most powerful” concepts.
We often say though that MDX is just like chess, knowing the rules doesn’t really mean you know how to play….. we made the concept of mastering MDX an art, we invite you to download our product and see how far MDX can be taken.