There are 5 different table types in the SAP ABAP Dictionary:
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 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)
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.
|
ABAP Tutorials 
