This type of object is useful, fast, and it is calculated on the Intelligent Server side so it doesn't put load on the database. As the name suggests, it serves the purpose of consolidating row values. This means not only adding one row to another, but also doing row-to-row calculations.
Remember from previous chapters that there are multiple London
or Paris
elements in the City
attribute, the schema was designed this way to respond to a specific requirement: allow the reports to display separate ZIP codes in large cities. Now we want to have a look at how much we sell in the entire city of London, but we don't have such an element in the City
attribute.
So, we create our own virtual attribute to show, in one single row, a consolidated value for all the elements that represent the city of London and another row with the values for the rest of the UK.
We will create a consolidation in My Objects folder:
London Area
, the red row below says Empty Expression.Rest of UK
.UK Areas
. Let's put it to the test.50 UK Sales
but do not close it.If you look at the SQL view, you'll see what happens behind the scenes:
where a12.GeographyKey in (244, 245, 246, 247, 248, 249, […]group by a12.GeographyKey
MicroStrategy generates a query with all the UK elements in the WHERE
clause, grouping by GeographyKey
, which is the ID of the City
attribute; the result is retrieved, then the consolidation is performed by the Intelligence Server (the part that does the calculation is called Analytical Engine as opposed to the SQL Engine, which generates the SELECT
).
See the last sentence of the SQL view:
[Analytical engine calculation steps: 1. Calculate consolidation: <UK Areas> 2. Perform cross-tabbing ]
This means that the RDBMS knows nothing about UK Areas
, we created our virtual attribute without having to modify the database schema.
One drawback of this technique is that you need to know your elements beforehand; you cannot dynamically select all London elements without prior knowledge of how many London(s) are there. See the custom groups later in the chapter for an alternative.
We want to add more rows to the grid, and look at how London compares to the rest of the UK. Consolidations allow us to perform this kind of inter-row operations, such as London / Rest of UK. Follow these steps:
London / UK
.What is happening is that we have a ratio (London / UK
), which should be formatted as a percentage, but it's not; since we are showing no decimals, the number is rounded to 1
.
Then in the Total row we have a sum of all the values in the consolidation, that's why the number shown is 4279010 instead of 4279009.
This is a very common mistake when using this type of object, and we should always keep in mind that, if we want a total here, we should create another element with the sum of the appropriate values only, in this case:
([London Area] + [Rest of UK])
One extremely useful feature of consolidations is that we can give different formats to different rows. It is worth noting that the format will be used for any metric used in conjunction with the consolidation (in the example, we are applying it to a SalesAmount
metric, but could be any other metric); it is up to the developer of the report to use it appropriately. So, let's change that format and add a total:
UK Total
.([London Area] + [Rest of UK])
, see image: