I have been working with Databricks lately and have been impressed by how modern the interface is, everything is accessible via a web browser (as opposed to using SSMS for Azure). You have data lineage, ability to share queries, and most importantly there is a catalog of every table and views where you get an overview of the artifacts, sample data, history etc.

One thing that got my attention was the ability to add comments to table/view columns in the catalog. Now if you are importing these views into your Power BI semantic model, you would want to import the column comments into the descriptions of the Power BI columns. There is no native way to achieve this in Power BI. Here comes the ‘information_schema’ to the rescue.

In the ‘information_schema’ there is metadata listed for all the tables and views in the catalog. The comments on each column is also listed. So how do we get this inside Power BI.

Let’s explore 3 options

1. Copy-paste. It’s 2025 AD, not 2025 BC, so this is a BIG NO.

2. Run a SQL query on the ‘information_schema’ and export the relevant fields (view name, column name, comments) into a csv and use Tabular Editor to import the comments into the description property for each column.

Not a bad idea, except that it is still a manual process to run the query and save it as a csv. You might be able to automate the export (havent tried it though), but you still have to deal with a csv file which you have to manage.

3. Use a C# script in Tabular Editor to import the comments into the description property of the columns in your semantic model. This can be part of the build process. Now we are talking. So how do we do this.

Import the relevant fields from the ‘information_schema’ into your semantic model as a separate table. You will also need a mapping table to map the view name from Databricks to the table name in Power BI.

Run the script below and you are done ! That’s it ! With a bit of once off set up work in your semantic model you can now import comments from views in Databricks into your enterprise models !

The learnings are divided into 4 sections: IMPORT, MODEL, REFRESH, SUPPORT. These correspond to roughly the four main tasks of a semantic modeller.

IMPORT

• • • • Apply transformations as left as possible

        All reusable logic needs to be shifted as left as possible and as close to the source as practical. This is to ensure that the databases do all the heavy lifting (extract, transform and load) and your semantic model becomes a layer to aggregate the metrics via measures rather than an ETL layer. This diagram from Part 1 shows where the various transformations and measures are defined

        

• • • • Star schema model is preferred

        A star schema is the best technique for faster reports and lesser memory consumption. An enterprise model may have multiple star schemas in the same model, with fact tables linked to conformed dimensions. This is the first step in getting the semantic model right. If it is not star schema, performance will suffer.

        
        Image source: MS Learn

• • • • Use views instead of tables

        Use views to import data into your Power BI model. Using views has three advantages
        1. Tables generally do not contain business friendly names. They might have a name such as MemberAccountBalance_Total which is not user friendly. You can write this in a view as Member Account Balance.
        2. You can remove/add columns in views. Tables often contain columns such as Record_From_Date, Record_To_Date etc which are required for testing purposes but are not required in the semantic model. So you can remove such columns in the views. You can also add new columns in the views. These are commonly report level logic which are specific to certain reports. So if you want to bin your data, you can write that logic in the views.
        3. You can join multiple tables in views. Sometimes the views are not straight forward and you might want to join multiple tables to form one view to meet the reporting requirements.

• • • • Simplify views – resulting in simpler DAX

        Simplify views as much as possible so that the DAX becomes simpler, and the queries perform faster. The goal of the semantic model is not to show off your DAX, in fact it is the exact opposite. The semantic model should only contain simple aggregations like SUM, DISTINCTCOUNT, AVERAGE and/or simple filters in CALCULATE. If you are traversing multiple tables with DAX then it’s too complex. Move the logic back to the tables/views so that the DAX is simplified.

• • • • Do not import all data into desktop

        This is the key to making your model lighter in desktop and faster to publish. A model I’m currently working on is ~12GB in Power BI service (memory) while it only occupies 4MB of disk space on my laptop. How is it even possible? The trick is to only import a fraction of the data into your desktop model. You can either import only 1000 rows for each table and/or use a ‘Start Date’ parameter to only import from a certain date onwards. Use parameters to achieve this as explained below.

• • • • Parameterize everything

        Use parameters in Power Query. Parameters can be used to store server name, database name, schema name, Start Date. A typical parameter can look like this:

        

        The advantage of using parameters are twofold:
        1. You can have different names for servers, databases in different environments. This is crucial as you would publish your model to a UAT/SIT environment first and then push it to production. And normally non prod environments have a different set of servers and databases
        2. You can quickly change names of servers, databases, schemas if they are renamed at the source. Without parameters you would have to manually go to each query and change it, which would be time consuming.

• • • • Utilise query folding in power query

        One of the core principles of an enterprise model is that all columns have to be defined in the views and not in Power BI. However, you can certainly remove some columns in Power Query which you may not want to import into your model. An example would be fact table primary keys. These keys are normally created for testing purposes but don’t serve a modelling or reporting purpose. So, you can remove them in Power Query. Another step you might apply in power query is a filtering step to limit the rows being imported. Ensure that these two steps still utilise query folding (from my experience they should)

MODEL

• • • • Use desktop for DEV

        Since you are only bringing in a fraction of the data into the desktop model, it cannot be used to test the data. Use it as a development (DEV) workspace where you apply all column and DAX formatting, table naming, column ordering etc. Since its a lighter model you can easily push the changes to UAT/SIT workspace with the use of external tools (see Use External Tools section).

• • • • Give descriptions for tables and fields

        It’s not just important to import all the data and write good DAX it is also important to provide descriptions to all entities used by the business users in the model (tables, columns, measures, hierarchy) so that they exactly know what those entities are and how they can be used.

• • • • Follow the eleven rules of DAX management

        DAX is the window of the semantic model to the outside world. It is via the DAX measures that users interact with the model. Hence the measures need to be appropriately named, faster to query, and proper formatting applied. Go through this article to apply all the eleven rules of DAX management before pushing the measures to production.

• • • • Use external tools

        The use of external tools greatly increases productivity and agility. There are three main tools which are of importance, and they should be in the arsenal of every semantic modeler. They are all free to use and if you do not have them, get your IT department to install them for you.

        Tabular Editor

        Tabular Editor is a tool that lets you easily manipulate and manage measures, calculated columns, display folders, perspectives and translations in Analysis Services Tabular and Power BI Models. You can also automate a lot of the modelling process by writing C# scripts that interacts with the Tabular Model and edits the model. There are a lot of custom C# scripts freely available to get your started. Once you get to know the objects you can manipulate in the Tabular Object Model, you can easily write scripts that performs formatting, column ordering, relationship creation etc. Modelling using Tabular Editor is a breeze and once you start using it you will never go back to using the clunky desktop GUI for your work.

        DAX Studio

        This is the ultimate tool for working with DAX queries. If you are writing lots of DAX, be it in the semantic model or report level measures you can test your queries for speeds, server timings, query plan etc. You can also use the DMV (Dynamic Management Views) to query the TOM model and get important insights like table size, number of rows, measure expressions etc.

        ALM Toolkit

        This is a great toolkit to manage and publish your datasets to different workspaces. You can compare two datasets and see what is different and push the changes you want to the workspace of your choice. By using this toolkit you are only pushing the metadata changes to a workspace and not the entire dataset. So if you have added 10 new measures into your desktop model, instead of publishing it the manual way using Power BI desktop and updating the model in service and running a refresh on it again, you only update the measures using this toolkit, without a need to refresh the entire model. A must have external tool for agile delivery.

• • • • Apply incremental refresh where possible

        Incremental refresh is a great way to reduce the memory footprint of your models while refreshing. When you apply incremental refresh policy on a fact table in your model you are locking in the past data and only incrementally refreshing the most recent data. Say you have a large fact table in your dataset with 200 million rows and five years’ worth of data and you want to reduce the number of rows to be refreshed every day, you could apply an incremental refresh policy and lock in the first 4 years of data and only refresh the current year. So, every day the fact table only gets data for the current year which would be much less than 200 million which means the model consumes less memory during refresh and you stay well within your memory limit (in case of Power BI Premium subscription).

        However, be mindful of the fact that if a table reload is required at the source, then you would need to disable incremental refresh in the model and bring in all the data once again. Be very careful of applying incremental refresh on a table in the model. Only do so when you are 100% sure that no table reloads will occur in the future.

REFRESH

• • • • Use pipelines in service

        Use deployment pipelines in Power BI service to push your models fom UAT to PROD. Deployment pipelines enable semantic modelers to manage the testing and publishing of their semantic models. You can also publish reports, paginated reports, dashboards, as well as dataflows. You can also automate it by using the Power BI Automation Tools Extension in DevOps which is an effcient way of deploying models especially if there are multiple modes.

• • • • Automate refresh

        Automatic refresh of semantic models doesnt mean setting up a refresh schedule for the models. This will not work as if the underlying tables are being reloaded, say each night in the data warehouse the exact time of when the reloads are complete cannot be determined. Hence setting up a scheduled refresh for the semantic models means that the model will start refreshing before the reloads have finished. This results in time out issues apart from not refreshing the latest data.

        In order to avoid such a scenario use the Power BI REST API to refresh the models after the reload is complete. Using this APT you can also fine tune the refresh by specifying the Max Parallelism values, tables and partitions to refresh.

• • • • Monitor refresh

        Use the Gen2 Metrics App to monitor the Power BI Gen2 premium capacities. Among the features of this dashboard is the ability to monitor the refresh times, peak memory consumption, CPU usage and number of users utilising your semantic models.

SUPPORT

• • • • Use source control

        Source control is a tricky subject in the Power BI world as there is no built in source control within Power BI. You would need to use a combination of Sharepoint/DevOps to manage your pbix/template files. A good place to start on an automated way to keep track of pbix files is here

        A turbulent journey through Power BI source control – Mutt0-ds Notes

• • • • Document the model

        It is important to document the model in production so that everyone from Managers to developers know what entities are available in the model. You can do this manually via Sharepoint/Confluence but it becomes cumbersome to maintain and error prone. An automated data glossary dashboard which extracts the metadata from your models in production is a much better scenario. This glossary gives you details on
        – M expressions of each query
        – Number of tables and columns in the model
        – Number of measures and their expressions
        – BUS matrix
        – Number of rows in the tables
        – Size of tables and columns in the model
        – Lineage between data warehouse tables/view to measures

        Talk to us if you need help in implementing such a data glossary for your models.

• • • • Optimize the model

        Models in production should always be optimised to ensure they consume less memory and refresh and query faster. Memory is at a premium in Power BI (forgive the pun) so you should always strive to make sure the models only use the bare minimum necessary to meet the reporting requirements. Here are some steps to perform to make sure models refresh faster and consume less memory
        – Remove unnecessary columns from tables, especially fact table primary key columns
        – Filter rows which are not required for reporting. If there is only a reporting requirement for the last five years, do not include data from 2010 onwards
        – Decrease precision of decimal fields to 2 decimal points
        – Set MDX as false to non attribute columns (PK, DK, Record_effective)
        – Set right encoding for columns – dimension tables should have hash encoding and decimal fields benefit from value
        – Custom partition on tables
        – Reducing cardinality
        – Do not use calculated columns
        – Use aggregated tables if detailed grain is not required for reporting

• • • • Automate semantic model testing

        How do you ensure that the measures you have written are correct? How do you know that the business can trust the numbers coming from the measures ? One way to do that is to test your semantic model against the source of the measures which in most cases are views. You can use the Execute Queries API to query your models in production, extract the measure results and compare them against an equivalent SQL statement from the views. If you have a tester they can set up a testing framework in ADF and it can be automated to make sure that the measures are always giving the correct results.

    So there it is, the end of this series on my musings from developing and deploying enterprise grade semantic models. As a parting note, developing enterprise grade semantic models is an exciting role to work in as you get to collaborate with a wide variety of stakeholders while having ultimate control over the semantic model. Treat it like a product and make sure you listen deeply to the users before adding any new features. Finally, your job as a semantic modeler is to make it easier for the end users to create reports. Provide as much details as possible on how to use it and evangelise it to everyone you meet in the organisation. All the best !

• • If you are doing it all by yourself, it is not enterprise grade

As discussed in Part 1 these are the following people I collaborated with while building enterprise grade semantic models for a major superannuation company in Australia

• • • • • Information Architects
        • Solution Architects
        • Data Stewards
        • Product Champions
        • Data Modelers
        • Business Analysts
        • Business Intelligence Developers
        • Testers
        • Delivery Managers
        • Report Developers

It truly does take a team to ideate, design, test, validate, and support the build of enterprise grade semantic models. In the past, I have developed pseudo enterprise grade models as I was donning multiple hats and that resulted in a not optimal data warehouse and subsequently the semantic model wasn’t fit for reporting. Hence is important to have specialists for the above roles. If you have built a semantic model by yourself, it is probably not enterprise grade. This leads to the next point

• • Designing a report for an enterprise is not the same as semantic modeling

Many Power BI consultants make the mistake of interpreting a report built for a business unit in an enterprise as enterprise grade semantic models. They are not one and the same. Firstly, the reports have been probably built by a single person meaning, the person building the report is the architect, data modeler, data engineer, semantic modeler, and a report developer all rolled into one. It is akin to building the Burj Khalifa all by yourself, simply not possible when you deal with enterprise data.

That doesn’t mean you should not build Power BI models for enterprises. But due to the localised nature of it, the models will only be used by a section of the end users and the rest of them won’t have a clue about it. Enterprise models should be available to be consumed (via reports) by all employees within the organisation. Only then can you call the models truly enterprise grade.

• • Semantic model is not the same as a data warehouse

A data warehouse is built to standards conforming to the industry business unit from which the data is sourced. It is usually designed using dimension modelling using techniques of conformed dimensions, slowly changing dimensions, enterprise bus matrix etc. However, it may not always be used as is by the business for reporting. For starters the field names in the data warehouse may be something like “MemberAccountBalance_Total”, which may not mean much to the business. However, in the semantic model you can change it to something like “Member Account Balance” which is understandable for everyone.

The other reason is more important. The fact tables in the data warehouse in most cases cannot be used directly to extract the corporate measures. For ex: in Superannuation and Banking industries, one of the most important measures is the Member Count, both current and historical. The Member Counts here represent Members who have an account in the superannuation or banking organisation. The Member Count should be increasing over time as that means the company is growing and is able to make a profit. This measure is normally not modelled as a field in the fact table in the data warehouse. Hence a semantic layer view needs to be created so that this measure is derived by say joining the Member dimension (which has information on all member attributes) with other fact tables like MemberBalanceSnapshot table (which has information on members who have accounts) along with the required dimensions so that it can be sliced appropriately.

• • Be prepared for multiple iterations

If you are building a semantic model for the first time, you will probably need a few iterations to get it right. The model which you ultimately choose will be the one which has the right granularity for corporate reporting, has the business approved field names, simpler DAX expressions, refreshes faster, queries faster and is well documented. It is recommended to start the iteration process by focusing on the correct field names, table names, measure names and definitions and begin by designing a high-fidelity prototype with the important fact, dimension tables and measures. The prototype should be parameterised so it can be deployed to different environments easily. This way you will have a version which will be ready to scale when you deploy the final model for production.

• • Semantic modeling is not technically difficult

While the job of a semantic modeler is technically not that demanding, say as compared to a data engineer it is probably the role with the most exposure to all stakeholders. You are like a conduit between the business and the technical team. You are constantly fielding questions on the semantic model from the report developers/business, and it is your job to make sure their questions are answered satisfactorily.

Requirements for new tables, columns, measures may come thick and fast and that is why it is critical to ask the right questions so that these requirements can be formalised through a demand portal and taken up by the technical team based on their priorities. Which brings us to the next point…

• • Have an excellent relationship with all relevant stakeholders

Because a semantic modeler sits between business and the technical team, they should maintain excellent relationships with all parties involved. They should not only be adept at talking to the data modelers and architects on things like measure definitions, table grain, memory usage, processing times etc. they should also be skillful at explaining the model in simple terms while talking to business.

You need to be persuasive to make your point while also seeking clarity to better inform your decision-making process. These are some of the soft skills which you need to master in order to be successful in this role.

Firstly, what is a semantic model ? Before we get to the semantic model we need to understand its relationship with respect to the semantic layer. According to Wikipedia:

A semantic layer is a business representation of corporate data that helps end users access data autonomously using common business terms. A semantic layer maps complex data into familiar business terms such as product, customer, or revenue to offer a unified, consolidated view of data across the organization

The above definition is as good as it gets without the use of unnecessary jargon. So we will stick with this going forward. Where does the semantic layer sit in a modern BI/analytics landscape. The below simplified architecture answers the question. This is for a Power BI landscape but would work similarly with other tools.

So as you can see, the semantic layer is that layer which sits between the data warehouse (which is the output of the Transformation Layers) and the reporting layer. The semantic layer consists of two parts

• • Semantic Layer DB – These are the SQL views which are created in the database from the Fact and Dimension tables. The views can be a one-to-one copy of the tables or they can be enhanced with fields containing report level logic. It is in these views that business friendly names are given to the fields. So instead of ‘MemberName’ we would have ‘Member Name’ as a field. It is important that no business transformations are applied in the views. All transformations are to be applied in the transformation layers and the data loaded to the data warehouse.

• • Semantic Model PBI – The views are imported into a Power BI Desktop model which is called the semantic model. Corporate measures, which have been defined by data stewards are then calculated in the model. Most of these measures are simple aggregations of fields in the tables (SUM, DISTINCTCOUNT). The semantic model is then published to PBI service where report developers connect to it, design reports and share via apps. The semantic model is the ‘single version of truth’ and is used as the primary data source for enterprise reports. In this example, all superannuation related reports would connect to this model to generate insights. It is the design and deployment of this semantic model which would be the focus of this series of blogs.

So in essence, in the PBI world, the semantic model is a dataset with corporate measures, used to query organisational metrics. The reports which query the dataset are in fact ‘Thin Reports’, with the report developers having the ability to create report level measures. In the simplest architecture the dataset contains many datamarts and the data is imported into the model. All datamarts have a star schema associated with them.

So why build the semantic model after all ? There are several reasons why an organisation should implement a semantic model. The key reasons are given below

• • Single Version of Truth (SVOT)

    When implemented correctly, the semantic model provides accurate and trustworthy data for key organisational metrics which serve as the SVOT no matter which tool is used to query it. Because the metrics have been defined in consultation with relevant stakeholders from the business, any report connecting to the model and querying the metrics (in the form of measures) produces the same result. This is quite powerful as there is no longer confusion on what the metrics mean, and everyone will be on the same page discussing the reports.

• • Seamless collaboration

    A semantic model allows for creation of a data model which is a visual description of the business for analyzing, understanding, and clarifying the data and the associated relationships. This model can not only be used by the business to generate insights but can also be used by data scientists to complement the raw data which they use in their models. Composite models, which are models which are created by combining the semantic model with business unit specific data (say salary data) can also be created and shared with the relevant stakeholders. Thus the creation of the semantic model enables easy authoring, sharing, and collaborating of data models and insights.

• • Reduce computing costs

    With most business running their data warehouses in the cloud, ad-hoc querying the data warehouse for every report leads to poor workload management and long running queries being run multiple times. With a cached semantic model, only optimised queries (via views) which are at the grain required for business reporting are run, which improves query performance and reduces costs.

• • Simplify DAX calculations

    The semantic model is structured in such a way that measures in the model are simple aggregations of the columns in the views. Since all the transformations are done prior to data being loaded into the data warehouse and report specific logic being implemented in the views, writing DAX to create either the corporate measures or report level measures becomes easier. This is why it is important to have solution architects and data modelers in your team who would make sure that the views are at the right grain and fit for purpose for reporting.

• • Improved security

    Users can be authenticated to use the semantic model with Azure AD groups and further, Row Level Security can be implemented at both the DB level and at the dataset level to protect sensitive data and limit access to data for users based on their roles in the organisation.

So what constitutes an enterprise grade semantic model ? In my opinion, the following conditions should be satisfied for a model to be classified as enterprise grade

• • Represent data from a business unit

    The semantic models which I designed enabled end users to query data related to the members of the superannuation fund. Metrics such as Member Count, Exited Member Count,Member Account Balance, New Join Count etc could be queried from the model by slicing them with dimensions such as Member, Age Bracket, Employer, Payment Institution, Amount Bracket etc. In short, the relevant business unit in this case was Superannuation and the semantic model contained almost all the data required by the business to attract and retain members into the fund. Normally there is an executive sponsor who funds the project to set the ball rolling.

     

  • Governed corporate measures

    It doesn’t make sense to model the data from a business unit if there is no consensus on the definitions of the corporate metrics. It is important that even before conceptualising the data platform, a thorough process is undertaken to define the most important corporate metrics and get them approved by the relevant stakeholders. This can be facilitated by setting up a Data Office in the organisation which is responsible for signing off on the corporate measures based on the approved definitions from the stakeholders.

     

  • Architecting the solution

    So, you have identified which business unit’s data to model and have also got sign offs on the corporate metrics which need to be the output of the model. It is then critical to start brainstorming on how the solution would look like. This is where the Architects come into play. Most enterprise data reside in databases in different source systems. The architects will perform a detail analysis on what is the current state of the source systems, the best way to extract the data from the source systems, selecting the appropriate cloud platform for the solution, and designing the conceptual and logical design in tandem with the Data Modelers. The data warehouse is then built by the data engineers based on the specifications given to them by the Data Modeler. The semantic model is then designed from the data in the data warehouse based on the reporting requirements of the business. One of the core architectural principles is that any reusable logic (columns) should be applied as close to the source as practical. ie, there should be no columns defined in Power Query or in the Power BI model. If the solution is not architected, then it is not an enterprise grade model.

• • Deliver fast queries

    Once the solution is architected and the corporate measures have been defined in the model based on the business definitions, it is time to deploy the model. If the reports connecting to the semantic model cannot query a measure in less than 3 seconds (nothing scientific about measures being able to run in less than 3 seconds, just a number which was felt good enough at the time of deployment), then it is time to go back to the drawing board. The semantic model should be fast enough to respond to the needs of the business. A slow model will impede adoption and people will lose trust in the efficacy of the model.

Hopefully this article has piqued your interest in all things enterprise semantic modelling using Power BI – They Why’s and the What’s. In the next series of articles, I will share about the learnings I gained from developing and deploying enterprise grade semantic models. Some will be general, and others will be technical. Hope you find them useful too.

The Business Problem – What is Australia’s share of global export coal revenue 

This problem involves calculating % of the total and is a common problem which needs to be solved in a business. Some other problems along the same lines:

• What is the % profit for each store last financial year
• How much rainfall in % did Brisbane get this year among the top 5 Australian cities
• What is the % of electric vehicles among all cars sold in Australia in 2021

For this problem we will be using data from this website which gives the top 15 coal exporting countries by revenue which account for  98.6% of global coal exports in 2021. The data model is shown below

Before calculating the measure for the % of the total we need to calculate the total, in this case the total export revenue

Export Revenue ($) =
SUM ( ‘Export'[Export Revenue] )

For the first iteration of the % of total we calculate the measure as

Export Revenue % v1 =
DIVIDE (
    [Export Revenue ($)],
    CALCULATE ( [Export Revenue ($)], ALL ( Location ) )
)

In the denominator we are using  ALL ( Location ) to remove any filters coming from the Location table and by doing that we get the total export revenue in the denominator. So for each country the numerator is the export revenue of that country and the denominator is the total export revenue and the ratio gives the %.

We place this two measures in a table visual along with the column ‘Country’ and we get

So, to answer the question, Australia’s share of the global coal revenue is 36.2% in 2021.

Let’s add some complexity and start asking more questions

The Business Problem – What is the export coal revenue for Asian countries as a percentage of Asia’s revenue

There are six countries in Asia in the model- Indonesia, Mongolia, Kazakhstan, Philippines, China, and Vietnam. The problem is to calculate the export coal revenue of each of those countries as a % of Asia’s revenue. We have the column ‘Continent’ available to us in the model, so we drag it into a slicer and select Asia and this happens

Not quite the result we expected for the Export Revenue % v1 measure. Why is that ? Recall that the denominator of the DIVIDE function in the measure uses  ALL ( Location )which removes filters from the Location table. Hence, even though we select Asia from the Continent column which is in the Location table, the filter from that column is removed giving all the rows of that table. Hence we get the % of the global export coal revenue and not Asia’s. We need to define another measure which retains the filters coming from the Continent column. We define it as below

Export Revenue % v2 =
DIVIDE (
    [Export Revenue ($)],
    CALCULATE ( [Export Revenue ($)], ALLSELECTED ( Location[Country] ) )
)

We have replaced  ALL ( Location ) with  ALLSELECTED ( Location[Country] ). What this does is gives all the rows from the selection, in this case we have selected ‘Asia’ from the ‘Continent’ column and this filter is applied on the measure and we get all the countries under ‘Asia’. Thus the denominator is the sum of the export revenue for Asia which is $30.66 bn.

We place this measure in the same visual as above and get the below

This is exactly the result we wanted. Indonesia has the biggest % share for all Asian countries at 86.4% followed by Mongolia at 6.2%. You can select any Continent in the slicer and the Export Revenue % v2 measure gives the % for the countries in that continent.

Let’s add a twist to the problem. What if we place Continent into the visual above and convert it into a matrix visual and expand to the lowest level (Country). From here on we would only be focusing on the v2 measure. The visual would look like this:

What we now have is that the % for the countries are correct but the % for the continents are wrong. Why is that ? Because in the denominator of the DIVIDE function the filter for continent is still present. Hence the numerator and denominator are one and the same and the ratio is 1.  We need another set of measures which gives the correct % for the countries as well as the continents. WE define another measure which we wont be using in the visual but will be used in the subsequent v4 measure.

Export Revenue % v3 =
CALCULATE ( ‘Export'[Export Revenue ($)], ALLSELECTED ( Location[Continent] ) )

The above measure is used in the v4 measure which is defined as follows

Export Revenue % v4 =
IF (
    ISINSCOPE ( Location[Continent] ) && NOT ( ISFILTERED ( Location[Country] ) ),
    DIVIDE ( [Export Revenue ($)], [Export Revenue % v3] ),
    [Export Revenue % v2]
)

This measure has two parts. The first part applies to the rows in the visual with continents filtered and the second to the rows in the visual with countries filtered. The measure is placed in the visual and it looks like this

This is exactly what we wanted and we can clearly see the difference between v2 and v4 measures. The v4 measure uses the v3 measure as a denominator in the DIVIDE function. And the denominator has ALLSELECTED ( Location[Continent] ) which removes filters from selected continents. We could have used ALL( Location[Continent] ) as well and achieved the same result as above but the difference is that when we select more than one Continent from a slicer it would not have worked. Let us do just that. We will select Europe and North America from the Continent slicer and see what the visual does

The reason for using ALLSELECTED ( Location[Continent] ) is now clear. When we select ‘Europe’ and ‘North America’ from the Continent slicer we get the % revenue of Europe and North America of their combined total.

Let us add another twist to this. For the set up above what we wanted to show the export revenue for each country as the % of  ALL the counties in the selection regardless of the continent they are in. For ex: we want to know the % of United States as $9.7/$35.06. For this we define our final measure as below

Export Revenue % v5 =
IF (
    ISINSCOPE ( Location[Continent] ) && NOT ( ISFILTERED ( Location[Country] ) ),
    DIVIDE ( [Export Revenue ($)], [Export Revenue % v3] ),
    DIVIDE (
        [Export Revenue ($)],
        CALCULATE ( [Export Revenue % v3], ALLSELECTED ( Location[Country] ) )
    )
)

Here, in the second part of the IF statement in the denominator of the DIVIDE function we remove all filters from the selected countries which would give us the total of $35.06 for all the countries and the numerator would the export revenue for that particular country. The final visual looks like this 

You can see that the % of United States coal revenue for all the countries in Europe and North America is 27.7%

Summary

In this fifth part of the series, we have seen how to use the ALL family of functions to calculate % of totals for various business requirements

Any problem involving the calculation of % of total values

• What is Australia’s share of global export revenue
• What % of garments are manufactured in China ?
• What is Amazon’s share of global electronics sales ?

Australia’s share of global export revenue=
DIVIDE (
    [Export Revenue ($)],
    CALCULATE ( [Export Revenue ($)], ALLSELECTED ( Location[Country] ) )
)

When Continent is added as the top most hierarchy in a visual, to get the share of each country as the % of the Continent total

IF (
    ISINSCOPE ( Location[Continent] ) && NOT ( ISFILTERED ( Location[Country] ) ),
    DIVIDE ( [Export Revenue ($)], CALCULATE ( ‘Export'[Export Revenue ($)], ALLSELECTED ( Location[Continent] ) ) ),
    [Export Revenue % v2]
)

When Continent is added as the top most hierarchy in a visual, to get the share of each country as the % of the selected Continents’ total

IF (
    ISINSCOPE ( Location[Continent] ) && NOT ( ISFILTERED ( Location[Country] ) ),
    DIVIDE ( [Export Revenue ($)], CALCULATE ( ‘Export'[Export Revenue ($)], ALLSELECTED ( Location[Continent] ) ) ),
    DIVIDE (
        [Export Revenue ($)],
        CALCULATE ( [Export Revenue % v3], ALLSELECTED ( Location[Country] ) )
    )
)

The Business Problem – How many sales orders are greater than $3000

Businesses are often interested in answering what is their given sales/tonnes/profit which is greater than a certain number for a given attribute. This is, so that they can isolate those orders/tonnes/projects and focus on what went right, targeted campaigns etc. Some questions along these lines

• How many excavators produced more than $1M tonnes of Irone Ore  ?
• What is the average height of the class of children who are more than 10 years old ?
• Which projects made a loss last quarter ?

So coming back to the original question. This is an interesting one as this requires us to think carefully on how to use the filters. The Sales Amount field is only available in the Fact table, hence we need to filter the FactOnlineSales table to only include sales orders which are greater than $3000 as these are high value orders for the business. Ultimately the business wants to know the % of high value orders. The pattern then becomes

Sales Orders Greater Than 3000=
CALCULATE (
    DISTINCTCOUNT ( FactOnlineSales[SalesOrderNumber] ),
    FILTER ( VALUES ( FactOnlineSales[SalesOrderNumber] ), [Total Sales] > 3000)
)

The result then becomes

The pattern for the % high value orders becomes

% of High Value Orders =
DIVIDE (
    [Sales Orders Greater Than 3000],
    DISTINCTCOUNT ( FactOnlineSales[SalesOrderNumber] )
)

The result then becomes

So, only 2.3% of sales orders have sales greater than 300

The Business Problem – How many customers made less than 50 purchases ?

This problem uses the similar pattern to the above but instead of using columns from the fact table it uses dimension table columns as a filter in the calculate function.

We first need to define the number of purchases

Number of Purchases = DISTINCTCOUNT ( FactOnlineSales[SalesOrderNumber] )

We then define the final measure where we use the above measure to filter the customers from the DimCustomer table

Number of Customers with less than 50 purchases =
CALCULATE (
    DISTINCTCOUNT ( FactOnlineSales[CustomerKey] ),
    FILTER ( VALUES ( DimCustomer[CustomerKey] ), [Number of Purchases] < 50 )
)

The result then becomes

The Business Problem – What is the average amount spent by customers whose annual income is greater than $150K and who spent more than $10M across all years

In this pattern we will discuss multiple numeric filters and apply some of the logic we have seen in previous series. The patterns answers questions along these lines

• How many cars were sold in 2021 whose engine capacity is more than 2L and customers spent more than $50,000 per car ?
• What were the loss making stores of last year who sold more than $1M items ?
• How many projects made a profit in 2020 where they had less than 10 people working per project ?

So lets talk high value customers. High value customers are those whose annual income is greater than $150,000 and who have spent more than $10M over the years. The business wants to know their average sales so that they can do some modelling and forecast how much more can these customers spend so that they can target their marketing campaigns on them. Astute readers will note that anyone who is on say $160K annual income will never be able to spend $10M on a particular stores(s). But knowing that this is a dummy dataset, we will ignore the absurdity of the data distribution and go ahead and solve the problem.

The patten then becomes

Average Sales of High Value Customers =
CALCULATE (
    AVERAGEX ( VALUES ( DimCustomer[CustomerKey] ), [Total Sales] ),
    DimCustomer[YearlyIncome] > 150000,
    FILTER ( VALUES ( DimCustomer[CustomerKey] ), [Total Sales] > 10000000 )
)

Summary

In this fourth part of the series, we have seen how to filter fact tables by using a measure to filter dimension/fact tables. Use the following patterns to answer the following questions.

Any problem involving the filtering measures in the fact table by iterating a measure across dimension/fact tables.

• How many sales orders are greater than $3000 ?
• Which projects made a loss last quarter ?
• How many customers made less than 50 purchases ?

While iterating over a fact table use this pattern

Sales Orders Greater Than 3000=
CALCULATE (
    DISTINCTCOUNT ( FactOnlineSales[SalesOrderNumber] ),
    FILTER ( VALUES ( FactOnlineSales[SalesOrderNumber] ), [Total Sales] > 3000)
)

While iterating over a dimension table use this pattern

Number of Customers with less than 50 purchases =
CALCULATE (
    DISTINCTCOUNT ( FactOnlineSales[CustomerKey] ),
    FILTER ( VALUES ( DimCustomer[CustomerKey] ), [Number of Purchases] < 50 )
)

Any problem involving the filtering measures in the fact table by a combination of filtering by dimension attributes and iterating a measure across dimension/fact tables.

• How many customers under the age of 30 spend $50k in 2021 ?
• How many accounts had accumulated less than $50k in interest where the annual income of customers was over $500k ?
• How many stores had less than 50 employees and made a profit last financial year ?

Average Sales of High Value Customers in 2021 =
CALCULATE (
    AVERAGEX ( VALUES ( DimCustomer[CustomerKey] ), [Total Sales] ),
    DimCustomer[YearlyIncome] > 150000, DimDate[CalendarYear] = 2021,
    FILTER ( VALUES ( DimCustomer[CustomerKey] ), [Total Sales] > 10000000 )
)

• Use Explicit measures and not Implicit measures

It still amazes me that I come across Power BI models developed by developers who still use implicit measures in their production ready models. Even if you do not follow the other 6 principles, this one simply cannot be skipped. So what are implicit and explicit measures ? Implicit measures are those which make use of the default summarization properties of columns (sum, average, count, max, min etc) to populate a visual. You can drag and drop a column into the ‘Fields’ or ‘Values’ section of a visual and set its summarization type to get your result. As you can see below the Production column has a default summarization set to SUM and is dragged into a card visual and the name changed to ‘Tonnes’ and the visual is populated. Why is this bad ?

The default summarization could have been set to SUM but it could have been changed to AVERAGE when placed under Fields. It’s very hard to audit what the measure is calculating without looking at each column and each visual which can become tedious

Complex measures cannot be defined this way as only basic summarizations are allowed.

The measure cannot be reused since its not explicitly defined.

It cannot be accessed via external tools like Excel, as only explicit measures are visible in those tools.

So then, what are explicit measures ? Explicit measures are the default way measures should be defined in Power BI. And we do that by explicitly writing out the formula in DAX. To redo the above example we write a measure called

Tonnes = SUM ( ‘Fact Production'[Production] )

and place it under ‘Fields’ in the card visual. You can see that there is a clear lineage between the measure definition and the output. Explicit measures are auditable, they can be reused inside other measures, you can author complex DAX measures and other tools like Excel can see them in their environments

• Use Consistent Naming Conventions

Follow a consistent naming convention so that its easier to read. In my projects I tend to use Proper Case , so I would write ‘Sales Amount’ instead of ‘Sales amount’. This is not a hard and fast rule though. But whatever convention you choose adopt it consistently.

• Measures should be performant

Once you have finished authoring explicit DAX measures, and placed them in visuals you need to ensure that they are performant. What does that mean ? You need to ensure that your visuals on a page are loading quickly (not more than 3 seconds) and that the DAX code is not taking long to execute. Thee is nothing worse than designing awesome looking dashboards if the end users find it frustrating to use as it takes a long time for the visuals to load as the DAX code is being executed in the background. This post will not cover how to optimise DAX code as other people have covered it extensively. A good starting point is to use the Performance Analyzer in Power BI and determine which measures are taking the longest to execute and copy the DAX query into DAX Studio for further investigation.

• Format the code

If its not formatted, its not DAX. Consider the code below

• Use comments

Use comments in code to clarify any assumptions made, on which page the measure is being used, if its a temporary measure etc. To activate comments, in a new line in the DAX editor window in Power BI press ‘Ctrl /’ and then type your comments. Below is an example. This makes it easier for you to know where your measures are being used and if they are being used at all.

Tonnes = SUM ( ‘Fact Production'[Production] )
// This is used in the Executive Summary page

• Provide a description and synonyms

A description of what the measure stands for is very useful especially if the model is being used to develop multiple reports. Usually, in corporate a base set of measures will have been defined and validated by the data stewards and data custodians and you can find them in a sharepoint page or confluence page. Copy those definitions and paste them under the description section of the measure. If there are synonyms used make sure to copy them as well.

• Apply appropriate data category

If your measure denotes an address like country or city you can apply the appropriate data category for it. This is important when you want to use the measure in geo spatial visuals so that the visuals correctly identify the location. If you measure contains an URL make sure to either apply a Web URL or an Image URL.

• Test measures against the source

This is especially important in enterprise semantic models where the source of the data is from a database/data warehouse. In such cases you can readily test the outputs of the measures against the equivalent SQL queries from the tables/views. You can automate this by running a testing framework in Azure by calling the Dataset Execute Queries REST API .

• Place the measures in a dedicated measure table

Placing the measures in a dedicated measure table ensure easy access to all the measures. You can call the table something like ‘ALL MEASURES’, ‘BASE MEASURES’, ‘REPORT MEASURES’ etc. You can also group them into different folders for ease of navigation.

• Document your code

Finally it is important to document all the measures you have written in your model or report once you have finalised it. The documented code serves as a final repository of all your DAX which can be easily accessible. There are no automated ways to document your code but tools like Power BI helper can help you in the journey.

You can download a handy pdf reference guide of the eleven rules below

Eleven rules of DAX management

The Business Problem – Sales Amount for Contoso Brand

A common business problem is to slice and dice Facts by their Dimensional attributes. A problem like “What is the sales amount for Brand XXX” is a common one. Similar examples are like the following

• What is the tonnes mined by a CAT excavator ?
• What is the total units manufactured in 2021 ?
• What are the expenses incurred by external consultants ?

Coming back to the problem of “What is the sales amount for Contoso Brand ?”, we need to filter the [Total Sales] measure where Brand = ‘Contoso’. The pattern is as follows

Contoso Sales =
CALCULATE ( [Total Sales], DimProduct[BrandName] = “Contoso” )

The result is as follows

Internally, the DAX measure is  written as

Contoso Sales =
CALCULATE (
    [Total Sales],
    FILTER ( ALL ( DimProduct[BrandName] ), DimProduct[BrandName] = “Contoso” )
)

This is important to know, as many a times I see the measure written as below.

Contoso Sales DO NOT USE =
CALCULATE (
    [Total Sales],
    FILTER ( DimProduct, DimProduct[BrandName] = “Contoso” )
)

While technically this measure produces the same result as the first one, there are two problems with it.

1. Instead of materialising just one column, BrandName, the entire table DimProduct may be materialised (depending on the version of Analysis Services you are running) which can make the measure slower to execute
2. The measure will return blank when a value apart from ‘Contoso’ is selected from the BrandName column slicer in the report. This may not be the result needed as in most cases we always need to display ‘Contoso Sales’ regardless of what value is selected from the BrandName column slicer

The Business Problem – Sales Amount for Contoso Brand AND Silver Colour

Businesses often want to report on metrics which are filtered to values from multiple entities in the dimension tables. The questions can take the following examples

• What is the sales amount for Contoso Brand and Silver Colour ?
• What is the total tonnes for CAT excavator in 2021 ?
• What is the expenses incurred by external consultants in the last quarter ?

The entities can come from the same or different table. The generic pattern when the AND condition is involved becomes the following for the problem “What is the sales amount for Contoso Brand and Silver Colour” becomes

Contoso Silver Sales =
CALCULATE (
    [Total Sales],
    DimProduct[BrandName] = “Contoso”
        , DimProduct[ColorName] = “Silver”
)

When the entities are from the same table which is the case in the above example this can also be written as

Contoso Silver Sales =
CALCULATE (
    [Total Sales],
    DimProduct[BrandName] = “Contoso”
        && DimProduct[ColorName] = “Silver”
)

The result is as follows

It is pertinent to note that the result is a subset of Contoso Sales as we want the Total Sales where BrandName = ‘Contoso’ AND ColorName = ‘Silver’. We can keep adding entities from the same table by appending ‘&&’ to them or from different tables by appending ‘,’ to them.

The Business Problem – Sales Amount for Contoso Brand OR Silver Colour

Sometimes the business problem is to determine the sales amount which involves an OR condition. Businesses want to know the sales amount where Brand is ‘Contoso’ or Colour is ‘Silver’. The pattern then becomes

Contoso OR Silver Sales =
CALCULATE (
    [Total Sales],
    DimProduct[BrandName] = “Contoso”
        || DimProduct[ColorName] = “Silver”
)

The result then becomes

Note that the ‘ || ‘ operator can only be used if we are filtering attributes from the same table. If you are using different you cannot use it, as it equates to using an AND operation and hence you should use ‘ , ‘ instead.

The Business Problem – Sales Amount for Brand Not Equal to Contoso OR Colour Not Equal to Silver

Sometimes the business problem is to calculate sales which does not equal values from one or more entities. In this case instead of focusing on the logic for the negation, focus on the logic for the reverse which is easier to do and then wrap it around the NOT operator. The pattern for the problem “What is the sale amount for brand not equal to Contoso or colour not equal to Silver ?” becomes

NOT Contoso OR Silver Sales =
CALCULATE (
    [Total Sales],
    NOT ( DimProduct[BrandName] = “Contoso”
        || DimProduct[ColorName] = “Silver” )
)

The result then becomes

How can we validate this result ? We know that the total sales is 2.72bn. We also know that the sales for “sales amount when brand is Contoso OR Color is Silver” is 1.06bn. So the difference of the two (2.72 – 1.06 = 1.66) should be the negation which is what the above measure gives.

The Business Problem – Average Sales Amount for Brand Not Equal to Contoso OR Colour Not Equal to Silver

What if we are interested in the Average Sales Amount by Sales Order but only for brands which are not equal to Contoso OR colour is not equal to Silver. We use the same patterns as above but instead of [Total Sales] we substitute it with the [Average Sales by Sales Order]. For clarity we will define the previous measure inside CALCULATE but you could define it as a measure on its own and call it inside CALCULATE.

Average Sales Amount for Brand Not Equal to Contoso OR Colour Not Equal to Silver =
CALCULATE (
    AVERAGEX ( VALUES ( FactOnlineSales[SalesOrderNumber] ), [Total Sales] ),
    NOT ( DimProduct[BrandName] = “Contoso”
        || DimProduct[ColorName] = “Silver” )
)

The result then becomes

Summary

In this third part of the series, we have seen how to use the WHERE equivalent of a SQL query or SUMIFS, COUNTIFS, AVERAGEIFS of Excel in DAX. Use the following patterns to answer the following questions.

Any problem involving the filtering measures in the fact table by one or many dimensional/fact table attributes and calculating totals

• What is the tonnes mined by a CAT excavator ?
• What is the sales for Contoso Brand and Silver Colour ?
• What are the expenses incurred by external consultants or internal consultants ?

Contoso Sales and Silver Colour =
CALCULATE ( [Total Sales], DimProduct[BrandName] = “Contoso” , DimProduct[ColorName] = “Silver”)

Contoso Sales or Silver Colour =
CALCULATE ( [Total Sales], DimProduct[BrandName] = “Contoso”  || DimProduct[ColorName] = “Silver”)

If you want the negation of the above measure

NOT Contoso OR Silver Sales =
CALCULATE (
    [Total Sales],
    NOT ( DimProduct[BrandName] = “Contoso”
        || DimProduct[ColorName] = “Silver” )
)

Any problem involving the filtering measures in the fact table by one or many dimensional/fact table attributes and calculating totals

• What is the average daily sales for Contoso Brand in 2008
• What is the average monthly tonnes mined by CAT excavator in Mine A1
• What are the average quarterly expenses incurred by external consultants last year ?

Average daily sales for Contoso Brand in 2008 =
CALCULATE (
    AVERAGEX ( VALUES ( DimDate[Datekey] ), [Total Sales] ),
    DimProduct[BrandName] = “Contoso”,
    DimDate[CalendarYear] = 2008
)

The Business Problem – Average Sales

A common business problem is to determine the average sales. Some other problems along the same lines

• What is the average rainfall ?
• What is the average temperature ?
• What is the average queue time ?

Averages can be tricky to compute in Power BI. For an average we need a numerator and a denominator. However, in Power BI we have functions to calculate averages and we only need to specify the column over which the average is performed. Coming back to our model, the FactOnlineSales table is at the granularity of SalesOrderLineNumber. This means that for every SalesOrder we can have multiple items which have thier own SalesOrderLineNumber. So when we say “Give me average sales amount” do we mean “average sales by sales order line number” or “average sales by sales order” ? Most likely we are interested in average sales by sales order. And they use different formulae. If you want to calculate “average sales by sales order line number” we just use the AVERAGE function over the SalesOrderLineNumber column

Average Sales Amount Per Sales Order Line Number = AVERAGE ( FactOnlineSales[SalesAmount] )

This gives the following result

In order to calculate “average sales by sales order” we need to use the AVERAGEX function which is an iterator. We know that we need the average sales for SalesOrderNumber, hence we use it in the first argument of AVERAGE and the pattern becomes

Average Sales Amount Per Sales Order = AVERAGEX ( VALUES ( FactOnlineSales[SalesOrderNumber] ), [Total Sales] )

This gives the following result

We can see that the Average Sales Amount Per Sales Order is greater than Average Sales Amount Per Sales Order Line Number. This makes sense as the sales order amount is greater than its sales order line number amount.

The Business Problem – Average Sales Per Store

Now lets discuss how to solve the problem “What is the average sales amount per store”. For this, we use the same pattern as above

Average Sales Amount Per Store = AVERAGEX ( VALUES ( DimStore[StoreName] ), [Total Sales] )

This gives the following results

Most of the time, businesses are not interested in a single number for “Average sales amount by store” but they are interested to see it in a total sales by store bar chart as a line so that they can visualise which stores have sales above/below average. The pattern for this involves using CALCULATE and ALL functions and it looks like this. The ALL is needed to remove the filter context from the StoreName column in the bar chart.

Average Sales Amount Per Store =
CALCULATE (
    AVERAGEX ( VALUES ( DimStore[StoreName] ), [Total Sales] ),
    ALL ( DimStore[StoreName] )
)

The bar chart looks like this for the current model

Now what if we dont have the column ‘SalesAmount’ in the model ? We cannot use the above pattern to calculate Average Sales. We need to use a pattern which first creates a virtual table in which we calculate a new column by multiplying the columns SalesQuantity and UnitPrice and subtracting any DiscountAmount and then iterating over that table to get the average sales. The pattern looks like this

Average Sales Amount Per Store =
VAR t1 =
    ADDCOLUMNS (
        SUMMARIZE ( FactOnlineSales, DimStore[StoreName] ),
        “TotalSales”,
            CALCULATE (
                SUMX (
                    FactOnlineSales,
                    FactOnlineSales[SalesQuantity] * FactOnlineSales[UnitPrice] – FactOnlineSales[DiscountAmount]
                ),
                FactOnlineSales[SalesQuantity] > 0
            )
    )
RETURN
    AVERAGEX ( t1, [TotalSales] )

This pattern is longer and not simple. Hence it is advisable to calculate the column ‘SalesAmount’ in the Fact table in the source so that we can easily retrieve it to calculate ‘Average Sales’ and use easier patterns.

SUMMARY

In this second part of the series on how to solve business problems using DAX we have covered business problems which involve averages and provided DAX formulas for each of them. Use the following patterns to answer the following questions.

Any problem involving averaging fact table columns in the same grain as in the model and if the questions are like the following

• What is the average sales amount by sales order line number ?
• What is the average temperature ?
• What is the average queue time ?

Average Sales Amount Per Sales Order Line Number = AVERAGE ( FactOnlineSales[SalesAmount] )

Any problem involving averaging fact table columns by dimension/fact table entities at a higher grain than the column to be averaged

• What is the average sales amount per store ?
• What is the average rainfall per year ?
• What is the average sales calls per region

Average Sales Amount Per Store = AVERAGEX ( VALUES ( DimStore[StoreName] ), [Total Sales] )

If you want to use this as a line in total sales amount bar chart, use this pattern

Average Sales Amount Per Store =
CALCULATE (
    AVERAGEX ( VALUES ( DimStore[StoreName] ), [Total Sales] ),
    ALL ( DimStore[StoreName] )
)

If you have to calculate ‘SalesAmount’ column in a virtual pattern because its not available in the model, use this pattern

Average Sales Amount Per Store =
VAR t1 =
    ADDCOLUMNS (
        SUMMARIZE ( FactOnlineSales, DimStore[StoreName] ),
        “TotalSales”,
            CALCULATE (
                SUMX (
                    FactOnlineSales,
                    FactOnlineSales[SalesQuantity] * FactOnlineSales[UnitPrice] – FactOnlineSales[DiscountAmount]
                ),
                FactOnlineSales[SalesQuantity] > 0
            )
    )
RETURN
    AVERAGEX ( t1, [TotalSales] )

So this year I wanted to expand on that by starting a series which would talk about how to use the various concepts and functions of DAX to solve business problems. Its one thing to know the inner workings of DAX but even with all the knowledge, sometimes DAX users fail to apply the correct functions while solving problems. This results in poorly written code which is not performant and worse, gives incorrect results. Hence the purpose of this blog.

I hope to standardize some patterns which can be used to answer various business problems like ” What is the total sales of all products for all years across all regions”, “How many units of Product A were manufactured in 2021″, ” What are the top 10 Stores in Category A for Size P” etc. The focus is not on understanding of the DAX functions per se (it is assumed that the reader has a very good understanding of the most common DAX functions) but rather, given a business problem how to write effective DAX that is not only readable and performant but which also answers the question correctly. At the end of each Part, a summary pattern  will be given which can be used to answer the business problem posed at the start of the blog.

Each part of the series will be dedicated to a business problem and various DAX formulae will be provided to answer the problem. Where possible, a often used but wrong solution will also be provided and explanation given as to why that solution is incorrect.

The Data Model

We will be using the Contoso database imported into Power BI as our data model. Contoso is a demo database provided by Microsoft which has a few fact tables on retail sales and dimension tables like Customer, Product, Store etc. We will be using FactOnlineStore as our Fact table and DimCustomer, DimDate, This is a typical star schema which is the recommended model for Power BI reports. If you do not have a star schema for your reports make sure to convert them to a star schema before continuing with this series. The model looks like this

The Business Problem – Total Sales

We will start with the most basic question asked in a Power BI report. This generally goes like this

• What is the total sales
• What is the total tonnes produced
• What is the total number of units manufactured

This can be answered by using the SUM function like this

Total Sales = SUM ( FactOnlineSales[SalesAmount] )

The measure [Total Sales] can be used in a card, line chart, bar chart etc. If we want to use it in a card drag a card visual onto a blank page and drag the measure under Values.

If you want to use it in a line chart or a bar chart you can use the appropriate fields from any of the dimension tables. A typical line chart and bar chart with this measure looks like this

Thus we can see that, from a basic pattern like SUM we can produce multiple visualisation from a start schema model and gain valuable insights

The Business Problem – What is the maximum/minimum discount given ?

A closely related business problem goes like this

• What is the maximum/minimum discount given ?
• What is the highest/lowest temperature ?
• What is the maximum/minimum sales calls made ?

A business would be interested to know what is the most/least amount of discount given for a sales order in order to better understand their profit margins. These can be answered using the MAX/MIN functions. To get the maximum discount amount in our model we need to figure out which field to use. in the model the DiscountQuantity field gives the discount that is given to any sales order. We can use this field to get the maximum discount given

Maximum Discount = MAX ( FactOnlineSales[DiscountAmount] )

This gives the following result in the model

In the same way we can determine the minimum discount given

Minimum Discount = MIN ( FactOnlineSales[DiscountAmount] )

This gives the following result in the model

Hence whenever we are dealing with determining the maximum/minimum values of a column we need to use the MAX/MIN over the column. In future parts we will look at some more complex business problems where we will have to determine the maximum/minimum at a grain higher than that of the model.

The Business Problem – What is the unique number of products sold ?

In the previous section we looked at summing sales/quantities and determining the maximum/.minimum of a field, In this section we will look at a common business problem of the likes of

• What is the unique number of products sold
• How many months worth of data does the model contain ?
• How many unique customers made purchases ?

Each of these questions can be answered by using the DISTINCTCOUNT function. So in our model if we have to determine how many unique products have been sold we need to look at the FactOnlineSales table and find the column which is in a many-to-one relationship with the DimProduct table. We have exactly such a column and its called ProductKey. Since each product could have been bought multiple times we need to find the distinct count of the ProductKey field from the FactOnlineSales table.

Unique Products Sold = DISTINCTCOUNT ( FactOnlineSales[ProductKey] )

This gives the following result in the model

A wrong solution to the problem is to count the number of Products in the DimProduct table. This may not give you the right answers as there might be products for which there have been no sales recorded. For educational purposes the formula is given but the reader is advised not to use it.

Unique Products Sold WRONG = COUNT ( DimProduct[ProductKey] )

This gives the following result in the model

We see that the number of products in the model is not equal to the unique products sold. The fact that they only differ by 1 is due to the demo model being used. In real life models the difference would be higher.

Let’s tackle a slightly dificult problem and answer the question “How many months worth of data is present in the model” ?. Ideally we would have liked a CalendarMonth column in the format yyyymm to be included in the FactOnlineSales table so that we could do a DISTINCTCOUNT over it and get the results. But the CalendarMonth column is only present in the DimDate table and there is no point in reproducing it in the Fact table just to answer this question. So then how do we calculate it ? We need to use the CALCULATE function and also use the concepts of Expanded Tables. If you need to learn these concepts in detail please go though the articles on www.SQLBI.com for indepth explanations of those concepts. For our purpose we will define this measure.

Months of Data Available = CALCULATE ( DISTINCTCOUNT ( DimDate[CalendarMonth] ), FactOnlineSales )

This gives the following result in the model

This works because when you put a Fact table in the second argument of CALCULATE, it creates a left join with all the dimension tables joined to it whereby ‘expanding’ the Fact table. Since the left join contains all the rows of the Fact table, the columns of the dimension table which are joined to this expanded Fact table also contain the same rows. Hence when you do a DISTINCTCOUNT over the CalendarMonth column from the DimDate you only get months for which there is sales data in the model.

SUMMARY

In this first part of the series on how to solve business problems using DAX we have covered some of the most basic business problems covered in a Power BI report and provided DAX formulas for each of them. Use the following patterns to answer the following questions.

Any problem involving summing sales, quantity, measurement and if the questions are like the following

• What is the total sales
• What is the total tonnes produced
• What is the total number of units manufactured

Total Sales = SUM ( FactOnlineSales[SalesAmount] ) 

Any problem involving calculating maximum/minimum over a column and if the questions are like the following

• What is the maximum/minimum discount given ?
• What is the highest/lowest temperature ?
• What is the maximum/minimum sales calls made ?

Maximum Discount = MAX ( FactOnlineSales[DiscountAmount] )

Any problem involving calculating the unique values of a column and if the questions are like the following

• What is the unique number of products sold
• How many months worth of data does the model contain ?
• How many unique customers made purchases ?

Unique Products Sold = DISTINCTCOUNT ( FactOnlineSales[ProductKey] )

If the column to be used is in the dimension table use this pattern

Months of Data Available =CALCULATE ( DISTINCTCOUNT ( DimDate[CalendarMonth] ), FactOnlineSales )