Before closing this chapter, let's briefly discuss two other InfoCube design techniques:
7.5.1 Compound Attributes
Compounding entities is an idea that BW borrows from R/3 to model coexistent entities. Compound attributes requires overhead, so you should not use them unless absolutely necessary.
Screen 7.38 shows that 0CO_AREA is a compound attribute of 0COSTCENTER as defined in Business Content.
Sometimes the meaning of master data depends on the source of the data. In these cases, we need to compound the characteristic with the InfoObject 0SOURSYSTEM (Source system ID).
For example, suppose a characteristic IO_HOUSE has an entry called White House. The characteristic could mean the home of the U.S. President if it comes from a government source system, or it could mean a house painted white if it comes from a home improvement Web site. To handle cases such as this one, we need to compound IO_HOUSE with 0SOURCESYSTEM to clarify the meaning of the characteristic.
The 0SOURSYSTEM InfoObject is provided with Business Content.
7.5.2 Line Item Dimensions
If a dimension has only one characteristic, we can make the dimension become a line item dimension. Consider the following example. For the InfoCube described in Chapter 2, we can create another dimension called Dim: sales transaction, and check the option Line Item as shown in Screen 7.39.
After checking and activating the InfoCube, Screen 7.40 reveals that the fact table has no dimension table created for the line item dimension. The key in the fact table is the SID of the SID table. Thus the fact table links to the master data, text, and hierarchy tables with the SID table, and one middle layer for the dimension table is removed. This design improves system performance.
The line item dimension derives its name from the need for detailed information reporting at the line item level. In Chapter 9, Operational Data Store (ODS), we will discuss another technique that allows us to build a multilayer structure for different levels of detail information reporting.
The level of detail found in a data warehouse is called its granularity. It is determined by business requirements and technology capabilities.
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