Explain ABAP Dictionary (Data Dictionary / DDIC) in SAP

8 / 65

ABAPbeginner

ABAP Dictionary (Data Dictionary / DDIC)

Central repository for defining database tables, structures, data elements, domains, and views used across ABAP programs.

The ABAP Dictionary (SE11) is where SAP's data model is defined — tables, fields, types and their relationships.

A domain is like a raw material spec (steel, grade, dimensions); a data element is a labeled component built from that material (a bolt of that steel with a part number and description) usable in many different assemblies while sharing the same underlying material spec.

Key Concepts

Its central idea is that a field's definition is written once and referenced everywhere, rather than repeated.

Three layers, from technical to business meaning.

    DOMAIN         the technical type      CHAR 10, with allowed values
       ^
    DATA ELEMENT   the business meaning    "Material Number", field labels, F1 help
       ^
    TABLE FIELD    the use                 MARA-MATNR refers to that data element

So MATNR is defined once. Every one of the thousands of tables and programs using a material number points at the same data element, which points at the same domain.

MATNR

Why the layering pays for itself. Lengthen the domain and every field derived from it changes together. Fix a typo in the field label and every screen showing it is corrected.

Type a field as CHAR 18 directly instead of referencing the data element, and you have created a field that no longer changes with the rest of the system — the classic mark of inexperience, and the cause of truncation bugs when SAP lengthens a field.

CHAR 18

Table types. A transparent table maps one-to-one to a real database table; nearly everything is transparent today. Pooled and cluster tables stored several logical tables inside one physical table, which saved space on old databases at the cost of being unreadable by SQL. On HANA these have largely been converted to transparent, which is why reporting directly on tables such as BSEG became possible.

BSEG

Views combine tables without duplicating data. A database view joins tables; a projection view hides fields; a maintenance view provides an editable screen; a help view supports value help. In S/4HANA, CDS views have taken over most of this work.

Foreign keys and check tables give you validation for free. Declare that MARC-WERKS refers to T001W and the field is validated on entry, with the check table's contents offered as value help — no code.

MARC-WERKST001W

Search helps are the F4 dropdowns users rely on. They can be attached to a data element, so every field using it gets the same help everywhere.

Adding your own fields to an SAP table. Two upgrade-safe mechanisms:

    APPEND STRUCTURE   your fields are appended to the end of an SAP table
    CUSTOMIZING INCLUDE  SAP left a named slot (CI_*) for you to fill

Both keep your fields separate from SAP's definition, so an upgrade that adds SAP fields does not collide with yours. Adding a field by editing the SAP table directly is a modification, and it will be flagged at every upgrade.

One practical note. Changing a table that already holds data can require a table conversion — the database copies the data into the new structure. On a large table that takes time and locks it, so these changes are planned into a downtime rather than transported casually.

What the interviewer is probing.1. "What is the difference between a data element and a domain?" Probing: the layering. Stalls: "Nothing." Moves up: the domain defines the technical type and value range; the data element adds the semantic meaning and field labels.

2. "Why do search helps belong in DDIC?" Probing: the benefit. Stalls: "Convenience." *Moves up:* defined once on the data element, they appear in every screen and report using that field without extra code.

3. "What does a table maintenance generator give you?" Probing: the practical answer. Stalls: "A table." Moves up: a maintenance dialog for a custom table, with transport linkage so configuration moves through the landscape.

4. "What is the risk of changing an active table's key?" Probing: the hazard. Stalls: "None." Moves up: it forces a table conversion that rewrites the data, which on a large table means downtime and a real risk of failure mid-way.