i got the basic understanding of ATTR function but I think I still don't know it's effect on a chart
for eg I don't know how will it affect a waterfall chart model as I was studying something related to it on
when should we like in general change a dimension to an attribute ?
I can't give any generic indication of what will happen to a specific chart, as a lot depends on the dimensions already in the view. The result of using ATTR() will depend on how the view is set up.
There's a bit of a description of when it can be useful in Table Calcs here:
And some more helpful info here:
With some applied practice, it will begin to make sense and you'll learn to predict when this aggregation is useful
I think you are referring to my blog post on waterfall charts Paint By Numbers: A handy use of Attributes in Tableau - colouring waterfall charts
This isn't the true definition of an attribute, but this is how I think about attributes when I use them:
If I want to include a dimension in the view so that it will change the color, or add a label, but will not change the order of things or break the data down into smaller chunks, I use an attribute. Its a bit like saying, show me the attributes of the dimension, but not the dimension itself.
That's how I think of it anyway, and it seems to work most of the time....
7 of 7 people found this helpful
Most all those other explanations that were linked to (including my earlier ones) are incomplete because they don't talk enough about dimensions and the relationships between fields that determine what results Tableau computes for aggregates in the view, including ATTR(). Here's my current working definition of ATTR:
"Show me the value of a dimension as an aggregate measure if there is one and only one value for that dimension for the given distinct combination of values of the other dimensions in the view, otherwise show *."
ATTR() is an aggregation like MIN(), MAX(), AVG(), etc. that is performed inside Tableau and like all aggregations turns the given field into a measure. The ATTR() aggregation is basically:
IF MIN([myDimension]) == MAX([myDimension]) THEN
ELSEIF ISNULL([myDimension]) THEN
* //which is a special Tableau-only variation of Null indicating that there are multiple values of myDimension in this context
Like all aggregations, this is computed at the level of granularity of the view. The level of granularity of the view is the distinct combination of dimensions "in the view", specifically on Rows, Columns, Pages, and the Marks Card. All of these dimensions are added to the GROUP BY of the SQL clause that Tableau issues to the data source and "partition" the view to create the results for each measure. If you understand SQL, the following should make a whole lot of sense, this is basically how Tableau works for SQL sources (data blending introduces additional complexity to the SQL).
I'll use Superstore as an example. In a view with Department and SUM(Sales), the query looks like:
SELECT Department, SUM(Sales)
GROUP BY Department
So there's one sum of Sales for each Department.
In a view with ATTR(Department) and SUM(Sales), the query looks like:
SELECT MIN(Department), MAX(Department), SUM(Sales)
In that case, there is no dimension to group the the data, so MIN(Department) returns Furniture, the MAX(Department) returns Technology, and the ATTR(Department) shows *. And SUM(Sales) is computed across the entire data set.
In a view with Department and ATTR(Department), the query looks like:
SELECT Department, MIN(Department), MAX(Department), SUM(Sales)
GROUP BY Department
Since Department is in the view and making the granularity finer, for each Department MIN(Department) and MAX(Department) return the same value, so we see each Department value for ATTR(Department), and Tableau sums the sales for each Department.
Now let's take a field that increases the granularity of the view that Department has a one to many relationship with like Category and put that in the view with ATTR(Department) and SUM(Sales). What Tableau does is:
SELECT Category, MIN(Department), MAX(Department), SUM(Sales)
GROUP BY Category
For each Category, MIN(Department) and MAX(Department) return the same value, so we see the specific Department value for ATTR(Department), and Tableau sums the sales for each Category.
Ok, one more, how about a field that Department has a Many to Many relationship with, such as Region:
SELECT Region, MIN(Department), MAX(Department), SUM(Sales)
GROUP BY Region.
Since there are multiple departments for each Region, MIN(Department) != MAX(Department) and Tableau will show * for ATTR(Department).
Aggregating dimensions into measures is useful when we don't want a dimension making the granularity of the view or display finer (such as for table calculations and line marks), and to improve performance. Performance can also improve with ATTR(): Adding more dimensions to the view adds more elements to the GROUP BY clause and that can slow down the query that Tableau is issuing a data source, whereas ATTR() just adds aggregate measures.
One point to note is that since ATTR() is computed inside Tableau it's sometimes not available when using nested blended calcs. Another point is that because of the extra evaluations ATTR() is slower than MIN(), MAX(), or AVG(). When I'm building out a view and I'm not sure of the dimensionality of the view, I'll use ATTR() because those * can be incredibly helpful at identifying when an extra dimension in the view is doing something I'm not expecting, and then once I have things locked down I'll switch over to one of the other aggregations for performance. Also, if I'm building a view for someone not so familiar with Tableau I'll use ATTR() whenever possible because then if someone doesn't have the right dimensions in the view then ATTR() will start throwing * and the view will "break" rather than return results that would be incorrect.
I also wrote a bit awhile back on testing whether ATTR() is returning * or not, it's at What ATTR() Does and Testing Whether ATTR() Returns * (Multiple Values).
Excellent Writing Jonathan thank you for your time :::::::)
Thanks so much Jonathan , I would keep posting questions on such core fundamentals as i come across any since I have recently started to learn Tableau and i think I am surrounded by niche people like you who can help the beginners learn in a better way.
Yes Peter i was referring to that only and I think I am getting a clear picture now .I have just started to learn Tableau , I think i would be more clear once I start building some charts.
Thanks for the response . Much appreciated