SAP BW 2.0A ODS Architecture | Business Information Warehouse for SAP (Prima Techs SAP Book Series)

Team-Fly

The ODS architecture in SAP BW 2.0 is quite different from its earlier versions, as shown in Figure 17-1. Now ODS becomes an active component of SAP BW, which completes the concept of a full data warehouse.

click to expand
Figure 17-1: SAP BW 2.0 ODS Architecture Compared to its Earlier Version, BW 1.2B.

In SAP BW 1.2B, ODS is used to store inbound data as a temporary holding area before it is loaded in the InfoCubes. After this, data is simply purged. SAP BW did not provide any services to access data from the ODS except by writing ABAP code to read such tables. From an ODS usability perspective, there is another big problem. The ODS physical table name is system generated and changes whenever transfer structure is activated or InfoSource structure changes.

In SAP BW 1.2B, you have few data load options, as shown in Figure 17-1. You can load directly in ODS, InfoCube, or both in parallel, or load in ODS and then from ODS to the InfoCube. The BEX Analyzer is limited to accessing data from the InfoCubes and not the ODS tables.

Now in SAP BW 2.0, there is one additional data management layer between InfoSources and the InfoCubes. Under new terminology, the earlier version of ODS is called Persistent Staging Area, or PSA, and the new data management layer on top of PSA is called ODS. The third layer, the InfoCubes, remains unchanged.

Persistent Staging Area

The structure of PSA is defined according to InfoSource and the source system and has the key request number, packet number, and record number. Data is stored in transparent database tables in the format of the transfer structure. As with SAP BW 1.2B, you can update PSA and InfoCubes sequentially, in parallel, or to the PSA alone, as shown in Figure 17-1.

ODS Operating Environment

The ODS is an environment to manage all ODS-specific objects in SAP BW 2.0. The ODS tables can be an identical copy of one PSA table for reporting, a consolidation of multiple PSA tables, or a subset of PSA tables. An ODS table, however, can be a consolidation of several ODS tables for cross-functional operational reporting. This feature makes it possible to clean, transform, merge, and sort data and build an ODS table containing document-level details for end-user reporting. These tables then can be drilled through from within an InfoCube if detailed information is desired.

You can access data from ODS from within the BEX Browser or via InfoSet Query, earlier known as SAP Query or ABAP/4 Query. In SAP BW 2.0, you also can build InfoCubes from an ODS table. With this capability, you can build staging tables for InfoCubes that will speed up InfoCube builds.

The philosophy behind an ODS is that it must also provide services to support intra-application data interconnects. In other words, several applications share common data sets for business-critical applications. For example, you have several OLTP applications that need data from an SAP R/3 OLTP instance as well as among themselves. Instead of building individual point-to-point interfaces, it would be much easier if all applications downloaded shareable data in the ODS. There, it is well managed and shared across all applications. It is expected that SAP BW 2.0 will also support such a data sharing data repository, shown as ODS3 in Figure 17-1.

Note

You must keep in mind that SAP BW business content was originally structured for somewhat summary-level analysis. Now that you have ODS functionality, you may want to either enhance existing extracts for finer granularity or build your new data sets for ODS.

Due to lack of ODS functionality in earlier versions, a few customers have built their InfoCubes to document-level detail. It takes a lot of time and resources to maintain such fine-grained InfoCubes. With ODS, you may need to redesign your InfoCubes to keep only summary-level detail in the InfoCube and details in the ODS tables.

With ODS implementation in SAP BW 2.0, you need to rethink your SAP BW modeling philosophy. Earlier, you modeled information primarily from multidimensional InfoCubes view. Now you need to decide what information goes in the InfoCube, ODS, Business Documents, and a data warehouse based on your information usage model.

The following guidelines will help you decide when to use certain data objects in SAP BW 2.0.

Store data in InfoCubes when you need to do
- pure numerical analysis-slicing and dicing
- analysis for fewer than 15 dimensions at a time
Store data in ODS when you
- need to track very detailed information
- need to do long-term historical analysis (building data warehouse objects)
- have textual information (non-key characteristics) descriptive in nature
- need an application integration hub to provide data feeds to other business applications, data marts, or data warehouses
- need to stage and consolidate data from several sources before building information objects in SAP BW-implementing a staging area

The primary goal of a data warehouse is to support business intelligence operations. Do not force-fit one technology to provide all analytical solutions. Model your data analysis needs and carefully select what has to go in an InfoCube and an ODS for Operational Reporting or Enterprise Data Warehouse objects. A combination of the right technologies will best suit end-user needs.

Team-Fly