2.3    The New Data Model and the SAP HANA Database

Traditional databases are based on designs that were developed decades ago. The technical conditions, as well as the usage requirements, during this time differed from today’s expectations. Traditional databases have been enhanced, but their ability to adapt to new challenges is limited due to compatibility reasons.

From the perspective of business application software, traditional databases lead to critical limitations and can complicate or even hinder the simplification, acceleration, and integration of business processes. The following characteristics of traditional databases can be obstructive, for example, when redesigning your business processes:

• Online transaction processing (OLTP) versus online analytical processing (OLAP)
  Users of database solutions have to decide whether they want to analyze data (OLAP) or update data (OLTP). However, in many situations, a combination of both views makes sense, for example, for forecasts and simulations or for making decisions on the basis of real-time data.
• Technical restrictions
  Traditional business applications have to deal with various restrictions, which complicate things for users. Examples include locks that occur so that only one user can work on a data set at a time, which slows down processes. Another factor is the delay resulting from internal data editing processes. Updates carried out by other users, or even by the same user, are sometimes written to the relevant system tables with considerable delay.
• Integration
  In traditional applications, raw data is usually first internally prepared and consolidated via aggregates. These aggregates follow the specific logic of the individual application. If other applications use this data, a delay occurs. Furthermore, you’ll require semantic knowledge of the corresponding application aggregate. Consequently, the data first needs to be translated into the data model of the other application. For this purpose, interfaces must be available or must be developed.
  Integration on the basis of such an architecture thus has disadvantages with regard to costs (development and maintenance of the interfaces) and with regard to lacking real-time access.

Over the last few years, new database architectures have been developed, so-called in-memory databases. SAP S/4HANA is completely based on this kind of database: SAP HANA. The following sections describe the characteristics of SAP HANA and describe why no other in-memory database is currently compatible with SAP S/4HANA.

2.3.1    SAP HANA

If you take a look at hardware development in the few last years, you’ll see that two basic changes arose at the turn of the millennium: On the one hand, multicore processor architectures emerged and, with them, the option of substantial parallelization. On the other hand, memory evolved from being relatively expensive and limited into being widely available.

Due to the memory restrictions with regard to availability (i.e., price and addressability), the data in software architectures was mainly stored on the hard disk, and only some data was stored in the memory. Accessing in traditional databases was limited by hard disk processing speeds. In in-memory databases, the hard disk is only used to store, archive, and restore data. The data itself is permanently kept in the main memory.

In contrast to other in-memory databases, SAP HANA has further unique characteristics: SAP HANA is not only an ideal generic database but has also been optimized for business applications due to SAP’s holistic experiences with this kind of applications.

The key result of SAP’s experience is that the data in SAP HANA is stored in column-based tables, while the data in other databases is stored in row-based tables (see Figure 2.5). Why is this relevant?

In business applications, most data is accessed “per column”: Usually, the values of a field or a selection of fields are selected and edited (e.g. names of a set of employees or prices of a selection of goods). Rarely is an entire set of rows required (i.e. all attributes of an employee or of a good). If SELECT statements are executed using column indexes, much smaller volumes of data need to be processed. Moreover, the values in the columns can usually be easily compressed—in particular under the conditions given for business applications, which consist of similar data.

Figure 2.5    Comparison of Row-Based and Column-Based Data Storage

Another benefit of SAP HANA is that this database has been optimized in such a way that the main business data operations can be executed with high performance. For this purpose, SAP HANA uses multicore CPUs (central processing units) for parallelization. In addition, algorithms are optimized using assumptions about the types of updates, inserts, and deletions that are carried out frequently and should consequently be the focus for high performance.

2.3.2    The Data Model

SAP S/4HANA is designed to fully exploit the benefits of SAP HANA described in the previous section. With this focus on SAP HANA, the following consequences arise for the data models in SAP S/4HANA:

• Aggregates are omitted.
• Existing ABAP Dictionary tables are redesigned.
• Code is pushed down.

The following sections discuss each of these consequences in greater detail.

Omission of Aggregates

To compensate for poor speed of traditional databases, data was previously consolidated in aggregate tables. The applications then accessed these aggregate tables to read the data. However, these aggregates had the following disadvantages: Due to the consolidation, entries in the aggregate tables always lagged behind entries in the original tables. This delay increases with the growth of the volume of data that needs to be processed.

Another disadvantage is that the aggregation uses assumptions of the content as a prerequisite for consolidation. As a result, processing this data from a different perspective is usually not possible without reworking the aggregation and thus can be a rather complicated task. For this purpose, you’ll have to use the original data, which reduces processing speed.

Figure 2.6 shows an example of a target architecture with a simplified data model for sales documents after migrating from SAP ERP to SAP S/4HANA.

Figure 2.6    Simplification of the Data Model for Sales Documents (Target Architecture)

The usual aggregate tables were omitted in this case. All new SAP HANA-optimized applications directly access the original data.

Note that the aggregates continue to exist in the new data model: The database can emulate the tables in real time. For this purpose, SAP S/4HANA provides predefined database views. These views simulate the aggregates in real time so that existing applications that have not been optimized for SAP HANA can be deployed smoothly.

[+]  Accessing the Traditional Data Model

SAP S/4HANA includes compatible database views, which allow you to access the data model of the traditional SAP Business Suite.

As a result, you’ll still have read access to existing custom developments, such as reports, and you can usually still use these reports without needing adaptations to the new data model. Chapter 10, Section 10.2.5, describes how you can check your existing code for compatibility with SAP S/4HANA.

Redesign of Existing ABAP Dictionary Tables

In addition to omitting aggregates, the example shown in Figure 2.6 also illustrates that the architecture for the storage of original data is also partly optimized. In this context, you must keep in mind that the data models in SAP ERP had been developed over several decades. On the one hand, these data models had to be compatible with all databases; on the other hand, rigid changes would have led to problems with SAP ERP EHP upgrades, which were promised and expected to be easy to use.

With the focus on the SAP HANA database and the clear differentiation to existing products, SAP S/4HANA now also allows for redesigning the data architecture in general. In this process, data storage is further optimized for SAP HANA, for example, to enhance the compression rate or optimize the general performance.

Code Pushdown

Another innovation in SAP S/4HANA is that procedures can be directly transferred to the database. In the traditional SAP Business Suite, the ABAP kernel decoupled the application from the database to ensure compatibility to any type of database. Consequently, the raw data first had to be loaded from the database and then concatenated in the application to carry out complex, data-intensive selections and calculations.

In SAP S/4HANA, some data-related processes are pushed down to the database itself, which accelerates the entire process, which is known as code pushdown. Code pushdown can be executed either in ABAP using Open SQL or via SAP HANA content created in SAP HANA Studio.

How does this affect existing custom code enhancements? Because existing Open SQL data access still works, you can continue to use existing enhancements and only have to adapt them in exceptional cases. However, these codes do not exploit the full potential of SAP S/4HANA. Thus, when you plan to migrate to SAP S/4HANA, you should check which custom codes should be rewritten and optimized. Because you can address custom code at any time after migrating SAP S/4HANA, you’ll enjoy greater flexibility in planning.

2.3.3    Handling Existing Data

How do these changes to the data model affect planning a migration? The good news is that you’ll only have to take into account a small portion of these data model changes because SAP S/4HANA provides database views with all the necessary compatibility (see “Omission of Aggregates” in Section 2.3.2). However, when planning your migration project, you’ll have to bring your existing data into the new data models. Depending on the technical migration scenario selected (Chapter 3 and Chapter 4 introduce the individual scenarios), different technical procedures are used to convert the data. Usually, these procedures include execution of program after import (XPRA) or after import methods (AIMs). Regardless of the scenario you choose, converting the technical data will take some time.

How much time this conversion needs mainly depends on the volume of the data to be converted. For this reason, you should check what existing data can be archived before migrating to SAP S/4HANA. In this way, you can reduce the volume of the data to be converted and thus minimize the conversion runtime. Thanks to SAP S/4HANA’s built-in compatibility mode, applications contain read modules that allow you to read archived data.

2.3.4    Sizing

If you want to implement a new SAP S/4HANA system or convert an existing SAP ERP system to SAP S/4HANA, you’ll have to consider the following issues:

• The sizing rules for SAP S/4HANA systems and for SAP ERP systems differ
  Analyzing hardware requirements (sizing) for modern systems follow different conditions and rules than sizing systems based on traditional databases. The main reason for this difference is that SAP HANA stores data in random-access memory (RAM), which requires different sizing requirements. The new SAP HANA data architectures and embedded data compression algorithms routinely achieve data compression rates of 3 to 5 on average.
• Random-access memory = twice the compressed data volume
  As a rule of thumb, SAP recommends calculating twice the compressed data volume for the RAM volume. Because sizing strongly depends on your specific conditions (for example, on the compression rate that can be achieved), SAP recommends running a sizing report in your existing SAP ERP systems. For more information on sizing, see http://service.sap.com/sizing.

In summary, the SAP HANA database is more closely linked to implementing application functions than other databases in previous years. This close link is the only way for applications to sufficiently benefit from the advantages of the database. This close relationship is probably also why SAP S/4HANA is currently only available for SAP HANA. The in-memory databases of third-party providers sometimes follow other approaches and require alternative implementations.