SAP HANA is an in-memory database that includes powerful data modeling tools.
SAP HANA is available as a cloud service or on-premise deployment. Both options implement data modeling directly in the database.
Usually, data modeling solutions sit on top of a database. So why would you create the models directly in the database?
Perhaps, like our developer Alex, you have always built data models at the application level. In other words, on top of the database. If so, you might be interested in Sara's answer to this question. In simple terms, her answer is that SAP HANA isn't just a database; it's built on the latest hardware and software technology and includes all the tools you need.
Alex does not fully understand what Sara means by process data where it is stored. Let us examine where the bulk of the calculations are performed with the classic approach compared to the SAP HANA approach.
The Push-Down figure illustrates how the technical execution of data requests has changed with SAP HANA. Imagine the query "For the last 5 years of our sales, calculate the net amount after discount for each line item, then summarize by region and year". If this calculation is executed on the application layer, the database first has to send millions of rows to the application layer for processing. The application layer then generates the required output. During this process, a large amount of data has to be moved back and forth between the database and the application layer.
Instead, with the new push-down approach of SAP HANA, the calculation is processed directly in the memory of SAP HANA. Sending only the results of the calculation to the application layer means a significant reduction in data movement. This approach results in much better overall runtime performance.
There is another reason for the high performance of data analysis on SAP HANA: Typically, a query summarizes the values of only a few columns of tables. Most of the columns in a table are untouched by the query. When you choose the column storage type, only the data from the required columns is read. However, for operational data processing, all columns are usually needed. In this case, you may want to choose the Row storage type. By defining the optimal storage type for a table, you can optimize the physical table design for either row-based or column-based data access. Watch the video to explore storage types in SAP HANA tables:
Alex now understands the benefits of in-memory calculation. But does storing data in memory instead of disk become expensive with large data volumes? Watch the video below to learn how SAP HANA handles this issue:
Alex now understands that he can store data from earlier years in the cold store of SAP HANA and is still accessible, but at a lower performance as the data is stored outside SAP HANA. He is concerned that during financial year-end closing, the data from previous years needs to be accessed at high speed. The cold storage option for previous years data might not be the optimal solution. He asks "Do we really have to run hardware with a large storage capacity just because we need it during a short period of year-end closing?"
Launch the video and consider an alternative approach that Alex might consider.
In this case, Alex is sure that SAP HANA Cloud, with its elasticity, is the best choice.