about me – Austin Senseman, CFA 5 years in Financial Services, Managed analytics for sales, marketing, risk, finance, & accounting functions Power Pivot user since 2011 MCSA: SQL Server CFA Charterholder, CPA License (inactive) Principal Consultant, 2015 – Work with clients all across the world on Power Pivot & Power BI solutions #1-ranked blog (powerpivotpro.com) #1 selling Power Pivot book (DAX Formulas for Power Pivot) Training, education, jumpstarts

today’s talk: understanding “context” The learning curve for DAX isn't a straight line - it starts off gradual and quickly gets steep. With a syntax similar to Excel, DAX seems easy enough for an Excel power user but things quickly get confusing without a good foundation in the basics of DAX. Those basics - context and calculation - are the topic for this session. This session is for the intermediate DAX user who has produced some quality data models and DAX calculations but who is still having difficulties with functions around filtering, time intelligence, and complex calculations. We'll go through a number of practical examples that show that DAX at a fundamental level is a combination of creating filter and row CONTEXTS and then using those contexts to produce CALCULATIONS. Understanding this concept is a must to produce more complex code in DAX and it's also a very useful framework for someone just getting started.

today’s talk: what you need to know 1.There are two types of evaluation context – row & filter 2.Filter Context Comes From 5 Places: Table Rows, Table Columns, Report Filters, Slicers, and CALCULATE() 3.Calculated columns automatically provide row context unless you introduce an aggregator 4.Simple aggregators in a calculated column disable row context and only look at filter context 5.Using CALCULATE() in a calculated column re-establishes the row context – this is called “context transition” 6.Iterative aggregators inherit filter context and establish row context – and the row context piece behaves exactly like a calculated column 7.The EARLIER() function is used to access row contexts outside the current row context in a calculated column 8.The CALCULATE() function is used to alter the filter context in a measure

concept: row context vs. filter context  Primarily a calc column “thing”  A calc column is calculated on a row-by- row basis, so there’s 1 row in play  You can reference a column and use it as a numerical result (scalar)  If no RC, you have multiple rows, so you can’t do that!  You lack an RC in measures * Row Context = Single Row  Primarily a measure “thing”  The set of coordinates coming from the pivot table (for a given Values-area cell)  Requires an aggregation function to turn a column reference into a numerical (or date, etc.) result  Row, Column, Report Filter, and Slicer fields Filter Context = Set of Rows

function: CALCULATE() Name of an existing measure, or formula that is valid for a measure ex: [Total Sales] ex: SUM(Sales[ExtendedAmount]) A simple filter expression like Table[Column] = ex: Products[Category]=“Bikes” ex : Calendar[Year]=2003 ex : SalesTable[ExtendedAmount]>=100 Operation Like SUMIF(), but more like “anything IF” Modifies the filter context as specified by the pivot, but ONLY for this measure! CALCULATE(,,,…)

recap of CALCULATE() basics 1.Takes an original measure and filters it –Kinda like SUMIF or SUMIFS! –It could have been named GOAPPLYFILTERS() 2.Each input is typically Table[Column]= –Like Calendar[Year]=2003 or Products[Category]=“Bikes” –But can also use >, =, 3.The order of the inputs does NOT matter –NEVER matters

recap of CALCULATE() basics 1.Each input “stacks” on top of other filters in the filter context –Adds filters/coordinate on top of the initial filter context from the pivot –Also adds filters/coordinates on top of those supplied by other inputs –Each filter/coordinate typically results in fewer rows “kept” 2.Exception: inputs REPLACE filters supplied by the pivot –Only when it’s the same column! –Otherwise, it stacks like above 3.“||” operator allows CALCULATE to keep rows that meet either of the two tests –Ex: Foods[Type]=“Peanut Butter” || Foods[Type]=“Jelly” –Keeps both the Peanut Butter AND the Jelly rows

function: FILTER() Name of a table, or formula expression that evaluates to a table ex: Calendar ex: VALUES(Calendar[Year]) ex: ALL(Calendar[Year]) Anything that evaluates to True or False ex: [Total Sales Measure] < 50 ex : SUM(SalesTable[ExtendedAmount]) > BudgetTable[Column1] ex : NOT(ISBLANK([Total Sales Measure])) ex : Table[Column1] <= Table[Column2] * 1.1 ex: [Total Sales Measure] 0 Operation Steps through every row (or value) in Evaluates at each step, in the context of that current row/value Only keeps rows that return True ONLY SUBTRACTS from filter context. NEVER adds or overrides. FILTER(, )

function: SUMX() Name of a table, or formula expression that evaluates to a table ex: Calendar ex: VALUES(Calendar[Year]) ex: ALL(Calendar[Year]) Measure name, measure formula, column name, or calc column formula ex: [Total Sales Measure] ex : SUM(SalesTable[ExtendedAmount]) ex : SalesTale[ExtendedAmount] ex : SalesTable[UnitPrice] * SalesTable[Quantity] Operation Steps through every row (or value) in Evaluates at each step, in the context of that current row/value Sums the results of all steps SUMX(, )

important observations 1.Special functions like ALL() and FILTER() can be used two ways –To alter the filter context during measure calculation –To return tables with particular contents 2.The purpose (filter or table) is determined solely by where it is used –If as a input to CALCULATE, used for filter modification –If as a input, used to return a table 3.But for either purpose, these functions operate the same way –Most clearly illustrated by FILTER() – row by row, keep or drop each row 4.Only after the function runs, are the results used differently –If used as a, the results modify filter context –If used as a, the temporary result table is then treated like any other table

important observations continued 5.If used as a, each table function has unique impact on filter context –EX: ALL() replaces an existing filter context with the full set of rows –…which is the same thing as removing a filter from the context, as previously learned –EX: FILTER() can only subtract rows from the filter context –…very different impact from ALL() 6.But if used as a, the results of table functions are treated identically –EX: ALL(Calendar) and FILTER(Calendar, 1) –If both return every row in the Calendar table (depends on initial filter context)… –…the “outer” function (like COUNTROWS) can’t tell the difference between the two

important observations continued 7.In a measure, we cannot refer to a “naked” column and use it directly as a value –Always requires an aggregation function –Because in a measure, we have a Filter Context (pivot coordinates), but we do NOT have a Row Context (which only exists in calc columns) –This does NOT apply in inputs to calculate, or to IF’s based on measures –Just watch for the “cannot be determined in current context” error 8.VALUES() is a very interesting function –Table Purpose: returns single-column table of all values that are “active” in the current filter context (for the given column) –Useful as the input to other functions like FILTER, so you can “iterate” over entities (like Household) for which you don’t have a physical table –Filter Purpose: restores/preserves filters –Both: respects “downstream” filters applied to columns that aren’t on the pivot (peers into the filter engine and not just the filter context prior to filter engine operation)