Skip to Content

In an Enterprise Data Warehousing context, InfoObjects often play an arbitrary double role: they are used for modeling the Data Warehouse Layer and multi-dimensional modeling the Reporting Layer. I advise segregation of duties by introducing a dedicated, independent set of InfoObjects: Data Warehouse InfoObjects.

Part 1 of this blog series provides a conceptual overview. In Introducing Data Warehouse InfoObjects – Part 2: Technical Details we will focus on the ABAP Data Dictionary as a great help in generating the Data Warehouse InfoObjects.

Different InfoObjects for Different Purposes

I see in many SAP NetWeaver BW implementations that only a single set of InfoObjects is used. In my opinion, those InfoObjects often play an arbitrary double role.

First of all, they act as Reporting InfoObjects, i.e. characteristics (conformed dimensions) and key figures in the context of architected data marts and multi-dimensional data modeling. The characteristics often have navigational attributes, display attributes and texts. They might have compounding relations with superior characteristics. In some cases they can have hierarchies.

Secondly, they act as Data Warehouse InfoObjects and are used to build up the Data Warehouse Layer. Here the InfoObjects are merely necessary as data elements to model DataStore Objects (DSOs) in the Data Warehouse Layer.

In practice it’s quite a challenge or even a mission impossible to meet all requirements with a single set of InfoObjects because of the different objectives. Reporting InfoObjects are business requirement driven, based on the information needs of the business users. Data Warehouse InfoObjects are source system driven, based on what can be extracted and where it’s never 100% crystal clear how all data elements and the underlying data model of the source system’s applications have to be interpreted. The high number of data elements is an additional complicating factor.

InfoObjects in an LSA Context

One of the key aspects of SAP BW Layered, Scalable Architecture (LSA), SAP’s best practice in the area  of Enterprise Data Warehousing (EDW), is decoupling the Data Warehouse  Layer from the Data Mart Layer.

Figure 1: LSA Layers (Source: SAP)

Figure 1: LSA Layers (Source: SAP AG)

By  definition, the Data Warehouse Layer should be populated as complete,  generic and unflavored as possible, in order to be able to not only  fulfill the current requirements (the “known”), but also the future  requirements (the “unknown”). It should also support the “extract once,  deploy many” philosophy: the data is extracted and persistently stored  only once and reused by various data marts and BI applications.

Figure 2: Iceberg of Requirements (Source: SAP)

Figure 2: Iceberg of Requirements (Source: SAP AG)

Please refer to the following blogs of Jürgen Haupt for more information on LSA:

You can also refer to SAP Help for more details on the Data Warehouse Concept.

InfoObjects  play an important role in general but in the context of creating your  Data Warehouse Layer, it’s obvious that some practical problems pop up:

  • The number of InfoObjects to be created is usually high;
  • It’s hardly impossible or at least arbitrary to define what is the “best data model”;
  • You want to prevent duplicate creation of the same data elements;
  • The impact of inappropriate design in the Data Warehouse Layer can be high and costly.

Generating Data Warehouse InfoObjects

The need for standardization and automation in this area becomes clear. A way to proceed is a bottom-up approach for creating the InfoObjects to model the Data Warehouse Layer. The data model of the SAP source system is the starting point. An analysis is done using the ABAP Data Dictionary tables and can output a comprehensive list with the technical ingredients of all InfoObjects to be created.

Another aspect of the approach is to work as atomic as possible. This means that all overhead like compounding and master data has to be eliminated. The Data Warehouse InfoObjects are neutral and elementary, they are solely used as data elements to model DSOs in the Data Warehouse Layer.

As we will focus on the process of creating the InfoObjects, you will have to be aware that some dependencies between steps can be applicable. That’s why the following sequence is suggested:

  1. Create Basic Characteristic InfoObjects *);
  2. Create Referenced Characteristic InfoObjects;
  3. Create Unit InfoObjects;
  4. Create Key Figure InfoObjects

The Basic InfoObjects are based on the domains in the ABAP Dictionary of the SAP source system and contain all technical metadata. One can think of data type and length.

The Referenced InfoObjects are created with reference to the Basic InfoObjects. They relate to the data elements in the ABAP Dictionary of the SAP source system and act as the semantical representation of the metadata. One can think of a long and a short description.

*) Please note that one should reference the Business Content Time characteristics (e.g. 0DATE), Units (e.g. 0UNIT and 0CURRENCY) and Technical Content (e.g. 0TCTREQUID) rather than creating your own Basic InfoObjects.

Conclusion

In this blog I shared my point of view on having a single set of InfoObjects for different purposes. The Reporting InfoObjects play a role in multi-dimensional modeling of the architected data marts. These InfoObjects might not be the perfect match for the data elements needed to build up the Data Warehouse Layer. Therefore, I suggest to introduce a dedicated, independent set of InfoObjects: Data Warehouse InfoObjects. These InfoObjects have to be neutral and elementary, without any overhead and complexity of master data and compounding.

In Introducing Data Warehouse InfoObjects – Part 2: Technical Details I will present the technical details behind this approach. It shows how the ABAP Data Dictionary offers a great help in determining the appropriate metadata. With these ingredients you can create the Data Warehouse InfoObjects.

Last but not least, I created an ABAP program to generate Data Warehouse InfoObjects for SAP source systems’ DataSources. Please refer to my blog Generating Data Warehouse InfoObjects – Part 1: Introduction for more details.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply