This week DS43 tackled blending as part of our client project. We’d been advised against blending in some cases as it can make things more difficult. In my previous blog, I spoke about optimising workbook performance. In Tableau’s optimizer feature, you may even see a recommendation to avoid blending as it can slow performance.
So, why use blending? When you connect to a Tableau Server data source, you can’t join or relate the data sources within the Tableau desktop. (This may be coming in an update soon…) Clients are increasingly using Tableau Cloud to store their data and this means the published data sources cannot be relationship-ed in Desktop. Blending can actually be faster than relationships since Tableau runs two separate queries rather than querying two things in one go.
For our client project, we prepared data in Tableau prep then published it to our Tableau Server, with the aim of transferring the published data sources to the client’s Tableau Cloud.
This was the general pipeline:
Tableau Prep -> Publish On Client Tableau Cloud as Published Data Source -> Blend the data sources on unique identifiers in Desktop (if different data sources have different aggregation levels, the aggregated data source is the primary data source. Essentially, a left-join is happening in the background).
The main issue we encountered was the appearance of null values appearing where we didn’t expect. They showed as the ATTR() aggregation in the view and a (*) value in the table - this happens when Tableau can’t decide what to summarise to. In your primary data source, every field you’re linking on should be in the secondary data source. Any gaps in the data can cause an issue, which is the case we encountered during our project.
The ATTR() (Attribute) function gives you a value if all the rows in a group have the same value for a certain expression. But if the values are different, it shows a star (*) instead. It doesn't count NULL values.