This tutorial gives you an overview and talks about the fundamentals of SAP HANA.
In-memory technology promises the extremely fast analysis and aggregation of huge amounts of data. It removes the limits known from traditional databases. The performance effect is a combination of different factors:
1. All data is held in the main memory of the server instead of hard disk
2. Transaction data is organized by columns and not by rows
3. The software has been optimized to take advantage of modern hardware architectures and heavily uses parallel processing
In-memory technology is being used by SAP in different usage patterns in the context of ERP systems.
1. Accelerators where SAP HANA will act as a secondary database to accelerate SAP ERP reports and transactions
2. SAP HANA as a side-by-side reporting system
3. SAP HANA as a primary database and replacement for your current relational database for transactions and reports. This has been possible for SAP Business Suite since January 2013.
SAP HANA as a secondary database :
In the first scenario (accelerators), the ERP system will continue to read from and write to the traditional database. Selected reads will be run against the HANA database which takes the role of an additional, secondary database in addition to the primary one (see Figure). The SAP HANA database contains a mirror fo selected tables of the normal databases via a so-called replication mechanism. This replication mechanism provides data rear real-time from the traditional database to SAP HANA. No batch loads are required. For this purpose, SAP offers a landscape Transformation (LT) component to be installed on a dedicated NetWeaver system, which serves as the middle-man between the ERP system and HANA. Technically, this component will use triggers on the source database to capture changers to the data. Alternatively, application-specific transactions or Sybase Replication Server can be used to transfer data from the primary database to HANA.
Architecture of ERP accelerators
This concept has certain advantages:
1. The HANA database is an optional accelerator, disconnecting the HANA database will only result in loss of performance (and not a loss in functionality or data)
2. The application logic remains unchanged, minimizing configuration, training and test effort for its implementation
3. Source data stays in the traditional database so any audit procedures in place remain valid
Its drawbacks are that write operations will be performed in the traditional database, not allowing changes in the logical table structure or performance gains in this area. It also requires a small change to the ERP application logic for enabling the acceleration.
SAP HANA as a supplementary analysis system:
In the second scenario (side-by-side reporting system), data from SAP ERP is replicated into SAP HANA. You can then use analytical frontends (e.g. the SAP Business Objects BI Suite) to present data to the end users. This scenario does not offer the acceleration of existing SAP ERP reports or functions. The general architecture is shown in Figure.
It provides free choice of the analytical frontend and the possibility to enrich your data with customer-specific modeling in SAP HAN, i.e. to combine SAP ERP data with data from other systems for reporting. It requires no change at all to the application layer of the ERP system. Both scenarios are complementary.
SAP HANA as a reporting system side-by-side to SAP ERP
SAP HANA as primary database :
So, far, the HANA in-memory technology has accelerated only individual analyses and programs. Which the use of SAP HANA as the primary database, SAP is making the in-memory technology available for all core processes of SAP Business Suite. Below Figure shows the considerable simplification this achieves in the system landscape. No SLT is required for data replication, and additional hardware that is used only for analyses is also no longer necessary. In this scenario, SAP HANA replaces the current relational database for all read and write processes.
SAP HANA as reporting system:
SAP HANA is being used side-by-side to the source system. It features a data replication mechanism for SAP source systems, e.g. ERP and CRM, and an ETL(Extraction Transformation Loading) component for third party systems.
Despite its different technology, SAP HANA can be addressed as any other database using standard SQL statements. It offers JDBC and ODBC drivers which are standardized programming interfaces to access relational databases. MDX (Multidimensional Expressions) is a widespread query language for OLAP database and is supported as well. Different reporting frontends can connect to HANA; SAP suggests using frontends of the SAP BusinessObjects BI Suite. Recommended frontends include SAP BusinessObjects Crystal Reports, Analysis Office, and Explorer.
Since data is typically replicated to HANA without transformation, you will need to enrich the raw model to get useful view for consumption. SAP offers some modeled content already to keep implementation efforts low. SAP HANA modeling is independent of SAP ERP; users and authorizations are not automatically taken over from the source system. All the above said features in SAP Hana Tutorial will be discussed in SAP Hana Training.