 Types Of hierarchy:

1. Multiple hierarches enabled

2. Dynamic hierarchy
3. stored hierarchy designation

 Members on stored hierarchies

Support with the following exceptions:
1. Support for the ^ (Never Consolidate) operator (underneath label-only members
only) and the + (addition) operator
2. Cannot have formulas
3. Restrictions on label only members (See Member storage types.)
4. No Dynamic Time Series members
5. Stored hierarchy dimensions cannot have shared members. Stored hierarchies within
a multiple hierarchies’ dimension can have shared members.

 Member storage types Support with the following exceptions:

1. Dynamic Calc and Store not relevant
2. On stored hierarchies, two limitations if a member is label only
 All dimension members at the same level as the member must be label only
 The parents of the member must be label only.
3. On dynamic hierarchies, ability to tag any member as label only
Note: On conversion from a block storage database, attribute dimension
members are tagged as Dynamic Calc. On standard dimension members
Dynamic Calc tags are converted and tagged as stored members

 Formulas Allowed with the following restrictions:

1. Must be valid numeric value expressions written in MDX (cannot contain %
operator, replace with expression: (value1 / value2) * 100)
2. No support for Essbase calculation functions
3. On dynamic hierarchy members, formulas are allowed without further
restrictions

 Period (Multiple hierarchies enabled) (Label only)

QTD (Dynamic (~) (Label Only)

 User ability to change data (write-back) in ASO:
a. Transparent partition technique used to enable limited write-back

 You must create an aggregate storage application to contain an aggregate storage database. An
aggregate storage application can contain only one database. You can create an aggregate storage
application, database, and outline in the following ways:
a. Convert a block storage outline to an aggregate storage outline, and create an aggregate
storage application to contain the converted database and outline.
b. Create an aggregate storage application and database. The aggregate storage outline is created
automatically when you create the database.
Note:
An aggregate storage outline cannot be converted to a block storage outline

 In an aggregate storage database, you can create two types of hierarchies:

● Stored
● Dynamic
The two types of hierarchies have different advantages and restrictions. A dimension may contain
both types of hierarchies. To use multiple hierarchies in a dimension (even if they are all stored
hierarchies), you must enable multiple hierarchies for that dimension.
Note: The first hierarchy in a multiple hierarchy enabled dimension must be a stored hierarchy.
 i.e Period (multiple hierarchie enabled)
1. Beg Balance(Stored)
2. YearTotal(Stored)
3. QTD(dynamic)
4. YTD(dynamic)

Stored Hierarchies
Members of stored hierarchies are aggregated according to the outline structure. Because
aggregate storage databases are optimized for aggregation, the aggregation of data values for
stored hierarchies is very fast. To allow this fast aggregation, members of stored hierarchies have
the following restrictions:
● Stored hierarchies can have the never-consolidation (^) operator (only underneath label only
members) or the addition (+) operator.
● Stored hierarchies cannot have formulas

The following members can be tagged as top of a stored hierarchy:

● A dimension member (generation 1). If a dimension member is tagged as top of a stored hierarchy,
the entire dimension is considered a single stored hierarchy, and no other member in the dimension can
be tagged as top of a stored hierarchy or top of a dynamic hierarchy.
● The children of the dimension member (generation 2). If a generation 2 member is tagged as top of a
stored hierarchy, all generation 2 members in the dimension also must be tagged as either top of a
stored hierarchy or top of a dynamic hierarchy. The first hierarchy in the dimension must be a stored
hierarchy.
The dimension tagged as accounts is automatically considered a dynamic hierarchy. You cannot
specify the accounts dimension as a stored hierarchy.

Dynamic Hierarchies
To evaluate a dynamic hierarchy, Essbase calculates, rather than aggregates, the members and
formulas. The order in which members and formulas are evaluated is defined by the solve order
property.
At the time of retrieval, Essbase calculates the required member combinations and calculates
any required outline member formulas. Because dynamic hierarchies are calculated, the data
retrieval time may be longer than for data retrieved from stored hierarchies. However, when you
design your database, dynamic hierarchies provide the following advantages:
● They can contain any consolidation operator.
● They can have formulas
Outline Paging
Aggregate storage database outlines are pageable. When you create an aggregate storage database, the
outline is created in a pageable format. When you use the Aggregate Storage Outline Conversion Wizard
to convert an existing block storage outline to aggregate storage, the outline is automatically converted
to a pageable format.
Note: Aggregate storage databases that have pageable outlines contain memory pages, and therefore
their outline files may be larger than binary block storage database outline files.

Outline Paging Limits The maximum size of a buildable outline (the number of members) depends on
several factors:
● The available memory for Essbase
● The amount of memory in Essbase allocated for other uses
● The amount of memory required for each member (and aliases for each member)

Essbase uses about 40 MB of memory on startup. In addition, the various caches require the following
memory allocations:
● Outline paging cache: 8 MB
● Aggregate storage data cache: 32 MB
● Aggregate storage aggregation cache: 10 MB
Therefore, the initial memory footprint for Essbase is about 90 MB. In addition, memory must be
allocated to process incoming query requests. Typical memory to reserve for this purpose is about 300
MB. The total memory allocated for Essbase is therefore 390 MB.
On a Windows system with 1.85 GB of addressable memory, the amount available to build and load the
outline is about 1.46 GB (1.85 GB - 390 MB = 1.46 GB). The maximum outline size depends on whether it
is built using a dimension build or from an outline already loaded into Essbase

Note: Currency name and currency category field types are not supported for aggregate storage outlines

Note: You cannot export data when loading data into a database.

Data load buffers :

The loading of multiple data sources into aggregate storage databases is managed through temporary
data load buffers.

Loading Data into Aggregate Storage Databases

Aggregate storage databases facilitate analysis of very large dimensions containing up to a million or
more members. To efficiently support loading data values into such large databases, Essbase:
● Allows the processing of multiple data sources through temporary aggregate storage data load buffers
● Allows you to control the percentage of resources a data load buffer uses
● Allows an aggregate storage database to contain multiple slices of data (a query to the database
accesses each slice, collecting all the data cells)
● Provides an incremental data load process that completes in a length of time that is proportional to
the size of the incremental data

Note: When using the aggregate storage data load buffer, the choice for replacing, adding, or
subtracting values is specified for the entire set of data sources when loading the data buffer contents
to the database.
Note: When loading SQL data into aggregate storage databases, you can use up to eight rules files to
load data in parallel. This functionality is different than the process described above. When preforming
multiple SQL data loads in parallel, you use one import database MaxL statement with the using multiple
rules_file grammar. Essbase initializes multiple temporary aggregate storage data load buffers (one for
each rules file) and commits the contents of all buffers into the database in one operation

Block Storage Calculation Features That Do Not Apply to Aggregate Storage Databases The following
characteristics of calculating block storage databases do not apply to aggregate storage databases:
● Calculation script calculations
● Dynamic Calc and Dynamic Calc and Store member storage properties
● Block storage formula syntax and predefined Essbase functions in formulas
● Custom-defined calculation functions and custom-defined calculation macros
● Formulas on members of dimensions other than members of aggregate storage dynamic hierarchies
● Preloaded values for member intersections above level 0
● Two-pass calculations tags
● Block storage performance features such as Intelligent Calculation

Calculation Order
Aggregate storage calculation order and block storage calculation order differ. For aggregate
storage databases, Essbase calculates data in the following order:
1. Aggregates members of stored hierarchies and attribute dimensions. The order in which members
and dimensions are aggregated is optimized internally and changes according to the nature of the
database outline and the existing aggregations. Because the aggregation is additive, the order in which
Essbase aggregates the dimensions and members does not affect the results.
Because the internal aggregation order for an aggregate storage database is not predictable, any inherent
rounding errors are also not predictable. These rounding errors are expected behavior in computer
calculation and are extremely small in relation to the data values concerned.

2. Calculates dynamic hierarchy dimension members and formulas. The order in which members and
formulas are evaluated is defined by the solve order property, which you can set for each member or
dimension. Calculation order may affect calculation results.

Solve Order Property

The concept of solve order applies to query execution. When a cell is evaluated in a multidimensional
query, the order in which the calculations should be resolved may be ambiguous. To remove ambiguity,
you can use the solve order property to specify the required calculation priority.

The value of the solve order property determines the priority with which Essbase calculates the
formulas. The formulas on the members that have a specified solve order are calculated in order from
the lowest solve order to the highest. You can specify a solve order between 0 and 127. The default is
0.
It is good practice to specify the solve order for each member by setting the solve order property at the
member level or at the dimension level. Members without formulas that do not have a specified solve
order inherit the solve order of their dimension. Members with formulas that do not have a specified solve
order have a solve order of zero.
You can specify the solve order at the member level or at the dimension level. Essbase uses the
following information to define calculation precedence:
1. Member solve order
2. Dimension solve order (members without formulas for which you do not specify a member solve order
inherit the solve order of their dimension. Members with formulas for which you do not specify a member
solve order have a solve order of zero.)
3. If multiple members have the same solve order, the members are evaluated in the reverse
order in which their dimensions occur in the database outline. The member that occurs later
in the outline takes precedence.

Note: When a member formula is dependent on the value of another member, the member with the
formula must have a higher solve order than the member or members on which it depends.

In the example, if the Variance member has a higher solve order than the Avg Units/Transaction member,
then the formula on the Variance member takes precedence and the result is the variance between two
ratios. This is the case in the ASOsamp.Sample database, because the solve order of the Variance member
is 20 and the solve order of the Avg Units/Transaction member is 10. The formula on Variance takes
precedence, because the Variance member has the higher solve order. The result for cell C12 of the query
in Figure 174 is the variance between the two ratios, as shown in Table 137:

Table 137 is correct.

Aggregating an Aggregate Storage Database
 Aggregate storage databases require no separate calculation step after data values are loaded into
the level 0 cells of the outline. From any point in the database, users can retrieve and view values that
are aggregated dynamically, for the current retrieval only. Aggregate storage databases are smaller
than block storage databases, enabling quick retrieval of data values.
 As databases grow, retrievals must process more data values to satisfy the calculation needs of the
queries. For faster retrieval, Essbase enables you to precalculate data values and store those values
in aggregations. If a database size nears one million aggregate cells, you should strongly consider
performing an aggregation. Depending on database usage and the usage environment, you can
achieve performance benefits by precalculating smaller databases as well. You can use either
Administration Services Console or MaxL to calculate an aggregate storage database.

Aggregate Cells
Cells for level 0 intersections across dimensions, without formulas, are called input cells. Data values can
be loaded to them. Higher-level cells involving members of the accounts dimension or dynamic hierarchies
are always calculated at retrieval. All other higher-level intersections across dimensions are aggregate
cells. Price Paid > Curr Year > 1st Half > Portable Audio > CO is an aggregate cell;
Original Price >Curr Year > Jan > Camcorders > CO is another aggregate cell.
Values for aggregate cells must be rolled up from lower-level values.
Aggregate cell values are calculated for each request, or they can be precalculate and stored on disk.

Aggregate Views
When Essbase defines which aggregate cells to precalculate and store, it works with aggregate views. An
aggregate view is a collection of aggregate cells. The collection is based on the levels of the members
within each dimension.
For example, consider one aggregate view for the outline in Figure 171 on page 954. This aggregate view
includes aggregate cells for the following dimension levels:
● Measures dimension, level 0
● Years dimension, level 0
● Time dimension, level 1 of hierarchy 0
● Product dimension, level 2 of hierarchy 0
● Geography dimensions, level 0
The example aggregate view is shown as 0, 0, 1/0, 2/0, 0

Aggregations
Aggregations are consolidations, based on outline hierarchy, of level 0 data values. An aggregation
contains one or more aggregate views. Essbase provides an intelligent aggregation process that selects
aggregate views to be rolled up, aggregates them, and then stores the values for the cells in the selected
views. If an aggregation includes aggregate cells dependent on level 0 values that are changed through a
data load, the higher-level values are automatically updated at the end of the data load process.
The term aggregation is used for the aggregation process and the set of values stored as a result
of the process.

Aggregation Scripts
Each aggregation script is a file that defines a particular selection of aggregate views to be materialized.
The Administration Services Aggregation Design Wizard enables you to create aggregation scripts and
store them in the database directory as text files with the. csc extension.
Performing Database Aggregations
You can use either Administration Services Aggregation Design Wizard or MaxL statements to perform an
aggregation. The aggregation process has two phases:
● Aggregate view selection.
● Calculation and storage of values for the selected aggregate views. This phase is also called the
materialization of the aggregation.

Working with Aggregation Scripts

Each aggregation script represents a specific aggregate view selection against a database. Aggregation
scripts can save you time. For example, after loading new data values you need not perform another
aggregate view selection. You can speed the aggregation process by using the selection stored in an
aggregation script to materialize the aggregation.
Aggregation scripts also give you flexibility. You can use them to save aggregate view selections optimized
for different retrieval situations; for example, you can use one script to optimize retrievals in month-end
reporting and another for daily retrieval requirements.
Optimizing Aggregation Performance
To possibly improve aggregation performance time, you can use the CALCPARALLEL configuration setting
to increase the number of threads. Because each thread handles a task of building an aggregate view, the
number of threads you define establishes how many aggregate views can be built concurrently. Even on
single-CPU computers, increasing the CALCPARALLEL configuration setting may improve performance
where building aggregates is I/O-bound, such as for databases too large to fit in memory. Because threads
must share aggregate storage cache, the cache size must be sufficiently large to support the number of
threads defined. Otherwise, increasing the number of threads could degrade aggregation performance
time.
Attribute Calculation Retrievals
Aggregate storage applications support only the Sum member of the Attribute Calculations dimension. If
you specify any other member name from the Attribute Calculations dimension, such as Min or Avg, an
error is returned.

Managing Storage for Aggregate Storage Applications

For aggregate storage applications, Tablespace Manager controls data retrieval and storage, using
tablespace definitions to manage data storage and work areas on the disk

Aggregate storage cache facilitates memory usage during data loads, aggregations, and retrievals. You can
view the current aggregate cache memory allocation and the maximum aggregate cache size setting.
Changing the setting may optimize memory use. The default maximum cache size, 32 MB, is the minimum
setting size. You can use the size of input-level data to determine when to increase the maximum size for
the cache. Administration Services and MaxL display the size of input-level data as the aggregate storage
database property: Size of level 0 values.
A 32 MB cache setting supports a database with approximately 2 GB of input-level data. If the input-level
data size is greater than 2 GB by some factor, the aggregate storage cache can be increased by the square
root of the factor. For example, if the input-level data size is 3 GB (2 GB * 1.5), multiply the aggregate
storage cache size of 32 MB by the square root of 1.5, and set the aggregate cache size to the result: 39.04
MB.
For aggregation materialization performance, consider the number of threads set for parallel calculation.
The aggregation materialization process uses multiple threads that divide the aggregate storage cache.
Increasing the number of threads specified in the CALCPARALLEL configuration setting for aggregate
storage applications or databases may require an increase in aggregate storage cache size. See the
CALCPARALLEL configuration setting.
ASO and BSO
Summary Difference

The main difference between ASO and BSO as show you as below:
1. ASO can support large scale of member such as Customer individual analysis, for example if your
customer dimension has 1M members, the aggregate calculation time will very faster than BSO.
2. ASO cannot support write-back but BSO can support that feature (Write-Back = Input data directly
back to Essbase Cube)
3. ASO can support large scale aggregation but for another purpose such as what-if or allocation should
use BSO.
4. For architecture of calculation, ASO use MDX script, BSO use Calc Script.
5. For Cube that have many dimension and more member, ASO can save storage space more than BSO
6. We can use in-line formula on BSO outline but ASO cannot use that
7) When you Add or Delete or changing the outline the entire data will remove.
8) There is no right back option.
9) In a standard Dimension + & ~ consolidation property only .In measure -,/,% other symbols are there..
10) Only one database for Application.
11) There are no Calculation scripts and formulas.
12) Two pass, Variance are not used in ASO.

Basic Difference between ASO/BSO

Aggregate storage applications differ from block storage applications in both concept and design.
Storage Kernel: Architecture that supports rapid aggregation, optimized to support high dimensionality
and sparse data. It doesn’t have Dense/Sparse concepts.
Physical storage definition Through the Application Properties window,
Tablespaces tab in Administration Services.
Database creation migrate a block storage outline or define after application creation.
ASO Support only one Database.

Outline Differences between Aggregate Storage and Block Storage

1) Multiple hierarchies enabled, dynamic hierarchy, or stored hierarchy designation

2) No two-pass calculation
3) ASO does not have concept of Dense/Sparse.
4) Support for the ~ (no consolidation) operator (underneath label-only members only) and the +
(addition) operator
5) Cannot have formulas
6) Restrictions on label only
7) No Dynamic Time Series members
8) Dynamic Calc and Store not relevant
9) No association of attribute dimensions with the dimension tagged as Accounts

Calculation Differences Between Aggregate Storage and Block Storage

1) Database calculation Aggregation of the database, which can be predefined by defining aggregate
views
2) Calculation script is not supported by ASO. Only outline consolidation.
3) Formulas Allowed with the following restrictions:
4) Must be valid numeric value expressions written in MDX (cannot contain % operator, replace with
expression: (value1/value2)*100)
5) No support for Essbase calculation functions
6) On dynamic hierarchy members, formulas are allowed without further restrictions.
7) Calculation order Member formula calculation order can be defined by the user using the solve
order member property
8) Attribute calculations dimension Support for Sum

Data Load Differences Between Aggregate Storage and Block Storage

1) In ASO level 0 cells whose values do not depend on formulas in the outline are loaded whereas in
BSO data can be loaded at any level (other than Dynamic Calc).
At the end of a data load, if an aggregation exists, the values in the aggregation are recalculated
automatically whereas in BSO it has to be explicitly call i.e calc all. Block storage No automatic update of
values. To update data values you must execute all necessary calculation scripts.
2) Aggregate storage databases can contain multiple slices of data. Data slices can be merged.
3) The loading of multiple data sources into aggregate storage databases is managed through
temporary data load buffers.

Creating Aggregate Storage Database, Application and Outline

There are 2 ways to create ASO cube

1) Convert a block storage outline to an aggregate storage outline, and create an aggregate storage
application to contain the converted database and outline.
2) Create an aggregate storage application and database. The aggregate storage outline is created
automatically when you create the database.

Stored Hierarchies

1) Members of stored hierarchies are aggregated according to the outline structure. Because
aggregate storage databases are optimized for aggregation, the aggregation of data values for stored
hierarchies is very fast. To allow this fast aggregation, members of stored hierarchies have the following
restrictions:
2) Stored hierarchies can have the no-consolidation (~) operator (only underneath Label Only
members) or the addition (+) operator.
3) Stored hierarchies cannot have formulas.

Dynamic Hierarchies

To evaluate a dynamic hierarchy, Essbase calculates rather than aggregates the members and formulas.
The order in which members and formulas are evaluated is defined by the solve order property. At the
time of retrieval, Essbase calculates the required member combinations and calculates any required
outline member formulas. Because dynamic hierarchies are calculated, the data retrieval time may be
longer than for data retrieved from stored hierarchies. However, when you design your database,
dynamic hierarchies provide the following advantages
1) Dynamic hierarchies can contain any consolidation operator.
2) Dynamic hierarchies can have formulas.
Alternate Hierarchies

An alternate hierarchy may be modeled in either of the following ways:

As an attribute dimension, which uses attributes to classify members logically within the dimension (for
example, a Product dimension can have attributes such as Size and Flavor.) As a hierarchy of shared
members. The alternate hierarchy has shared members that refer to non-shared members of previous
hierarchies in the outline. The shared members roll up according to a different hierarchy from the non-
shared members to which they refer. Shared members on dynamic hierarchies can have formulas. The
non-shared instance of the member must occur in the outline before any shared instances of the
member

DATA BLOCKS CREATE

Sparse dimension in Calculation, Blocks get created.