Block storage - Oracle Hyperion Essbase Analytics

Since version 7, Essbase has supported two "storage options" which take advantage of sparsity to minimize the amount of physical memory and disk space required to represent large multidimensional spaces. The Essbase patent describes the original method, which aimed to reduce the amount of physical memory required without increasing the time required to look up closely related values. With the introduction of alternative storage options, marketing materials called this the Block Storage Option, later referred to as Essbase Analytics.

 

Put briefly, Essbase requires the developer to tag dimensions as "dense" or "sparse". The system then arranges data to represent the hypercube into "blocks", where each block comprises a multi-dimensional array made up of "dense" dimensions, and space is allocated for every potential cell in that block. Sparsity is exploited because the system only creates blocks when required. In the example above, say the developer has tagged "Accounts" and "Time" as "dense", and "Region", "Customer", and "Product" as "sparse". If there are, say, 12,000 combinations of Region, Customer and Product that contain data, then only 12,000 blocks will be created, each block large enough to store every possible combination of Accounts and Time. The number of cells stored is therefore 192000 (4 × 4 × 12000), requiring under 2 gigabytes of memory (exact 1,536MB), plus the size of the index used to look up the appropriate blocks.

Because the database hides this implementation from front-end tools (i.e., a report that attempts to retrieve data from non-existent cells merely sees "null" values), the full hypercube can be navigated naturally, and it is possible to load values into any cell interactively.

Calculation engine :

Users can specify calculations in Essbase BSO as:

- the aggregation of values through dimensional hierarchies;

- stored calculations on dimension members;

- "dynamically calculated" dimension members; or

- procedural "calculation scripts" that act on values stored in the database.

The first method (dimension aggregation) takes place implicitly through addition, or by selectively tagging branches of the hierarchy to be subtracted, multiplied, divided or ignored. Also, the result of this aggregation can be stored in the database, or calculated dynamically on demand - members must be tagged as "Stored" or "Dynamic Calc." to specify which method is to be used.

The second method (stored calculations) uses a formula against each calculated dimension member - when Essbase calculates that member, the result is stored against that member just like a data value.

The third method (dynamic calculation) is specified in exactly the same format as stored calculations, but calculates a result when a user accesses a value addressed by that member; the system does not store such calculated values.

The fourth method (calculation scripts) uses a procedural programming language specific to the Essbase calculation engine. This type of calculation may act upon any data value in the hypercube, and can therefore perform calculations that cannot be expressed as a simple formula.
 

A calculation script must also be executed to trigger the calculation of aggregated values or stored calculations as described above - a built-in calculation script (called the "default calculation") can be used to execute this type of calculation.