Solution: Relate every dimension with their respective fact tables.

• Identify the shared dimensions.
• Relate them with every fact.

Sometimes this model is called constellation schema, where each fact table individually is a perfect star schema design because each one is related with a dimension.

Advantages

• Star schemas are easy to read, understand and use.
• Best performance.
• You can filter both fact tables using the shared dimensions.

Disadvantages:

• As the fact tables are not related to each other if you try to add columns from both tables in the same visual that do not have a shared dimension you will get the following error:

Bad Practices:

• Duplicate dimensions in the model:
  • You will increase the size of your model which could impact the refresh time.
  • You can’t use the same dimension to filter the data of both tables.
• Consolidate the fact tables: Join fact tables through a union (append in Power Query) will create a huge table that can take a long time to refresh, in addition to a lot of blank values in the unmatched columns.

 Scenario 2: Multiple fact tables related to each other with different granularities

Remember that the granularity represents the level of detail in each row of your fact table. In the header/detail models you must be careful to use the correct granularity in your calculations and try to maintain a good performance considering that they are not a perfect star schema.

An example of header/detail models is when you have an order (header) and order details. The order table has an order number, date, a customer, and much more useful information at the order level.  The detail table contains the product, the price, the quantity, and detailed information related to the individual order line.

Solution 1: Flatten the header table into the detail table: With this solution you will get a denormalized model, where you locate the data from the header table to the detail table increasing the granularity.

Advantages:

• You will get a perfect star schema that offers all its advantages.
• The values will get the correct granularity.
• The model will be easier to use because it can be summed and sliced by any dimension.

Disadvantages:

• Increase the data model size.
• Categorical values repeated in the denormalized model.

Solution 2: Relate the header and detail table

Be careful with this solution because you could get incorrect results due to the granularity differences between both tables. You can use it in the following scenario:

• You need to use columns from the different fact tables in a same visual table.
• The header detail table had a big number of column and flattening it into the detail table would create a huge table.
• You need to make few calculations over the header.
• The reports just needed to be sliced using common dimensions.

Considering these points, apply the following solution:

• Identify the shared dimensions.
• Relate them with every fact to get a star schema model for every fact.
• Relate the header and detail table through an inactive relationship:

• Use a Many to one Cardinality and a “Both” cross filter direction:

• Finally, to summarize or bring the columns from the header table, use the USERELATIONSHIP DAX formula:

Contract Amount =
CALCULATE (
SUM ( ‘Fact Header'[Contract Amount] ),
USERELATIONSHIP ( ‘Fact Detail'[WIP PK], ‘Fact Header'[PK] )
)

In this solution, linking the header and the detail table breaks the rules of the star schema because both tables act as a dimension and a fact table at the same time.

It’s a dimension when you need to slice the detail and it’s a fact table when you summarize values at the header granularity.

So, you will get a snowflake when the header table acts as dimension, although you should avoid it, sometimes as in this specific scenario could be a good solution to representing the data.

Advantages:

• Avoid increase the size the data model having fact tables separated.
• You can use the star schemas to create reports that don’t need to include in a same visual, columns from different fact tables

Disadvantages:

• This solution only works if you slice the data using the common dimensions, because otherwise you will get incorrect results due to the granularity differences between both tables.
• Possible performance degradation.

What are the DMVs

The DMVs queries are an interface to schema rowsets based on SQL and use a SELECT statement and the $System schema with an XML/A schema rowset, however, they do not support the full syntax of a SELECT statement as: JOIN, GROUP BY, LIKE, CAST, and CONVERT.

Apply to: SQL Server Analysis Services, Azure Analysis Services, Power BI Desktop and Power BI Premium

Example of a DMV query:

SELECT * FROM $System.DISCOVER_CALC_DEPENDENCY

WHERE OBJECT_TYPE = ‘MEASURE’

ORDER BY TABLE ASC

For more information visit the official documentation: https://docs.microsoft.com/en-us/analysis-services/instances/use-dynamic-management-views-dmvs-to-monitor-analysis-services?view=asallproducts-allversions

What are they for?

• The DMVs provide information about the active sessions and connections, objects that consume the most CPU or memory at a specific point in time, such as:

• To document your Power BI or SSAS data model, the main queries DMVs available for model documentation are:

• • TMSCHEMA_TABLES: List the Column objects in each table.
  • TMSCHEMA_COLUMNS: List the Columns objects in each table.
  • TMSCHEMA_MEASURES: List the Measure objects in each table.
  • TMSCHEMA_RELATIONSHIPS: List the Relationship objects in the model.
  • TMSCHEMA_ROLES: Shows information about the Role objects in the model.
  • TMSCHEMA_PARTITIONS: Provides information about the Partition objects in each table.

In the past I used to create my own documenters using the DMVs, but I recently discovered the excellent and very complete tool “Model Documenter” created by Marc Lelijveld (MVP).

This tool generates the documentation about your data model in an easy and quick way, you can get more information and download the tool in the page: https://data-marc.com/model-documenter/

DISCOVER_CALC_DEPENDENCY

With this DMV you can obtain the list of the dependencies among the objects in your model and extract the DAX expressions. This allows you to have more control over your data models as you can measure the impact of modify or remove any object.

I created the tool “Tabular model cleaner” using this DMV, which helps you to obtain all the dependences of the data model in an efficient and automated way and the usability of the model objects in the reports connected to the Power BI or SSAS Data model.

For more information visit: Tabular model cleaner

How to run the DMVs

1. DAX Studio: Open the Power BI Dataset that you want to document. Open DAX Studio and choose the “PBI / SSDT Model” data source option, then click on Connect:

If you have Power BI Premium you can connect to the dataset, to do this select the workspace, go to “Workspace settings” and copy the Workspace Connection and paste it into the “Tabular Server” option in the DAX Studio.

Go to DMV pane and click on the query you want consult:

2. From Power BI Desktop: You can run DMVs queries from DAX Studio but that will return you a table with the data, you should connect to the DMVs using Power BI, to view and analyze the information more easily.

– Open Power BI Desktop.

– Choose the “SQL Server Analysis Services database” source.

– Include the Server and Database.

Consider if you are connected to a local data model, the database name will change every time you open the Power BI Desktop file, so you will have to edit the connection parameter when you need to refresh the data.

For datasets with incremental refresh policy applied, you must avoid publishing and replacing them with a version of a PBIX file from Power BI Desktop, because you will have to refresh all the historical data which could take hours and result in the system’s downtime for users.

Instead, it’s better to perform a metadata-only deployment using the ALM Toolkit tool which is an open-source schema compare tool for Power BI datasets. You can download it at: http://alm-toolkit.com/

This allows the deployment of new objects without losing historical data. For example, if you have added a few measures, you can deploy only the new measures without needing to refresh the data, saving a lot of time.

To perform a metadata only deployment:

1. Select the running Power BI Desktop instance as the source, and the existing dataset in the service as the target:

Both Source and Target you have the following options to connect to your datasets:

– Dataset: You have to indicate the workspace connection URL, to get it in workspace go to Settings > Premium > Workspace Connection, select Copy.

• Power BI Desktop: The tool scans open Power BI files and allows you to select the file you want to use.

• File: You can select a file from your computer.

2. To get only the objects with differences, go to Home > Select Actions > Hide Skip Objects with Same Definition:

In this case the difference is that the “Test Measure” is missed in the target:

You have the option to create it or select skip to don’t create it.

3. Finally click on “Validate Selection” to ensure the integrity of the target model and then click on “Update”:

4. If the deployment was successful, the following screen will be displayed:

– Use filters in your visualizations to reduce the amount of data that display: The more data a visual must display, the slower it will load, so apply filters in the Filters pane, or use Top N, to reduce the number of items displayed.

So, if your report is connected to a large data model and you do not apply any filtering, all the data will be loaded into memory and decompressed on each update, creating a huge memory demand.

– Only include the necessary number of visuals in your report: This will decrease the number of calculations that Power BI is performing when rendering your report. For example, you should use a multi-row card instead of using multiple single cards.

– Limit the use of slicers: Because they are visualizations, the underlying data will be updated every time the dashboard is refreshed, which could affect the performance.

– Use Microsoft-certified custom visuals: These have the Microsoft’s guarantee that these visual elements perform at their best, in addition have more options than non-certified ones. 

– Avoid unnecessary interactions between visuals: Power BI automatically creates interactions between all the visuals on a page, which require high loading capacity that could slow down the loading of reports.

Therefore, make sure to eliminate the unnecessary interactions that Power BI creates by default.

– Use Performance Analyzer to Analyze the performance of your report elements: such as visuals and DAX formulas when users interact with them, and which consume the most resources.

✅ Excel Checklist

Download the Excel checklist at the following link: https://github.com/NuricBI/Checklist

Conclusions

In this article we reviewed how to improve and analyze the performance of your Power BI solutions in the different development layers:

✔ Data source.

✔ Data model.

✔ DAX.

✔ Data visualization.

You must be careful in each of them, because in whatever could be the cause that affects the final performance of the report.

Keep handy the excel file with the summarized list of best practices and recommended tools to analyze the performance of each phase of your solution.

In this checklist you will find the tools you can use at every step of the way:

1. DATA SOURCE

Query Diagnostic

 This Power BI Desktop feature will help you understand what happens inside the Power Query when a query is executed, the parts of the query that are being performed locally or remotely, and the slowdowns you may encounter during:

– Loading and transforming your data.

– Refreshing your data in Power Query.

Start a Query Diagnostic:

• Go to the ‘Tools’ tab in the Power Query Editor ribbon. You will have the following options Diagnose Step and Start Diagnostics / Stop Diagnostics:

Start Diagnostics / Stop Diagnostics is more used because it provides complete information about each query while Diagnose Step analyzes the performance of a specific step without showing you the diagnostic of the other steps of the query.

• In Power Query Editor, select the query you want to analyze.
• Go to Tools in the Home ribbon, click “Start Diagnostics”.
• Perform the evaluations you want analyze, as: authoring, refreshing a preview, full refresh, etc.
• When you are finished, make sure that you select “Stop Diagnostics”.

This generates two new queries with the diagnostics results:

In my opinion the most important column is the Exclusive Duration, you should convert it to seconds in the Power Query Editor and then summarize it to get an idea of where time is spent and identify how you can optimize the queries in your power bi models:

2. DATA MODEL

DAX Studio

– Launch DAX Studio. Select the model that you want to analyze:

– Go to the advanced tab and click on “View Metrics”:

This will show metrics that help you quickly detect the performance issues.

Cardinality: This is the number of unique values in a column. High cardinality columns can be particularly expensive, especially when have a string or date/time format.

If possible, remove columns such as GUID and timestamp from a SQL Server table from your model. In addition, I recommend splitting Datetime columns into two columns, one for date and one for time.

Size information: The other important thing you can see is the space that is taking up each table and column of the model, for example:

In this case, the Work Order table is taking up almost 20% of the entire model, which helps you analyze where your model consumes the most memory and choose which columns to remove to optimize it.

Summary information: In the Summary tab you can see the total size of this model, in this example the analyzed PBIX is consuming 198.27 MB. You can also see the number of tables and columns:

Bravo for Power BI

This is a free open-source tool for users who do not need a high level of complexity. In case you need more advanced functionalities you should use other more advanced tools such as DAX Studio and Tabular Editor.

After downloading Bravo, go to the “Analyze Model” and connect to the data model:

You will get information about the tables and columns in your model that are consuming the most memory:

In addition, you can drill down to see more detail for any table:

To analyze the unreferenced columns, I recommend my tool Tabular Editor, which can help you identify the reports connected to the dataset where these columns are used.

3. DAX FORMULAS / VISUALIZATION

Performance Analyzer: To Analyze the performance of your report elements, such as visuals and DAX formulas when users interact with them, and which consume the most resources.

In the View ribbon you can find the Performance Analyzer. By opening this pane and clicking Record, this will show you how fast your report renders when performing different functions in your report.

You can review the results of your performance test in the Performance analyzer pane. To review the tasks in order of duration, longest to shortest, right-click the Sort icon next to the Duration (ms) column header:

The log information for each visual shows the time it has taken (duration) to complete the following categories of tasks, which will help you detect what is causing performance delays so you can work on improving those sections.

• DAX query– Time taken by the to send the query and the time it took Analysis Services to return the results.
• Visual display– Rendering time on the screen, including the time required to retrieve web images or geocoding.
• Other– The time it took the visual to prepare queries, wait for other visuals to complete, or perform other background processing tasks.

The only real way to reduce the long duration is to optimize DAX queries for other visuals or reduce the number of visuals in the report.

4. DATA MODEL / DAX FORMULAS / VISUALIZATION

Best Practice Analyzer within Tabular Editor.

Best Practice Analyzer is an external tool that scans your data model and easily validates if your data model complies with all best practices at formatting level, performance, naming conventions and DAX expressions.

I analyzed a test data model getting the following information which shows the potential issues and improvements that can be made in the data model in each category:

This can help you save a lot of time by avoiding having to validate all these recommendations manually.

In this article 👉 Best practice rules to improve your model’s performance you can read the rules that analyze which are segmented into categories. Some rules are more aesthetic-oriented while others are more focused on performance optimization.

Benefits.

• Reduce space and processing time.
• Faster refresh times.
• Lower latency reports.
• Reduce the time development.
• More user-friendly data models because the user will not navigate through a bunch of useless objects that are not needed to build the reports.

– Choose the appropriate dataset mode for your solution: You can use Import, DirectQuery, and Composite model.

There are a variety of factors to consider when deciding which method to use, so I recommend that you review the advantages, disadvantages, and limitations of each in the Microsoft documentation so that you can select the correct one.

– Build your data model using a star schema architecture avoiding snowflake schema:

Benefits

• More user friendly.
• The DAX formulas are simpler.
• The time refreshes are faster.
• Reduces redundant data

Star schema are specialized data models used when designing data warehouses, the tables are classified as either dimension or fact. In this schema the fact sits in the middle and the dimensions are all around related directly to the fact which gives it the shape of a star.

– Only include the essential columns to create the reports: You do not want a report larger than necessary. However, removing the unnecessary columns could be too complicated when you have a lot of reports connected to the dataset because they can break.

I created a tool to help you to clean up your data models easily and quickly, you can download it for free, visit the link: Tabular model cleaner.

– Load in your data model the necessary tables: Probably you need to import a table in Power Query to make intermediate calculations but if you won’t use this table in your reports remember unchecking the “enable load” option in Power Query:

– Apply an Incremental Refresh policy to reduce the amount of data: Power BI desktop is limited for your computer resources, if you are working with very large models will be necessary configure the Incremental refresh.

Benefits

• Optimize your time development because you work over a smaller data model.
• Shorter data refresh time.
• Lower resource consumption in the Power BI Service.

Check our article: Configure an Incremental Refresh Policy in seven steps

– Group by and summarize combined with composite models: Depending on the level of granularity that you need to handle in your reports you can group your data by month, division, city for example.

In case you have to visualize a detail of the data, you can create a composite model and adding a drill through page that retrieves the detail data from a DirectQuery table.

For more detail check: Composite Models in Power BI Desktop

– Avoid many-to-many relationships: Most of the time, this can be avoided by creating a bridge table with unique values and one-to-many relationships from the bridge table to the fact tables, thus adopting star schema.

– Avoid both-directional relationships in your data model: You need to have a solid data modeling knowledge to measure the impact of this type of relationship in your data model, otherwise this could cause:

• Unexpected results
• Performance problems

Instead of creating a bi-directional relationship, try using a measure like the one below to get the value you need:

– Add a date table to your model and mark it as a date table.

– Disable auto date/time option: This avoids Power BI automatically create a lot of date dimension tables in the background.

– Disable the “Autodetect new relationships after data is loaded” option: Because you could mess up your data model if you do not have solid experience in data modeling.

– Remove columns with high cardinality: High cardinality columns can be particularly expensive. If possible:

• Remove columns such as GUID and timestamp from a SQL Server table from your model.
• Splitting Datetime columns in two columns, one for date and one for time.

– Select the correct data type: Don’t use decimal type if you only need the whole number or if your data granularity is at day level don’t use Date/Time data.

– Create measures instead of Calculated Columns: Using measures where applicable will help reduce data model size and increase the efficiency of the calculations.

 – Create custom columns in Power query instead of DAX calculated columns: The custom columns created in Power Query achieve a better and more efficient compression.

– Use tools as DAX Studio and Bravo you to analyze where your model consumes the most memory: and choose which columns and tables you should remove to optimize it.

– Use the tool Tabular model cleaner to analyze the impact in your reports of make changes or removing objects from your data models.

Click here for part 3 of this series.

– Convert Multiple Measures to Variables: This will minimize the number of measures on your data model and improve their performance.

– Use the DIVIDE function for division instead divide operator (/): This function is optimized to check division by zero which generates a significant performance gain.

– Avoid using the IFERROR function: It’s better to avoid using the ISERROR and IFERROR functions. Instead, apply defensive strategies when developing the model as:

• • Apply Power Query transformations to remove or substitute invalid or missing values, and to set correct data types.
  • Use the IF function to determine whether an error result would occur or error-tolerant functions.

– Reduce usage of calculated columns that use the RELATED function.

– Use SELECTEDVALUE() instead of HASONEVALUE().

– Use COUNTROWS instead of COUNT because it’s more efficient and performs better.

– Write Explicit measures: You will have more flexibility and will be able to reuse them within other DAX formulas.

Implicit measure: This is when you use a column with numeric values directly in a visualization, you will identify it because each numeric column has the Sigma (or sum) icon next to it.

Explicit measure: These are the ones created using a DAX formula, they show a calculator icon beside them.

I recommend that you use explicit measures even for simple measures such as sum, count, average, etc. and then hide the corresponding column to avoid confusing users by having both the column and the measure in the data model.

– Use DAX Formatter to format your code: The code will be easier to read and maintain.

– Use performance analyzer to identify the DAX formulas with longer rendering time.

– Use DAX Studio to troubleshoot the slowest formulas: This tool will help you to speed up the troubleshoot process as you can modify the DAX code there directly and when running it know in detail the performance impact. I recommend you check out this article that goes deeper in this topic.

Click here to read the last part of this series.