Hyperion Essbase 184.108.40.206 – Transparent Partition – Using ASO as Partition target – Part 1
Posted by Venkatakrishnan J on March 19, 2009
In the last blog entry we saw how a Transparent partition works. Today we shall go more into detail on what this partition does and how it works on BSO and ASO cubes. To demonstrate this, i would be using a nASO cube as the partition source. Both ASO as well as BSO would be used as partition targets. This would let us understand the differences between ASO and BSO while using them as Transparent Partition targets. Lets start with a Global ASO outline as shown below. This would act as our transparent partition source.
Now, assume that we have 2 partition targets. One in ASO and the other in BSO. As a thumb rule, for partitioning to work, the number of dimensions in the source and the target should match. But the dimensions would typically be a subset of the source partition. The outlines of the target ASO and BSO cubes are provided below.
Lets create a partition on the source ASO cube. There are 4 main steps while creating a transparent partition
1. Assigning a target ASO/BSO database
2. Assigning security
3. Assigning Areas
4. Creating mappings between the source and target.
The first 2 steps are self explanatory. In our first case, we shall use ASO as a target.
Once the security and the target have been assigned, the next step is to define the area. The area definition (basically this defines the slices of the source and target databases) should follow certain rules.
1. Number of cells chosen in the source and the target should match
2. When the source and target dimension members match, just include them in the area definition and there is no need for additional mapping.
3. When the source and target dimension members do not match, mapping editor should be used to map the individual members.
4. If a dimension is not chosen in the area, then the partition inherently assumes that the dimension has a one-to-one match between the source and the target.
In our case, since we have the same dimension member names, we shall map just a single level-0 dimension member combination of the source with the target as shown below.
Since we do not have any Customer dimension mapping, the partition assumes that every member in the source Customer dimension and the target customer dimension match. Now, lets load some data into the source.
And lets try to view the data in the target.
As you see, we are able to query the source from the target. This is straight forward. Now, the next step is to define another area like the one above. This time map the Apr-99 member from the source to the target. The basic reason for doing this is to understand whether the target does a dynamic aggregation based on multiple partition/multiple areas within a partition.
After doing this lets validate the partition and verify the data from excel add-in.
As you see, the target is able to do an aggregation from 2 different areas of the partition dynamically. This is the value add of a transparent partition.
One of the major differences between ASO and BSO transparent partition targets is that, ASO does not support local data. Even if one loads data into the unmapped regions of the partition target, this would not be recognized by the ASO target. To validate this lets load the data in the ASO target for the Month of Jun-99.
After loading this data validate the partition.
As you see, the warning message clearly states that local data is not supported. Even when we query from the excel add-in we would not be getting the local Jun-99 data.
In the next blog entry we shall see how a BSO cube behaves when it is used as transparent partition target. I would also show how a BSO transparent partition target can be used for Custom ASO writebacks.