ASO and BSO concepts overview

Aggregate storage database (ASO):

               ASO databases drive operational analytics and are optimized for high dimensionality, extreme sparsity of data, and dimensions with millions of members.

Block storage database (BSO):

               BSO supports dense data sets, enabling users to write back interactively and perform complex financial analytics.

Differences between ASO and BSO:

ASO	BSO
Architecture that supports rapid aggregation, optimized to support high dimensionality and sparse data.	Multiple blocks defined by dense and sparse dimensions and their members, optimized for financial applications
Copying of database is not supported.	Database copying is supported.
One database is supported per application	It accepts more than one database.
ASO cannot support write-back	It supports write back option.
It uses MDX scripts for calculation	Use calculation scripts for calculation.
ASO outline is validated when database is started, outline is saved, when user requests.	BSO outline is validated when outline is saved and when user requests.
For formulas in ASO it accepts only valid numeric value expression written in MDX. It will not support for Essbase calculation functions.	Supports Essbase calculation functions
Partitioning functionality support with restriction that no outline is synchronized.	Partitioning is fully supported.
Aggregate storage databases can contain multiple slices of data. Data slices can be merged.	In BSO it is not supported.
After-update triggers supported.	On-update triggers and after-update triggers supported
A shared member automatically shares the attribute associations of its non-shared member.	A shared member does not share the attribute associations of its non-shared member.

Advantages and disadvantages of ASO:

               These days ASO is becoming the standard for extra-large Essbase databases. It fills nicely where the need for high speed data retrieval for reporting and analysis can eclipse the need for full-featured functionality. Here are some of the features for you.

Advantages

            Listed below are just a few high-level features that makes the ASO a good choice:

• Easy optimization, massive data scalability, reduced disk space, and up to 100 times faster.
• Database creation is accomplished by either migrating a BSO outline or defined as new after application creation.
• Outline dimensions will not need to be designated as dense or sparse.
• Outline is validated every time a database is started.
• Database calculation or aggregation of the database can be predefined by defining aggregate views.
• Calculation order is not relevant for database calculation, but is relevant for dynamic calculation formulas.
• Limited write back ability.
• At the end of a data load, if aggregation exists, the values in aggregation are recalculated and updated automatically.
• Aggregate storage database outlines are page-able. This feature significantly reduces memory usage for very large database outlines.

Disadvantages

Listed below are a few high-level features that we feel you may need to be wary of when using the Essbase ASO:

• Aggregate storage applications have some limitations that do not apply to block storage applications with regard to consolidations, calculations, and overall robust functionality.
• Can store only one database per application.
• Names reserved for table spaces cannot be used as application or database names.
• Accounts dimension does not support time balance members and association of attribute dimensions.
• On non-account dimensions, there are restrictions on label only members and dynamic time series members. Members tagged as dynamic hierarchies have no restrictions on the consolidation settings. Stored hierarchy members can only be tagged as label only or (+) addition.
• Non-account dimensions support only consolidation operator (+) addition.
• Calculation scripts are not supported.
• Formulas are allowed only on account dimension members and allowed with certain restrictions.
• Only Level 0 cells whose values do not depend on formulas in the outline are loaded.
• Data values are cleared each time the outline is structurally changed.

Therefore, incremental data loads are only supported for outlines that do not change.

• Currency conversion is not supported without the use of special MDX queries. This method can have a negative effect on performance.
• As you can see, there are some substantial differences and some very good reasons to use one type of database over another. To give you our idea of the ideal application of ASO and BSO, read below:
• ASO Database: The ASO database is ideal for dynamically built Essbase cubes that are usually Read only and used for reporting, presentation, and analysis. This type of database would also tend to have a rather large outline where at least one dimension has a significant amount of members. A parts dimension or product dimension comes to mind. Behind this ASO database would be a large BSO parent Essbase database, from which the dynamic ASO databases are built on the fly.
• BSO Database: The BSO database is ideal for virtually any size cube, but where performance is not necessarily the number one priority. Accuracy and completeness of data would be the main consideration. The BSO database is ideal as the large parent database where users from many different departments can trigger jobs which will dynamically build ASO reporting cubes on an as needed basis. The typical BSO database is ideally suited for financial analysis applications.