SAP ABAP Data Dictionary: Domains, Data Elements, Tables, Views and Search Helps

This guide covers classic ABAP Dictionary concepts, commonly explored in SE11 on compatible SAP systems. Development tools and supported objects vary by release. For ABAP Cloud work, check the language version and released-object rules instead of assuming every classic object is available.

Domain vs data element: technical format and business meaning

A domain is a reusable definition of technical properties such as data type, length and value range. A data element describes what a field means, including its labels and documentation. Several data elements can share a domain when their technical representation is the same but their business meaning differs.

For a fictional training application, a four-character department code could use domain ZTR_DEPT_CODE and data element ZTR_DEPARTMENT. A table field typed with that data element can reuse the department label and documentation. These names are examples, not delivered SAP objects. SAP also allows a data element to specify technical attributes directly; a separate domain is not compulsory for every elementary definition. See SAP’s domain documentation and data-element documentation.

Table, structure and table type: what stores data?

• Transparent database table: defines persistent storage. Its primary key identifies a row; field types describe the stored columns.
• Structure: describes a grouped set of components. Defining a structure does not create a database table to store its values.
• Table type: describes an internal table’s row type, category and keys. A program can declare an in-memory data object using this type.

A program might read a database table into an internal table and map each result into an output structure. These objects cooperate, but they are not interchangeable. Continue with the standard, sorted and hashed internal-table guide when choosing the runtime collection.

A small DDIC model to practise

Use a development sandbox and synthetic records only. Suppose a fictional application records equipment allocated to a training department. Agree the following design before creating objects:

1. Department master: define a custom department table containing an identifier and name. For a client-dependent design, include the client field in the key and map client fields consistently in relationships.
2. Equipment table: use an equipment identifier as the business key within the client. Add department code and a meaningful equipment description.
3. Reusable types: assign deliberate data elements to the business fields. Reuse the department’s technical definition instead of creating conflicting lengths.
4. Relationship: define the equipment department’s foreign key against the department check table, with the appropriate field mapping.
5. Value help: let the learner search departments by identifier and name and return the selected identifier to the input field.

Record why each field exists, whether it is mandatory in the application and how an invalid value will be handled. A neat table layout does not replace application validation or authorisation checks.

Value table vs check table: a common mistake

A domain’s value table is a proposal used when defining a foreign-key relationship. Entering it alone does not implement the check. A check table participates in the actual Dictionary foreign-key definition. SAP explicitly documents this distinction in Value Table.

Do not treat a DDIC relationship as permission to skip validation in a custom interface. Establish which input path performs the check and test that path. A screen using Dictionary checks and a custom program performing database writes are different execution paths.

Search help vs validation

Search help assists selection; validation decides whether a submitted value is acceptable. In a classic input screen, F4 help can present candidate departments with readable names. The field should receive the identifier, not accidentally receive the description. An elementary search help defines one search path; a collective search help groups alternatives. SAP’s Dictionary search-help guide explains reuse in Web Dynpro ABAP.

If help is missing, inspect the field’s typing, search-help assignment and parameter mapping. If help returns the wrong field, inspect the export mapping. Test an unknown department entered manually as well as a valid one selected from the list.

Views, lock objects and modern CDS

A view presents a selected or combined representation of data. Classic Dictionary view types have different purposes; a maintenance view is not simply a reporting query. Learn the object’s intended use before selecting it for a task.

A lock object defines an application-level locking interface for coordinated updates. Programs must use the locking mechanism correctly; defining the object alone does not make every writer cooperate. For the equipment exercise, describe what should happen when two users attempt to allocate the same equipment at once.

CDS introduces a different modelling workflow from classic Dictionary views. Do not assume a classic SE11 view and a CDS view entity are the same artifact. Use the S/4HANA, CDS and OData guide as the next step after understanding basic types and relationships.

Activation and change-safety checklist

1. Check dependencies and activate the required domains, data elements and dependent objects in a valid order.
2. Use the activation log to find the specific inactive object or incompatible field definition.
3. Review where-used results before changing a shared type. A shorter field can affect stored data and consuming programs.
4. Review keys, client handling, delivery class and technical settings with the sandbox’s requirements; do not copy settings from an unrelated table.
5. Test valid input, invalid input, missing values, duplicate keys and value-help return values.
6. Document transport dependencies and repeat the checks in the target test environment.

SAP’s database-table definition procedure is a reference for object setup. Do not experiment with destructive changes to production tables as a learning exercise.

Interview questions to practise

Can two data elements use the same domain?

Yes. Explain their shared technical representation and their different business labels or documentation.

Does a structure persist records?

No. It defines a composite type. Persistence needs a suitable database object and program logic.

Why can an invalid value still appear in an interface?

Investigate the actual write path and its checks. Value help is not a security boundary, and a domain value-table proposal is not a complete validation implementation.

Related SAP ABAP guides

• Enhancements, BAdIs and user exits
• Smart Forms and Adobe Forms
• IDocs, BAPIs, RFC and APIs
• ABAP Objects and exception handling

Build practical ABAP foundations

Explore SAP ABAP training in Vizag and Visakhapatnam for the course overview and enquiry options. This article’s fictional exercise is a learning suggestion, not a claim about a delivered client project.