10.3    Data Types

By using the Data Types radio button in the ABAP Data Dictionary initial screen, we can create global data types such as data elements, structures, and table types. You’ve seen how to create these global types at various points in previous chapters, so this section will focus on the additional options that can be maintained for these global types centrally and can then be inherited into programs automatically.

10.3.1    Data Elements

A data element describes an elementary data type or a reference data type. It allows you to maintain both technical and semantic attributes. Semantic attributes are significant for screen fields that refer to this data element. For example, the screen field can automatically import input help ((F4) help) or field help ((F1) help) from a data element. For ABAP data objects that refer to the data element, the semantic attributes hold no significance.

For an elementary data type, technical specifications are derived from a domain or directly maintained in the data element. Similarly, for reference data types, a reference to a global class or interface can be maintained or a reference to a predefined type can be maintained.

Figure 10.52 shows the Data Type tab of the data element, where the technical attributes can be maintained by selecting the relevant radio button (i.e., Elementary Type, Predefined Type, or Reference Type).

Data Type TabData types

Figure 10.52    Data Type Tab

There are various semantic attributes that can be maintained for the data elements. Under the Data Type tab and in the application toolbar of the Dictionary: Change Data Element page, the following attributes can be maintained:

Under the Further Characteristics tab, as shown in Figure 10.54, the following options can be maintained:

Most of the semantic attributes of data elements are significant for UI elements (screen elements), but some may be useful for database fields (such as documentation). We recommend creating separate data elements for UI fields and database table fields.

Field labels can be maintained for the data element under the Field Label tab (see Figure 10.55); these labels are used as column headings for lists on screens. You can maintain short, medium, and long headings, plus a header with a freely definable length field.

Field Label

Figure 10.55    Field Label

10.3.2    Structures

We discussed creating structures in Chapter 5, and most of the steps involved in creating structures are similar to those for creating database tables, discussed earlier in this chapter in Section 10.1.1.

A structure can include elementary data types, other structures, or table types. Structures can be nested to any depth. Structures allow you to centrally maintain the fields when similar fields are used in multiple objects (e.g., programs, function module interfaces, etc.).

The components of a structure can include elementary types, reference types, or boxed types, as shown in the available typing methods in Figure 10.56.

Typing Method

Figure 10.56    Typing Method

The following list defines each of these types:

Reference types don’t take any initial memory space, so boxed types fall somewhere between elementary types and reference types. In other words, the initial memory of boxed types is much lower than elementary types but greater than reference types.

Currently, only static boxes are supported. Static types are boxed components for which components are known statically. Only a substructure of a structure or attributes of classes or interfaces can be defined as boxed. Boxed types are defined in programs by adding BOXED to the TYPES statement, as shown in Listing 10.4.

TYPES : BEGIN OF ty_lfa1
         Lfa1 TYPE lfa1 BOXED,
        END OF ty_lfa1.

Listing 10.4    Defining Boxed Component Using TYPES

The efficiency of a boxed structure is due to the initial value sharing in which all occurrences of similar data are referenced to the same initial memory. However, the initial value sharing is revoked under the following circumstances:

Once the initial value sharing is revoked, the internal reference will reference an instance of the structure.

Boxed types reduce the memory requirement of structures that are used more than once. For example, if an internal table has a substructure, then each row will increment the memory store even if the row is initial. If the substructure is defined as boxed type, then it won’t require multiple memory stores, because each row can point to the same initial memory as long as only read accessed is permitted.

Figure 10.57 shows the initial memory allocation of structures, as shown in the debugger window, using the normal types, boxed types, and reference types defined in Listing 10.5. In Listing 10.5, we’ve defined three structures of each type to highlight how the memory is allocated individually when the object of the same type is repeated.

As you can see in Figure 10.57, boxed types have a much smaller memory footprint then normal types. Boxed types are deep structures—that is, structures that contain table types.

*Normal type
TYPES : BEGIN OF ty_kna1,
  kna1 TYPE kna1,
END OF ty_kna1.
*Boxed type
TYPES : BEGIN OF ty_kna1_b,
  kna1 TYPE kna1  BOXED,
END OF ty_kna1_b.
*Data declarations using normal type
DATA : st_kna1_1 TYPE ty_kna1.
DATA : st_kna1_2 TYPE ty_kna1.
DATA : st_kna1_3 TYPE ty_kna1.
*Data declarations using boxed type
DATA : st_kna1_b_1 TYPE ty_kna1_b.
DATA : st_kna1_b_2 TYPE ty_kna1_b.
DATA : st_kna1_b_3 TYPE ty_kna1_b.

*Data declaration using reference type
DATA : st_kna1_o_1 TYPE REF TO ty_kna1.
DATA : st_kna1_o_2 TYPE REF TO ty_kna1.
DATA : st_kna1_o_3 TYPE REF TO ty_kna1.
BREAK-POINT.

Listing 10.5    Different Types of Components

Memory Allocation for Different Types of ComponentsMemoryallocation

Figure 10.57    Memory Allocation for Different Types of Components

10.3.3    Table Types

Table types describe the structure and functional attributes of internal tables. You learned how to create a global table type in ABAP Data Dictionary in Chapter 7, but we limited our discussion there in order to quickly define a table type with default options. In this section, we’ll discuss table types in greater detail and go over the various options that are available while defining a table type in ABAP Data Dictionary.

The Line Type tab of the Dictionary: Change Table Type screen in ABAP Data Dictionary (see Figure 10.58) allows you to maintain the line type for the table type. This line type then defines the components of the table type. Internal tables that refer to this table type will have a row type as defined by the line type of the table type.

There are multiple options to define the line type of the table type:

Under the Initialization and Access tab (see Figure 10.59), attributes such as the type of table and initial size can be maintained. The available options are as follows:

The Primary Key tab (see Figure 10.60) allows you to define the primary key. This property will then be set for internal tables that refer to this table type. The available options on this screen are as follows:

Beyond the primary key, additional secondary keys can be specified under the Secondary Key tab (see Figure 10.61). You can define up to fifteen secondary keys for the table type. Each secondary key should have a unique name. The name of the secondary key can’t be PRIMARY_KEY or LOOP_KEY. The secondary key can be either a sorted key or a hash key. If it’s sorted key, it can be unique or non-unique; a hash key is always unique. The key definition for a secondary key is defined by the entire table row if the line type is not a table type or doesn’t contain a table type as a component.

In this section, we discussed using data types, including data elements, structures, and table types. In the next section, we’ll see how type groups are used and maintained.

Secondary Keys

Figure 10.61    Secondary Keys