Abap Data Dictionary

The ABAP Dictionary centrally describes and manages all the data definitions used in the system. The ABAP Dictionary is completely integrated in the ABAP Development Workbench. All the other components of the Workbench can actively access the definitions stored in the ABAP Dictionary. The ABAP Dictionary supports the definition of user-defined types (data elements, structures and table types). You can also define the structure of database objects (tables, indexes and views) in the ABAP Dictionary. These objects can then be automatically created in the database with this definition.

The ABAP Dictionary also provides tools for editing screen fields, for example for assigning a field an input help (F4 help). The most important object types in the ABAP Dictionary are tables, views, types (data elements, structures, table types), domains, search helps and lock objects.

Dictionary Purpose

Order custom essay Abap Data Dictionary with free plagiarism report

450+ experts on 30 subjects Starting from 3 hours delivery

Get Essay Help

Data definitions (metadata) are created and managed in the ABAP Dictionary. The ABAP Dictionary permits a central description of all the data used in the system without redundancies. New or modified information is automatically provided for all the system components. This ensures data integrity, data consistency and data security. You can create the corresponding objects (tables or views) in the underlying relational database using these data definitions. The ABAP Dictionary therefore describes the logical structure of the objects used in application development and shows how they are mapped to the underlying relational database in tables or views. The ABAP Dictionary also provides standard functions for editing fields on the screen, for example for assigning a screen field an input help.

What Information is Stored in the ABAP Dictionary?

The most important object types in the ABAP Dictionary are tables, views, types, domains, search helps and lock objects. Tables  are defined in the ABAP Dictionary independently of the database. A table having the same structure is then created from this table definition in the underlying database. Views are logical views on more than one table. The structure of the view is defined in the ABAP Dictionary.

A view on the database can then be created from this structure. Types are used in ABAP program. The structure of a type can be defined globally in ABAP programs. Changes to a type automatically take effect in all the programs using the type. Lock objects are used to synchronize access to the same data by more than one user. Function modules that can be used in application programs are generated from the definition of a lock object in the ABAP Dictionary. Different fields having the same technical type can be combined in domains .

A domain defines the value range of all table fields and structure components that refer to this domain. The ABAP Dictionary also contains the information displayed with the F1 and F4 help for a field in an input template. The documentation about the field is created for a data element that describes the meaning of the contents of a table field. The list of possible input values that appears for the input help is created by a foreign key or a search help. Integration in the ABAP Development Workbench The ABAP Dictionary is completely integrated in the ABAP Development Workbench.

The R/3 System works interpretatively, permitting the ABAP Dictionary to be actively integrated in the development environment. Instead of the original objects, the interpreters see only internal representations of these objects. These internal representations are adjusted automatically when the system finds that changes have been made in the ABAP Dictionary. This ensures that the screen and ABAP interpreters, input help, database interface, and development tools always access current data.

The following ABAP program lists the airline carriers and carrier IDs contained in table SCARR. Only structure SCARR_TAB is declared in the program. All the information about this structure, such as the field names, data types and field lengths, are copied from table SCARR, which is defined in the ABAP Dictionary. This information about table SCARR is called from the ABAP Dictionary when the program is generated.

This means that the source text of the program need not be adjusted when a change is made to table SCARR, for example when the length of a table field is changed. The next time the program is called, the system automatically determines that the structure of table SCARR has changed. The program is simply regenerated, thereby retrieving up-to-date information about table SCARR from the ABAP Dictionary.

Runtime environment of the application Runtime environment of the application When you work on development projects, objects of the ABAP Dictionary can be changed any number of times before being activated and made available to the operative components of the system. Objects can have both an active and an inactive version in the ABAP Dictionary at the same time. Inactive ABAP Dictionary objects have no effect on the runtime system (ABAP processor, database interface).

SAP AG executability of the system. The objects can only be activated together when they have all been changed. Tables can be defined independently of the database in the ABAP Dictionary. The fields of the table are defined with their (database-independent) data types and lengths. When the table is activated, a physical table definition is created in the database for the table definition stored in the ABAP Dictionary. The table definition is translated from the ABAP Dictionary to a definition of the particular database.

The customer can modify SAP tables with append structures and customizing includes. This kind of modification ensures that the customer enhancements are automatically merged with the new versions of the SAP tables when there is a release upgrade.

Field name

The field name can have a maximum of 16 places and may contain letters, digits and underscores. The field name must begin with a letter.

• Key flag:determines whether the field should belong to the table key.
• Field type: data type of the field in the ABAP Dictionary.
• Field length: number of valid places in the field.
• Decimal places: number of places after the decimal point, specifying numeric data types. Short text: short text describing the meaning of the field.

You can also include the fields of a structure in the table. Assignment of the Data Type, Field Length and Short Text You can assign the data type, length and short text in different as: You directly assign the field a data type, field length (and if necessary decimal places) and short text in the table definition. You can assign the field a data element. The data type, field length (and decimal places) are determined from the domain of the data element. The short description of the data element is assigned to the field as a short text.

This search help defines the input help flow on all the screens in which the field is used. Reference field and reference table: You must specify the table field in which the corresponding unit of measure or currency can be found for fields containing quantities (data type QUAN) or currency amounts (data type CURR).

This reference table must contain a field with the format for the currency key (data type CUKY) or unit of measure (data type UNIT). This field is called the reference field of the output field. The reference field can also reside in the table itself. A field is only assigned to the reference field at program runtime. For example, if a field is filled with currency amounts, the corresponding currency is determined from the assigned reference field, that is the value entered in this field at the moment defines the currency.

In addition to listing the individual fields, you can also include the fields of another structure in tables and structures. Individual fields and includes can be mixed as required.

You can assign the include a group name with which the group of fields in the include can be addressed as a whole in ABAP programs. Includes can also be nested, that is structure A includes structure B which in turn includes another structure C, etc. The maximum nesting depth is limited to nine. The maximum length of a path of nested includes in a table or structure is therefore nine (the table/structure itself not included).

Include U2 U3 Maximum depth = 9 Include U8 U9 Include U9 Only flat structures  can be included. In a flat structure, every field either refers to a data element or is directly assigned a data type, length and possibly decimal places. Only structures may be included in a table. Tables, structures and views may be included in a structure. The length of the field names is more restricted in tables than in structures. In a table, a field name may not have more than 16 places, but in a structure up to 30 places are allowed for the field name.

A structure therefore can only be included in a table if none of the field names of the structure are longer than 16 places. The path of nested includes may only contain one table. Table TAB1 includes structure STRUCT1, which in turn includes structure STRUCT2. The path of the nested includes here only contains table TAB1. It is also possible to include TAB1 in a further structure STRUCT0, but no other table TAB2 may be included in TAB1 since in this case a path of nested includes would contain two tables (TAB1 and TAB2).

Named Includes

If an include is used to define a database table or structure, a name can be assigned to the included substructure. The group of fields in the include can be addressed as a whole in ABAP programs with this name. In ABAP programs, you can either access the fields directly with - or analogously with --. You can access the fields of the group as a whole with. Structure PERSON includes structure ADDRESS with the name ADR. ADDRESS has a field CITY. With PERSON-ADR you can address all the fields in structure ADDRESS. The included field CITY can also be addressed with PERSON-CITY or PERSON-ADR-CITY.

You can include a structure more than once (e. g. in a period group). Since direct access by field name should be permitted here, the included field names must be renamed to ensure that they are unique. A suffix can be assigned to each group, extending the names of the group fields. The fields can then be addressed in ABAP programs with - or --. Structure PERSON includes structure ADDRESS twice. An address is the private address with suffix H and name ADRH. The other address is the business address with suffix W and name ADRW. You can access field CITY in the private address with PERSON-CITYH or PERSON-ADRH-CITY.

The functionality of the named includes in the ABAP Dictionary corresponds to the ABAP construction INCLUDE TYPE ... AS ... RENAMING ... . 18 April 2001 SAP AG BC - ABAP Dictionary Foreign Keys Foreign Keys You can define the relationships between tables in the ABAP Dictionary by creating foreign keys. Using foreign keys, you can easily create value checks for input fields. Foreign keys can also be used to link several tables in a view [Page 97] or a lock object. Field Assignment in the Foreign Key A foreign key links two tables T1 and T2 by assigning fields of table T1 to the primary key fields of table T2.

One record of the foreign key table uniquely identifies one record of the check table using the entries in the foreign key fields. Check Field and Value Check One of the foreign key fields is marked as the check field. This means that the foreign key relationship is maintained for this field. April 2001 19 BC - ABAP Dictionary Foreign Keys SAP AG When an entry is made in the check field, there is a check whether the check table contains a record with the key defined by the values in the foreign key fields. If this is so, the entry is valid. Otherwise the system rejects the entry.

How the Input Check Works A SELECT statement is generated from the definition of the foreign key. If an entry is made in the check field, this SELECT statement is submitted. If a suitable record of the check table is found, the entry is valid. Otherwise the entry is rejected. The corresponding SELECT statement has the following form for the foreign key table shown in the above graphic: SELECT * FROM T2 WHERE T2-FIELD5 = T1-FIELD2 AND T2-FIELD6 = T1-FIELD4. A screen entry for check field Field2 is therefore only valid if the check table contains a record with the entries made in the screen for Field2 and Field4 as key.

Table SBOOK in the flight model contains the customer’s flight bookings for a carrier. The flight bookings can be made by a travel agency or directly at the carrier’s sales counter. If the booking was made at a counter, its number is stored together with the booking in field COUNTER in table SBOOK. 20 April 2001 SAP AG BC - ABAP Dictionary Foreign Keys You must make sure that only correct counter numbers can be entered. All the counters are entered in table SCOUNTER. The necessary value check can be defined by creating a foreign key for check field COUNTNUM. Foreign key fields Foreign key table SBOOK

You can use generic foreign keys in these cases. Fields are excluded from the assignment to the key fields of the check table here. The check is only against the remaining key fields. You can also assign a constant value to a key field of the check table. In this case you only have to check against the specified constant. You can use this check if only records of the check table which contain a constant value in this key field are valid.

Primary key

The corresponding SELECT statement for the screen check has the following form for the foreign key definition in the graphic: SELECT * FROM PTAB WHERE PTAB-FIELD1 = FTAB-FIELD6 AND PTAB-FIELD3 = FTABFIELD8 AND PTAB-FIELD4 = ‘K’. An entry is only valid in check field Field6 if a record of check table PTAB exists containing the input value for Field6 in PTAB-Field1, the input value for Field8 in PTAB-Field3 and constant K in PTAB-Field4.

Dictionary Semantic Attributes of Foreign Keys

SAP AG Semantic Attributes of Foreign Keys A foreign key describes a relationship between two tables. You can define this relationship more precisely by specifying the cardinality and type of foreign key fields. This information is optional and is primarily for documentary purposes. In particular, the definitions of the cardinality and type of the foreign key fields are not used in the value check for the foreign key. The definition of the semantic attributes is only sed in the following cases: If Key fields of a text table is selected as the type of the foreign key fields, the foreign key table is considered to be the text table for the check table. If a screen field is checked against a table, the key entries of the check table are normally displayed in the input help (F4 help) for this field. If there is a text table for the check table, each key entry displayed is enhanced with an explanatory text (contents of the first character-like field of the text table) in the user’s logon language.

Tables can only be included in a help view or maintenance view if they are linked with a foreign key. It only makes sense to create such a help or maintenance view if for each record in the primary table of the view there is no more than one corresponding record in each secondary table of the view. The system therefore checks if the foreign key with which the tables were linked in the view have suitable cardinalities when it creates a maintenance or help view. See also Restrictions for Maintenance and Help Views. The foreign key between tables SBOOK and SCOUNTER ensures that only existing counters can be entered in field COUNTER (counter at which the flight was booked). See the example in Foreign Keys. A booking can be made at either a travel agency or at the carrier’s sales counter. If the booking is made at a travel agency, the field COUNTER of table SBOOK remains empty. The foreign key fields do not have to be filled, that is the left side of the cardinality is C. Any number of bookings may be made at each counter.

There may therefore be any number of entries (bookings) in foreign key table SBOOK for each record of the check table SCOUNTER. The right side of the cardinality is therefore CN. Of course several bookings can be made for the same carrier at a counter. These bookings do not differ in their foreign key fields (MANDT, CARRID, COUNTER). The entries in the foreign key fields therefore do not uniquely identify an entry in the foreign key table SBOOK (a booking). The foreign key fields therefore have the type No key fields/candidates. 24 April 2001 SAP AG BC - ABAP Dictionary Cardinality Cardinality

The cardinality (n:m) describes the foreign key relationship with regard to the number of possible dependent records (records of the foreign key table) or referenced records (records of the check table). The left side (n) of the cardinality is defined as follows:  n=1: There is exactly one record assigned to the check table for each record of the foreign key table. n=C: The foreign key table may contain records which do not correspond to any record of the check table because the foreign key field is empty. This can occur for example if the field of the foreign key table is optional, in which case it does not have to be filled. =1: There is exactly one dependent record for each record of the check table. m=C: There is at most one dependent record for each record of the check table. m=N: There is at least one dependent record for each record of the check table. m=CN: There may be any number of dependent records for each record of the check table. The right side (m) of the cardinality is defined as follows:

The following types of foreign key field can be defined: No key fields/candidates: The foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table (key candidates). For this reason, 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 already uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore (partially) identify the foreign key table.

Key fields of a text table

The foreign key table is a text table for the check table, that is the key of the foreign key table only differs from the key of the check table in that it has an additional language key field. This is a special case of the type Key fields/candidates. Only one text table can be created for table B! The system checks this when you attempt to activate a table with text foreign keys for B. 28 April 2001 SAP AG BC - ABAP Dictionary Multi-Structured Foreign Keys Multi-Structured Foreign Keys When you define a foreign key, a field of the work area that is not contained in the foreign key table can also be assigned to a check table (for example a field of another table). This is possible for all fields except for the check field. Table T2 is the check table of foreign key table T1. Field F of the work area is assigned to key field Field6 of check table T2.

Otherwise the check always fails, and no values can be entered in the check field. April 2001 29 BC - ABAP Dictionary Technical Settings SAP AG Technical Settings The technical settings of a table define how the table will be handled when it is created in the database, that is whether the table will be buffered and whether changes to data records of the table will be logged. The most important parameters are: · · Data class: The data class [Page 31] defines the physical area of the database (tablespace) in which the table should be created. Size category: The size category [Page 32] defines the size of the extents created for the table.

When the table is created in the database, the required information about the memory area to be selected and the extent size is determined from the technical settings. · · Buffering permission: The buffering permission [Page 33] defines whether the table may be buffered. Buffering type: If the table may be buffered, you must define a buffering type (full, singlerecord, generic). The buffering type [Page 34] defines how many table records are loaded into the buffer when a table entry is accessed. Logging: This parameter defines whether changes to the table entries should be logged.

If logging  is switched on, each change to a table record is recorded in a log table. · The Convert to transparent table flag (transparent flag) is also displayed for pooled tables or for tables which were converted into transparent tables earlier on with this flag.

Each data class corresponds to a physical area in which all the tables assigned to this data class are stored. There are the following data classes: · · · APPL0 (master data): Data which is seldomly changed. An example of master data is the data contained in an address file, such as the name, address and telephone number. APPL1 (transaction data): Data that is frequently changed. An example of transaction data is the goods in a warehouse, which change after each purchase order. APPL2 (organizational data): Customizing data that is defined when the system is installed and seldomly changed.

The size category defines the expected space required for the table in the database. You can choose a size category from 0 to 4 for your table. Each category is assigned a certain fixed memory size in the database, which depends on the database system used. When a table is created, initial space (an Initial Extent) is reserved in the database. If more space is required at a later time due to data entries, additional memory will be added depending on the selected size category.

Database Selecting the correct size category prevents a large number of very small extents from being created for a table. It also prevents space from being wasted if extents which are too large are created. 32 April 2001 SAP AG BC - ABAP Dictionary Buffering Permission Buffering Permission You must define whether and how a table is buffered in the technical settings for the table. There are three possibilities here: · Buffering not permitted: Table buffering is not permitted, for example because application programs always need the most recent data from the table or the table is changed too frequently.

Buffering permitted but not activated: Buffering is permitted from the business and technical points of view. Applications which access the table execute correctly with and without table buffering. Whether or not table buffering will result in a gain in performance depends on the table size and access profile of the table (frequency of the different types of table access). Table buffering is deactivated because it is not possible to know what these values will be in the customer system. If table buffering would be advantageous for the table size and access profile of the table, you can activate it in the customer system at any time.

Buffering activated: The table should be buffered. In this case you must specify a buffering type.

Buffering Types

The buffering type defines which table records are loaded into the buffer of the application server when a table record is accessed. There are the following buffering types:

• Full buffering: All the records of the table are loaded into the buffer when one record of the table is accessed.
• Generic buffering: When a record of the table is accessed, all the records having this record in the generic key fields (part of the table key that is left-justified, identified by specifying a number of key fields) are loaded into the buffer.
• Single-record buffering: Only the records of a table that are really accessed are loaded into the buffer.

All the records of the table are loaded into the buffer when one record of the table is read. In this example, a program reads the record highlighted in red from table SCOUNTER. If the table is fully buffered, all the records of the table are loaded into the buffer. The buffered data records are sorted in the buffer by table key. Accesses to the buffered data can therefore only analyze field contents up to the last specified key field for restricting the dataset to be searched.

The left-justified part of the key should therefore be as large as possible in such accesses. For example, if you do not define the first key field, the system has to scan the full table. In this case direct access to the database can be more efficient if the database has suitable secondary indexes.

When Should you Use Full Buffering?

When deciding whether a table should be fully buffered, you should take into account the size of the table, the number of read accesses, and the number of write accesses. Tables best suited to full buffering are small, read frequently, and rarely written.

Full buffering is recommended in the following cases:

• If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded. However, you should always pay attention to the buffer utilization. Larger tables where large numbers of records are frequently accessed.
• If these mass accesses can be formulated with a very selective WHERE condition using a database index, it could be better to dispense with buffering.

Tables for which accesses to non-existent records are frequently submitted. Since all the table records reside in the buffer, the system can determine directly in the buffer whether or not a record exists. With generic buffering, all the records in the buffer whose generic key fields match this record are loaded when one record of the table is accessed. The generic key is a part of the primary key of the table that is left-justified. In this example, the record highlighted in red is read by a program from table SCOUNTER.

In general, only records of one language will be needed on an application server. In this case, the generic key includes all the key fields up to and including the language field. How Should you Define the Generic Key? In generic buffering, it is crucial to define a suitable generic key. If the generic key is too small, the buffer will contain a few very large areas. During access, too much data might be loaded in the buffer. If the generic key is too large, the buffer might contain too many small generic areas.

These can reduce buffer performance since there is an administrative entry for every buffered generic area. It is also possible that too many accesses will bypass the buffer and go directly to the database, since they do not fully define the generic key of the table. If there are only a few records in each generic area, it is usually better to fully buffer the table. Only 64 bytes of the generic key are used. You can specify a longer generic key, but the part of the key exceeding 64 bytes is not used to create the generic areas.

Access to Buffered Data

It only makes sense to generically buffer a table if the table is accessed with fully-specified generic key fields. If a field of the generic key is not assigned a value in a SELECT statement, it is read directly from the database, bypassing the buffer. If you access a generic area that is not in the buffer with a fully-specified generic key, you will access the database to load the area. If the table does not contain any records in the specified area ("No record found"), this area in the buffer is marked as non-existent. It is not necessary to access the database if this area is needed again. Single-Record Buffering Single-Record Buffering With single-record buffering, only the records that are actually read are loaded into the buffer. Single-record buffering therefore requires less storage space in the buffer than generic and full buffering. The administrative costs in the buffer, however, are greater than for generic or full buffering. Considerably more database accesses are necessary to load the records than for the other buffering types. In this example, the record highlighted in red is read by a program from table SCOUNTER.

When Should you Use Single-Record Buffering? Single-record buffering should be used particularly for large tables where only a few records are accessed with SELECT SINGLE. The size of the records being accessed should be between 100 and 200 KB. Full buffering is usually more suitable for smaller tables that are accessed frequently. This is because only one database access is necessary to load such a table with full buffering, whereas several database accesses are necessary for single-record buffering. Access to Buffered Data All accesses that are not submitted with SELECT SINGLE go directly to the database, bypassing the buffer.

This applies even if the complete key is specified in the SELECT statement. If you access a record which is not yet buffered with SELECT SINGLE, there is a database access to load the record. This record is marked in the buffer as non-existent if the table does not contain a record with the specified key. This prevents another database access when accessing the table at a later time with the same key. 40 April 2001 SAP AG BC - ABAP Dictionary Logging Logging Using the logging flag you can define whether changes to the data records of a table should be logged.

Don't let plagiarism ruin your grade

Run a free check or have your essay done for you

Check my essay Hire Writer