Database Reference
In-Depth Information
With the exception of replicated Partitions, you can now use partitioning in all
directions between ASo and BSo cubes. This greatly enhances solution possibilities
for ASo cubes. It is imperative to remember that partitioning combinations with ASo
cubes do not always work exactly the same as when you use BSo cubes.
The following is an example of behavior I have tested and verified myself. how this
works surprised me a bit because, technically, I could not explain why.
• BSo cube A = Actuals Data.
• BSo cube B = Budget Data.
• I create a transparent partition from BSo cube B (Source) to BSo cube A
(target) based on the Scenario of Budget; the partition is created with no errors
or warnings.
When I query the BSo cube A I can see both Actuals and Budget Data. This is the
expected result. now I change the Scenario:
• ASo cube A = Actuals Data.
• ASo cube B = Budget Data.
• I create a transparent partition from ASo cube B (Source) to ASo cube A (target)
based on the Scenario of Budget; the partition is created with the warning “The
Essbase cube has data, which will not be considered during query time.”
When I query the ASo cube A, I can only see Budget Data-Actuals Data returns all
#mISSIng. This is not an expected result because there is not an overlap of the partition.
I have to assume this is not a bug because I was given a warning message that accurately
anticipated what would happen if I proceeded with the partition. none of the data in
the ASo cube A can be queried. It is as if it is not there. So, I change the Scenario again:
• ASo cube P = Empty Partition cube—no Data.
• ASo cube A = Actuals Data.
• ASo cube B = Budget Data.
• I create a transparent partition from ASo cube B (Source) to ASo cube P
(target) based on the Scenario of Budget; the partition is created with no errors
or warnings.
• I create a transparent partition from ASo cube A (Source) to ASo cube P
(target) based on the Scenario of Actual; the partition is created with no errors
or warnings.
When I query the ASo cube P, I can see both Actual and Budget Data. This is the
expected result. The lesson learned from this is that ASo cubes cannot act as a target
and
provide data as a Source. When made a target, the ability to provide data in a
query is invalidated. Effectively, this means that ASo target cubes should always be
empty. They should never have data in them. If they do have data, it will not be able
to be queried once the partition is created making it a target. Although this behavior
is not the same as that of a BSo cube, it is easy enough to work around once you
understand it.
If partitioning is something you have never considered in your designs, it should be.
I have not built a BI solution in the past 10 years that did not invoke partitioning. Some
of my counterparts may scoff at that statement, but when utilized correctly, transparent
