If you spend too much time engineering a solution for applying your complex business rules into a calculation in SAS® Visual Analytics, or feel it can’t be done, or simply want to learn something new and powerful about SAS® Visual Analytics calculations, this article is for you!
SAS® Visual Analytics provides an extensive list of operators that can be used in expressions, but some types of calculations may become very challenging, and defy your ability to solve a few problems, independently of your industry or business area. SAS® Visual Analytics 8.3 brings a series of new enhancements that together are so powerful that they allow you to go above and beyond the capacity of delivering the insights that you need. Those capabilities are: aggregated data sources, data source join, AggregateTable operator, and AggregateCells operator (this last one available since VA 8.2).
This article kicks off a series to explain each one of them separately and the last one guides you through an example that leverages them to deliver the expected results for a specific Per Member Per Month (PMPM) use case. Did you get stuck in the past trying to produce reports with non-trivial calculations? This is your chance to rethink them.
We are going to start with AggregateCells operator.
The AggregateCells operator aggregates values of a specific set (or range) of cells for an object. It can be used to calculate cumulative totals, running average, etc.
In SAS Visual Analytics 8.3, the AggregateCells operator can be found under the Aggregated (tabular) group, on the left side of the expression window, when creating a new calculated item:
In SAS Visual Analytics 8.2, this operator is found under the group called Aggregated (advanced).
The AggregateCells operator has a few parameters, as indicated in the picture below:
Some of those parameters may need a bit of additional explanation, like the direction of the aggregation and the range (starting and ending point) of the aggregation.
According to the documentation, the default option specifies that the direction is selected automatically (column or row) based on the contents of each object. Trying to map columns and rows into a line chart for example is not that straight forward, so I like to think of them as vertical and horizontal respectively. In the case of a line chart, the default is the same as row (or horizontal), as the category role is laid down across the X axis.
Normally the default option should work as expected for most of the objects, but there might be cases where you need to change the direction, especially with crosstab objects, where the definitions of rows and columns are clear, and it might make sense to aggregate in a different direction. For example:
If a crosstab has categories across *rows only*, the default option is the same as column (vertical aggregation), independently if measures are in rows or columns:
If a crosstab has categories across *columns only*, the default option is the same as row (horizontal aggregation), independently if measures are in rows or columns:
If a crosstab has categories across *rows and columns* and measures are in columns, the default option is the same as column (vertical aggregation):
If a crosstab has categories across *rows and columns* and measures are in rows, the default option is the same as row (horizontal aggregation):
These parameters are the ones that define the set of cells to be aggregated. The option *start* specifies the first value in the row or column. The option *end* specifies the last value in the row or column. The option *current* specifies the current value being processed in the row or column. The offset just moves the pointer around the value:
All previous pictures used to explain the parameter direction are calculating cumulative total. To implement cumulative total, you just choose Sum as the aggregation, then make the starting point equals to *start* with offset zero, and the ending point *current* with offset zero:
These are the charts for Order Quantity and its cumulative total:
If you replace the measure Order Quantity in the previous example with a fixed number 1, the expression generates sequential numbers that can be used as line numbers:
To implement moving average, let’s say for a window of 7 days, you first make the aggregation equals to *Average*, then the starting point *current* with offset -6, and ending point *current* with offset zero:
Both Cumulative Total and Moving Average can also be obtained via “one-click” calculations. In our examples, you just need to right-click on the Order Quantity measure under the Data pane and select them from the dropdown:
It’s not difficult to imagine how the AggregateCells operator could be used to derive more complex calculations to compare data elements from different offsets, such as the difference, the ratio, etc.
In the next article you will be exploring the AggregateTable operator.
Additional resources on advanced calculations and aggregations:
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.