11 Replies Latest reply on Oct 11, 2016 9:52 AM by David Li

    Table Calculations--Partitioning Fields and Addressing Fields

    heather.vogt

      Hello! I've been reading this for information about table calculations and their authentic application. In understanding partitioning fields and addressing fields, could you make the generalization that partitioning fields are dimensions; and addressing fields are measures?

       

      I'd like to stay away from generalizations in my work, but I'd like to see an authentic situation where this wouldn't be the case. When could a measure be a partitioning field and a dimension be an addressing field?

       

      Thanks!

        • 1. Re: Table Calculations--Partitioning Fields and Addressing Fields
          David Li

          Hi Heather! That generalization is inaccurate, unfortunately. Measures can never be partitions nor addresses. Only dimensions (or any field used as a dimension) can be either of these, and that's because all of the dimensions used to build a sheet's level of detail must be either partitions or addresses in a table calculation used in the sheet, and only those dimensions that contribute to the level of detail may be used as a partition or address. Measures are just aggregated by the level of detail, so they cannot be partitions nor addresses.

           

          Let me clarify and give an example. The level of detail refers to all the dimensions you've added to shelves or marks to make the cells that you see in the sheet. Let's say that you're working with the Superstore data set and you put Category and Sub-Category into rows and then drop Sales into the Text mark. The only two fields that contribute to the level of detail are Category and Sub-Category. If you were to put in a table calculation (say window sum), you would see that Category and Sub-Category are the only options in the table calculation editor for partitioning or addressing. Sales will not appear (except as a way to sort the aforementioned dimensions).

           

          Tableau performs a different iteration of the table calculation for each partition, and it goes from each address to the next in a particular order. Think about the table calculation like a fruit garden. Let's say that you're trying to add up all the fruit from the garden, but you want different piles for different kinds of fruit. Let's say you separate the different types of fruit so that they each occupy a quarter of the garden. These quarters are your partitions (think of this as a field called [Fruit Type]). When you go about harvesting the fruit, you go from plant to plant gathering up the fruit. These individual plants are like your addresses.

          • 2. Re: Table Calculations--Partitioning Fields and Addressing Fields
            heather.vogt

            So dimensions are the only data that can be partitions and addresses? So how can you do a table calculation for running total? Don't you need a measure for that, like Sales? Sales is a measure and it is the "direction" the data is being taken.

             

            Wha...this is so beyond my scope of understanding.

            • 3. Re: Table Calculations--Partitioning Fields and Addressing Fields
              David Li

              The measure is the thing being aggregated by the table calculation. The partitions and addresses define how Tableau will go about taking the measure's value from each cell and aggregating it into the table calculation's results.

              • 4. Re: Table Calculations--Partitioning Fields and Addressing Fields
                heather.vogt

                I guess my understanding is that when you're looking for an addressing field you ask yourself, "Which field are we finding the [table calculation] of?" So for running total between Sales and Category, Sales would be the addressing field.

                 

                For partitioning fields you ask yourself, "Which field is reflecting the table calculation?" In the example above, Category would be the partitioning field.

                 

                Again, I could be completely wrong on this. I guess I'd really like someone to explain the difference between the two using the scenario below. I can't apply what you're saying to me in a novel situation yet.

                 

                59 partitioning and addressing.png

                • 5. Re: Table Calculations--Partitioning Fields and Addressing Fields
                  David Li

                  In this situation, Category is not the partitioning field. It's actually the addressing field.

                   

                  Think of it this way: partitions are like walls, and the table calculation can only see what's within the walls of a single partition. Here, the table calculation divides the each Category's value by total value for all Categories. That means that it must be able to see all three Categories, and thus they cannot be different partitions. They are instead addresses, and the table calculation visits each one, looks at its value, divides it by the total for the entire partition (i.e. everything), and reports that value.

                   

                  If you were to change Category to be a partitioning field, you would find that every bar becomes 100%. That's because the table calculation would only be able to see one Category, so that Category's value divided by itself is always 1.

                   

                  Note that if you right-click the table calc's pill and click a field inside "Compute using", that field becomes the addressing field. In order to make Category the partitioning field, you'd have to edit the table calculation and select "Advanced..." in the dropdown next to "Summarize the values from". Then, you would move Category to the partitioning side.

                  1 of 1 people found this helpful
                  • 6. Re: Table Calculations--Partitioning Fields and Addressing Fields
                    heather.vogt

                    So there is no partitioning field?

                    • 7. Re: Table Calculations--Partitioning Fields and Addressing Fields
                      David Li

                      Correct. In this case, the sole partition includes everything.

                      1 of 1 people found this helpful
                      • 8. Re: Table Calculations--Partitioning Fields and Addressing Fields
                        heather.vogt

                        So can I say this,...

                         

                        When looking for the addressing field ask yourself, “Which field are we finding the [table calculation] of?”

                         

                        When looking for the partitioning field ask yourself, “Which field is reflecting the table calculation?”

                        • 9. Re: Table Calculations--Partitioning Fields and Addressing Fields
                          David Li

                          Well, I'm not sure what you mean by "reflecting", and I think you're still stuck thinking that a measure can be an address. Think of a table calculation as having three parts: the measure being calculated, the partitions, and the addresses.

                          • The measure is the field/calculation that we're measuring. It's the actual number that comes out of the table calculation.
                          • The partitioning fields are used to break up the cells into different partitions. Each instance runs only within a single partition. Note that each partition is essentially a least common numerator of the partitioning fields. For instance, if your partitioning fields are Category and Date, there will be a different partition (and thus a different instance of the table calc) for each Category and Date.
                          • The addressing fields are all the other dimensions in your level of detail. Any dimension used in the sheet (except filters and dimensions used as attributes) that is not a partitioning field must be an addressing field. You can think of addressing fields as the individual steps through which each instance of the table calc will run.
                          1 of 1 people found this helpful