CHAPTER 1

D AX is the programming language of Microsoft SQL Server Analysis Services (SSAS) and Microsoft

(yes, in 2010 PowerPivot was spelled without the space; the space was introduced in the Power Pivot
name in 2013). Over time, DAX gained popularity in the Excel community, which uses DAX to create
Power Pivot data models in Excel, and in the Business Intelligence (BI) community, which uses DAX to
build models with SSAS.

DAX is a simple language. That said, DAX is different from most programming languages and
it might take some time to become acquainted with it. In our experience, having taught DAX to
thousands of people, learning the basics of DAX is straightforward: You will be able to start using it in
a matter of hours. But when it comes to understanding advanced concepts like evaluation contexts,
iterations, and context transition, everything will seem complex. Do not give up! Be patient. Once
your brain starts to digest these concepts, you will discover that DAX is, indeed, an easy language.
It just takes time to get used to.

relationships. We recommend readers of all experience levels read this section in order to gain
familiarity with the terms we use throughout the book when referring to tables, models, and different
kinds of relationships.

In the next sections, we offer advice to readers who have some experience with other programming
languages—namely Excel, SQL, and MDX. Each section is for readers who already know that language

is totally expected. Just skip that part, since it contains information that is essentially meaningless to
you, and move to the next chapter, where our journey into the DAX language really begins.

Understanding the data model

already know what a data model is, but if you are not familiar with it, it is worth dedicating some
pages to a description of data models and relationships, so as to create a foundation on which you
will build your DAX knowledge.

1
 Relationships can form a chain. Each product has a subcategory and each subcategory has a
category. Thus, each product has a category. In order to retrieve the category of a product,
you will need to traverse a chain of two relationships. Figure 1-1 includes an example of
a chain made up of three relationships, starting with Sales and continuing on to Product
Category.

In each relationship, there can be one or two small arrows. In Figure 1-1 you can see two
arrows in the relationship between Sales and Product, whereas all other relationships have a

We will discuss this in much more detail in later chapters, because determining the correct

In the tabular data model, relationships can be created on single columns only. Multiple
column relationships are not supported by the engine.

Filtering always happens from the one-side of the relationship to the many-side. If the relationship is

the one-side.

An example might help you understand this behavior better. If you create a pivot table based on
the data model previously shown in Figure 1-1, with the years on the rows and Sum of SalesAmount
and Count of ProductName in the values area, you will see the result shown in Figure 1-2.

FIGURE 1-2

The Row Labels contain the years—that is, a column from the Date table. Date is on the one-side
of the relationship with the Sales table. So when you put the Sum of SalesAmount in the pivot table,

bidirectional; when you put the count of product names in the pivot table, you get, as the result, the

table using a chain of relationships.

If you now modify the pivot table by putting the Color on the rows and adding the Count of
FullDateLabel in the values area, the result is somewhat harder to understand, as you can see in
Figure 1-3.

CHAPTER 1 What is DAX? 3

 FIGURE 1-4

DAX for Excel users

Chances are you already know the Excel formula language, which DAX somewhat resembles. After
all, the roots of DAX are in Power Pivot for Excel, and the development team tried to keep the two
languages similar. This makes the transition to this new language easier. However, there are some very
important differences.

In Excel, you perform calculations over cells. A cell is referenced using its coordinates. Thus, you write
formulas as follows:

DAX is different. In DAX, the concept of a cell and its coordinates does not exist. DAX works on
tables and columns, not cells. So whenever you write DAX expressions, they will only refer to tables

range as a table (by using the Format as a Table function), you can write expressions in Excel that
reference tables and columns. If you look at Figure 1-5, you see the column SalesAmount evaluates an
expression that references columns in the same table, instead of cells in the workbook.

CHAPTER 1 What is DAX? 5

 One aspect where the two languages are very similar is in the fact that both Excel and DAX are
functional languages. A functional language is made of expressions that are—basically—function
calls. Neither in Excel nor in DAX is there the concept of statements, loops, and jumps, which are
common to many programming languages. In DAX, everything is an expression. This aspect of the
language is often a challenge for programmers coming from different languages, but it should be no
surprise at all for Excel users.

One concept that might be new to you is that of iterators. When working in Excel, you are used to
performing calculations one step at a time. In the previous example, you have seen that, in order
to compute the total of sales, you have created one column containing the price multiplied by the
quantity and then, as a second step, you summed it to compute the total sales. This number will then
be useful, for example, as a denominator to compute the percentage of sales of each product.

Using DAX, you can perform the same operation in a single step, by using iterators. An iterator
does exactly what it name suggests: it iterates over a table and performs a calculation on each row of
the table, aggregating the result to produce the single value you needed.

In the previous example, you can compute the sum of all sales using the SUMX iterator:

Both advantages and disadvantages occur in this approach. The advantage is that you can perform
many complex calculations as a single step without having to worry about adding many columns,

is that programming with DAX is less visual than it is in Excel. In fact, you do not see the column
computing the price multiplied by the quantity; it exists only for the lifetime of the calculation.

To tell the truth, you still have the option of creating a calculated column that computes the
multiplication of price and quantity. Nevertheless, as you will learn later, this is seldom a good
practice, because it uses precious memory and might slow down the calculations.

Let’s be clear: This is not a difference between programming languages; this is a difference between
mindsets. Like any human on this planet, you are probably used to searching on the web for complex
formulas and solution patterns for the scenarios you are trying to solve. When using Excel, chances

8
 For example, in one of the worksheets that I use daily, I have this formula:

I do not really understand exactly how the formulas in curly brackets work and how that IF

keyboard combination. That said, it works, it always worked and the number that it computes is of
interest rather than how it internally computes the value. Thus, as an author of books and a DAX
expert, I fall in this category of users, too.

This approach, which works in Excel, does not work with DAX. You will need to study some theory
and understand thoroughly how evaluation contexts work before you will be able to write good DAX
code. Without the proper theoretical foundation, DAX will either compute values like magic or it will
compute strange numbers which make no sense. The problem is not DAX, but the fact that you have
not yet understood exactly how it works.

Luckily, the theory of DAX is limited to a couple of important concepts, which are explained in
Chapter 4, “Understanding evaluation contexts.” When you reach that chapter, roll up your sleeves
and be prepared to go back to school for some time. Once you have mastered its content, DAX will
have no secrets for you, and learning it will be mainly a matter of gaining experience. However, please
do not try to go further unless that piece of theory is well established. Remember: knowing is half the
battle.

DAX for SQL developers

If you are used to the SQL language, then you have already worked with many tables and created
joins between columns in order to set relationships. From this point of view, you will feel at home
in the DAX world, because computing in DAX is a matter of querying a set of tables joined by
relationships and aggregating values.

can set foreign keys between tables to declare relationships, but the engine never uses these foreign
keys in queries, unless you are explicit about them. If, for example, you have a Customer table and a
Sales table, where CustomerKey is a primary key in Customer and a foreign key in Sales, you can write
a query such as the following:

CHAPTER 1 What is DAX? 9

 Even if you declared the relationship in the model using foreign keys, you still need to be explicit
and state the join condition in the query. Although it makes queries a little more verbose, this is useful
because it lets you use different join conditions in different queries, giving you a lot of freedom in the
expressivity of the queries.

In DAX, relationships are part of the model and they are all LEFT OUTER JOINS
the model, you no longer need to specify the join type in the query: DAX uses an automatic LEFT
OUTER JOIN in the query whenever you use columns related to the primary table. Thus, you would
write the previous SQL query in DAX as:

Because DAX knows the existing relationship between Sales and Customers, it does the join
automatically following the model. Finally, the SUMMARIZE function needs to perform a group by
Customers[CustomerName], but you do not have any keyword for that: SUMMARIZE automatically
groups data by columns selected.

retrieve using SELECT statements, without worrying about how the engine will actually retrieve the
information. DAX, on the other hand, is a functional language.

In DAX, every expression is a function call and function parameters can be, in turn, other function
calls. The evaluation of parameters might lead to very complex query plans that DAX executes in
order to compute the result.

10
 For example, if you want to retrieve only customers who live in Europe, you can write this in SQL:

Using DAX, you do not declare the WHERE

function (FILTER

You can see that FILTER is a function: It will return only the customers living in Europe, producing
the expected result. The order in which you nest the function and the kind of functions you use have

query optimizer does a great job, the programmer has more responsibility in writing good code.

In SQL, there is a clear distinction between the query language and the programming language; that
is, the set of instructions used to create stored procedures, views, and other pieces of code in the
database. Each SQL dialect has its own statements to let programmers enrich the data model with
code. DAX, on the other hand, makes virtually no distinction between querying and programming.
A rich set of functions manipulate tables and can, in turn, return tables. The FILTER function you have
just seen in the previous query is a good example of this.

Thus, in respect to this, DAX is simpler than SQL. Once you learn it as a programming language (it

CHAPTER 1 What is DAX? 11

 One of the most powerful features of SQL as a query language is the option of using subqueries.
DAX has some similar concepts even if, in the case of DAX subqueries, they naturally arise from the
functional nature of the language.

For example, in SQL, to retrieve customers and total sales for only the customers who bought more
than US$100, you can write this query as follows:

You can obtain the same result in DAX by simply nesting function calls:

In this code, the subquery that retrieves CustomerName and SumOfSales is later fed into a FILTER
function that retains only the rows where SumOfSales is greater than 100. Right now, this code might
seem unreadable to you but, as soon as you start learning DAX, you will discover that the usage of

12
DAX for MDX developers
Many BI professionals start to learn DAX because it is the new language of SSAS Tabular and, in the
past, they have used the MDX language to build and query SSAS Multidimensional models. If you are
among them, be prepared to learn a completely new language: DAX and MDX do not share much.
Worse, some concepts in DAX will remind you of similar existing concepts in MDX, even if they are
very different.

In fact, in our experience, learning DAX after MDX is the most challenging option. In order to
learn DAX you will need to free your mind from MDX; try to forget everything you know about
multidimensional spaces and be prepared to learn this new language with a clear mind.

time for you to understand that the [All] member of any attribute hierarchy is indeed a point in the
multidimensional space.

DAX works in a much simpler way. There are no dimensions, no members, and no points in
the multidimensional space. In other words, there is no multidimensional space at all. There are

The DAX space is built on top of tables, columns, and relationships. Each table in a tabular model
is neither a measure group nor a dimension: It is just a table and to compute values you have to

relationships.

You will soon discover that, from the modeling point of view, Tabular offers fewer options than
Multidimensional does. Having fewer options, in this case, does not mean being less powerful,
because you have a programming language (that is, DAX) which lets you enrich the model. The real
modeling power of Tabular is the tremendous speed of DAX. In fact, you are probably used to avoid
using too much MDX in your model, because optimizing MDX speed is often a challenge. DAX, on
the other hand, is amazingly fast. Thus, most of the complexity of the calculations will not be in the
model, but in the DAX formulas instead.

DAX and MDX are both programming languages and query languages. In MDX, the difference is
made clear by the presence of the MDX script. You use MDX in the MDX script, along with several
special statements that can be used in the script only (for example, SCOPE statements) and you
use MDX in queries when you write SELECT statements that retrieve data. In DAX, this is somewhat

new to DAX, which does not exist in MDX) and measures (similar to calculated members in MDX).

CHAPTER 1 What is DAX? 13

 You can also use DAX as a query language, for example, to retrieve data from a tabular model using
Reporting Services. Nevertheless, there are no special functions in DAX that are useful only for one of
these two uses of the language. Moreover, you can query a tabular model using MDX, too. Thus, the
querying part of MDX works with tabular models, whereas DAX is your only option when it comes to
programming a tabular model.

Using MDX, you rely on hierarchies to perform most of the calculations. If, for instance, you wanted to
compute the sales in the previous year, you had to retrieve the PrevMember of the CurrentMember on

The measure uses the ParallelPeriod function, which returns the cousin of the CurrentMember on

You can write the same calculation in many other ways, using FILTER and other DAX functions, but

you will probably miss hierarchy calculations until you get used to DAX.

Another important difference is that in MDX you refer to [Measures].[Sales Amount] and the

SUM(Sales[Sales Amount]).
it whenever you want to use it (you can always create a measure that holds the sum of sales, but we
do not want to be too wordy here).

14
 Another important difference between DAX and MDX is that the latter makes heavy use of the
SCOPE statement to implement business logic (again, using hierarchies), whereas the former needs a
completely different approach, because hierarchy handling is missing in the language altogether.

For example, if you want to clear a measure at the Year level, in MDX you would write this
statement:

In DAX, there is no SCOPE statement. To obtain the same result, you need to check the presence of

You will learn later what this formula computes in detail but, intuitively, it returns a value only if the
user is browsing the calendar hierarchy at the month level or below, returning a otherwise. This
formula is much more error-prone than the equivalent MDX code. To be honest, hierarchy handling is
one of the features that is really missing in DAX.

Finally, when using MDX you probably got used to avoiding leaf-level calculations. Performing
leaf-level computation in MDX turns out to be so slow that you always prefer to pre-compute values
and leverage aggregations to return results. In DAX, leaf-level calculations work incredibly fast and
aggregations do not exist at all. This will require a shift in your mind when it will be time to build the

one for Tabular, and vice-versa.

CHAPTER 1 What is DAX? 15