The structure of the objects of application development are mapped in tables on the underlying relational database.
The attributes of these objects correspond to fields of the table.
A table consists of columns (fields) and rows (entries). It has a name and different attributes, such as delivery class and maintenance authorization.
A field has a unique name and attributes; for example it can be a key field.
A table has one or more key fields, called the primary key.
The values of these key fields uniquely identify a table entry.
The basic objects for defining data in the ABAP Dictionary are tables, data elements and domains. The domain is used for the technical definition of a table field (for example field type and length) and the data element is used for the semantic definition (for example short description).
A domain describes the value range of a field. It is defined by its data type and length. The value range can be limited by specifying fixed values.
A data element describes the meaning of a domain in a certain business context. It contains primarily the field help (F1 documentation) and the field labels in the screen.
A field is not an independent object. It is table-dependent and can only be maintained 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 the data type and number of places is defined by specifying a direct type.
The data type attributes of a data element can also be defined by specifying a built-in type, where the data type and number of places is entered directly.
A transparent table is automatically created on the database when it 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 data types in the ABAP Dictionary are converted 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 on the database. This permits you to insert new fields without having to convert the table. When a new field is added, the adjustment is made by changing the database catalog (ALTER TABLE). The new field is added to the database table, whatever the position of the new field in the ABAP Dictionary.
ABAP programs can access a transparent table in two ways. One way is to access the data contained in the table with OPEN SQL (or EXEC SQL). With the other method, the table defines a structured type that is accessed when variables (or more complex types) are defined.
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 be used to define the types of variables.
Structures can be included in tables or other structures to avoid redundant structure definitions.
A table may only be included as an entire table.
A chain of includes may only contain one database table. The table in which you are including belongs to the include chain. This means that you may not include a transparent table in a transparent table.
Includes may contain further includes.
Foreign key definitions are generally imparted from the include to the including table. The attributes of the foreign key definition are passed from the include to the including table so that the foreign key depends on the definition in the include.
You must maintain the technical settings when you define a transparent table in the ABAP Dictionary.
The technical settings are used to individually optimize the storage requirements and accessing behavior of database tables.
The technical settings can be used to define how the table should be handled when it is created on the database, whether the table should be buffered and whether changes to entries should be logged.
The table is automatically created on the database when it is activated in the ABAP Dictionary. The storage area to be selected (tablespace) and space allocation settings are determined from the settings for the data class and size category.
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.
The data class logically defines the physical area of the database (for ORACLE the tablespace) in which your table should be stored. If you choose the data class correctly, the table will automatically be created in the appropriate area on the database when it is activated in the ABAP Dictionary.
The most important data classes are master data, transaction data, organizational data and system data.
Master data is data that is rarely modified. An example of master data is the data of an address file, for example the name, address and telephone number.
Transaction data is data that is frequently modified. An example is the material stock of a warehouse, which can change after each purchase order.
Organizational data is data that is defined during customizing when the system is installed and that is rarely modified thereafter. The country keys are an example.
System data is data that the R/3 System itself needs. The program sources are an example.
Further data classes, called customer data classes (USER, USER1), are provided for customers. These should be used for customer developments. Special storage areas must be allocated in the database.
The size category describes the expected storage requirements for the table on the database.
An initial extent is reserved when a table is created on the database. The size of the initial extent is identical for all size categories. If the table needs more space for data at a later time, extents are added. These additional extents have a fixed size that is determined by the size category specified in the ABAP Dictionary.
You can choose a size category from 0 to 4. A fixed extent size, which depends on the database system used, is assigned to each category.
Correctly assigning a size category therefore ensures that you do not create a large number of small extents. It also prevents storage space from being wasted when creating extents that are too large.
Modifications to the entries of a table can be recorded and stored using logging.
To activate logging, the corresponding field must be selected in the technical settings. Logging, however, only will take place if the R/3 System was started with a profile containing parameter 'rec/client'. Only selecting the flag in the ABAP Dictionary is not sufficient to trigger logging.
Parameter 'rec/client' can have the following settings:
rec/client = ALL All clients should be logged.
rec/client = 000[...] Only the specified clients should be logged.
rec/client = OFF Logging is not enabled on this system.
The data modifications are logged independently of the update. The logs can be displayed with the Transaction Table History (SCU3).
Logging creates a 'bottleneck' in the system:
Ÿ Additional write access for each modification to tables being logged.
Ÿ This can result in lock situations although the users are accessing different application tables!
EDITOR CALL PART ONE
EDITOR CALL PART TWO
ELSE AND ELSE-IF
EXEC
EXPORT PART ONE
EXPORT PART TWO
FETCH
FIELD SYMBOLS
Post a Comment