ABAP Tutorials

There are 5 different table types in the SAP ABAP Dictionary:

- Transparent tables

- Structures

- Pool tables

- Cluster tables

- Views

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.  All structures and certain views are also created in the ABAP Dictionary
but are not stored in the RDBMS. The ABAP Dictionary is SAP’s tool for developers to maintain
any type of table that exist in the physical database.

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 exclusively in transparent tables
(TRANSP).

Transparent Tables
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

1/3
ABAP Tutorials

INTTAB tables are field strings (structures) which do not hold data. Therefore, they are not
mapped to the database and have no underlying database tables.
INTTAB tables must be activated just like TRANSP tables. However, no technical settings are
required and the Database Utility is not automatically invoked when you click the activate icon
since INTTAB tables do not exist in the database.
Structures can be used in multiple tables. They help avoid redundant field definitions throughout
the system. Structures can be nested up to nine levels and can contain a maximum of one
table. They are similar to the copybook function of other programming languages.

Pool and Cluster tables

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 on the database in which all the records of the allocated pooled
tables are stored.
Cluster tables 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 keys must
agree. Several cluster tables are stored in one corresponding table on the database.

Technical Settings
Technical settings allow you to optimize the storage requirements and table access behavior of
database tables.
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.

Data Class
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)

2/3
ABAP Tutorials

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.

Size Categories
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.

Buffering type
Buffering is only recommended for tables with data that typically does not change or get
updated. Buffering types:
Single record: Only records actually being processed are 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 is 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.

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.
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.

3/3