SAP supports most databases. However you may be restricted to only a few based on the platform (hardware/OS) you have selected. When selecting a platform you should keep in mind the choice of databases you would be restricted to. Not all platforms supports all databases.

SAP supports most databases including:

• Microsoft SQL Server
• IBM DB2
• Oracle
• MaxDB

MaxDB is SAP's own database. It is growing in popularity. It is more common on Linux platform. It is a low-cost alternative to other popular databases.

Most databases support log shipping feature including Oracle and Microsoft SQL Server. Log shipping is a concept where changes to the database are transferred in regular intervals to another standby database. When production system goes down for any reason, the standby system is ready to be activated as production. This would result in almost zero downtime.

You can imagine database as a filing system that contains useful information. Information is stored in tables within a database. A database could contain many tables

Table has rows and columns. You can imagine table as a spreadsheet with rows and columns. At the intersection of rows and columns, there are cells. Cells contain values.

A table stores information about entities e.g. Employee, Department etc. Something of importance is referred to as entities. The columns of the table represent attributes of the entity. For example Name, Salary, Department Number etc are attributes of an Employee.

Each record (or row) of the table represents an instance on the entity. For example Scott and Larry.

No two rows could be the same. That is why there are ID columns in tables. ID columns contain incremental values like 1, 2, 3 etc. This creates uniqueness for each row. Each value represent distinct instance of the entity.

Tables are tied together through relationships

Entities could have one to one, one to many, or many to many relationships with each other.

This relationship is represented in tables.

Let’s take a case of EMPLOYEE and DEPARTMENT tables.

In a DEPARTMENT table we would store department IDs and Names.

TABLE: DEPARTMENT

In a EMPLOYEE table we would store employee IDs, Names, and the Department ID in which they work.

TABLE: EMPLOYEE

The DEPTID column of EMPLOYEE table is tied to the ID column of the DEPARTMENT table creating one to many relationship (through a foreign key)

Each department could be assigned to various employees.

After establishing this relationship the database would not let you insert a value in DEPTID column of EMPLOYEE table that does not exist in ID column of DEPARTMENT table. E.g. you cannot insert 30 in DEPTID because it does not exist in DEPARTMENT table.

The tables are tied to each other through relationships. This is where the name "relational database" comes from.

SAP software has various components (or products).

For example: SAP ERP, SAP CRM etc

Each component generally has its own database. If a company is using both components SAP ERP and SAP CRM, then SAP ERP would have its own database and SAP CRM would have its own database as well.

You can think of SAP as a combination of two things:

• Programs
Data

Programs contain application logic. Programs read data from the database and also write data to the database. The database is there to make the data retrieval and data modification easy for the programs. Programs are separate from the database. Programs contain application logic e.g. how to create checks, how validate invoices. Database contain actual data (in tables) that would be retrieved and modified by the programs

SAP database contains thousands of tables.

For example SAP ERP database contains more than 30,000 tables.

Some lighter products like SAP NetWeaver Process Integration (PI) contains less than 10,000 tables.

In SAP about 10% of the tables contain 90% of the data.

That means few tables grow in size while other remains relatively constant.

The tables that grow in size are most transactional tables. Transactional tables contain transactions like Invoices, Journal etc.

The table that remain unchanged are mostly master tables. Master tables contain master data like list of currencies, list of states within USA etc.

Master data does not change as often as transactional data.

Tables store data.

Indexes are used to speed up retrieval of data.

Imagine a table containing 1 million records. Lets say a program has requested the database to fetch records for all employees whose name is SCOTT. The database would have to start reading the table from row 1 to the last row until it finds all the records where name is SCOTT. This is called a full table scan.

Full table scan slows down the performance as it is time consuming.

Indexes are created to avoid the full table scan.

In this example you would create an index on column NAME of EMPLOYEE table.

Imagine index as a table that only contains one or two columns. The actual EMP table could have more than 10 columns. The index on NAME column could be imagined as a table with one column NAME.

Now if you ask the database to retrieve all rows where NAME is SCOTT, first the database would visit this index. Index could be scans in a matter of seconds since it is a small object as oppose to the table.

Index has pointers pointing to the actual rows of the table.

First the database finds all desired values within the index.

Pointers could be used to retrieve other attributes of the entity residing in the actual table e.g. SALARY etc.

• SAP Indexes
• SAP relies heavily on indexes to improve the performance.
• 50% of the SAP database size comprise of indexes.