Database Reference
In-Depth Information
cube. Calculation Scripts were often created to just aggregate the cube in a specific order.
This will no longer be necessary with an ASo cube. Instead, you will have Solve orders
defined in the outline. The same statement can be made for scripts that were designed and
used to perform back-calcs (calculations completed after aggregation in order to derive
the correct mathematical answer). For any process that remains in the script, I would
attempt to map them to member formulas, creating new members and formulas where
appropriate. There are a large number of developers who put every single calculation they
used in a BSo cube in the Calculation Script. They did not even attempt to create member
formulas even when it was appropriate. Their rationale for using this method of coding
was that they could better control the calculation outcome if it was in a script. For the few
remaining complex tasks, like allocations, you may find the need to create one of the new
Custom Calculations we discussed earlier in this section. read up and carefully study the
constraints in the DBAg before attempting to create a Custom Calculation. you may find
you suddenly have the desire to make a member calculation (or some other process) work.
The conversion process from a BSo cube to an ASo cube is now essentially complete.
(Well done. now, load data and play with some of the advanced concepts from Chapter
7 by Dan Pressman.) There will still be a few miscellaneous tasks you will have to finish
to prepare the cube for use:
• Set up security filters.
• update provisioning of existing groups to point to the new cube.
• Shut down the old cube if you do not want it to be used (by deleting it or by
removing provisioning; renaming it is not enough).
• update batch processing scripts; many maxL commands have an ASo version
that will need to be used.
• update user information or training guides if hierarchy structures were changed
significantly.
• update partitioning scripts (if applicable).
All in all, converting a cube from one kernel storage type to another is not such a ter-
rible process, is it? This is a one-way metamorphosis. you can convert BSo to ASo, but
you cannot convert ASo to BSo. That being said, if you think you might want to revert
back to your old BSo cube at some point, you will want to archive of the contents of the
database file prior to deleting the BSo application from the Essbase system.
5.4 what aBout reporting CuBes?
In the discussion that was just completed regarding the converting of a BSo cube to an
ASo cube, the situation was straightforward. I want to make the conversion and then
get rid of the BSo cube completely. There are situations that arise, however, where this
is not the case. Sometimes, a mechanism to allow faster reporting is what is needed.
nothing is being replaced or deleted. Some sample scenarios might include:
• An ASo calculation is too costly for large scale ad hoc reporting; to speed things
up, a temporary BSo cube is used to calculate the data and then the result is
extracted and loaded into an ASo reporting cube.
• A specified BSo cube is too slow for widespread ad hoc reporting because the
cube is optimized for complex calculations; as with the first scenario, to speed
things up, calculated data is extracted and loaded into an ASo reporting cube.
