New Visualization Types in Power BI Desktop

In the July 2015 update for Power BI Desktop there were a load of improvements to the tool including new data sources, new transformations, direct querying of SSAS Tabular Models, new Data and Relationship view, publishing directly to your Power BI site and some new visualization types.

Dashboard report built with Power BI Desktop

The new visualization types added to Power BI Desktop are the Waterfall chart, Area chart, Donut chart and Matrix and I just wanted to take a few moments to walk you through them and how I see them being used in future dashboard designs.

Donut Chart in Power BI Desktop

Donut chart built with Power BI Desktop

The donut visualization is new in the July release of the Power BI Desktop. Obviously the donut chart visualization is very similar to the pie chart. One of the weaknesses with a pie chart visualization is that because of the angles in the visualization its often difficult to make comparisons between the slices in the pie. This makes a pie chart not very useful. For the same reason, I think the donut chart isn’t all that useful. Maybe its marginally better than a pie chart because its easier to make a comparison between the slices in the donut chart versus the pie, but I don’t think I would willingly use the pie chart.

The whole point of a dashboard is to quickly and easily gain insights into the success or failure of the business. If you need to stare at the report trying to decide if the fifth or sixth slice is bigger, then the dashboard isn’t doing its job. There are many other visualizations i would use that would work better than the donut chart, in my humble opinion.

Area Chart in Power BI Desktop

Area chart built with Power BI Desktop

The Area visualization is similar to the good ‘ole trusty line chart, one of the staples of any dashboard. The area chart has one key difference compared to a line chart: the area below measurement line is filled in. I think this can be a good thing because the filled areas in the chart can make it easier to spot differences between lines. But the downside is that the areas can obscure one another depending on the level of transparency. I think the area chart will work best with only a couple or few lines to compare but anymore than that I’d suggest sticking with the line chart.

Matrix in Power BI Desktop

Matrix report built with Power BI Desktop

The Matrix visualization is new to the Power BI Desktop but definitely not new to Microsoft reporting. The matrix visualization doesn’t come with any formatting options but I was able to control the background color of the matrix by first using a different visualization to modify the background color and then switching to the matrix report.

Waterfall Chart in Power BI Desktop

Waterfall chart built with Power BI Desktop

I think of all the new visualization types, the waterfall chart is the most useful because of the way it allows us to see changes in values between periods or categories. In the waterfall chart above, I created a month over month growth measure for me to be able to monitor change between months. The waterfall chart only displays the change between groups on the x-axis, making it perfect for measuring growth or change metrics. The waterfall chart is definitely the most useful new visualization type included in the July 2015 update of Power BI Desktop.

Resources

Watch my video walkthrough of the new Power BI Desktop. If you’re new to Power BI, you’ll definitely want to take a look at this.

If the video isn’t for you, take a look at my blog post with the run down on the new Power BI Desktop.

Feedback?

What do you think of the new visualization types and the July update for Power BI Desktop? I’d love to hear your thoughts on the new chart types and where you see yourself using them. Leave me a comment below.

 

#MDXMonday: Previous Year Month to Date Calculation

I recently had a client give us a call asking for helping creating a calculation in her cube to show the month to date value for the previous year. Here’s the basics of the calculation I created.

View last week’s #MDXMonday –> Calculating Daily Average Sales

This calculation involve two parts. First we must create a calculation that figures the month to date value of the measure in question. To do this I used the MTD function along with Continue reading #MDXMonday: Previous Year Month to Date Calculation

#MDXMonday: Calculate Daily Average Sales

Creating an SSAS MDX calculations for daily average sales is a pretty common requirement I’ve come across as a consultant for Pragmatic Works and as the instructor for Pragmatic Works Introduction to MDX class. Because of this and the fact that many people often come to me with their MDX challenges, I’ve decided to start a series of blog posts covering these challenges and experiences both as a reference for myself and other and also as a way to give back to the community. These examples will be done using the Adventure Works cube unless otherwise stated. Some of these will be simple and some will be more complicated but I hope you will enjoy learning a little bit about MDX as much I do so lets begin!

There are two basic parts to creating this calculation. The first step is Continue reading #MDXMonday: Calculate Daily Average Sales

Learn Designing a Data Warehouse from the Ground Up at SQL Saturday 442 Orlando, FL

image I’m very excited to announce that I’ve been selected to present a session entitled Designing a Data Warehouse from the Ground Up on October 10, 2015 in Orlando, Florida at Seminole State College of Florida! I’ll be presenting this session for the first time along side Mitchell Pearson (b|t). This is going to be an amazing event with tons of amazing, FREE training for everyone including SQL server newbies on up to those who have been in the profession for years. Continue reading Learn Designing a Data Warehouse from the Ground Up at SQL Saturday 442 Orlando, FL

What’s New in SQL Server Analysis Services 2016?

There’s a load of new features that are included in the release of SQL Server Analysis Services 2016 CTP2. I’m pretty excited about these changes and while these changes have been public for a while now, I’d like to share my thoughts. I’ll say that these features are included in the SSAS 2016 CTP2 release. This release does not include all the enhancements to SSAS 2016 and these enhancements are subject to change. You can read about the enhancements here. Continue reading What’s New in SQL Server Analysis Services 2016?

TSQL Script to Find Foreign Key References to a Given Column

It’s always kind of a pain to have to hunt down all those foreign key references so you can address the issues. So I put this script together (based on a script found on StackOverflow) in order to help me find all the required information related to a particular column in a specified table. I’m mostly posting this for my own reference later and for anyone else that may find this useful, so enjoy!

SELECT OBJECT_NAME(f.object_id) as ForeignKeyConstraintName,
    OBJECT_NAME(f.parent_object_id) TableName,
    COL_NAME(fk.parent_object_id,fk.parent_column_id) ColumnName,
    OBJECT_NAME(fk.referenced_object_id) as ReferencedTableName,
    COL_NAME(fk.referenced_object_id,fk.referenced_column_id) as ReferencedColumnName

FROM sys.foreign_keys AS f
    INNER JOIN sys.foreign_key_columns AS fk 
        ON f.OBJECT_ID = fk.constraint_object_id
    INNER JOIN sys.tables t
        ON fk.referenced_object_id = t.object_id

WHERE OBJECT_NAME(fk.referenced_object_id) = 'your table name'
    and COL_NAME(fk.referenced_object_id,fk.referenced_column_id) = 'your key column name'

 

Here’s a picture of what the results look like. I ran this query against the ReportServer database used for SSRS in case you were wondering.

T-SQL to find FK key columns

If you want to find every Foreign Key in your database, just eliminate the Where clause to bring back all the FKs. Hopefully you found this as useful as I did.

Three SSAS Best Practices to Follow

There is a lot of work that goes into performance tuning a SQL Server Analysis Services solution for a client. And even though there may be many steps involved in identifying performance and management issues with a large SSAS solution, there are a few things that we can quickly check and implement to give us quick wins for improving the performance of our cube. In this post, I’d like to quickly point out three best practices that we can follow to improve performance and create a more positive experience for our users. These are not meant to be the top three best practices to follow, but rather three (among many) very important best practices you should follow. I believe following these three best practices will make a difference in your solution.

Create Hierarchies with Attribute Relationships

In my opinion, creating natural hierarchies are the single most beneficial thing an SSAS developer can do to improve the performance and usability of a cube. There are several reasons correctly defined user hierarchies are beneficial, but here are a couple of the top reasons.

Increased Query Performance

Calendar HierarchyCreating attribute relationships between attributes that are included in a user defined hierarchy improve the performance of queries using these attributes for a couple different reasons. In this case, we’ll look at the Calendar hierarchy in the Adventure Works Date dimension. The Calendar hierarchy has five levels with the Calendar Year attribute at the top level and the Date attribute at the bottom level of the hierarchy. We can also see the following attribute relationships created to give SSAS an understanding of how the members of these attributes relate to one another. Once created, these relationships give SSAS the ability to understand that a given date member is related to a single month member, a given month member relates to a single quarter, and so on and so forth.

imageThis also means that during processing, special indexes are created that map the relationships between each member of each level in the hierarchy. This means that before a query is written, SSAS also knows to which month, quarter, semester, and year each date aggregates. These indexes are only created if you correctly define the attribute relationships between the attributes in the hierarchy.

Improved User Experience

imageUser defined hierarchies also improve the user’s experience with the dimension because the hierarchy provides a very natural way for the user to navigate through the data in the dimension. A user defined hierarchy does two things for a user: 1) Using the hierarchy obviously presents the data to the user in an understandable and clear way. And 2) the hierarchy organizes the data based on your business requirements. This means that the user doesn’t have to think about how should these attributes be organized or labeled because you’ve done that for them. The user can focus on reading their reports, understanding the data, and making business decisions.

Partition Measure Groups to Separate Volatile and Static Data

imageMeasure groups that are larger than (about) one million records should be separated into multiple partitions. There are several advantages to separating larger measure groups into multiple partitions.

Increased Processing Performance

Partitions in a measure group are processed in parallel. This means that a measure group containing three years worth of data separated into one partition for each month will process faster than a measure group with all three years worth of data in a single partition. Your processing strategy for each measure group may vary depending on the amount of data. For instance, a large telecommunication company may collect hundreds of millions of records per day, dictating a more complex and granular partitioning strategy.

Also, we should consider which partitions contain data that is changing vs. data that is now static. If our businesses will continually log transaction in the current month, we can partition our data by month effectively separating our volatile data from the static data. This means we only need to process one months worth of data in our cube to pick up the latest changes instead of having to processing the whole measure group.

Increased Query Performance

By partitioning our data at the month level, certain queries will also perform better. For instance, imagine a user queries our measure group searching for last month’s sales figures. Because we have partitioned our measure group with each month being loaded into a separate partition, this means that the entire measure group does not have to be scanned. Only the partition containing the data for the month in question needs to be queried.

Create Aggregations for Large Measure Groups

You can think of Aggregations as indexes for SSAS. Aggregations are used to help SSAS find the answer to a user’s query faster. Aggregations are typically used for measure groups that are large and take a considerable amount to query.

Improved Query Performance

Aggregations contain the data of a measure group at a summary level typically higher than the lowest level of data included in the measure group. Aggregations are populated during the processing phase of the partition. You can think of Aggregations as exactly the same as the lowest level of the measure group just at a summary level. This means that when SSAS receives a query that can be answered using an Aggregation, SSAS does not have to spend the additional time required to retrieve the measure group data from the lowest level and roll up the data to the requested level because the Aggregation design already contains the data at the desired level.

Beware Too Many Aggregations

Because Aggregations are built during the processing phase, this means that for every aggregation you define more time is required to build the aggregations. This also means that it is especially important to only build useful aggregations that are necessary to improve performance. By creating aggregations that are not often used, you can degrade query performance and increase processing time with little to no benefit. Like indexes on a SQL Server table, too many aggregations or the wrong aggregations can actually hurt performance, so make sure you test, test, and then test to ensure your aggregations are helping your query performance.

I hope you have found this information useful. By following these three best practices, I really believe you’ll see a generous improvement in the performance of your SSAS cubes.

If you found this information helpful, I’d love to hear from you! Please leave me a comment and let me know what you think. Do you have any ideas on something I left out or should have included? Please let me know! Thank you!

Dustin Ryan is an MSBI consultant, trainer, speaker & author specializing in data warehousing, SSAS, SSIS, SSRS, Power BI and SharePoint

Follow

Get every new post delivered to your Inbox.

Join 37 other followers