SAP HANA Database

In order to understand the SAP HANA architecture, it is required to understand the traditional database which was followed until the SAP HANA database came into the picture.
Before looking at that, let’s first have a look at the topics which we’ll be covering in this session:

From the previous sessions, we know that in the traditional RDBMS database, data was stored in the disk. And if the data was to be retrieved, the requirement was to be sent from the CPU to the RAM and then to the disk. Then, the disk used to respond in a similar path. And, more importantly, all of this used to take a long time. Basically, the time consumed by a large amount of database for this process would be somewhat 1–2 hours.
SAP HANA Database
So, to overcome this problem, there is a change in design in the SAP HANA architecture as shown in the following image. It is based on the in-memory platform. Here, the disk is placed inside the RAM, so our data is available in the specially designed RAM and it is closely related to the specially designed and integrated CPU. So, when the query is executed in SAP HANA box, it will execute inside the RAM avoiding the time consumed for communication between devices as the disk and data, both are available inside the RAM. And as it is using a specially designed and integrated CPU, the time consumed for communication between the RAM and the CPU is also negligible. As all data is available inside the RAM, the processing and execution of the query will be very fast. So, this in-memory database is one of the reasons why there is a complete boost in the performance of SAP HANA.
SAP HANA Database In memory database

SAP HANA Architecture Vs. Traditional Database Architecture

After understanding how the traditional architecture and the SAP HANA architecture work, let’s now look at their structures.

Come to Intellipaat’s SAP Community if you have more queries on SAP HANA!

Traditional Database Architecture

Let’s discuss the traditional database architecture, first. It is illustrated in the image below:
Traditional Database Architecture
Let’s discuss each of them in detail:

  • Business Suite: A set of fully integrated applications such as ERP, CRM, and SCM that enables enterprises to run their core business functionality. Here, all operation applications are integrated, and all these applications are generating lots of data. Having access to this data is not easy.
  • ETL: ETL is the Extract, Transform, and Load tool that is used to fulfill any drawbacks from the Business Suite. It is also used to move the data to another database and we call this database as ODS.
  • ODS: ODS is an acronym for the Operational Data Store. Now, all our data is moved to ODS so that we can assess all our data without impacting our Business Suite. That much is good. Now the problem is, in the data store, we have lots of information, and we don’t want to see all those detailed information. Maybe, we want to see the information by years or by any other dimensions.
  • Aggregates: Here, we need something which summarizes this data, so we will build Aggregates that will give us access to summarize the information. But, there is a high possibility that we will have lots of Aggregates.
  • Indexes: For quicker access to data, we need to build Indexes. After building Indexes, we still miss something, that is, the ability to define some complex key performance as they are not in our data. So, we will build Complex Calculations.
  • Complex Calculations: These calculations will help us define key performance indicators.
  • Data Warehouse: With all this, we can now construct a big cube to put our data and we call it a Data Warehouse or Business Warehouse. But the problem is, we have different departments; we have finance with a specific need, marketing with another, and HR with yet another. So, we have to build customized data sets for them called Data Marts.
  • Data Marts: Using Data Marts, we can build smaller cubes after the bigger cubes are built. With this, we are ready to generate reports.
  • Reports: For generating reports, we can use different tools like Tableau, SAP BusinessObjects, Pentaho, etc. from a dashboard to look at the insights.

Looking for SAP HANA Training All-in-1 Combo Course? Enroll now!

That’s great! Even though we have a great tool in the environment, the issue with this setup is that when changes happen in the requirement, like if we want to add another Business Suite or if we change anything in any of the stacks, the complete environment gets collapsed.
Traditional Database Architecture complete environment
This happens because the whole environment is not robust enough and is too complex. Even though we have good tools, we are not able to maintain them.
To overcome this problem, we can use the SAP HANA.

Want to get certified in SAP HANA. Learn from our SAP HANA expert and do excel in your career with intellipaat’s SAP HANA Admin certification!

SAP HANA Architecture

Let’s discuss SAP HANA architecture and see how the problem caused by the traditional database system can be resolved.
SAP HANA Architecture
So, this is how SAP HANA works: There are business applications and as we know with Business Suite and it will be using some transactional and operational data for that we have Business Client who will be accessing the Business Suite. Now, here comes the SAP HANA platform in the picture and we set it next to the Business Suite. With this, we will select the transition data from the Business Suite and copy them to the SAP HANA platform on a real-time basis, so we will have the same set of table replica in both our Business Suite and SAP HANA. This will allow us to accelerate some of the transitions, for instance, Profitability Analysis (CO-PA) or Financial Accounting (FI-CO) i.e. SAP FICO, and we call it as an accelerator. It is a quick start to SAP HANA; whenever we are in need, we can switch the accelerator on SAP HANA, and SAP HANA will copy what it needs with the help of an accelerator.

An accelerator will redirect our transitions to the SAP HANA platform when it is needed in an accelerated way. One of the interesting things which we get here in the SAP HANA platform is that we can run reporting anytime when it is required on the SAP HANA platform because we have an accelerator and we can get accelerated reporting any time. Here, we can go even further. Remember we had a Data Warehouse in our traditional system? What we should do with that?

Now, our Data Warehouse/Business Warehouse is running on the SAP HANA platform and even we can run our Business Suite on the SAP HANA platform. And the best part of this setup is that we can directly run our Business Client on the SAP HANA platform. So, every transaction will run smoothly on the SAP HANA platform and we can easily run Reports on this platform.

It also provides a feature for advanced Data Mining, and we can run Predictive Algorithms on top of the SAP HANA platform. This shows that SAP HANA is in-memory, but it also provides parallel processing so that it can run all complex algorithms directly on its platform. We can even build Mobile Applications on the SAP HANA platform and access our data quickly. Even if we have any specific special application called Industry Application, also we can run on top of the SAP HANA platform.

Check out the top SAP HANA Interview Questions to learn what is expected from SAP professionals!

In this session, we have learned the robust architecture which SAP HANA follows. As we have learned all the basic information, let’s go ahead and install SAP HANA and start learning about it in detail.

Recommended Videos

Leave a Reply

Your email address will not be published. Required fields are marked *

Solve : *
22 + 14 =