Skip to Content
Business Trends

How SAP BW/4HANA Revolutionizes the BW Modeling You Know

For almost 20 years, every SAP Business Warehouse (SAP BW) project started with defining tens or hundreds of InfoObjects. This task was not only time consuming, but it also laid the foundation of your overall data model—for years!

SAP began to introduce new modeling objects with SAP BW 7.4 back in 2013. The newer releases of SAP BW 7.5 and especially SAP BW/4HANA added more and more functionality over time. However, most customers and consultants just looked at the new features and functions, and forgot to recognize the impact on business warehouse (BW) modeling in general. The effect is tremendous as the SAP BW modeling was silently revolutionized.

New Objects and Features

It all starts with the new SAP BW objects: CompositeProvider, Open ODS View, and DataStore Object (advanced). They were introduced with a purpose, not just to replace »classic« objects and to overcome their deficiencies. Most blogs and documents only talk about simplification with SAP BW/4HANA, cutting down from ten to four modeling objects. That is only half the truth and sounds more like taking away options.

Adding long missing flexibility to SAP BW data models is essential and enabling agile data warehousing capabilities was also long overdue. Field-based modeling and virtualization are key features in this context. Field-based models avoid creating the hundreds of InfoObjects before you can do anything valuable for a pilot or prototype data model. It is also a big plus if the data can be accessed directly without having to load it to the system first. Moreover, you can add native SAP HANA SQL-artefacts like calculation views to enable mixed modeling without having to move multiple copies of your data. The icing on the cake comes with optimized data tiering across hot, warm, and cold data stores all within one DataStore Object (advanced) based on partition level.

General Modeling Strategies

Virtual data modeling is one of the newer concepts introduced by SAP HANA virtual tables linking to data outside the system. It avoids persistent data storage and only reads the data when a query runs against that virtual table for instance using an Open ODS View or a CompositeProvider. This does not make persistent storage of data within SAP BW obsolete—it adds another dimension when modeling new scenarios.

For years, the traditional modeling followed a strict top-down approach, where those countless InfoObjects had to be created first before doing anything else. Now, the option to model based on fields allows bottom-up modeling. Fields and InfoObjects can also be mixed. This way you can have models very close to the structure of your source data and can analyze it without further processing. This raw data layer was previously the PSA and could not be queried directly.

As mentioned before, you can still plug-in InfoObjects for master data features to help building more robust models or use InfoObject associations within CompositeProviders and Open ODS Views to inherit InfoObject features in queries (wherever this makes sense). However, this gained flexibility could come with costs. If all models are virtualized and field based, this could potentially mean many joins and on-the-fly data access. The cost for this could be performance depending on the overall complexity, number of layers, and many other influencing factors.

Modeling Approaches

Plenty of books and articles have been written on data modeling in a data warehouse context. It started mainly with two approaches: dimensional data modeling and normalized data in third normal form (3NF). More recently data vault became a popular concept too. The superiority question is an academic discussion, as each method has its sweet spots and personal preferences differ.

SAP BW/4HANA now enhances the traditional dimensional modeling of SAP BW. The aforementioned features allow you to create more flexible models using concepts from data vault like the modeling of highly volatile master data now also in an SAP BW system. You can also build agile scenarios by using a direct connection to a source system with Smart Data Access and build virtual layers on top of that. Alternatively, you can replicate the data and persist it. In both cases, you very often get the data in 3NF. You can now mix those into hybrid models that fit your requirements and SLAs. (You can find more information about this in, LSA++ and BW on HANA Dynamic Dimensional Modeling.

Data Acquisition and Connectivity

The previous example of real-time access or replication brings data in a normalized format into the system as most OLTP systems are built on data models close to 3NF. On the other hand, traditional business warehouse extractors for SAP systems deliver data in a dimensional format. Hence, the data acquisition type and the data source itself often determine the lower layer(s) of your data model architecture. If you then start to harmonize and consolidate data across a heterogenous source system landscape, you can use the SAP BW/4HANA modeling capabilities to handle this with minimum persistency.

One popular feature is the usage of native SAP HANA views to replace complex transformations. Often hundreds of code lines in SAP BW can be replaced by a few SAP HANA views, which not only simplifies the overall data model, but also the maintenance aspect of your data model.

Connectivity was always a weak spot for SAP BW. The introduction of HANA Smart Data Integration (SDI) with SAP BW 7.5 on SAP HANA dramatically enhanced the connectivity of SAP BW to pretty much any source system out there. This includes open source data lakes like Hadoop and Spark. All with traditional batch load jobs but also direct access capabilities or real-time replication, depending on the source system.


This is where it all comes together. The business requirements and service level agreements have a large impact on every data model. For example, the expected response times, global vs. divisional view, real-time vs. batch delivery, and so on, all have an influence on your data model. On top of that there are additional functional and non-functional requirements as well as internal governance rules and sometimes even external regulations the final data model must meet.


Balancing the diverse requirements is not an easy task. However, SAP BW/4HANA enables much more flexibility than SAP BW modelers ever dreamed of. It also helps greatly reduce operating costs since change requests can be handled much easier through fewer persistent layers. There’s not a single killer feature, but the innovations delivered over the past years in SAP BW powered by SAP HANA and SAP BW/4HANA together provide a toolset for a modern data platform that can handle today’s and tomorrow’s business requirements.

You must be Logged on to comment or reply to a post.
  • Fantastic article!

    What is a good example of replacing complex transformations with native HANA views?

    Were you referring to the merging of data from multiple data sources?

    • There are so many use cases where you could use mixed modeling. One replacement example is a case where the customer has a very complex currency conversion. Using the classic BW transformations with ABAP they had to persist the data multiple times in DSO's and it took some time to load the data. They were able to replace the 1000 lines of code with calculation views and no additional persistence. Now it is much easier to maintain and on top of that the calculation is done on the fly whenever the query runs, so real-time.
      Joining data could be another example. This is often easier in calculation views as with BW objects.
      Swisscom is using mixed modeling extensively:
      There was a very good session at TechEd 2016 about the topic:

      Best regards

  • We have been building new models with both Fields and InfoObjects. I like the concept of field based modeling and it does save a lot of time. This works great when the field contains text and not a code. If my source system is ECC which populates fields with codes how do I use field based modeling for this?

    • Field-based modeling also works with key fields like customer or material number. Just map the source field from your ECC to a field in the DataSource. However, if you have InfoObjects for that characteristic already in place I would use them. It always makes sense where ever you have characteristic master data with attributes, texts, hierarchies, etc. to use that BW functionality.
      The tricky part of using fields could be the data types, as not all HANA or source system data types are compatible with the ones in ABAP (see SAP note 2185212 for more info).

      For further information I would recommend the following section in the SAP Help:
      which also contains links to two very good SAP notes on the topic with ADSO's and CompositeProviders.
      Another good document regarding modeling including fields is this:

      Best regards

  • Hi KP,
    I know that I can assign a key to a field. This is very straight forward. The issue is getting text description of the key.
    The scenario is this. I create a classification data source in ECC with 40 fields. 30 of the fields contain keys. I can easily create an ADSO using the Data Source as a template and load the data to it. Again this is very easy to do and can be done quickly. The issue is that I have 30 columns that are not very usable because nobody knows that Field X with a value of "R' equals Rail. Historically I would have created an Infoobject for Field X that had text associated with it I know that I can associate an Infoobject or an open ODS in a Composite provider to get the text. This works great, but it means creating another object. What would be great is if there was an option to have a text table automatically generated for a field. Basically create an Infoobject with Text in the back ground that is associated with the field.


    • Hi Rich,
      such a feature is not available and also not planned. You could either use the InfoObject you already have or alternativley use an Open ODS View of type Text. Both ways you need an additional object.
      However, you could use the idea place to submit your idea:
      Best regards

  • I was reading so many blogs since morning on SAP on HANA and how we can leverage HANA feature. Finally, I got something to take on. Very Informative and thanks, Klaus-Peter Sauer for the Blog. I wanted to know what feature we can use if any customer has SAP on HANA.

    • Hi Subrato,

      there are many features which you could use. It really depends on the customer requirements. However, field based modeling is certainly something to look at with SAP BW/4HANA. The date hierarchy and transitive attributes might be other interesting features as well as the data tiering for larger systems.

      Best regards

  • Hi Klaus. Excellent article.
    I'm and old school BW consultant (started on 1.2B...) but really newbie on BW/4HANA.
    And, obviously, resistent to all of this changes. 🙂
    You know if the features of old "data flow" that associates fields to infoobjects (in an inforsource for example) is lost in BW4?
    Thanks in advance and best regards.

  • Hi Braulio,
    not sure what you mean with "old data flow". I guess 3.x data sources with transfer and update rules. These 3.x objects are no longer supported in SAP BW/4HANA.
    Best regards