Agile Data Modeling with SAP BW/4 HANA

Intro

SAP BW means inflexible and expensive monolith? That doesn’t have to be! With SAP BW/4 HANA, the development can be much more iterative than before.

So the following applies(?): SAP BW/4 HANA = leaner, faster … cheaper? It depends on your architecture!

With this post I would like to give you an impression of why SAP BW/4 HANA (finally) enables data models that react flexibly to changes!

Scenario Iteration 1

We want to evaluate orders. The data model is described schematically in the figure below.

SAP BW/4 HANA Data model

Classic approach

In previous SAP BW systems (without HANA), such a data model in SAP BW would have been set up as follows. An InfoObject would have been created for the supplier, product and product group and inserted into the InfoCube. Navigation attributes etc. should have been activated in the Cube & MultiProvider.

Dynamic flexible Star Schema

With HANA and the composite provider, the dynamic flexible star scheme has come. The semantics can be defined independently of the source in the composite provider.

In theory, InfoObjects can be completely dispensed with in the source aDSO. The InfoCube as an aggregate is no longer necessary anyway. The master data is only associated in the composite provider.

aDSO can also be modeled field-based. In the past, InfoObjects also had to be created for simple flags or posting texts although the fields do not contain any further master data (top-down modeling), this is no longer necessary. The reporting can consist of a mixture of fields and InfoObjects associated in the composite provider.

Virtualization of the master data

Another variant would be to replace info objects with OpenODS Views (OOV). In my example there is an OOV for the supplier and the product attributes with the special feature that there is a calculation view between aDSO and OOV. At this point in time, the calculation view has no function other than ensuring the greatest possible flexibility for the future. If hierarchies are required, they must still be modeled with InfoObjects. If the master data is to be kept persistently in SAP BW, this architecture requires aDSO to hold the data. This can be done field-based.

Scenario – Iteration 2 & 3

In the following iterations, the scenario is expanded to include more information about the supplier. The information on the business area and region comes from different sources than the previous master data. How are these iterations mapped in our data model variants?

Iteration 2

Iteration 3

Classic approach

In older SAP BW systems, the InfoObject supplier would have had to be extended to include the attributes. In addition, you have to adapt the cube and MultiProvider. Over time, a large master data object is created that becomes increasingly inflexible to changes.

It is not without reason that SAP BW has a reputation for being inflexible and expensive in terms of changes. Fortunately, we don’t have to work like this anymore.

Dynamic flexible Star Schema, Dimension Satellites & Snowflaking

With the dynamic flexible star schema, the option for dimension satellites has also been introduced. A field of an aDSO can be associated several times in the composite provider.

In the scenario, the information on the business area and region comes from different systems. There is no direct technical connection. It makes sense that the master data is stored in encapsulated satellites. We get three InfoObjects for the supplier.

◉ Supplier: Attribute system 1

◉ Supplier: Business Area

◉ Supplier: Region

Due to the virtual association in the composite provider, the persistent data model for the orders does not have to be adapted. The advantage is that by creating satellites we can create smaller units that can react 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 satellite dimension, the meaningfulness of each should certainly be checked. For example, if the business area is a field from the same source table where the other master data comes from, an extra satellite makes no sense. Criteria for the formation of satellites can be, for example, the volatility of the data model (how often there are changes to data model structures) or the frequency of changes (how often does a satellite have to be loaded). In projects, we have also created satellites when some attributes require a combination of characteristics (e.g. compounded info objects to company code) and other attributes do not. By dividing it over two satellites, sums can be formed for suitable attributes in reports without the need for a bracketed field, as was the case in classic SAP BW models.

The set of dimension satellites logically represent business entities / objects. In our example, several InfoObjects form the business entity Supplier. This can pose challenges to the transparency of the data model if more objects have to be considered in the composite provider. If you want to model the master data using InfoObjects, a possible solution would be to create a so-called “Link” InfoObject. The respective InfoObjects are inserted as attributes in a central InfoObject supplier. The attributes of the “linked” InfoObjects can be activated as transitive attributes in the composite provider. The gain in transparency is bought with a little less flexibility. This means that transitive attributes of the linked InfoObjects can no longer be accessed. In addition, an additional join is carried out, which is likely to have performance disadvantages, especially with very large models.

Virtualization of the master data

The virtual type of master data modeling is particularly valuable when there are changes. If the modeling seems oversized in the case of only one master data table, the approach now shows its strengths.

The calculation view below the OOV can be flexibly expanded to include additional satellites that have been modeled as aDSO. In this case, the virtual OOV represents the supplier business entity. You have both: A very high degree of flexibility through virtualization and, at the same time, 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 further scaled as required. Our analyzes show that even large scenarios work well.

Possible next iterations

Further conceivable extensions of the data model can also be in additional transaction data such as planning data for the orders placed. Here, too, SAP BW / 4 HANA is flexible. In the simple case of planning data, a composite provider can very well form a uniform picture for reporting via unions or simple joins. If it becomes more complex and you still want to do without persistence, calculation views are also ideal here for mapping complex facts.