ABAP - ABAP Dictionary

ABAP Dictionary

The ABAP Dictionary contains all metadata about the data in the SAP system. It is closely linked with the ABAP Workbench in that any reference to data (e.g., a table, a view, or a data type) will be obtained from the dictionary. Developers use the ABAP Dictionary transactions (directly or through the SE80 Object Navigator inside the ABAP Workbench) to display and maintain this metadata.

When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.

A brief description of the most important types of dictionary objects follows:

• Tables are data containers that exist in the underlying relational database. In the majority of cases there is a 1-to-1 relationship between the definition of a table in the ABAP Dictionary and the definition of that same table in the database (same name, same columns). These tables are known as "transparent". There are two types of non-transparent tables: "pooled" tables exist as independent entities in the ABAP Dictionary but they are grouped together in large physical tables ("pools") at the database level. Pooled tables are often small tables holding for example configuration data. "Clustered" tables are physically grouped in "clusters" based on their primary keys; for instance, assume that a clustered table H contains "header" data about sales invoices, whereas another clustered table D holds the invoice line items. Each row of H would then be physically grouped with the related rows from D inside a "cluster table" in the database. This type of clustering, which is designed to improve performance, also exists as native functionality in some, though not all, relational database systems.

• Indexes provide accelerated access to table data for often used selection conditions. Every SAP table has a "primary index", which is created implicitly along with the table and is used to enforce primary key uniqueness. Additional indexes (unique or non-unique) may be defined; these are called "secondary indexes".
• Views have the same purpose as in the underlying database: they define subsets of columns (and/or rows) from one or - using a join condition - several tables. View is actually a virtual table which does not contain data physically. Views take very short memory space in database because the views contain only the definition of data.
• Structures are complex data types consisting of multiple fields (comparable to struct in C/C++).
• Data elements provide the semantic content for a table or structure field. For example, dozens of tables and structures might contain a field giving the price (of a finished product, raw material, resource, ...). All these fields could have the same data element "PRICE".
• Domains define the structural characteristics of a data element. For example, the data element PRICE could have an assigned domain that defines the price as a numeric field with two decimals. Domains can also carry semantic content in providing a list of possible values. For example, a domain "BOOLEAN" could define a field of type "character" with length 1 and case-insensitive, but would also restrict the possible values to "T" (true) or "F" (false).
• Search helps (successors to the now obsolete "matchcodes") provide advanced search strategies when a user wants to see the possible values for a data field. The ABAP runtime provides implicit assistance (by listing all values for the field, e.g. all existing customer numbers) but search helps can be used to refine this functionality, e.g. by providing customer searches by geographical location, credit rating, etc.
• Lock objects implement application-level locking when changing data.