chapter 04_abap dictionary tables in relational databases

ABAP Dictionary Tables in Relational DatabasesIBM Global Services
© 2005 IBM Corporation
The participants will be able to:
Describe the different types of tables in the SAP ABAP Dictionary.
Explain the technical settings for optimizing the storage and maintenance requirements.
Describe performance benefits through indexing.
ABAP Dictionary Tables in Relational Databases |
IBM Global Services
SAP Table Types
There are 3 different table types in the SAP ABAP Dictionary:
Transparent tables
2. Pool tables
3. Cluster tables
Data in the SAP R/3 system is stored in a relational database management system (RDBMS). All tables in the SAP R/3 system are created using the ABAP Dictionary and are stored in the relational database.
The ABAP Dictionary is SAP’s tool for developers to maintain any type of table that exist in the physical database.
IBM Global Services
Transparent Tables
Master Data
SAP stores both master data and transaction data in transparent tables.
Transactional Data
SAP uses the term master data to refer to control tables and the traditional files that are necessary to run a business such as personnel files, general ledger accounts, customer files, etc. There is a 1:1 correlation between the master data tables in the Dictionary and the tables in the physical database. For each master data table in the Dictionary, the same master data table exists in the physical database.
Commercial data or transaction data is another SAP term used to refer to data created as a result of performing SAP business transactions such as creating: invoices, orders, production schedules, purchase requisitions, stock transfers, etc.
SAP stores both master data and transaction data in transparent tables (TRANSP).
IBM Global Services
PROFILE
Transparent (TRANSP) tables have a 1:1 correlation between the ABAP
Dictionary and the physical database.
DB
Transparent (TRANSP) tables have a 1:1 correlation between the ABAP Dictionary and the physical database. For each TRANSP table in the Dictionary, the same table name exists in the physical database.
Since TRANSP tables exist in the physical database, you can use either Open SQL or Native SQL to access them.
Transparent tables are created automatically in the database after you specify the table’s technical settings and activate the table using the Database Utility. The Database Utility gets invoked automatically when you activate the table by clicking the icon.
IBM Global Services
Pool Table
Cluster Table
Pooled tables can be used to store control data (e.g. screen sequences,
program parameters or temporary data).
Cluster tables may contain continuous text (e.g. documentation).
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table in the database in which all the records of the allocated pooled tables are stored.
Cluster tables may contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the primary keys must agree. Several cluster tables are stored in one corresponding table on the database.
We will not be working with these two type of tables in the exercises for this course.
126.unknown
127.unknown
Data class
DB storage
On or off
Technical settings allow you to optimize the storage requirements and table access behavior of database tables.
The Technical Settings screen appears when you click the icon on the ABAP Table Maintenance screen.
Data class - Designates the table to an area in the physical database where similar tables are grouped (in ORACLEä and INFORMIXä only).
Size Category - Identifies the amount of disk space that will be required to hold the data records for a table in the database (in ORACLEä and INFORMIXä only).
Buffering - Determines whether table records will be accessed directly from the database server or from global memory.
Logging - Creates before and after images of changes to the table of contents. Logging must be activated by the profile when the system is started.
IBM Global Services
Tables in the ABAP Dictionary must be assigned to one of the following classes of data:
Master Data: Large amounts of data which do not change often. It is often read, but
rarely updated. An example of master data is the data contained in an address file,
such as the name, address and telephone number. (APPL0)
Transaction Data: Data with temporary lifecycle, not stored long. Frequently
updated. An example of transaction data is the goods in a warehouse, which change
after each purchase order. (APPL1)
Organization and Customizing Data: Specified when the system is configured and
then not often changed. An example is the table with country codes. (APPL2)
Two further data classes, USER and USER1, are provided for the customer. These are used to define user developments.
Defining a data class has the effect of storing the table in a defined area of the database when the table is created.
IBM Global Services
Size Categories
A table’s size category identifies the amount of disk space on the database that
is allocated to the table.
A table’s size category identifies the amount of disk space on the database that is allocated to the table.
This amount is translated to a number of data records if you hit F4 for help, depending on the underlying database.
If the number of records in a table exceeds the original size category, then more space will automatically be allocated in the database. The storage space will be incremented by the amount of the original size category.
IBM Global Services
Single Record
Buffering is only recommended for tables with data that typically does not change or get updated.
Buffering types:
Single record: Only a single record actually being processed is moved into the buffer. This type of buffering preserves buffer space but requires more database hits in order to load the table. Recommended for large tables when only a few records need to be accessed.
Generic: A subset of the table records are loaded based on part of the primary key. Recommended if only certain “generic” areas of the table will be needed.
Full: Results in either all of the table or none of it being loaded into the buffer. Recommended for a) tables up to 30 K in size, b) larger tables where access is needed to many records, and c) tables against which attempts to access data will frequently yield a “no record found” result.
IBM Global Services
Logging
On the technical settings screen you can specify “Log data changes” to
automatically generate a log file of details on the structure of a table, a list of the
data changes made during a certain period, and statistics.
On the technical settings screen you can specify “Log data changes” to automatically generate a log file of details on the structure of a table, a list of the data changes made during a certain period, and statistics.
In addition to clicking the checkbox “Log data changes” on the technical settings screen, you must ensure that the System Administrator has also specified the switch or entry to allow “Table Logging On”.
Log files do not rely on successful database updates to be completed before they are written.
The existing logs can be displayed with Transaction code SCU3.
IBM Global Services
Maintaining Technical Settings
Activating tables causes the Technical Settings screen to display. Choose an appropriate data class and size category. Use the F4 help to list the possible entries.
The Buffering and Logging settings can also be set on this screen.
When the settings are saved, SAP automatically runs the Database Utility.
A table’s Technical Settings can be changed at any time.
For successful activation of tables, we need to specify the enhancement category using the menu path Extras Enhancement Category in ECC 6.0.
IBM Global Services
Demonstration
Observation of the technical settings of the SAP Table MARA and familiarization with the technical settings of a transparent table.
IBM Global Services
Practice
Observation of the technical settings of the SAP Table MARA and familiarization with the technical settings of a transparent table.
IBM Global Services
DB
The Database (DB) Utility is a tool used in SAP to serve as a interface
between the database management software (i.e., ORACLE, INFORMIX,
DB2, INGRES, etc.) and the ABAP Dictionary
The Database (DB) Utility is a tool used in SAP to serve as a interface between the database management software (i.e., ORACLE, INFORMIX, DB2, INGRES, etc.) and the ABAP Dictionary. It is used to:
Convert data (i.e., change field lengths and data types, etc.)
Activate objects in the ABAP Dictionary
Create tables and indices
Perform all standard table operations in the database that were entered in the ABAP
Dictionary
The DB Utility automatically writes the SQL commands necessary to create, change and delete tables and indexes in the physical database, and records the tables in the ABAP Dictionary.
As the DB Utility is operating, a log file gets created which contains information on whether or not the conversion was successful and the point of failure during the conversion if it was not successful.
The DB Utility can be run either online or in the background.
You can also manually run the DB Utility from any ABAP Dictionary screen under the UTILITIES Database Object Database Utility menu or transaction SE14.
IBM Global Services
Index
To improve performance, SAP automatically creates a primary index (id 0) for
transparent tables based on the primary key. You can also define your own
secondary indexes for transparent tables.
To improve performance, SAP automatically creates a primary index (id 0) for transparent tables based on the primary key. You can also define your own secondary indexes for transparent tables.
Indexes accelerate the reading of tables when the system looks for records satisfying specific search criteria. The system determines the most efficient index by which to select data for the specific request.
An index serves as a sorted copy of the table reduced to specific fields, with a pointer to the remaining fields.
Database indexes are defined in ABAP Dictionary and stored in the physical database.
From the ABAP table maintenance screen use the menu path GoTo Indexes.
A pop-up window appears. In pop up window press the create button and select the entry ‘Create Index’ from the dropdown. Assign a 3-character id to your index.
Provide a short text and select the field(s) by which the table needs to be indexed.
Sometimes the presence of an index causes a performance problem. You can indicate the optionality of the index with different databases. Secondary index is used for the tables which are not frequently changed (Eg: Master tables)
Creating an index on an SAP table requires a repair, but it will not get overwritten with an upgrade.
IBM Global Services
In the cases where database accesses are necessary and appropriate, it is imperative to perform those accesses as efficiently as possible. The single most important method of optimizing a database access is by using an index.
An index is a set of fields from a table that is sorted and then stored in a location separate from the table itself. Each record in the index contains a pointer to matching record(s) in the actual database table.
IBM Global Services
This analogy is probably as old as computer science itself, but it still works well. Think of an index like a telephone book.
If you want to find someone’s phone number, the first thing you might do is decide where you want to look for that number. One thing you probably won’t do is start calling all possible telephone number combinations until you hit upon the right one! You might ask a friend, or call directory assistance, or look up the information in a phone book.
Let’s suppose you decide to use a phone book. The next thing you do is to begin searching for that person’s name in the book. Once you find the name, you then look across from the name to find the number.
A DBMS goes through a similar process when performing a query. It first must decide how it is going to look for the information that has been requested, just as you did when looking for a telephone number. One option is to look at each record in the table, one at a time, until all the matching records have been found. This would be analogous to trying all possible combinations of telephone numbers until you found the right one.
As ridiculous as that sounds, sometimes DBMS’s have to do just that. This is called performing a full table scan.
605.unknown
Another option the DBMS has is to perform an index scan. In this case, the DBMS looks in a separate file, searching for the information by a particular key field (or fields). This is like using the phone book, searching for the correct name.
Once the matching record(s) have been found in the index, the DBMS follows a pointer from the index to retrieve the actual record in the table. This pointer consists of a disk address that tells the system exactly where to find the desired record(s). In our telephone book example, the analogous process is pretty simple: you simply look across the line from the name to the telephone number.
994.unknown
The Index Range Scan
Sometimes an index doesn’t point to a single record, so it has to go for the
Index Range Scan
This process is analogous to an index range scan that might be performed by a DBMS. Sometimes an index doesn’t point to a single record. If you have an index of customers by their last names, this will probably be the case - you will probably have many customers with the same last name.
In this case, once the database finds matching record(s) in the index, its job isn’t over. It now must retrieve all the records that matched the selected index records, and examine each one to see if they meet the final selection criteria for the query.
607.unknown
The Unique Index Scan
If each index record matches exactly one record in the table, and if all the fields
of the index are specified in the query, a unique index scan can be performed.
In contrast, if each index record matches exactly one record in the table, and if all the fields of the index are specified in the query, a unique index scan can be performed. Queries based on a table’s full primary key always fulfil this criterion - such as by client (implicit if using Open SQL) and customer number in table KNA1.
In this case, once the DBMS finds the matching record in the index, its work is almost done. All it must do is follow the pointer from the index to the solitary table record that it knows will satisfy the query.
IBM Global Services
Unique Index Scan
Index Range Scan
Full Table Scan
A unique index scan is generally faster than an index range scan, because it has
less data to sort through and retrieve.
In general, indexed reads are much quicker than normal table reads, and some types of indexed reads are quicker than others. A unique index scan is generally faster than an index range scan, because it has less data to sort through and retrieve.
The smaller the amount of data being processed by a query, the faster it will run.
Here are some guidelines:
Use indexed reads over full table scans.
Use unique index scans when possible.
609.unknown
Summary
There are 3 different table types in the SAP ABAP Dictionary: Transparent tables, Pool tables & Cluster tables
Technical settings allow you to optimize the storage requirements and table access behavior of database tables.
Defining a data class has the effect of storing the table in a defined area of the database when the table is created.
A table’s size category identifies the amount of disk space on the database that is allocated to the table.
Buffering is only recommended for tables with data that typically does not change or get updated.
To improve performance, SAP automatically creates a primary index (id 0) for transparent tables based on the primary key. You can also define your own secondary indexes for transparent tables.
IBM Global Services
What is data class ?
What is size category ?

chapter 04_abap dictionary tables in relational databases

Documents