Database Reference
In-Depth Information
learn and stretch your skills and start utilizing the full oLAP platform and both storage
kernels available to you. having options and knowing you have options is a key turning
point in your education.
5.2 when shoulD i not try to use aso CuBes?
While ASo cubes have really come a long way since the initial release in version 7 and
are definitely a great tool in the Essbase arsenal, there are still some times when you
may want to stick with the traditional BSo cube for your ultimate solution. In my opin-
ion, there are two significant differentiators that have to be fully considered, and then
a number of more minor ones. The single most important differentiator is write-back,
followed closely by calculations and calc functions. Although an ASo cube can facilitate
write-back now (it could not in the version 7 release), it is still only available at level-0 of
the dimensional hierarchy. There are many instances where I may have design reasons
to create an application where I am writing back to an intersection that is not at level-0
of every dimension. That is a design decision, and if I decide that is indeed what I want
or need to do, then a BSo cube is still my storage option and design choice. In view
of the fact that ASo cubes allow for an increased breadth of dimensionality (more
dimensions), as well as a greater depth of dimensionality (more children members),
writing back to level-0 of all dimensions can get very complex indeed.
Another thing to consider is the calculations or prebuilt calc functions that I want
to use in my cubes. I do not endorse the attitude to always use BSo cubes if you have
any complex calculations. I did this originally and now believe it was a mistake. mDx
as a calculation language is very robust. While the learning curve is often very steep
for “old school” Essbase developers, if you work with people who are good with mDx,
you will soon realize that you can do some very complex calculation sequences in
Essbase. I believe the more appropriate consideration is whether you want to use some
prebuilt functionality provided within Essbase. A secondary consideration is whether
this functionality can readily and accurately be reproduced in mDx. Sometimes, we do
things because we can, not because it is the correct or most appropriate choice for the
circumstance at hand. Why would I want to spend 200 hours coding a function in an
ASo cube using mDx and creating a maintenance headache for the cube administra-
tor, when I can just use a prebuilt function in a BSo cube to do the same thing? If there
is nothing else preventing me from using a BSo cube, then the answer would be that I
would not want to do that. I should take the path that will provide the greatest amount
of flexibility with the least amount of ongoing maintenance.
to help in this decision point, review the calculation functions you are using in the
Essbase Technical Reference
. There is a lot built into a function like @ALLoCAtE or @
mDALLoCAtE, two of the common functions used to determine where to push/split an
expense in the hierarchy based on business rules. to rebuild an mDx sequence to accom-
plish what these functions automatically do for you would be laborious at best. Admittedly,
financial applications are the single most affected group of applications when you start
looking at calculations. With functions like @Irr (calculates the internal rate of return on
cash flow) and @DECLInE (calculates the depreciation of a member over time), you can
only imagine the amount of mDx code that would have to be built to mimic what these
calculations do out of the box with no coding. If any of these calculation functions are
something you need to utilize in your cube design, and there is not an acceptable (or easily
developed) mDx replacement, then you may want to stick with the BSo cube option.
