This chapter is from the book
This chapter is from the book
This chapter is from the book
Database Basics for SAP
With hardware and operating system details behind us, it is now time to turn our attention to the role of the database underneath an SAP business application. The same care that goes into choosing a hardware platform and OS should be used when choosing a database. Depending on your platform and SAP version, you may be restricted to only a few database choices (which underscores the importance of looking at your SAP infrastructure holistically). SAP tends to support most mainstream databases such as Microsoft SQL Server, IBM DB2, and Oracle’s ubiquitous database offerings. SAP also supports its very own database called MaxDB, which has an interesting history of acquisitions and continues to grow in popularity. More common for SAP-on-Linux platforms, MaxDB is an interesting and low-cost alternative to the other primary SAP-supported database offerings. Indeed, it is serving to level the playing field in the same way that commodity hardware and OS solutions are leveling the hardware and operating system playing fields.
Most IT departments choose a database based on what their current database administrators (DBAs) are familiar with or know. In the past, it has been a daunting task to retrain DBAs for a new database platform, particularly one associated with mission critical applications such as SAP. Today, though, low-overhead database offerings from Microsoft and IBM are making this transition easier.
Relative to selecting a database platform for SAP, you need to base your decision in part on the advanced functionality of database software you may need to meet your business user’s response-time and availability requirements. Microsoft SQL Server and Oracle both support log shipping and clustering technologies for increasing the availability of SAP systems. Log shipping allows you to maintain a secondary copy of your SAP (or any) database on another system to fail over to in case of a disaster situation. Sometimes log shipping is called “poor man’s DR.” Regardless, it is a robust and widely used technology for SAP as much as any other business application.
A Database Primer
Whichever database you choose, enterprise applications such as SAP are essentially made up of programs along with the data that is both used by and created by those programs. The data is organized in a meaningful way within a database, making it easy for the programs to access and find the data necessary to do something useful like run a financial report or create a sales order. In the case of an SAP component or product such as ERP, the programs and data reside together in the same database. Each component generally has its own database (although exceptions exist)—a production system landscape composed of SAP ERP, SAP NetWeaver Portal (EP), and SAP Customer Relationship Management (CRM) consists of three production databases, for example.
A database is essentially an electronic filing system that houses a collection of information organized in such a way that it allows a computer program to quickly find desired pieces of data. In the simplest form, a database is composed of tables, columns (called fields), and rows (called records or data). The basic structure of a database is quite similar to the well-known Microsoft Excel spreadsheet, where columns (fields) store row after row of records (data). The biggest difference between a database and a spreadsheet is simply that databases can contain multiple (and extremely large) tables that are connected to one another through relationships. Thus, a database can be thought of as a much more complex, and ultimately much more useful, spreadsheet. The database plays a key role in each SAP system because it houses all the data used by that particular SAP component or application.
Tables, Indexes, and Structure
The SAP database contains literally thousands of tables that store information. Some products, such as ERP, comprise greater than 30,000 tables, whereas less complex offerings such as SAP NetWeaver Process Integration (PI) might have fewer than 10,000. It is noteworthy to know that in most SAP systems, 10% of the tables house 90% of the data, so some tables can get quite large and be subject to constant change, whereas others tend to remain very small and relatively static. Regardless of the number, though, these various tables are all tied to each other through established relationships. It is precisely this series of connected multiple tables that creates what is known as a relational database management system (RDBMS).
Databases are made up of indexes, too; whereas tables house the data, indexes are used to speed up the retrieval of data from those tables. An index might best be described as a copy of a database table reduced to only the key fields. The data in this reduced copy is sorted according to some predefined criteria, enabling rapid access to the data. Not all fields from the copied table exist in the index, and the index contains a pointer to the associated record of the actual table. You might be surprised to know that indexes make up approximately 50% of the overall size of an SAP database!
SAP uses another concept called transparent tables, which are SAP database tables that only contain data at runtime. A transparent table is automatically created in the database when a table is activated in the ABAP/4 Data Dictionary. This transparent table contains the same name as your database table in the ABAP/4 Dictionary. Each of its fields also contains the same names as their database counterparts, although the sequence of the fields might change. The varying field sequence makes it possible to insert new fields into the table without having to convert it, all of which allows for more rapid access to data during runtime.
Database structure is another technical term that you really do not need to concern yourself with too much, but it’s important nonetheless. Simply remember that database structures are a group of internal fields that logically belong together. Structures are activated and defined in the ABAP/4 Data Dictionary and only contain data temporarily—during the execution of a program. Structures are differentiated from database tables based on the following three criteria:
- A structure does not contain or reflect an associated ABAP/4 Data Dictionary table.
- A structure does not contain a primary key.
- A structure does not have any technical properties such as class, size, category, or buffering specifications.