Introduction to SAP ABAP Dictionary (SE11) — Complete Data Dictionary Guide

When people ask me what makes SAP different from writing traditional web applications with MySQL or PostgreSQL, my answer is always the same: The ABAP Data Dictionary (DDIC).

In standard web frameworks (like Node.js, Django, or Rails), developers write database migrations manually. You define table columns, foreign keys, and indexes directly in SQL scripts. If a front-end developer needs a field label in 5 languages, they write custom translation dictionaries in JSON files.

SAP takes a completely different approach.

SAP centralizes all data definitions, table structures, relationship rules, input validation ranges, search helps, screen titles, and multi-language translations inside one master repository: the ABAP Dictionary.

Transaction code: SE11

Every single standard table in SAP (like MARA for materials, VBAK for sales orders, or KNA1 for customers) and every custom table you create (ZTABLE) is defined inside SE11.

This guide provides a complete, beginner-to-advanced overview of the ABAP Dictionary, its 7 core object types, database table classifications, technical settings, and relationship rules.

---

What is the ABAP Dictionary?

The ABAP Dictionary is an active management repository embedded directly inside the SAP Application Server.

It acts as a middleware abstraction layer between your ABAP application programs and the underlying physical database system (HANA, Oracle, DB2, or SQL Server).

┌─────────────────────────────────────────────────────────────┐
│                 ABAP Application Programs                   │
│        (Reports, Function Modules, Classes, OData)          │
└──────────────────────────────┬──────────────────────────────┘
                               │ Reads/Writes via Open SQL
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                 ABAP Data Dictionary (SE11)                 │
│  Central Metadata Repository: Tables, Views, Data Elements  │
└──────────────────────────────┬──────────────────────────────┘
                               │ Translates to Native SQL
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                   Physical Database Layer                   │
│              (SAP HANA, Oracle, DB2, MS-SQL)                │
└─────────────────────────────────────────────────────────────┘

Because of this abstraction:

1. You write database queries in Open SQL (ABAP’s database-independent SQL dialect). The ABAP Dictionary automatically translates Open SQL into the native SQL dialect of your specific database server.
2. When you modify a table definition in SE11, SAP manages the database ALTER statements and table conversions automatically.
3. Field descriptions and labels defined in the Dictionary automatically populate across all user screens in whatever language the logged-in user speaks.

---

The 7 Core Objects in Transaction SE11

When you open transaction SE11, the initial screen presents seven primary object categories:

┌─────────────────────────────────────────────────────────────┐
│             ABAP Dictionary Initial Screen (SE11)           │
├─────────────────────────────────────────────────────────────┤
│ (•) Database table     [                            ]       │
│ ( ) View               [                            ]       │
│ ( ) Data type          [                            ]       │
│ ( ) Type Group         [                            ]       │
│ ( ) Domain             [                            ]       │
│ ( ) Search help        [                            ]       │
│ ( ) Lock object        [                            ]       │
└─────────────────────────────────────────────────────────────┘

Here is what each object category does:

---

1. Database Tables

Stores physical business records in rows (records) and columns (fields).

• Examples: MARA (Material Master), EKKO (Purchase Order Header), ZEMPLOYEE_MASTER.

---

2. Views

Virtual tables that combine data from one or more database tables using predefined joins or filters without storing redundant physical data.

• Types: Database Views, Projection Views, Maintenance Views, Help Views.

---

3. Data Types

Defines data type structures used across ABAP programs:

• Data Elements: Elementary data types describing semantic meanings and screen labels.
• Structures: Groupings of related fields (like an internal work area line).
• Table Types: Structure definitions for internal tables.

---

4. Type Groups

Global ABAP declaration pools (created via transaction TYPE-POOL) that define reusable global constants and type definitions for complex programs.

• Example: ABAP type group containing constants like ABAP_TRUE ('X') and ABAP_FALSE (' ').

---

5. Domains

Defines technical attributes of data: data type, field length, decimal positions, and allowed value ranges (fixed values, intervals).

---

6. Search Helps (F4 Input Help)

Provides user-friendly popup search windows when a user presses the F4 key on an input field.

• Types: Elementary Search Helps (single search path) and Collective Search Helps (multiple tabbed search paths).

---

7. Lock Objects

Manages concurrency control and data locking when multiple users try to edit the same record simultaneously.

• Generates function modules ENQUEUE_<NAME> (to lock a record) and DEQUEUE_<NAME> (to unlock a record).

---

The 3 Types of Database Tables in SAP

Not all tables in the ABAP Dictionary behave the same way on the physical database. SAP defines three distinct database table types:

                      ┌──────────────────────────────┐
                      │    Database Table Types      │
                      └──────────────┬───────────────┘
                                     │
      ┌──────────────────────────────┼──────────────────────────────┐
      ▼                              ▼                              ▼
┌──────────────────┐           ┌──────────────────┐           ┌──────────────────┐
│ Transparent      │           │ Pooled Table     │           │ Cluster Table    │
│ Table            │           │ (Legacy)         │           │ (Legacy)         │
│ (1:1 Mapping)    │           │ (N:1 Mapping)    │           │ (N:1 Mapping)    │
└──────────────────┘           └──────────────────┘           └──────────────────┘

---

1. Transparent Tables (1:1 Mapping)

A Transparent Table has a strict 1:1 relationship between the ABAP Dictionary definition and the physical database table.

• If a transparent table ZCUSTOMER has 10 columns in SE11, the database server (Oracle, HANA, SQL Server) has a physical table named ZCUSTOMER with the exact same 10 columns.
• Stores primary application business data (sales orders, master data, financial postings).
• Can be queried directly using native SQL database tools outside SAP.

All custom Z-tables you build in SE11 are Transparent Tables.

---

2. Pooled Tables (N:1 Mapping — Legacy ECC)

A Pooled Table combines multiple small, logical Dictionary tables into a single physical table pool in the database.

• Used in older SAP ECC systems for internal system configuration parameters and control data.
• Reduces database overhead for thousands of small system tables.

S/4HANA note: In SAP S/4HANA running on the HANA in-memory database, pooled tables are automatically converted into standard Transparent Tables to maximize column-store query speed.

---

3. Cluster Table (N:1 Mapping — Legacy ECC)

A Cluster Table stores continuous data streams from multiple related tables into a single compressed binary cluster record in the database.

• Famous standard example: Payroll evaluation results in SAP HR (B2 cluster) or financial document text segments (BSEG in legacy ECC).

S/4HANA note: In S/4HANA, major cluster tables like BSEG have been converted or mapped into transparent views on top of the Universal Journal (ACDOCA).

---

The 2-Tier Architecture: Domain -> Data Element -> Table Field

SAP enforces a two-tier structural hierarchy when creating table fields:

1. Domain (Technical Layer)
   └─ Data Type: CHAR, Length: 10, Uppercase: Yes
      │
      ▼
2. Data Element (Semantic Layer)
   └─ Labels: "Vendor", "Vendor Number", "Supplier ID"
      │
      ▼
3. Database Table Field (Application Layer)
   └─ Table: LFA1, Field: LIFNR

Why this 2-tier design matters:

1. Global Reusability: If you update the short text label on a Data Element, that change automatically propagates across hundreds of SAP screens and reports without modifying a single line of ABAP code.
2. Technical Consistency: If you change a Domain length, all referencing Data Elements and physical database table columns resize consistently.

---

Technical Settings in SE11

When creating a transparent table in SE11, you must configure its Technical Settings (menu button: Technical Settings or Ctrl + Shift + F1).

Technical Settings tell the database how to store and manage the table:

---

1. Data Class (Physical Storage Location)

Specifies the database tablespace area where the physical table will be allocated:

• APPL0 (Master Data): Data that changes infrequently (e.g., customer names, material master records).
• APPL1 (Transaction Data): Data that changes constantly during daily operations (e.g., sales orders, invoices, stock movements).
• APPL2 (Organizational / Customizing Data): Configuration tables defined during system setup (e.g., company code tables, plant codes).

---

2. Size Category

Defines the estimated initial data volume for table memory allocation (Size 0 = 0 to 8,000 records; Size 1 = 8,000 to 30,000 records; up to Size 9 for millions of rows).

---

3. Buffering Options

Buffering copies table records into the application server’s shared memory (RAM). When an ABAP program reads a buffered table, SAP reads from RAM instead of making a slow database query.

• Buffering Not Allowed: Default for large, constantly changing transaction tables (VBAK, BSEG).
• Buffering Allowed but Switched Off: Can be enabled later if needed.
• Buffering Switch On:
  • Full Buffering: Loads the entire table into RAM (best for small config tables under 500 rows).
  • Generic Buffering: Buffers groups of rows based on key fields.
  • Single-Record Buffering: Buffers individual rows as they are read.

---

Delivery Classes for Tables

The Delivery Class determines how table records behave during transport between systems (DEV → QAS → PROD) and system upgrades.

Delivery Class	Description	Use Case
A	Application Table (Master & Transaction Data)	User data, not transported during system upgrades
C	Customizing Table	Maintained by customers, transported via CTS
L	Temporary Data Table	Logs, temporary staging tables
G	Customizing Table (protected against SAP updates)	Customer configuration
E	Control Table	System control records
S	System Table	Delivered by SAP, updated only during SAP upgrades

For custom business application tables, choose Delivery Class A.

---

Step-by-Step: Navigating SE11 to Inspect a Standard Table

Let’s walk through inspecting standard table MARA (Material Master General Data).

1. Enter transaction /nSE11.
2. Select Database table radio button.
3. Type MARA and click Display.
4. You will see:
   • Fields tab: Lists technical field names (MATNR, ERSDA, ERNAM, MTART), Key flags, Data Elements, Data Types, and descriptions.
   • Delivery and Maintenance tab: Shows Delivery Class A and Table Maintenance Allowed status.
   • Input Help/Check tab: Shows foreign key relationships linking MARA to reference tables like T023 (Material Groups).
   • Indexes button: Displays primary key index MARA~0 and secondary indexes created to speed up queries.

---

Quick Checkpoint — Test your understanding

Question 1: What is the fundamental difference between a Transparent Table and a Pooled/Cluster Table in SAP?

Answer: A Transparent Table has a 1:1 relationship between the ABAP Dictionary and the physical database table. Pooled and Cluster tables have an N:1 relationship, merging multiple Dictionary tables into a single physical database pool or cluster.

Question 2: Which technical setting in SE11 determines whether table data is cached in the application server’s RAM to speed up read access?

Answer: Table Buffering (Full, Generic, or Single-Record Buffering).

Question 3: What two function modules are generated when you create a Lock Object (E...) in transaction SE11?

Answer: ENQUEUE_<NAME> (to set locks) and DEQUEUE_<NAME> (to release locks).

---

Common mistakes to avoid

Mistake 1: Forgetting to activate dependent objects. If you modify a Domain, you must activate the Domain first, then re-activate the referencing Data Element, then re-activate the database table. In SE11, use the Mass Activation tool (Ctrl + Shift + F3) to activate dependent objects automatically.

Mistake 2: Enabling Full Buffering on rapidly changing transaction tables. Full buffering a table with 500,000 rows that gets 1,000 updates an hour will flood application server RAM and degrade system performance due to continuous buffer invalidation messages. Reserve full buffering for static configuration tables.

Mistake 3: Modifying standard SAP tables directly without append structures. Never add custom fields to standard SAP tables (MARA, VBAK) by modifying the standard table structure. Use Append Structures (SE11 → Display Table → Enhancements → Append Structure). Append structures survive system upgrades cleanly.

Mistake 4: Not maintaining field labels on Data Elements. Leaving short, medium, and long field labels blank on custom data elements means screens and ALV report headers displaying those fields will show blank column titles or cryptic technical names like ZFLD01.

---

Related reads on this site:

• What is a Domain in SAP ABAP? — deep dive into technical domain definitions
• SAP ABAP Data Element — building semantic field descriptions
• SE11 Transaction Code in SAP ABAP — step-by-step table creation tutorial