Pros and cons of ASO and BSO

There are some differences between the ASO and the BSO. Even though there are differences, we would like the
reporting output to be the same and the analyst who is running the report should not even know to which type of
database he is connected. Let us take some time to look at a few of the pros and cons between these two types of
databases.

Pros and Cons of BSO

The Essbase BSO is the original format of the Essbase database technology. The BSO is also the mainstay for
Essbase as it offers robust, full-featured functionality. Here we will describe what we feel are some of the positive
features of the BSO as well as some of the not so positive features for you.

Pros
Listed below are just a few high-level features that we feel makes the Essbase BSO a good choice:

 Several databases stored in one application.

 No reserved names for application and database names.

 Account dimension supports all types of calculations and attribute members.

 Calculation scripts are supported.

 Uncomplicated write back ability.

 Formulas are allowed in all dimensions with no restrictions.

 Outline changes do not automatically clear data values, even if a data source is used to both modify

members and load values. Therefore, incremental data loads are supported for all outlines.

 Currency conversion is supported.

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

 For better performance, the outline dimensions must be defined as Dense or Sparse, based on data density,

which can sometimes be difficult to get exactly right.

 Database calculation—calculation script or outline consolidation.

 Calculation order will need to be defined in the calc scripts and is predetermined in a default outline

calculation.

 Unrestricted write back ability which can be dangerous if care is not exercised.

 No automatic update to values after data load. Necessary calculation scripts need to be specially executed,

including any default calculations.

 Sometimes requires large amounts of resources.

Pros and Cons of ASO

 The ASO is fast becoming the standard for extra large Essbase databases. Where the need for high speed data
retrieval for reporting and analysis can eclipse the need for full-featured functionality, ASO fills in nicely. Here we will
describe what we feel are some of the positive features of the ASO as well as some of the not so positive features for
you.

Pros
Listed below are just a few high-level features that we feel makes the Essbase 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.

Cons
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.

Of course, these are just one possibility or scenario. The beauty of Essbase is that you can do most anything with it.
Heck, you could easily have a large Oracle relational database as the backend data source for your ASO cubes.

The possibilities are endless!