The SAP HANA database in business terms

In the last course you learned that SAP S/4HANA runs only on SAP HANA. This lesson explains what that means for people who use the system, without assuming you know anything about databases. You do not need to administer HANA. You need to know what it makes possible, because that shapes the reports, apps and processes you will test.

A database, in one paragraph

Every SAP document you create, whether a sales order, a goods receipt or a journal entry, is stored as rows in tables in a database. Traditional databases keep those tables mainly on disk and read them into memory when needed. They are very good at saving one record quickly, but slow when a report has to read and add up millions of rows.

Two ideas: in-memory and columns

SAP HANA does two things differently. First, it is an in-memory database: it keeps the working data in the server’s main memory, which is far faster to read than disk. Second, it stores tables by column rather than by row. A sales report that totals the "net value" column only has to read that column, not every field of every order. Column storage also compresses well, because a column such as "plant" contains the same few values over and over.

Question a user asks	Row-based database (classic ECC)	SAP HANA (S/4HANA)
Save one sales order	Fast	Fast
Total revenue for plant 1710 this month	Slow on detail, so pre-built totals tables were kept	Fast, calculated from line items on request
Drill from a total to the documents behind it	Often a separate report or a batch job	Usually immediate in the same app
Report on a new combination of fields	May need a new totals table or data warehouse load	Often possible directly on the line items

What changes for business users when the database can total line items on the fly.

What you actually notice

The visible result is real-time reporting on line items. In older systems, many reports read pre-calculated totals that were updated with each posting, or worse, loaded overnight into a separate data warehouse. With HANA, an app can read the individual postings and total them when you ask. That brings three practical changes.

Fewer overnight jobs. Reports that once waited for a batch run can show current numbers. At Contoso, the plant controller in Detroit can see today’s production variances today.
Analytics inside the transaction system. Many Fiori apps combine a list of documents with charts and key figures, because the same database can do both jobs.
Drill-down to the source. From a total, you can usually drill straight to the journal entries or documents that make it up.

HANA does not make every screen instant, and it does not fix bad data. A report that totals wrongly coded postings will show the wrong number very quickly. Speed changes how fast you can check; it does not change what is correct.

Why testers should care

Real-time reporting changes what you can check during a test. You no longer have to wait for tomorrow’s report to confirm that a test posting landed in the right place. Post the document, open the report, filter for your test data, and look. That makes tests faster and makes it reasonable to ask for reporting evidence, not just transaction evidence, before sign-off.

It also changes what can break. When reports read line items directly, a wrong field on a posting (a missing profit center, a wrong segment) shows up immediately in management reports. That is good if someone looks, and painful if nobody does until the CFO opens a dashboard.

Key points