SAP ABAP Data Dictionary (SE11)

What is Data Dictionary?

Data Dictionary is a central source of information for the data in a information management system. Its main function is to support the creation and management of data definitions (or “metadata”).

In SAP, this central store is called the ABAP Dictionary, and it is maintained with transaction SE11. Every table, field, view, and lock used by an ABAP program is described here once and then reused everywhere, so a definition never has to be repeated inside individual programs.

The screen above shows the SE11 initial screen, where each dictionary object type is selected before it is displayed or changed. Before looking at those object types, it helps to understand why SAP keeps this metadata outside the programs that use it.

Why the ABAP Dictionary Matters

The ABAP Dictionary exists because SAP separates the description of data from the programs that process it. A field such as the purchasing document number is described exactly once, and every report, screen, and function module that needs it refers back to that single description.

This central definition delivers four practical benefits. Consistency is guaranteed, because a change made to a domain immediately reaches every field that refers to it through a data element. Redundancy disappears, since developers reuse existing definitions instead of inventing new ones. Integrity is protected, as value ranges, check tables, and foreign keys are validated by the dictionary rather than by application code. Finally, the dictionary is database independent, so a table defined in SE11 is created in the underlying database with the correct native types automatically.

The dictionary is also active at runtime. Screens read their field labels, help texts, and value ranges directly from it, which is why an F1 help or an F4 value list appears without a single line of extra coding. Understanding the three levels below explains how that reuse is organised.

ABAP Dictionary 3 levels

Objects in the ABAP Dictionary resided on three levels that support their re-usability. These levels are:

1. Domains
2. Data elements
3. Tables and structures

Each level builds on the one before it: a domain supplies the technical attributes, a data element gives those attributes a business meaning, and a table or structure groups the data elements into a record. Lets look into them in detail –

Domains

• Describes the technical characteristics of a table field
• Specifies a value range which describes allowed data values for the fields
• Fields referring to the same domain (via the data elements assigned to them) are changed when a change is made to the domain
• Ensures consistency

Ex. Purchasing document number (EBELN)

The domain screen above defines only the data type and length. The business meaning of that value is supplied by the next level, the data element.

Data Elements

• Describes the role played by a field in a technical context
• Fields of same semantic meaning can refer to the same data element
• Contains the field information

Ex. Purchasing document number (EBELN)

The data element screen carries the field labels and documentation that users see on a screen. Data elements are then combined into tables.

Tables

• Represent the Database Tables where data actually resides.
• Tables can be defined independently of the database in the ABAP Dictionary.
• The fields of the table are defined with their (database-independent) SAP ABAP data types and lengths.

Structures

• Are record declarations that do NOT correspond to a Database Table.
• Just like user-defined data type.
• Defined like a table and can then be addressed from ABAP programs.
• Structures contain data only during the runtime of a program.

The table below compares the three levels at a glance.

Aggregated Objects of ABAP Dictionary

Aggregated means consisting of several components. In the ABAP Dictionary, aggregated objects are objects which come from several different transparent tables.

1. Views
2. Search Help
3. Lock Objects

Lets look into them in detail

Views

• Views in SAP – ABAP are used to summarize data which is distributed among several tables
• The data of a view is not actually physically stored. The data of a view is instead derived from one or more other tables
• It is tailored to the needs of a specific application

Search Help

• A Search help is a tool to help you search for data records in the system
• An efficient and user-friendly search assists users where the key of a record is unknown

Lock Objects

• Simultaneous accessing of the same data record by two users in the SAP system is synchronized by a lock mechanism.
• Locks are set and released by calling certain function modules. These function modules are generated automatically from the definition of so-called lock objects in the ABAP/4 Dictionary

Function modules : Enqueue_<obj name> – to lock the table dequeue_<obj name> – to release the lock

⚠️ Warning: A lock that is set with ENQUEUE and never released with DEQUEUE stays active until the user session ends. Always call the DEQUEUE module, including in the error path of the program.

With the object types understood, the next section applies them by creating a transparent table in SE11.

How to Create a Transparent Table in SE11

A transparent table is the most common dictionary object, because it has a one-to-one relationship with a physical table in the database. The steps below create one from scratch.

1. Open SE11: Enter transaction SE11, select the Database table radio button, type a name in the customer namespace (beginning with Z or Y), and choose Create.
2. Enter the short description and delivery class: On the Attributes tab, add a short text and set the delivery class, which tells SAP how the data behaves during a client copy or an upgrade. Delivery class A is used for application data, and C is used for customizing data.
3. Set the maintenance attribute: Choose Display/Maintenance Allowed so a maintenance view can later be generated with SE55 or SM30.
4. Define the fields: On the Fields tab, add MANDT as the first key field with data element MANDT, then add the business key fields. Every field is typed by a data element, which in turn refers to a domain, so the three levels described earlier are reused rather than redefined.
5. Maintain technical settings: Click Technical Settings (transaction SE13) and set the data class, for example APPL0 for master data, together with the expected size category. These values decide the tablespace and the initial size in the database.
6. Activate: Press Activate. Activation generates the physical table in the database and makes the definition usable in ABAP programs.

💡 Tip: Create foreign keys for every field that must be validated against a check table. The dictionary then enforces the relationship automatically, and no validation code is needed inside the program.

Once the table is active, it can be addressed directly from an ABAP program with Open SQL. The example below reads the standard dictionary table SCARR into an internal table and lists its contents.

REPORT zdemo_ddic_read.

* Internal table typed directly from the dictionary table SCARR
DATA: lt_scarr TYPE STANDARD TABLE OF scarr,
      ls_scarr TYPE scarr.

SELECT carrid carrname currcode
  FROM scarr
  INTO TABLE lt_scarr.

LOOP AT lt_scarr INTO ls_scarr.
  WRITE: / ls_scarr-carrid, ls_scarr-carrname, ls_scarr-currcode.
ENDLOOP.

Because the internal table is typed with TYPE STANDARD TABLE OF scarr, every field length and data type comes from the dictionary. If the table definition changes, the program picks up the change after activation without any edit.

Essential ABAP Dictionary Transaction Codes

The following transactions cover the daily work of defining, checking, and maintaining dictionary objects.

FAQs