ABAP Dictionary Notes

You must specify a reference table for fields containing a currency (data type CURR) or quantity (data
type QUAN). A reference table must contain a field (reference field) with the format for currency keys
(data type CUKY) or the format for units (data type UNIT). The field is only assigned to the reference field
at program runtime.

A table is automatically created in the database when a transparent table is activated in the ABAP
Dictionary.

At this time, the database-independent description of the table in the ABAP Dictionary is translated into
the language of the database system used.

The database table has the same name as the table in the ABAP Dictionary. The fields also have the
same name in both the database and the ABAP Dictionary. The system converts the data types in the
ABAP Dictionary to the corresponding data types of the database system.

The order of the fields in the ABAP Dictionary can differ from the order of the fields in the database.
Therefore, you can insert new fields without having to convert the table. When you add a new field, the
system adjusts the list of fields by changing the database catalog. This mechanism is called ALTER TABLE.

The include mechanism exists to avoid redundant structure definitions. You can re-use structures by
including them in other structures or tables.

A table cannot be included in another table.

Includes may contain other includes.

Foreign keys defined in the INCLUDE structure are passed on to the including table.

The technical settings determine the storage requirements and the access behavior of database tables.
When you activate the table in the ABAP Dictionary, the system automatically creates the table in the
database system. The technical settings define how the table is handled when it is created in the
database system. The settings for the data class and size category determine the storage area to be
selected and the expected table size. The settings for buffering define whether and how the table should
be buffered. You can define whether changes to the table entries should be logged.

Tables that include transaction data can have large gaps in their allocated space due to fast growth or
frequent data record changes, such as inserting or deleting the data records. This data fragmentation on
the database server always leads to potential performance problems. Indexes can also be fragmented
due to frequent or mass data record changes.
To reduce the fragmentation of database tables, one of the possible solutions is to rebuild the tables.
During the rebuild process, the SAP system creates a new table and transfers the data to this table.
Afterwards the system deletes the old, fragmented table and replaces it with the new one.

You cannot read or change the content of the table during the rebuild process. Depending on the table
size, the process can last for several minutes or hours. In a productive environment, therefore, you
should exercise care when executing the procedure. The conversion should take place at times when the
load on the system is at a minimum.

To minimize fragmentations, you must choose the correct data class and size category in the technical
settings of the table.

The database system has different physical storage areas. The data class defines where the table resides
within the database system.

The most important data classes are as follows:

Master data: data that is seldom modified. An example of master data is the customer master data,
which includes customer name, company address, and company details.

Transaction data: the data that is frequently modified. An example is the material stock of a warehouse,
which can change after each purchase order.

Organizational data: the data you can define when you customize and install the system, and is seldom
modified afterwards. The country keys are an example.

System data: the data that the SAP system needs. The system configurations are an example.

The size category describes the expected storage requirements for the table in the database. When the
system creates a table in the database, it reserves an initial extent. The size of the initial extent is
identical for all size categories. If the table needs more space for data at a later time, further extents are
added. These further extends have a fixed size that depends on the size category specified in the ABAP
Dictionary.

You can choose a size category from 0 to 9. Depending on the database system, each size category has a
fixed extent size.

Correctly assigning a size category ensures that you do not create a large number of small extents that
may increase table fragmentation. At the same time, do not choose a size category that is too large and
wastes storage space.

You can use logging to record and store changes to the entries of a table. Selecting the flag in the ABAP
Dictionary is not sufficient to trigger logging. Logging is only performed if it is enabled in the system
profile parameter rec/client.
Settings for the parameter rec/client:

- ALL => log all clients

- 000[...] => log specified clients only

- OFF => logging is deactivated in this system

In DB-Specific properties tab of the technical settings you can change the storage type, depending on
the database you use.

Conceptually, a relational database table is a two-dimensional data structure, with cells organized in
rows and columns. SAP NetWeaver 7.4 uses both the column and row store of SAP HANA. If you use the
data dictionary to create a table for SAP HANA, it will be a table in column store by default, in which the
database serializes all of the values of a column together, then the values of the next column, and so on.

In cluster tables, you store functionally dependent data, which is divided among different tables, in one
database table. Accordingly, the intersection of the key fields of the cluster tables form the key of the
table cluster, known as the cluster key.

The data dependent on one cluster key is stored in the VARDATA field of the table cluster. If the
VARDATA field does not have the capacity to take on all the dependent data, the database interface
creates an overflow record. The PAGNO field guarantees the uniqueness within the table cluster.

The database interface compresses the content of the VARDATA field. Accordingly, the VARDATA field
contains a description for decompressing its data. The TIMESTAMP and PAGELG fields contain
administrative information.

A table pool, as opposed to a table cluster, stores data records from the tables defined in the ABAP
Dictionary that are not dependent on one another. You would like to combine small SAP tables in one
database table.

In the example in the figure, you can see there are no common key fields between TABA and TABB.
Despite this, the TABAB table pool stores the data records from TABA and TABB.

The key for a data record of the TABAB table pool consists of both the TABNAME and VARKEY fields. The
TABNAME field assumes the name of the pooled table. The VARKEY field consists of the concatenation
of the key fields of the pooled table. For this reason, the key fields of a pooled table must be of the type
C.

The database interface stores the non-key fields of the pooled tables in an unstructured way, in the
VARDATA field in compressed form. The DATALN field contains the length of the VARDATA field.
In the pooled table, the technical settings are exactly the same as transparent table. The only addition is
the Convert to transparent table indicator. You can convert the pooled table into a transparent table
with this indicator

The following points are important when indexes are created:

An index should be as small as possible. Use only those fields that are frequently used in the WHERE
clause of SELECT statements.

An index must contain significant fields only. A field is significant if it contains considerable data content
that can help to identify a table row.

Whenever you insert, update, or delete database content, the system must adjust all of the assigned
indexes. This is time- consuming. Tables whose contents are frequently changed must not have too
many indexes.

Indexes on a table are as disjunct as possible.

The most frequently selected fields should be at the first positions in the index.

The field order in the WHERE clause of SELECT statements should match the index field order. This
ensures that the index is used properly by the database system.

The differences between the different types of index are as follows:

Primary Index: contains the key fields of the table. The primary index is always unique. When a table is
activated for the first time, the system automatically creates the primary index.

Secondary Index: useful if a large table is often accessed with a selection on fields other than the table's
key fields. Most of the secondary indexes are non-unique but unique secondary indexes are also
possible.

Extension Index: part of the enhancement framework. Extension indexes are automatically copied over
during upgrades and no modification adjustment takes place.

When you create an index, you can choose between a non-unique index and a unique index. You can
also specify whether it should be created on the database when it is activated.

Uses of unique indexes are as follows:

- The fields of a unique index identify each record in the table uniquely.

- When you insert or update table data, the system enusres that there are no duplicate entries in the
databse table.
Full buffering

With full buffering, the table is either completely in the buffer or not at all. Whenever a record of the
table is accessed, all of the table records are loaded into the buffer.

When you decide whether to fully buffer a table, you must take the table size, the number of read
accesses, and the number of write accesses into consideration. The smaller the table is, the more
frequently it is read and the less frequently it is written to, the better it is to fully buffer the table.

Full buffering is also recommended for tables that have frequent accesses to records that do not exist.
The buffer can quickly check if a record exists, as all the records of the table reside in the buffer.

Generic buffering

When one record of the table is accessed, all the records whose generic key fields agree with this record
are loaded into the buffer. The generic key is a left-justified part of the primary table key. The generic
key must be selected so that the generic areas are not too small, which would result in too many generic
areas. Full buffering is preferred for the table that has few records for each generic area. If you choose a
large generic key, too much data will be invalidated if there are changes to table entries, which would
have a negative effect on the performance.

A table can be generically buffered if only certain generic areas of the table are usually needed for
processing.

Client-dependent, fully buffered tables are automatically generically buffered. The client field is the
generic key. This is based on the assumption that not all of the clients are actually used on one
application server. Language-dependent tables are an example of generic buffering. The generic key
includes all the key fields up to and including the language field.

The generic areas are managed in the buffer as independent objects. The generic areas are managed in
the same way as fully buffered tables.

Single-record buffering

Single-record buffering saves storage space in the buffer compared to generic and full buffering.

The overhead for buffer administration is higher than for generic or full buffering.

Considerably more database accesses are necessary to load the records than for the other buffering
types.
In single-record buttering, the records that are actually accessed with SELECT SINGLE are loaded into the
buffer.

Single-record buffering is recommended particularly for large tables in which only a few records are
accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE
bypass the buffer and directly access the database.

If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load
the record. If the table does not contain a record with the specified key, this record is recorded in the
buffer as non- existent. This prevents a further databse accesses if you make another access with the
same key.

If an application program accesses data in a table, the database interfaces determine whether this data
is located in the buffer of the application server. In this case, the data is read directly from the buffer. If
the data is not in the buffer of the application server, it is read directly from the database and loaded
into the buffer.

A domain describes the value range of a field by specifying its data type and field length. If only a limited
set of values is allowed, these can be defined as fixed values.

You can define the value range of the domain by specifying fixed values. Fixed values are used as value
help (F4) and input validation for the fields on the screen.

Fixed values can either be listed individually or defined as an interval.

You can create appends for fixed values. A fixed value append is assigned to exactly one domain. A
domain can have multiple fixed value appends.

Fixed value appends are modification-free enhancements of the SAP standard. The system automatically
copies over fixed value appends during upgrades.

The following settings exist for the type of foreign key fields:

Not specified

No information about the kind of foreign key fields can be given.

No key fields/candidates

The foreign key fields are neither primary key fields, nor do they uniquely identify a record of the foreign
key table (key candidates). Therefore, the foreign key fields do not (partially) identify the foreign key
table.

Key fields/candidates
The foreign key fields are either primary key fields of the foreign key table or they uniquely identify a
record of the foreign key table (key candidates). Therefore, the foreign key fields (partially) identify the
foreign key table.

Key fields of a text table

The foreign key table is a text table of the check table. The key of the foreign key table is identical to the
key of the text table, but has an additional language key field. This is a special case of the category Key
fields/candidates.

A text table has all the key fields of the normal table along with an extra key, which is the language key
field.

For each table, you can define one foreign key of type ‘text table’ only. This means that each table can
have a maximum of one text table assigned to it.

The mass activation is automatically called when a transport request is imported into a system. The
mass activation gets a list of ABAP Dictionary objects. All objects in the list are then activated in one
action. The mass activation program has two advantages over activating objects one at a time: If
dependent tables are affected by changes to different domains or data elements, they have to be
reactivated only once.

Related objects, for example, a domain and its associated value table, can be activated together. If you
are activating objects individually, you need to activate each of the objects separately and in the correct
sequence. For example, before activating a table, you must activate all domains and data elements to
which the table fields refer.

Where-Used List

If an object is likely to be used by a large number of objects, you can perform the search in the
background.

ABAP programs can only access a database table correctly if the runtime object of the table is consistent
with the structure of the table in the database. Each time the table is changed in the ABAP Dictionary,
the system checks during the activation (when the runtime object is updated) whether it has to adjust
the database object to the changed ABAP Dictionary definition of the table.

The database structure does not have to be changed for certain changes to the ABAP Dictionary. For
example, you do not have to change the database structure when the order of the fields (except key
fields) in the ABAP Dictionary is changed. In this case, the changed structure is activated in the ABAP
Dictionary and the database structure remains unchanged.
The database table can be adjusted to the changed definition in the ABAP Dictionary by doing one of the
following:

Deleting the database table and creating it again. The table in the database is deleted, the inactive table
is activated in the ABAP Dictionary, and the table is created again in the database. The existing data in
the table is lost.

Changing the database catalog ALTER TABLE. The definition of the table in the database is simply
changed. The existing data is retained. However, indexes of the table may have to be built again.

Converting the table. This is the most time-consuming way of adjusting a database table.

Table Convection

If the table does not contain any data, it is deleted from the database and created again with its new
structure. If data exists in the table, the system attempts to adjust the structure with ALTER TABLE. If the
database system used is not able to do so, the structure is adjusted by converting the table.

Conversion is the most resource-intensive method of adjusting structures. However, structural changes
involving changes to the database catalog can also result in costly internal data reorganizations in some
database systems. You must not adjust the database structure during production. All applications that
access the table must be deactivated during the structural adjustment. Since the table data is not
consistent during the structural adjustment (in particular during conversion), programs may behave
incorrectly when they access this data.

The procedure actually used by the system in a particular case depends on the following:

- Type of structural change

- Database system used

- Whether or not data already exists in the table

A terminated conversion can be analyzed with the database utility (transaction SE14) and then resumed.

You can usually find the precise reason for the termination in the object log. If the object log does not
provide any information about the cause of the error, you have to analyze the System Log (transaction
SM21) or the ABAP Dump Analysis (transaction ST22)

Append Structures

When a table is activated, all the active append structures for the table are found and their fields are
appended to the table. If an append structure is created or changed, the table to which it is assigned is
also activated.

If you copy a transparent table in the ABAP Dictionary to which an append structure has been added,
the fields of the append structure are converted to normal table fields.
If you copy a transparent table in the ABAP Dictionary to which an append structure has been added,
the fields of the append structure are converted to normal table fields.

Restrictions regarding append structures:

- No append structures may be created for pooled and cluster tables.

- Tables containing a long field (data type LCHR or LRAW) cannot be extended with appends structures.

- This extension is not possible because long fields have to be the last field of the table.

- The fields in the append structure must be in the customer namespace beginning with YY or ZZ. Using
the customer namespace prevents name conflicts with future table fields delivered by SAP.

- If, as a partner, you have your own reserved namespace, it is recommended that you choose the
names for your append structures from your namespace.

Structures and tables that have been defined by SAP in the ABAP Dictionary can be enhanced by the
customer in the following ways:

Customizing includes: certain places within a standard structure or table are reserved by SAP for
customer enhancements. The Customizing environment supports customers using these Customizing
includes.

Using appends: any fields without previous reservation are appended to the end of structures or tables.

Enhancementls using append structures may cause the following problems:

Structure enhancements affect not only the enhanced structure itself, but also all dependent structures
that use the enhanced structure as an include or substructure.

However, when the enhanced structure is included in a dependent structure, this can lead to fields in
the dependent structure being displaced. The field displacement can prevent ABAP programs from
reading the structure correctly.

In programs with de-activated Unicode checks, structure enhancements can lead to syntax and runtime
errors. These errors are generally found in type checks and in connection with deep structures.

In programs with activated Unicode checks, structure enhancements additionally affect value
assignments, operand checks, and accesses with offset and length. Enhancements may also cause some
issues because the fragment view is changed, and checks in assignments and comparisons that are
based on this are affected as a result.

Database Views

The field names of the underlying table fields are used as field names in the view. However, you can also
choose a different field name. You need to choose a different field name if two fields with the same
name are to be copied to the view from different tables. In this case, you must choose a different name
for one of the two fields in the view.

To include a table in a view, you must enter the character "*" in the field View field in the view
maintenance, the name of the table to be included in the field Table, and the character "*" again in the
field Field name.

If you do not want to insert a field of the included table in the view, you must enter a "-" in the View
field, the name of the included table in the Table field, and the name of the field to be excluded in the
Field name field.

By using an append view, you can include fields of the base tables of a database view in the view
without modifications.

Maintenance Views

In a one-step maintenance dialog, the data of the table rows is represented as a table control. The key
fields have a gray background and are not intended for changes. The function fields have a white
background and can be changed.

In a two-step maintenance dialog, double-click a table line to present the selected data record in a clear
form.

Generated maintenance dialogs should not be used regularly by a large number of users. These dialogs
are intended to enable a limited number of users to quickly and easily maintain customizing tables and
customer tables containing small to medium volumes of data.

Append Search Helps

The append search help is in the customer namespace. Normally, the search helps included in the
append search help are also created by the customer and are in the customer namespace. However, the
required elementary search help might already be provided by SAP, in which case, customers only have
to add it to their own append search helps.

SAP collective search helps often contain elementary search helps that are not required by all
customers. The search helps you do not need can be hidden using an append search help. For this
purpose, the corresponding search help must be included in the append search help and the hidden flag
must be set.

Search Help Exits