How ASo Works and how to Design for Performance - Developing Essbase Applications - page 233

when I introduce the last rule (Pop's rule) and again in Section 7.8 (A Final Word about
rule r1).
In summary, I say “it ain't really ASo” if you have to be reading off the disk drive.
By having all of the .dat file information in rAm, ASo Essbase can dynamically do the
stored rollups that are the essence of ASo quickly and easily.
Note: I am not referring to the memory in the aggregate storage cache. The total unused
memory available on your machine after starting all services (EPm and other programs)
and loading all of the BSo and ASo cubes you plan to run should equal the sum of all
the ASo .dat files for the cubes you plan to load. In Windows, this memory available
may be found on the resource monitor's memory tab. on the bar graph, it would be the
sum of the dark (Standby) and light blue (free) areas. The green In-use area includes the
ASo Caches for your loaded cubes.
7.3.4 The Essbase Implementation of the Data Card
The data on the face of the card is either the numeric fact data itself or simply the meta-
data description (in Essbase, the alias) of the data punched on the perimeter (effectively,
the member name). nothing surprising there. But, what is “punched” on the perimeter,
i.e., seen in the bitmap? metadata identifying any level-0 stored data of course, but what
about upper-level data? The only upper-level data that can be punched on the perimeter
is that from a known hierarchy; one without dynamic calculations (either consolidation
or formula based).
What do I mean by that last sentence? With a physical card, if we had a dataset of
circular objects (say, buttons), we would most likely have the radius of each button as
a data element on the card. We could include the value of that radius in a set of hole
punches. If we also wanted to know the surface area of the button, we would have to
calculate πr 2. If we wanted that value as a searchable piece of metadata punched on the
card, we would have to calculate it in advance and then have a set of punches for the
different area measurements. The sorting-needle could not make the calculation for us
because it can only sort based on ready-to-go metadata, i.e., data that has been punched
on the edge.
An upper-level cube member cube works the same way. In order for the result
of a calculation to be found by the bitmap, it would have to be precalculated. An
upper-level member that is the result of calculation, such as πr 2 , cannot be queried
directly by the bitmap mask, just as it could not be queried by the sorting-needle. In
ASo terms, πr 2 is dynamic. If you take out your calculator (or have SQL do it before
load) and compute it, you could punch the resulting value onto the card and ASo
can code it into the bitmap. But, the formula would not really be on the card, would
it? The results of applying the formula would be on the card. It certainly would not
change dynamically when the value of r (presumably a data element on the card) was
changed.
In Essbase terms, the only dynamically calculated data that can be found as the
equivalent of a hole on the card is the additive sum of predefined sets of lower-level
members as organized in the hierarchy. As mentioned earlier, the bitmap identifies data
not just by its member name, but also by the upper-level hierarchies to which it belongs.
Actually, that last sentence should be modified to read “… the upper-level Stored hier-
archies to which it belongs.” upper-level membership in Stored hierarchies is the only
upper-level membership to be found in the bitmap.