Creating New Data Classes in SAP

DATA CLASSES IN SAP

Step 1: Checking Existing Data Classes

When I needed to create a new data class, the first place I looked was the DDART table. This table lists all active and created data classes in the SAP system. Running a simple query in SQL*Plus gave me visibility into what was already defined:

sql

SQL> select * from SAPSR3.DDART;
SQL> desc SAPSR3.DDART;

The structure showed two key fields:

• TABART (VARCHAR2(15), not null) → represents the data class name

• DDCLASS (VARCHAR2(9), not null) → represents the category

Step 2: Ensuring Tablespaces Are Known

Before adding anything new, I confirmed that the relevant tablespaces were already recognized by the SAP system. This is critical because each data class must be mapped to a physical memory area (tablespace). If the tablespace isn’t registered, the new data class won’t function properly.

Step 3: Inserting a New Data Class

Using SQL*Plus, I inserted a new entry into DDART to define the data class:

sql

SQL> insert into SAPSR3.DDART (TABART, DDCLASS) 
     values ('MY_DATA_CLASS', 'CATEGORY');
SQL> commit;

This step effectively registered the new data class in the SAP dictionary.

Step 4: Linking to Tablespaces

Creating the entry alone isn’t enough. The new data class must be connected to the memory area. For this, I updated the TAORA and IAORA tables. These tables define the mapping between data classes and tablespaces.

• TAORA → holds assignments for standard tables

• IAORA → holds assignments for index tables

I used SQL*Plus again to insert or update the mappings so the new data class pointed to the correct tablespace.

Additional Notes from My Experience

• Validation: After committing changes, I always validated by checking if the new data class appeared in DDART and was correctly linked in TAORA/IAORA.

• Transport Requests: In real SAP environments, changes to DDART, TAORA, and IAORA should be captured in transport requests to move them safely across DEV → QA → PROD systems.

• Consistency: It’s important to ensure that the data class naming convention aligns with SAP standards, otherwise inconsistencies can cause confusion in administration.

• Performance Impact: Assigning data classes to the right tablespaces can improve performance, especially in large systems where table distribution across disks matters.

• Security: Only DBAs or SAP Basis administrators should perform these changes, since incorrect mappings can lead to data persistence issues.