Challenges with classic SAP BW
In a classic SAP BW system, several objects are needed for an ETL run, and these are often defined through different aggregation levels. As soon as a report is changed – for example, by the addition of a new field or the extension of an analysis model – several objects must be modified and transported. Consequently, performing ETL runs fast is practically impossible.
Another limitation is the scope of InfoObjects: In classic systems, central InfoObjects such as “material” or “customer” have numerous other InfoObjects as display or navigation attributes. Often, there’s a multilayered system of correlations and dependencies. Accordingly, the underlying DataSources, InfoProviders, and Transformations are highly complex. A modular approach to modeling could significantly reduce these complexities, and result in a more flexible and clearer system.
Increasing efficiency with SAP BW on Hana
SAP BW on Hana takes precisely this approach. When modeling an ETL run, there are fewer objects than with the classic system – so, overall, you can develop and maintain your Business Warehouse faster. Apart from the fewer objects, BW on Hana brings with it Open ODS views and CompositeProviders as a new modeling option. In the following three sections, I’ll explore the use of transitive attributes, satellites, and joins with CompositeProviders.
In a classic SAP BW system, InfoProviders can have navigation attributes that are directly available in reporting. With BW on Hana, it’s possible to access navigation attributes directly from navigation attributes – known as transitive attributes – something that was only possible using additional ETL runs in the classic system. This approach makes modeling possible with a snowflake schema, where the granularity is determined through the transformation tables.
InfoProviders can be streamlined by distributing navigation attributes across several levels. What’s more, redundant information can be avoided in the system.
Within the context of BW on Hana, satellites represent the splitting of InfoObjects. By using CompositeProviders, a source field of an advanced DataStore Object can be assigned to several InfoObjects. In this way, an InfoObject’s attributes can be modeled (for example, a machine’s attributes can be grouped into functional and technical attributes) and assigned to various business areas.
This approach makes InfoObjects less complex and makes it easier to add entire company fields. Furthermore, the authorization concept becomes much simpler, because business departments can only access the object information that is relevant to them.
Join with CompositeProviders
The classic MultiProvider in an SAP BW system unites the data from InfoProviders via a union operator. With the introduction of the CompositeProvider, SAP BW on Hana enables a more complex connection between the individual InfoProviders via a join operator, with the choice between an inner join and a left outer join. InfoObjects are given as the condition for the join. In turn, the attributes of a joined object can serve as the basis for another join.
Thanks to this extended logic, complex company-specific requirements can be implemented more agilely and easily, because additional information and objects can be read when reports are run.
With the introduction of new objects and the removal of old objects, SAP BW on Hana presents new opportunities for modeling data. The complexity of existing ETL runs can be split using satellites and joins with CompositeProviders, reducing redundancies in the system and facilitating modularization in general. As a result, new requirements and models are implemented faster and the system becomes altogether clearer. These modeling tools reveal the whole power of BW on Hana – which isn’t just characterized by a faster database.