Database Reference
In-Depth Information
• 1998: IBm started shipping Essbase under the name of “DB2 oLAP Server,”
a porting of the software to their platforms for widespread release with their oS
that continued until 2005.
• 2005: ASo was introduced with version 7.
• 2005: Essbase was declared one of the most Influential technologies of the last
10 years by Information Age magazine.
• 2007: hyperion (who was in the middle of renaming Essbase for some unknown
and undisclosed reason) was acquired by oracle.
• 2009: oracle renamed the product officially to “oracle Essbase” (loss of the
Essbase name had not been treated happily in most technical and even business
realms and everyone jumped for joy at its return).
That traditional Essbase cube first developed in 1992 and still developed today now
has several names. often, you can tell how long someone has been working with this
oLAP (online analytical processing) technology by which names they use when they
refer to Essbase. you may see within oracle materials the references to Essbase BSo
(Block Storage option), BSo cubes, or Essbase Analytics. It is one of the two storage ker-
nel options now available to the developer when creating a cube from scratch. Selecting
this option allows you to create cubes as they have been created for the past 20 years,
taking considerable time to determine (among other things) which dimensions should
be Dense versus Sparse. time also will be spent considering whether the resulting block
size will be optimal, or if the system will run out of memory because the block size is
too big. on and on goes the list of worries and angst that exist when we build traditional
Essbase BSo cubes. The entire debate becomes so complex that it has always been essen-
tial to have a good consultant at your beck and call to help you determine how to best
configure your cube.
This is contrasted to the newer technology option that also has several names in the lit-
erature and marketing materials. Essbase ASo (Aggregate Storage option), ASo cubes,
and Enterprise Analytics are all references that can be found and are valid. With ASo
cubes, many of the things we worry about with regard to BSo cubes are gone. you can
just build your dimensions, add member calcs using mDx (multidimensional expres-
sions), load your data, and you are ready to go. no more Dense versus Sparse debates.
no more spreadsheets to evaluate optimal block size. The dimensionality can increase in
ways you never dreamed (depth and breadth). you also can store a much greater volume
of data with ASo. The disk footprint is incredibly smaller, and many times the batch load
and calc times drop so dramatically that it seems like magic. Little did anyone realize that
the simplicity this brought to many cube designs would be a trait as well, which caused
many developers (including myself) to shun it for years. The belief that “it just cannot be
this easy” was pervasive and rampant among my peers. I was not alone.
Erring on the side of caution, I built BSo cube after BSo cube, despite the growing
amount of white papers and conference presentations on how great ASo cubes were.
I would listen to talk after talk on how they could be built faster, loaded faster, aggre-
gated faster, and how you could have dozens of dimensions and millions of members
in a dimension if you wanted it. That was unheard of and I continued to savor my own
skepticism, knowing that some undefined pitfall was lurking nearby that would surely
catch the ASo cube users unaware and I alone would be saved.
The turning point for me was the day I was asked to reduce the amount of disk
space my 80 BSo cubes were taking up. Since these were well built, streamlined, fully
