Simplify definition of table calculations
Hi all,
One thing I find really painful in Tableau is working with table calculations. Perhaps I am unique in this, but it
seems to me as soon as you start doing anything moderately complex in Tableau, you have to start using lots
of table calculations, and often those table calculations have to refer to other table calculations and so on.
Things often get very messy, and the user interface provided to specify how table calculations show work is
quite cumbersome to work with when you need to define a lot of them.
Some example of the problems you can get:
1. Allowing 'Compute using' to be set to 'Table (Across)' and 'Table (Down)' and so on causes lots of
issues. Because these are all relative to where the dimension happens to be placed, it is very easy to
move a field from one place to another, and suddenly have it spit out completely different values than
it used to. This is especially a problem if you are creating a datasource for other users who may not be
aware of or understand how the calculation is working.
2. When a calculated field refers to one or more table calculations, it is impossible to set the 'default'
dimension for the referenced table calculations in the datasource. You have to drag the calculation onto
a view before you get the option to define the compute dimension for the referenced table calculations.
3. The dialog you use to edit the table calculation mentioned in #2 is very unwieldy, if your field refers to
more than one table calculation, you have to go through a whole bunch of drop downs and modal dialogs
to get the result you want.
4. And if you have that same field represented many times on the view, then you have to go through the
whole process of editing every one of them individually! This is a real pain if you happen to modify one
of the underlying calculations... it will take you 1/2 hour to go through and change every reference to the
table calculation in every place it is used in a view.
5. If you need to set the 'compute using' to an 'advanced' grouping, then that is buried down in yet
another unwieldy dialog. And if you then drag that calculation onto a view that doesn't include all those
dimensions, then it will freak out.
6. When it freaks out as in #5, it just complains that a required dimension is missing, but doesn't tell
you which one... it can be very difficult to figure out and will take 10 mins of clicking through the
aforementioned dialog boxes before you do.
Anyway, enough of my whinging, what do I propose it the solution?
I tend to make my calculations be very specific, eg. I'll have a field called 'Region's % of Sales', and then I
might have another called 'Region's % of Sales (3 Month Moving Average)'. Ideally I'd want to be sure that that
field is always calculating the same thing, no matter how I or someone else happens to use it in a view. And if I
change that calculation, I want to know that any views using it are going to update accordingly.
If I was able to specify the dimensions across which to compute the calculation in the function itself, I think
it would solve or alleviate all the issues I described. So this would mean all the table calculations would take
extra parameters to specify the dimensions and what have you eg:
1
Simplify definition of table calculations
TOTAL(expression, [dimensions, level, restarting])
(I realise it would have to be a little more complicated given that you can specify arbitrary numbers of
dimensions, and level and restarting only apply to dates, but I'm keeping the example simple to get the idea
across, Tableau's brainy engineers can figure out the rest!)
So in my case mentioned above, my two calculated fields would end up being something like:
Region's % of Sales:
SUM([Sales]) / TOTAL( SUM([Sales]), [Region] )
Region's % of Sales (3 Month Moving Average):
WINDOW_AVG([Region's % of Sales], -2, 0, [Date], 'month')
This way, I can be sure that the Region's % of Sales is always just what it says it is, regardless of where it's
used. And when someone using the moving average calculation, they don't have to know or care about making
sure the underlying table calculation is calculated over the correct dimensions either.
Cheers
Tom
2