For example, when blending two or more data sources, fields from the secondary data source are automatically wrapped in ATTR() because fields from a secondary data source must be aggregated. If there are multiple values for a secondary dimension, then ATTR(Secondary Dimension) will show an asterisk in the view, as explained further in
Troubleshoot Data Blending: Asterisks show in the sheet. If another aggregation was used in place of ATTR() then Tableau Desktop would show misleading information. Such as MIN(Secondary Dimension) would show the first dimension value, and there would be no way to tell that there are actually multiple values in the secondary data source.
The asterisk is an indication that the relationship or the view needs to be adjusted. In it simplest form, the formula reads like this: IF MIN ([dimension]) = MAX ([dimension]) THEN MIN ([dimension]) ELSE "*" END
Last Modified Date: 24 Aug 2022 Question
How the Attribute (ATTR) function works and is different from other aggregations such as MIN or SUM. Environment
Tableau Desktop Answer
ATTR() Indicates Multiple
Values
The ATTR() aggregation indicates there are multiple values, but only one was expected.How it Works
ATTR() compares all of the values from each record in the underlying data that are grouped into one partition in the view (e.g. a bar, a circle, a cell, etc... ) and if the values are all the same then ATTR() will return that value. Otherwise ATTR() will return an asterisk.
The ATTR function evaluates all the members within the field and returns a value if 1) there is only a single value (MIN = MAX) or 2) all members are identical (MIN = MAX) else it returns "*". Which can be interpreted as "there is more than one value".
You can build out the basic ATTR function by adding conditions for when the ATTR function should be triggered, for example:
IF ISNULL ([dimension]) THEN NULL
ELSEIF MIN ([dimension]) = MAX ([dimension]) THEN MIN ([dimension])
ELSE "*"
END
Use Cases for ATTR()
- Per the above example, ATTR() can indicate that there are multiple values from the secondary data source
- Dimensions added to Tooltip on the Marks card are automatically wrapped in ATTR() because dimensions on Tooltip must be aggregated. If another aggregation like MIN() is used, then the tooltip will show a single value which may mislead the
viewer to think there is only a single value. Therefore ATTR() will display an asterisk as an indication that the view or the values added to the tooltip need to be adjusted. See Asterisks Display in Tooltips
- Like other aggregations, ATTR() can be used to change a non-aggregate value to an aggregate value to resolve aggregation errors in the calculation. See
Aggregate Error Messages In a Calculation Editor
Please note, when a calculation that returns numeric data contains ATTR(), if there are multiple values in the ATTR(), the calculation will return NULL rather than an asterisk.
- ATTR() can be used as a precaution to guard against data changing
Limitations
- Calculated fields containing ATTR() cannot be used to manually set a dynamic sort
- A calculation containing ATTR() may return NULL in the grand total even if it's returning the expected values elsewhere in the view. See Grand Totals Are Blank For Calculated Field That Include ATTR()
Additional Information
Discuss this article...Modeling hobbies for our contacts
Introduction
Attributes (like phone numbers) that are explicitly repeated in a class definition are not the only design problem that we might have to correct. Suppose that we want to know what hobbies each person on our contact list is interested in (perhaps to help us pick birthday or holiday presents). We might add an attribute to hold these. More likely, someone else has already built the database, and added this attribute without thinking about it.
The multivalued attribute is obvious in this example as its name is in plural. Be aware that this won’t always be the case. We can only be sure that there’s a design problem when we find data in a table as depicted below.
Contact hobbies1639 | George | Barnes | reading |
5629 | Susan | Noble | hiking, movies |
3388 | Erwin | Star | hockey, skiing |
5772 | Alice | Buck | |
1911 | Frank | Borders | photography, travel, art |
4848 | Hanna | Diedrich | gourmet cooking |
In this case, the hobby attribute wasn’t repeated in the scheme, but there are many distinct values entered for it in the same column of a row. This is called a multivalued attribute. The problem with this design is that it is now difficult (but possible) to search the table for any particular hobby that a person might have, and it is impossible to create a query that will individually list the hobbies that are shown in the table. Unlike the phone book example, NULL is probably not part of the problem here, even if we don’t know the hobbies for everyone in the database.
Using UML Multiplicity for multivalued attributes
In UML, we can again use the multiplicity notation to show that a contact may have more than one value for hobby.
Mapping to the relational model
As you should expect by now, we can’t represent the multivalued attribute directly in the Contacts relation scheme. Instead, we will model it using its own relation scheme. Thus, we remove the old hobbies attribute and create a new scheme, very similar to the one that we created for phone numbers in the repeated attribute design pattern.
The relationship between Contacts and Hobbies is one-to-many, so we create the usual pk-fk pair. The new scheme has only one descriptive attribute, the hobby name. To uniquely identify each row of the table, we need to know both which contact this hobby belongs to and which hobby it is—so both attributes form the pk of the scheme.
With data entered, the new table looks similar to the PhoneNumbers. It can also be joined to Contacts on matching pk-fk contactID pairs, re-creating the original data in a form that we can now conveniently use for queries.
Hobbies1639 | reading |
5629 | hiking |
5629 | movies |
3388 | hockey |
3388 | skiing |
1911 | photography |
1911 | travel |
1911 | art |
4848 | gourmet cooking |