尤尼佳12_MULTICUBE-OFFICIAL.docVIP

BW Multicube in BW Basic concepts 22. October 2001 Introduction 1 Example Scenario 2 Definition of the Infocube-Union / of the Multicube 5 Characteristics 5 Key figures 6 Building the Multicube 7 Myths of the Join Infocube 8 Query processing with Multicubes 9 Query Pruning 9 Technical breakdown of a query in the Data Manager 9 Appendix A: Parallel vs. Non-Parallel Processing of Multicubes 11 Appendix B: How to join data from two infocubes 11 Introduction Up until now the concept of the BW has been to view the Infocube as the only reporting unit. This means that (a) queries only have access to the data in one Infocube and, conversely (b) the users must store all of the data for current and future queries in a single Infocube. Therefore, the following problem situations exist: There are reporting scenarios, that actually contain several subordinate scenarios (see example below). Many requests are, in effect, concentrated on one of these subordinate scenarios. However, a few requests need answers from two or more sub-scenarios. In order to satisfy such requests, all sub-scenarios must be put together in one, common infocube. Unnatural and / or large modeling, on the one hand and unnecessary processing costs on the other, arise as a result, for requests that are only actually valid for a sub-scenario, whose processing must also support a great deal of irrelevant data from other sub-scenarios. . Point of view (b) points to a challenge in the data concept, namely, to also bear in mind future requirements. Otherwise InfoCubes become unnecessarily overloaded in many cases. Comment: The concept described in this paper up until now is known as a so-called Join-Infocube. However, as we will see below, there is no similarity to a database join, rather, far more to the traditional union operator. Therefore, when talking about a Multicube we are dealing with a Union-Infocube. Example Scenario A typical example of a scenario, that contains several sub-scenarios, can be foun