Does SAP BW mean an inflexible, sluggish, and expensive monolith? Not necessarily! With SAP BW/4HANA, data warehouse development can be much more iterative than before.
So does this mean that SAP BW/4 HANA = leaner, faster...cheaper? It depends on your architecture! In this article, we want to give you an impression of why SAP BW/4 HANA (finally) enables data models that respond flexibly to changes!
Further information
Read here our blog article on the topic of "Agile Data Warehousing with SAP BW/4HANA."
Our scenario: Iteration 1
We would like to evaluate orders. The data model is described schematically in the figure below.
Data model: Iteration 1
Mapping options with SAP BW/4HANA
Classic SAP BW data modeling
In previous SAP BW systems (without HANA), such a data model would have been mapped in SAP BW as follows. An InfoObject would have been created for the supplier, products, and product group and inserted into the InfoCube. Navigation attributes, etc., would have had to be activated in the Cube & MultiProvider.
Dynamic flexible star schema
HANA and the Composite Provider have introduced the dynamic flexible star schema. Semantics can be defined independently of the source in the Composite Provider.
In the source aDSO, InfoObjects can theoretically be dispensed with entirely. The InfoCube as an aggregate is no longer necessary anyway. The master data is only associated in the composite provider.
aDSOs can also be modeled based on fields. In the past, InfoObjects also had to be created for simple flags or posting texts, even though the fields did not contain any additional master data (top-down modeling). This is no longer necessary. Reporting can consist of a mixture of fields and InfoObjects associated in the composite provider.
Virtualization of master data
Another option would be to replace InfoObjects with OpenODS Views (OOV). In our example, there are OOVs for the supplier and the product attributes, with the special feature that there is a calculation view between aDSO and OOV. At this point, the calculation view has no function other than to ensure maximum flexibility for the future. If hierarchies are required, they must continue to be modeled with InfoObjects. If the master data is to be stored persistently in SAP BW, this architecture requires aDSO to hold the data. This can be done on a field-by-field basis.
Our scenario: Iterations 2 and 3
In the following iterations, our scenario is expanded to include additional information about the supplier. The information about the industry and region comes from sources other than the previous master data. How are these iterations mapped in our data model variants?
Data model: Iteration 2
Data model: Iteration 3
Classic SAP BW data modeling
In older SAP BW systems, the InfoObject Supplier would have had to be extended to include the attributes. In addition, the cube and MultiProvider would have had to be adapted. Over time, this would have created a large master data object that would have become increasingly inflexible to changes.
It is not without reason that SAP BW has a reputation for being inflexible and expensive when it comes to changes. Fortunately, we no longer have to work that way.
Dynamic flexible star schema, dimension satellites, and snowflaking
The dynamic flexible star schema also introduces the possibility of dimension satellites. A field in an aDSO can be associated multiple times in the composite provider.
In our scenario, the information on industry and region comes from different systems. There is no direct technical connection. It makes sense to store the master data in encapsulated satellites. We receive three InfoObjects for the supplier
- Supplier: Attribute System 1
- Supplier: Industry
- Supplier: Region
Thanks to virtual association in the composite provider, the persistent data model for orders does not need to be adapted. The advantage is that we can create smaller units by forming satellites, which can respond more flexibly to future changes. Snowflaking or transitive attributes also make it possible to include the product group as an additional field in the composite provider. It behaves like a separate original field. Navigation attributes of the product group can be used.
When creating the Satellites dimension, it is certainly advisable to check whether it makes sense to do so. If, for example, the industry is a field from the same source table from which the other master data also originates, an extra satellite does not make sense. Criteria for creating satellites can include, for example, the volatility of the data model (how often changes are made to data model structures) or the frequency of changes (how often a satellite needs to be loaded). In projects, we have also created satellites when some attributes required feature grouping (e.g., company code) and others did not. By dividing them into two satellites, totals can be formed for suitable attributes in reports without the need for a grouped field, as was the case in classic SAP BW models.
The set of dimension satellites logically maps business entities/objects. In our example, several InfoObjects represent the business entity Supplier. This can pose challenges for the transparency of the data model if more objects need to be considered in Composite Provider. If you want to model the master data using InfoObjects, one possible solution would be to create a so-called "link" InfoObject. Here, the respective InfoObjects are inserted as attributes into a central InfoObject Supplier. In the composite provider, the attributes of the "linked" InfoObjects can be activated as transitive attributes. However, the gain in transparency comes at the cost of slightly less flexibility. Transitive attributes of the linked InfoObjects can no longer be accessed. In addition, an additional join is executed, which is likely to result in performance disadvantages, especially in very large models.
Explain the option for "Link IOBJ" where multiple satellite IOBJs are combined into one IOBJ.
Virtualization of master data
The virtual nature of master data modeling is particularly valuable when changes occur. While modeling may seem oversized in the case of a single master data table, this approach now demonstrates its strengths.
The calculation view below the OOV can be flexibly expanded to include additional satellites that have been modeled as aDSOs. In this case, the virtual OOV represents the business entity "supplier." This provides both a high degree of flexibility through virtualization and a high level of transparency through a central business object. Constructs such as snowflaking, etc., can also be flexibly mapped using virtual joins in the calculation view. The data model could be scaled further as desired. Our analyses show that even large scenarios function with high performance.
Possible further iterations
Further conceivable extensions to the data model may also lie in additional transaction data, such as planning data for orders placed. Here too, SAP BW/4 HANA proves to be flexible. In the simple case of planning data, a composite provider can easily create a uniform picture for reporting via unions or simple joins. If things get more complex and you still want to avoid persistence, calculation views are also ideal for mapping complex situations.
Summary
We hope that these fairly simple examples have made it clear how much SAP BW/4 HANA is changing data modeling. New, much more flexible data models and process models for development are now possible. Virtualized data models in particular are ideal for implementing an agile and iterative approach to developing the SAP BW-based data warehouse.
We have formulated four principles that we believe are crucial for agile SAP BW modeling:
- Field-based first, decoupling persistence and semantics
- Avoid unnecessary redundancies, virtualization first
- IOBJ only when necessary
- Model satellites where possible
Should all data models now only be virtualized? Are InfoObjects (largely) superfluous? There is no generic recommendation for modeling that applies in all cases. The virtualization of master data models or transformation logic offers a very high degree of flexibility. However, if only SAP S/4 HANA Finance data is evaluated, this is usually not necessary at all. Data modeling relies on stable structures that hardly change. In addition, Business Content provides master data models that can be used immediately. At the same time, it may be absolutely necessary to set up a highly virtualized data model for other sources in the same SAP BW system.
How do you achieve such a flexible system? Can your system be "migrated"? Perhaps our process model for Road-2-BW/4 HANA.
Christopher Kampmann
Head of Business Unit
Data & Analytics
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
