Data Bear – Power BI Training and Consulting

Call us Today! (020) 8720 6880 | info@databear.com

# Measures vs. Calculated Columns in Power BI

### Introduction

Welcome to an insightful exploration of Power BI, where we demystify the differences between Measures vs. Calculated Columns. Essential for optimal Power BI modeling, join us on this journey as we navigate DAX formulas, providing practical insights and use cases to master your reports.

##### Measures vs. Calculated Columns: A Deeper Dive

To set the stage, let’s imagine a scenario where a report slices data by brand, featuring both a calculated column and a measure calculating the sales amount. Surprisingly, the results appear identical at first glance. But the question remains â€“ why choose one over the other, and what role does DAX play in this decision?

1. Storage and Computation:
• Calculated Columns: Computed once during the process refresh, stored in the model, and occupy space.
• Measures: Computed at query time, exist as source code in the model, and do not consume additional space.

DAX Formula Example:

1. Filter Context:
• Measures: Executed in the filter context of the visual, adapting calculations based on applied filters.
• Calculated Columns: Computed at process time without access to the filter context.

DAX Formula Example:

##### When to Use Measures or Calculated Columns?

In general, prioritize measures and resort to calculated columns when the physical structure of the column is necessary. Let’s explore specific scenarios:

Use Case Scenario: Slicing and Dicing Data by BrandÂ

• Measure: Line Amount as Measure = CALCULATE(SUMX(‘Sales’, ‘Sales'[Quantity] * ‘Sales'[Net Price]), ‘Sales'[Brand] = SELECTEDVALUE(‘Sales'[Brand]))
• Calculated Column: Essential for slicing by a specific column, e.g., ‘Sales'[Brand].
##### Pitfalls and Solutions:

Using the same expression for both a measure and a calculated column can lead to unexpected results. A measure designed for the filter context may yield incorrect values when used in a calculated column. Conversely, creating a measure using code intended for a calculated column will result in a syntax error.

##### Trick for Distinguishing Between Measure and Calculated Columns:

If unsure, look at the menu. “Measure Tools” signifies you’re working on a measure, while “Column Tools” indicates you’re creating a column.

##### Practical Demonstration: Understanding the Pitfalls

Now, let’s delve into a practical demonstration to observe the unexpected outcomes and errors that can arise when using the same code for both a calculated column and a measure.

1. Initial DAX Formula:

This measure dynamically adapts its calculation based on the filter context of the report.

2. Creating a Calculated Column with the Same Formula:

Using the same formula, we create a calculated column named ‘Sales Amount as Column.’

1. Adding the Calculated Column to the Report:
• Upon adding ‘Sales Amount as Column’ to the report, you might notice that the displayed number is incorrect. It’s not merely a formatting issue; the value is fundamentally wrong.
• Reason: A calculated column is evaluated at process time, without access to the filter context of the report. This may result in the column containing the grand total for every row, leading to unexpected results when aggregated in the report.
1. Formatting the Calculated Column:
Attempting to format the calculated column as a decimal number may not resolve the issue. Even after formatting, you might still encounter a disproportionately large or incorrect value.

• Reason: The underlying problem lies in the fact that the formula designed for the measure is not suitable for direct use in a calculated column.
1. Creating a New Measure with the Same Code as the Calculated Column:
Trying to create a new measure using the same formula as the calculated column will result in a syntax error. The formula is not designed to work in the absence of a filter context.

• Error Message: “A single value for column ‘Quantity’ cannot be determined.”
• Reason: Measures, unlike calculated columns, are executed in the filter context of the report. Without a row context, they cannot directly evaluate column values without aggregating or creating a row context.

### Key Takeaway:

This practical demonstration vividly illustrates the pitfalls of using the same code for both a calculated column and a measure. It emphasizes the importance of choosing the right element based on the context and purpose. Attempting to use identical code for both can lead to inaccuracies, errors, and unexpected outcomes. Understanding these nuances is crucial for accurate reporting and effective Power BI modeling.

By being mindful of these intricacies, you’ll be better equipped to make informed decisions when designing your Power BI models and ensuring the accuracy and reliability of your reports. So, embrace the power of DAX, make wise choices, and elevate your Power BI journey to new heights!

Remember to check out the Data Bear trainingÂ pageÂ for some awesome courses.