In this section, we discuss yet another design alternative. This time, we will create a new IO_SREP, called IO_SREPN2. We will treat IO_SREG and IO_SOFF as independent characteristics, just like IO_SREPN2, and put them all together in the same dimension. Figure 7.3 shows a simplified star schema for this design.
Figure 7.3. BW STAR SCHEMA OF ALTERNATIVE II INFOCUBE DESIGN
In Figure 7.3, /BIC/SIO_SREG and /BIC/SIO_SOFF have their own master data table and text table. These tables are not shown in the figure.
This design methodology is known as the Dimension Characteristics method. The following steps explain how to build this new design.
Step 1. Repeat the Steps in Section 2.3 to create IO_SREPN2. It has no hierarchies.
Step 2. Create an InfoCube and include IO_SREG and IO_SOFF as characteristics.
Step 3. Assign IO_SREG, IO_SOFF, and IO_SREPN2 to the same dimension as shown in this screen. (See Screen 2.27 for the difference.)
Click to check the new InfoCube. If it is valid, click to activate the new InfoCube.
Step 4. We also need to include IO_SREG and IO_SOFF in the communication structure. (See Screen 3.52 for the difference.)
Step 5. Load data into the new InfoCube and create a query.
In the left panel, we see the three characteristics Sales office, Sales region, and Sales representative. They are all in the same dimension.
Step 6. As before, we specify 31.12.9999 as the key date, and run the query.
Screen 7.28 shows the query result. The Denver office is listed under the Midwest region, instead of the West region, although we specified 31.12.9999 as the key date. This result arises because the sales transactions conducted by the Denver office all took place before January 1, 2000 (see Table 1.4). In the data warehousing world, this query result is referred to as a yesterday-or-today scenario – the data were valid when they were generated.
In a yesterday-and-today scenario, the data that were valid yesterday and today are displayed. In our example, we would not see the Denver office data in a yesterday-and-today scenario. For further information on this scenario, refer to ASAP for BW Accelerator, "Multi-Dimensional Modeling with BW."
Now we know that our new InfoCube design does not provide the two views of data that we saw earlier with the time-dependent hierarchy structure and time-dependent navigational attributes – namely, the today-is-yesterday scenario and the yesterday-is-today scenario.
From a performance point of view, this design improves upon the two earlier options, because it places IO_SREG and IO_SOFF closer to the fact table.
Performance is, of course, one of the major concerns in data warehousing. Here are some guidelines for dealing with this issue:
When considering the dimension in which a characteristic should be placed, follow these two guidelines:
Another advantage of this InfoCube design is that we can create aggregates on IO_SREG and IO_SOFF. As in Alternative I, however, the levels of the sales organization are fixed in Alternative II.
Part I. Guided Tours
Business Scenario and SAP BW
Creating an InfoCube
Loading Data into the InfoCube
Checking Data Quality
Creating Queries and Workbooks
Managing User Authorization
Part II. Advanced Topics
Aggregates and Multi-Cubes
Operational Data Store (ODS)
Generic R/3 Data Extraction
Appendix A. BW Implementation Methodology
Appendix B. SAP Basis Overview
Appendix C. Glossary
Appendix D. Bibliography