OLTP vs.

OLAP and How Do They

Connect to SAP?

inui.io
SAP
Last updated on January 21, 2020

In this article, you’ll learn what the differences are between OLTP and OLAP and
how they connect to SAP.

OLTP and OLAP both describe how a database is used.

Get or update your fundamental SAP knowledge here.

So without further ado, let’s do this.

Contents
 How to OLAP vs. OLTP and SAP
 What Is a Database?
 What Is a Database Management System?
 What Is a Relational Database Management System?
 What Is a Data Warehouse?
 What Is Online Transaction Processing?
 What Is Online Analytical Processing?
 Differences between OLTP and OLAP
 OLTP, OLAP, and SAP

How to OLAP vs. OLTP and SAP

First, we need to define these terms.
OLTP stands for Online Transaction Processing, and OLAP stands for Online
Analytical Processing.

As these names indicate, the difference between them is how they are used.

OLTP and OLAP describe two different types of databases and two different ways of
processing data.

Because the data is used differently, it is also structured differently in the database.

OLTP is designed for processing operational requests in a database.

These are the kinds of requests to the database from applications used in standard
business operations, such as maintaining sales orders.

OLAP is designed for processing analytical requests in a database.

These are the kinds of requests to the database from applications used for business
intelligence and data mining.

A business intelligence application provides information about sales orders, such as

the aggregated net value for a specific timeframe.

To understand the differences between OLTP and OLAP and how they function in
SAP, you’ll need to begin by understanding these terms:

 DB (Database)
 DBMS (Database Management System)
 RDBMS (Relational Database Management System)
 DW (Data Warehouse)
 OLTP (Online Transaction Processing)
 OLAP (Online Analytical Processing)

What Is a Database?
A database (DB), also called a database system, is a collection of structured data
and software to access that data (the DBMS, or database management system).

Typically, the data is stored electronically.

A database system serves users and applications to:

 save high volumes of data in a way that is

 efficient
 consistent
 permanent
 provide data subsets in
 different presentation forms
 needs-based presentation forms
A database system consists of two parts:

 the actual database in a narrow sense, and

 a database management system (DBMS).

The actual database consists of just the data in a database system, which is
managed by the DBMS.

Although the entire database system is often simply called a database.

Let’s look at the example of a zoo.

You want to save all the data about the zoo:

 animal names,
 zoo areas,
 zookeeper wages, and
 etc.

This is the actual data that resides in the database.

To store and retrieve the data, a DBMS is necessary.

What Is a Database Management System?

A DBMS (Database Management System) is the administration software of a
database system that manages the database that contains the actual data.

Whenever someone wants to add information to the database or retrieve information

from it, they make a request to the DBMS.

The DBMS

1. takes the request,

2. translates it,
3. and executes it, modifying or retrieving data as requested.

The DBMS organizes the structured storage of the data and controls all reading and
writing access to the database.

To manage and request data, a database system provides a database language,

such as SQL (Structured Query Language).

In order to make a request of the DBMS, they must format their request in the
language that the particular DBMS uses.

Here are ten examples of database management systems:

 SAP Sybase ASE

  SAP HANA
 Microsoft SQL Server
 Microsoft Access
 Oracle RDBMS
 IBM DB2
 PostgreSQL
 MySQL
 MongoDB
 Amazon RDS

Let’s go back to our zoo example.

You have an application to manage the zoo animals, and you add a new animal in
the application:

1. The application takes the provided animal data and sends it to the application
server.
2. The application server translates the request to save the data into the
database system into the DBMS language and then sends it to the DBMS.
3. Finally, the DBMS puts the animal data into the database.

What Is a Relational Database Management System?

An RDBMS (Relational Database Management System) is a DBMS that stores data
in a relational structure.

This means that the data is grouped in logical units in tables, and those units link to
each other using keys.

The tables have relations with each other through the keys.

DBMSs are made to retrieve and store data with the presence of redundant data.

RDBMSs are made to retrieve and store data on a data basis without the presence
of redundant data.

Let’s say that you would like to save the zoo animals according to their zoo area.

In a so-called flat and non-relational database, you would save all animals and their
zoo area together in one table, like this:

ID Animal Type Zoo Area

1 Dolphine Water
2 Wale Water
3 Hawk Mountain
4 Zebra Desert
5 Rhino Desert
6 Penguin Snow
ID Animal Type Zoo Area
7 Ice Bear Snow
8 Seal Snow

But in a relational database, you would save the animals and the zoo areas as
logical units in separate tables.

Each entry in the animals table would have a key that points to an entry in the zoo
areas table.

The keys relate to each animal entry with an entry in the zoo areas table.

The process of structuring data that belongs logically together in a database into
separated tables is called normalization.

Here is the animals table with relations via the zoo area ids to the zoo areas table:

ID Zoo Area ID Animal

1 1 Dolphine
2 1 Wale
3 2 Hawk
4 3 Zebra
5 3 Rhino
6 4 Penguin
7 4 Ice Bear
8 4 Seal

And the zoo areas table:

ID Zoo Area
1 Water
2 Desert
3 Mountain
4 Snow

There are two key advantages of a relational database over a flat database that
saves all data in one table:

1. reduced data redundancy, and

2. improved data integrity.

Let’s say that you would like to add zookeepers to the database, along with the
animals and zoo areas.

You want this to include information about who is responsible for which animal and
therefore works in which zoo area.
In a flat (not relational) database, you would have to extend your one table with the
data about the zookeepers.

The table already holds the data about your animals and zoo areas. The table gets
more and more packed, complex, and redundant.

In a relational database, you would just add a new table for the zookeepers, and use
a key to relate the entries of the zoo area tables to the zookeeper table.

The key relates each entry in the zoo area table with an entry in the zookeeper table:

ID Zoo Area ID Zoo Keeper

1 3 Michael
2 2 Emily
3 1 Alex
4 4 Sarah

Now you know which zookeeper is responsible for which zoo area through the
relation of the zookeeper table to the zoo area table.

Plus, you know which zookeeper is responsible for which animal through the relation
of the zookeeper table through the zoo area table to the animal table.

In comparison to a DBMS and one single table, an RDBMS and its multiple related
tables are less packed, less complex, and do not have any redundancies.

Tables in an RDBMS are well structured and make sense for a human through their
logical groupings, such as animals, zoo areas, and zookeepers.

Relational database systems are the most common database systems.

What Is a Data Warehouse?

A DW (Data Warehouse) is at its core just another relational database. It is a
relational database that is structured to fit the needs of analytical requests.

A data warehouse extracts, transforms, structures, and finally stores data from
operational databases and external sources.

A data warehouse is made for analytical applications.

A data warehouse supports analytical applications in

 data consolidation,
 analysis,
 and reporting, including the aggregation of data.

In turn, these analytical applications are made for decision support.

Let’s go back to the zoo.

You are thinking about closing your zoo for a month because you want to go on
vacation to Hawaii.

However, you are not sure which month would be the best month to close your zoo
in terms of revenue.

You use an analytical application that is connected to a DW to get the net value of all
sold zoo tickets for each month over the past two years.

Then you can pick the month with the least net value of sold tickets for your vacation
to Hawaii.

What Is Online Transaction Processing?

OLTP (Online Transaction Processing) describes databases that are optimized for
operational requests.

These requests are by far the most frequently used in business operations, such as
managing sales and other interactions.

Operational requests are not requests from applications that are used for analytics
such as decision support.

An OLTP database is not a DW.

An OLTP database is made to

 process high volumes of requests,

 respond without delay to requests,
 process requests as fast as possible, and
 maintain the data integrity despite multiple simultaneous requests.

The effectiveness of an OLTP database is measured in processed transactions per

second.

Therefore, efficient operation is the most important feature of an OLTP database.

OLTP systems are designed to serve data to operational applications that access the
database by providing fast and consistent processing of the applications’ requests.

As the name says, the requests to an OLTP database are

 transactions, and
 processed online.

The “Transaction” in OLTP

A transaction is a request to a relational database and is a logical unit.

This means that after the request is processed successfully, the request leaves the
database consistent.

Consistent, in turn, means that the data is changed only in a way allowed by the
database, so that data integrity remains intact.

Data integrity within a relational database is maintained if the

 attributes are within their value ranges,

 primary keys are unique,
 primary keys are not empty,
 foreign keys are either empty or an equivalent primary exists, and
 custom integrity rules are fulfilled.

Either a transaction successfully executes, or it is rolled back until the database has
the same status as if the transaction had never been executed.

Therefore, if a transaction is aborted during its processing, then all the transaction
changes in the database until its abortion must be undone.

For example, the zoo has vacations for the animals.

At each zoo area’s entry is a note with the vacation times of the zoo area.

Each zoo area and the animals inside of it get four weeks of vacation in a year,
during which the area is closed to visitors.

The zoo area is opened again when the vacation ends.

Let’s take some liberties and say that the animals can decide on their own when they
want their zoo area closed so they can take their vacations.

The hawk from the desert zoo area decides to take two weeks of vacation from
January 01, 2019 to January 14, 2019.

The hawk communicates its vacation to Michael, the zookeeper for the zoo’s
mountain area.

Michael then records the vacation in the mountain area’s vacation note.

The transaction could look formal like this:

start of the transaction.

read the field remaining vacations for Chad the hawk.

write January 01, 2019 into the field vacation from for Chad the hawk.

write January 14, 2019 into the field vacation to for Chad the hawk.
end of the transaction.

That is a valid transaction that leaves the vacation note in the database consistent.

But imagine that the above transaction gets aborted before Michael has written to
the “vacation to” field: the zoo area gets closed but never reopened again.

If this note were left in the database and its instructions followed, this would cause
some problems.

The aborted transaction would leave the note inconsistent.

The transaction actually would be no transaction, because of its inconsistent effects

on the note.

The invalid transaction would be a mere request to the note.

When a transaction is aborted, all its changes done in the database must be rolled
back to retain the consistency of the database.

Let’s look at another scenario: it’s now June, and Chad the hawk took two weeks of
vacation in January, and another two in April.

If zookeeper Michael did not read the field “remaining vacation” before entering any
vacation requests, Chad the hawk could take as much vacation as he wants, even
though he’s already used up his four weeks of vacation per year.

The transaction again would not be a transaction but a mere request, because the
request would not be consistent.

The transaction would violate the custom integrity rules of the note, which say that a
zoo area has overall only four weeks vacation in a year.

The “Online” in OLTP

The “online” in OLTP means that the transactions in an OLTP system are processed
in real-time, without any delay.

The data is processed as soon as the request is made and gives an answer as fast
as possible.

An ATM is a good example: as soon as you confirm your PIN code, the ATM checks
immediately if the entered PIN code is correct, and then allows you to proceed with
your transactions.

The opposite of real-time is batch processing.

In a batch processing system, the requests are processed in bulk at a later time.
That means that the answer to the batch processing is provided at a later time as
well.

An example of this is a program to optimize images: during the day, new images get
uploaded by users to a server, and at night, when the workload of the server is
lower, the program optimizes the new images on the server in a batch.

The results are then available the next day when the processing is complete.

Real-time processing requires constant user interaction: the user interacts with an
application, the application fires the request up to the database, the database
processes the request, and it fires a response back to the application.

Batch processing requires user interaction once, or no user interaction at all.

The user starts the batch process, and the system processes the batch until it is
finished.

The other option is that the user schedules a batch request, and the system
processes the batch automatically.

The naming “batch processing” comes from the 60s/70s.

In this time, data and programs were stored on punch cards, and those punch cards
were read and processed in batches, often at night.

What Is Online Analytical Processing?

OLAP (Online Analytical Processing) describes databases that are optimized for
analytical requests.

These are requests from applications that are used for decision support, such as an
application to analyze the aggregated net value of sales orders per month or the
average empty seats on flights overall.

An OLAP database is not an operative database, but a database structured for

analytics that extracts data from operative databases and then organizes that data in
a different way.

As the name says, the requests to an OLAP system are

 analytical, and
 processed online.

The “Analytical” in OLAP

An OLAP database is made to analyze data and thus to answer questions about the
data.
For example, you, as the zoo owner, would like to know all about your zoo, such as:

 What is the net value of all sold tickets for last year?
 What is the average amount of food that each zoo animal has eaten last
month?
 Who is the zookeeper with the most overtime overall?

An OLAP database is a data warehouse.

A DW extracts, transforms, and stores data from operational databases or external

sources.

Imagine a DW or OLAP database providing an additional layer on top of the

operational database.

An advantage of an OLAP database is that it is separated from the operational

databases.

Therefore, it does not use any of the computation power of an operational database
to answer analytical requests and thus does not slow down the day-to-day-business
applications.

The “Online” in OLAP

The online in OLAP means the same as online in OLTP: the requests to the
database are processed in real-time, without any delay.

Data is processed as soon as the request is made, and the results of the requests
are made available as quickly as possible.

Differences between OLTP and OLAP

  OLTP OLAP
Describes Structure of an RDBMS database for Structure of an RDBMS database for
operational requests analytical requests
Data Source Original data source Extracts data from OLTP databases and
external sources
Purpose Day-to-day-business requests to run Analytical requests for decision support,
the fundamental business planning, and problem solving
Request Types Create, read, update, and delete Read
Request Aims Operational such as update the price of Analytical such as what is the net value of all
the item with the ID 1 sold items in 2018
Performance High volume of transactions High volume of data
Scope
Data Structure Normalized data Denormalized data
Data Scope Current Historical
Data Set Age 6 - 18 months 2 - 7 years
  OLTP OLAP
Request Mostly short and simple requests that Mostly long and complex requests that
Complexity are standardized contain aggregations

OLTP, OLAP, and SAP

OLTP databases are used in SAP ERP systems, such as the R/3 and ECC.

Data from these databases have traditionally been extracted into OLAP databases,
used in SAP NetWeaver Business Warehouses.

But the future is bright in the world of SAP: SAP’s own database called HANA
combines the functions of OLTP and OLAP systems in a single database.

HANA is an in-memory database.

In-memory means that the data does not reside on a hard drive, to be loaded into the
memory only when it is needed for processing or analysis.

Rather, it resides all the time in memory.

Because the data resides permanently in memory, and therefore no hard drive
access is necessary, a HANA database is super fast.

Therefore, OLTP and OLAP requests can be processed altogether in a single HANA
database.

SAP’s newest generation of ERP and CRM applications use HANA, such as

 SAP S/4HANA (ERP), or

 SAP Sales Cloud (CRM).