The structure of the objects used in application development is mapped to

tables in the database system. The attributes of these objects correspond to the
fields of the table.
A table consists of columns (fields) and rows (entries). The table has a name
and different general attributes, such as delivery class and maintenance
authorization.
A field has a unique name and attributes; for example, a key field.
A table has one or more key fields. The values of these key fields uniquely
identify a table entry. These key fields collectively are called as a primary key.
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.
The basic objects for defining data in the ABAP Dictionary are as follows:

 Tables
Table is used to define transparent tables on the database system. You can
store business data in database tables.

 Domains
A domain is used for the technical definition of a table field (for example,
field type and length). It also describes the value range of a field by its data
type and length. The value range can be limited by specifying fixed values.

 Data element
A data element is used for the semantic definition, for example, a short
description of a table field. A data element also describes the meaning of a
domain in a certain business context. The data element primarily contains
the field help (F1 documentation) and the field labels on the screen.
A field is not an independent object. It is table-dependent. You can only
maintain a field within a table. You can enter the data type and number of
places directly for a field. No data element is required in this case. Instead,
you can choose a predefined type to specify the data type and number of
places.
You can specify the technical attributes of a data element even without
using a domain. To do so, enter the built-in data type and the number of
places directly.
Example of Two-Level Domain Concept
Table fields AIRPFROM (departure airport) and AIRPTO (arrival airport) have
the same domain S_AIRPID. Because both fields use the same domain and
contain airport IDs, they have the same technical attributes. Both table fields
have a different semantic meaning and use different data elements. Field
AIRPFROM uses data element S_FROMAIRP and field AIRPTO uses data
element S_TOAIRP.

Audio Transcript
The table SPFLI stores the flight schedule.
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.
ABAP programs can use a transparent table in the following ways:

 You can access the data contained in the table with OPEN SQL (or native
SQL).
 You can use the transparent table as a structure type when defining
variables (or more complex data types).
You can also create a structured type in the ABAP Dictionary for which there is
no corresponding object in the database. Such types are called structures.
Structures can also define the types of variables.

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 optimize 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 (tablespace)
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.
Particularly tables that include transaction data can have large gaps in their allocated
memory space due to the fast growth or frequent changing of the datasets as well as
the insertion and deletion of data records. This fragmenting of the data on the hard
drive of the database server always leads to repeated performance problems. Simple
measures, such as creating an index, cannot rectify these problems. You must
distinguish between fragmented indexes and fragmented tables.

Fragmented Indexes

Fragmented indexes can be defragmented by simply deleting them and then entering
them again. The database calculates the content and structure of the index again and
creates the necessary memory space in one piece in the storage medium. While the
index is being re-created by the database system, ABAP programs can still access the
table content.

AUDIO TRANSCRIPT
If the index belongs to a large table (> 100.000 data records), the index re-
creation process may take several minutes or even hours. While re-creating the
index, the index cannot be used for database access, which may lead to
increased response time when reading table data (due to Full Table Scan).

Fragmented Tables
To reduce the fragmentation of database tables you must convert the tables.
During table conversion 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.
In case the table has been grown unexpectedly fast, you should check and
adjust the size category in the technical settings before converting the table.
To avoid such fragmentations, you must choose the correct data class and size
category in the technical settings of the table.

AUDIO TRANSCRIPT
You cannot read or change the content of the table during the conversion process.
Depending on the table size, the conversion process can last for several minutes or
hours. In a productive environment, therefore, you should exercise care when
executing the conversion. The conversion should take place at times when the load on
the system is at a minimum, for example, at night.
The database system has different physical storage areas known as
tablespaces. The data class defines which tablespace is used for a specific
table within the database system.
The most important data classes are as follows:

 Master data
Master data is data that is seldom modified. An example of master data is
the data of an address file, name, address, and telephone number.

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

 Organizational data
Organizational data is 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
System data is the data that the SAP system needs. The program sources
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 4. 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 modifications to the entries of a table. To
activate logging, select the Log Data Changes checkbox in the technical settings.
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.
AUDIO TRANSCRIPT
In addition to transparent tables, where the definition in the ABAP Dictionary and in the
database are identical, there are pooled and cluster tables in the SAP system. Pooled
and cluster tables are characterized by the fact that several tables logically defined in
the ABAP Dictionary are combined in a physical database table (table pool or cluster).

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.

Pooled Tables
Audio Transcript
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 recognize that the intersection of the key
fields of TABA and TABB is empty. 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. Because of that 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. The DATALN field contains the length
of the VARDATA field

AUDIO TRANSCRIPT
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.
The primary advantage of pooled and cluster tables is that the data can be
stored in compressed form in the database. This reduces the memory required
as well as the network load.
Combining tables into pooled tables or cluster tables results in fewer tables and
fewer table fields (due to data compression). The result is that fewer different
SQL statements need to be carried out.
Because pooled and cluster tables are not stored as separate tables in the
database, administration is simpler. With cluster tables, functionally dependent
data is read together, which results in fewer database accesses. The main
disadvantage is that database functionality is restricted. It is not possible for
non-key fields to create an index. There are neither primary indices nor indices
on a subset of the key fields. The use of database views or ABAP JOINs is also
ruled out, as are Table Appends. You can access the data in pooled or cluster
tables only by OPEN SQL (not Native SQL).
The SAP database interface splits the WHERE clause of an SQL statement.
Only the WHERE condition for key fields is transferred to the database system.
ORDER BY (or GROUP BY) clauses are not transferred for non-key fields.
You need longer keys than semantically necessary for pooled tables.