The document describes the functionality and purpose of the SAP ABAP Data Dictionary. The Data Dictionary provides a platform-independent interface to database metadata. It facilitates development by eliminating the need for programmers to manage specific database details. The Data Dictionary contains objects like domains, data elements, tables and their relationships which are used to develop and maintain ABAP applications.
11. Specifying Value Ranges for a Domain Fixed Values Example: Value Table Example: Domain: S_CLASS (Classes for a Flight Booking) Values: C (business class) F (first class) Y (economy class) Domain: S_CARR_ID (Carrier ID) Value Table: SCARR Table: SCARR Carrier ID Name AA American DL Delta LH Lufthansa SA Singapore UA United
13. Interdependency of ABAP Dictionary Objects Tables Domains "technical field description" From City To City S_FROM_CIT S_TO_CITY City S_CITY Data elements "semantic field description" Tab. Tab. Tab.
14. Table Primary key (Field) values TABLE Airline Carriers Rows (tuples) Table SCARR Carrier ID AA DL LH UA ... Carrier Name American Airlines Delta Lufthansa United Airlines ...
25. Size Categories DB TS1 TS1 TS1 0 1 2 3 Number of data records in a storage area 4 = 0 to 640K = 610K to 2400K = 2400K to 9800K = 9800K to 39000K = 39000K plus TS1 Dict Table Selection T1 0 T2 1 T3 2 T4 3 T5 4
27. Buffering 1st access DB T2 T3 T1 ABAP Dictionary S1 S2 F1 ... T1 T3 T2 T1 Buffer: 100% and generic Buffer: partial Yes Import record No Yes No Yes Generic key complete SELECT SINGLE record exists No 1st access Yes No G1 G2 S3 F1 ... T2 S1 S2 F1 ... T3 100% generic partial G1 G2 S3 F1 ... G1 G2 S3 ... S1 S2 F1 ... G1 G2 S3 ... G1 G2 S3 F1 ... S1 S2 F1 ... TABL TABLP Change number of key fields 2
28. Logging DB Log T1 DD S1 S2 F1 F2 F3 ... Table T1 Manual Field-related log records System profile Logging Change S1 S2 F2 F3 ...
29. INCLUDE Substructure US Table Field Data element T1 S1 ... TRANSP S2 ... .INCLUDE US F1 ... ... ... T2 F1 ... TRANSP .INCLUDE US F2 ... ... ... USF1 USF2 USF3 .....
30. APPEND Substructure Table Field Data Element ZTBL1 FLD1 ... TRANSP FLD2 ... .APPEND ZAZTBL1 Database Field Sequence ABAP Dictionary Sequence FLD1 FLDX FLD2 FLD1 FLD2 FLDX Append contains definition of field FLDX .APPEND CI_ZTBL1 OR Customizing Include
31. Views FIELD A FIELD B FIELD C FIELD A FIELD D FIELD E FIELD F TABLE 1 TABLE 2 FIELD A FIELD C FIELD D FIELD F VIEW 1
32. Search Help User selects row Values are returned User chooses F4 on field The search path used the last time is displayed User chooses a different search path The chosen search path is displayed Hit list is displayed A B C A B C
38. Settings Sort Sequence for output list ... - List table fields - Maximum 9 sort fields - Flag fields with 1 to 9 Fields to be selected ... - List table fields - Flag the fields to be included in the the output list Affects the output list Fields to be used for data selection ... - List table fields - Flag the fields to be used for data selection - Maximum 40 Affects the selection screen Personal Settings - Width of output list - Maximum number of entries to be selected - Take into account conversion exit - Column headings can be either: . Field name, or . Field text (from data element) Data Browser: Table SPFLI .... .... .... Settings .... .... System Help List format Sort User parameters Choose Fields Fields For Selection
39. Exercises Exercise 4 - ABAP Dictionary Search, 30 minutes Exercise 5 - View a Table with the Data Browser, 20 minutes
A data dictionary is the centralized and structured source of information for business applications. The elements that make up a data dictionary are known as metadata. Metadata is data that describes other data. For example, a customer order number would be considered operational data and the length of the customer order number field would be considered metadata. The data dictionary allows the user to create, modify or delete data definitions.
Advantages of a data dictionary: Facilitates the development of platform-independent programs. Avoids inconsistencies when defining data types that will later be used in different parts of the application. This helps avoid redundancy and considerably decrease the cost of maintenance. When a type of data is defined in the dictionary, it is available to any program or function module in the application. A change in the definition of a type of data automatically affects all other data or programs that use that data type. The data dictionary is a great source of information for the developer/user. It is a fast and efficient way to answer questions such as which entries exist in a particular table, what the structure of a particular table is, etc.
The ABAP Dictionary is the core of the R/3 development system. It contains an extensive amount of information on the SAP system data, and it has a series of tools for the entry and evaluation of this information. The ABAP Dictionary allows data management without redundancy, that is, information need only be entered once to be available throughout the entire system. All changes take immediate effect in all relevant modules. The ABAP Dictionary is actively integrated into all operative components of the R/3 system.
The basic objects for modeling in the ABAP Dictionary are: Tables Fields Data elements Domains The structure of a table is comprised of logically related entities, referred to as fields. A field is not an independent object and can only be maintained within the contents of its’ particular table. Each field is related to a data element, which in turn is related to a domain.
When adding a field to a table, a data element must be specified for that field. When defining a data element, a domain must be specified for that data element. Domains, data elements and fields all have attributes. A data element inherits attributes from the specified domain, and a field inherits attributes from the specified data element. Defining these attributes at multiple levels of abstraction make it easier to make system changes. For example, if the output length of a domain is changed, then the output length will also automatically be changed in all data elements that reference that domain. In turn, the field lengths for all table fields that reference those data elements will also be changed. These attributes will be discussed in more detail throughout this module.
The ABAP Dictionary employs a two-level domain concept involving technical domains (referred to as “domains” in SAP) and semantic domains (referred to as “data elements” in SAP). A domain describes a value set for a field. The value set is specified through the creation of formal attributes, such as length, format, etc. Domains roughly correspond to type declarations in the various programming languages (typedef in C/C++). A data element provides a precise description of the function of a domain within a specific context for the benefit of the fields dependent on it.
The domain describes the set of values for a field, which is determined by specifying external format, length, etc. of values or by specifying a value table. For example, the field CITYFROM in the flight table SPFLI has the external format CHAR 20 - it is 20 characters in length and can only assume values that lie in this range. The range is determined by the domain S_CITY to which the field CITYFROM refers. A number of fields that are similar with regard to technical characteristics are grouped together by means of a domain. Fields that are linked by means of reference to the same name can no longer be changed independently of one another. The decimal places attribute only displays when the data type entered is DEC, FLTP, QUAN or CURR.
The value range of a domain is initially defined by specifying a data type and a length for that domain. For example, if a domain is defined as a character field of length 1, the value range of that domain would be restricted to the values zero through Z. Sometimes it is necessary to further restrict the value range of a domain. This can be done in two ways by either: specifying a set of “fixed values” for the domain specifying a “value table” for the domain Fixed values are typically specified for a domain when the list of possible values for a domain is short and the values are going to be static (i.e., not changing). If fixed values are defined for a domain, they will be used as an input check on screen fields. (If no other help is defined for a field, such as a search help or a foreign key, the fixed values are also provided in F4 help). A value table is typically specified for a domain when the list of possible values for a domain are contained within another table in the system. This is very common, especially when the list of possible values is longer and more dynamic in nature. Defining a value table for a domain does not automatically initiate a check against that value table whenever data is entered in a field that references this domain. NOTE: A check is not automatically enabled simply by specifying a value table. In order to enable this check, a foreign key must be defined that specifies this value table as the check table for that foreign key. Foreign keys and check tables for foreign keys will be discussed later in this module. A table can only be the value table for a single domain. Therefore, all fields that need to use this table to define a value range must all reference the same domain.
A data element describes the function of a domain in a particular context. A domain can have different characteristics that, although they have the same formal attributes (format, set of values), differ with regard to their technical meaning. For example, the domain “city” (S_CITY) could have various functions depending on it’s use, for example, from city, to city, employee’s home city, etc. The data element is a carrier of the field information that is valid for every field referring to this data element, independently of the table in which the field is used. A data element is to be created for each domain function. The function of a data element is of importance at the external or semantic level of a dialog: for example, a data element can be a key word in a screen a column header in a table screen or online documentation help. At the level of the data element, three lengths of the key word and a header are maintained. In Screen Painter, select the length that is required. Maintenance is mandatory. Standard value Max. Length Recommendation: Short field label: 10 10 Medium field label: 15 20 Long field label: 20 40 Header: Field length Table field documentation is stored at the data element level and is accessed via GOTO->DOCUMENTATION menu option on the data element definition screen.
A field refers to a data element; a data element refers to a domain. Several data elements can refer to the same domain. Individual data elements can be used in many different fields.
A table is a two-dimensional matrix that describes a relationship in the database system. A table structure is defined by a number of logically related entities, referred to as fields. Each row in a table contains precisely one data value for each of the fields defined in the table structure. Rows within a table are uniquely identified by a primary key. The primary key is made up of one or more table fields that uniquely identify each table row. A key, and thus a row, may occur only once within a table.
Foreign keys define the relationships between tables. A foreign key is a key field of one table that appears as a non-key field in another table. This foreign key serves as a logical link between the two tables. One of the most important functions of foreign keys is to ensure data integrity in the relational data model. Data integrity is ensured by checking entries on a screen against the entries in the check table. The table containing the allowed values is called the check table. The table in which only these values may be used is called the foreign key table.
When defining a table field as a foreign key, the system will default the check table to the value table specified in the domain for that field. (NOTE: It is possible to override this default and specify another table as the check table).
Cardinality is expressed in the form N:M, where possible values are: 1:1 relationship - One element of table A corresponds to one and only one element of table B. 1:C relationship - One element of table A corresponds to at most one element of table B (i.e., 0 or 1 elements of table B). 1:N relationship - One element of table A corresponds to at least one element of table B (i.e., 1 or more elements of table B). 1:CN relationship - One element of table A corresponds to 0, 1 or more elements of table B.
SAP data can be logically divided into four categories. Master Data: Business data that does not change often, such as vendor master record, general ledger account definition Transaction Data: Business data that is volatile, such as customer orders or accounting transactions System Data: Control data for the SAP system Configuration: Data that does not change often and that customizes the behavior of SAP R/3 applications
SAP supports four table types: Transparent tables are structures that correspond 1:1 to the underlying database table. Cluster tables are made of several SAP tables related using foreign keys. Pooled tables are made of a set of tables stored in a single SAP table. Internal tables are defined within an ABAP program. They can be based upon a structure defined within the data dictionary or a structure coded within the program itself. Internal tables are program specific and cannot be accessed using the ABAP dictionary. From an application point of view, transparent, pool and cluster tables behave the same and are used for the same purpose. Pooled and clustered tables exist both for performance and to group logically related tables. These table types are slowly being phased out with each release of SAP. The only limitation of pooled and clustered tables is that they cannot be queried directly (i.e., outside of SAP) in the underlying database, since their structures are only logically known at the SAP level.
To describe a table in full, that is both from the application view and from the database view, a number of different steps are necessary, which vary according to the table type. Tables of type TRANSP are mapped 1:1 to the database. They are defined and activated only once in the ABAP Dictionary (as SAP tables) and are then automatically created as database tables.
Table are created and changed via transaction SE11. Tables are defined in two stages: Each table is assigned certain attributes, for example, a short explanatory description, a table type, and a delivery class. The table structure contains the fields and the field description. The fields forming the primary key are indicated as such. Field maintenance can be carried out at table or at field level. Each field must refer to a data element. If the data element referred to does not yet exist, it can be created at this point from within the table maintenance function. A data element must, in turn, refer to a domain. If the specified domain does not yet exist, it must be created from within data element maintenance. A primary key must be identified for each table. The primary key is used as a unique identifier for each row of data in the table.
The technical attributes of a table are normally defined when the table is created and cannot be changed afterwards. Data class: Assigns the table to a physical area in the database Possible values: APPL0 (master data), APPL1 (transaction data), APPL2 (organization and customizing data), USER (customer data), USER1 (customer data) Size category: Determines the space required for a table in the database Possible values: 0, 1, 2, 3, 4 (equates to an expected number of table records) Buffering type: Determines whether and how a table is to be buffered Logging: Automatic logging of database changes by users for table (where row size < 455)
To improve performance, database indexes can be created in the Data Dictionary via transparent tables (type: TRANSP). Database indexes are defined in two stages: description of the database index in the Data Dictionary creation of the database index in the database Menu Path: TOOLS --> ABAP WORKBENCH --> ABAP DICTIONARY --> enter change mode for a specific table --> GOTO --> INDEXES To specify the table type, if other than Transparent is desired, use the EXTRAS ---> CHANGE TABLE TYPE menu option.
Tables defined in the Data Dictionary can be assigned logically to a specific table class - master, transaction, organization and customizing (system) data. This assignment has the effect of storing the table in a defined area of the database when the table is created.
The storage area provided for a ABAP Dictionary table in the database is defined in accordance with the selected size category.
Buffering a table enhances the performance when accessing the data records contained in it. The table buffers reside locally on each application server in the system. Access to the data of buffered tables can thus take place directly from the buffer of the application server. The time-consuming process of accessing the database is thus avoided. Buffering is recommended only for tables that are almost never changed (updating). Buffering type determines how a table is buffered (i.e., partially, generically, or completely). The data type of the key fields must be CHAR. UPDATE always accesses the database. Displacement: TABL, no entry in system log TABLP, table last recently used is entered in system log The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.
If logging is switched on by the Basis Administrator, each change to an existing data record (UPDATE, DELETE) by the user or application program is recorded in a log table (DBTABRT). Before logging can take place, an appropriate entry must have been made in the system profile, which is checked by the database. Logging is carried out independently of updating. Logging slows down accesses that change the table. First, a record must be written in the log table for each change. Secondly, a number of users access this table in parallel. This can cause lock situations although the users are working with different application tables.
Tables can be included in other tables as substructures to avoid redundant structure definitions. A table can be included only as a complete table and must be of table type structure or TRANSP. A table of type TRANSP may be contained only once in an INCLUDE chain. Substructures can in turn contain substructures. Customizing INCLUDEs: Supplied by SAP Maintained by a special transaction developed for the specific customizing INCLUDE
Append structure: Facilitates the addition of fields to an SAP table without having to open a Correction Currently cannot be deleted, possible in a future release One per table Customizing Include: An SAP-provided append structure Maintained with a special transaction (outside of the ABAP Dictionary) Sequence of fields on the database may differ from the sequence in the ABAP Dictionary. Append will always be shown last in the ABAP Dictionary. When a table within an APPEND structure is displayed, fields referenced in the APPEND structure are not delineated in any fashion when table is displayed. It is not possible to append structures to tables with fields of type VARC, LCHR, or LRAW because such fields must always be defined at the end of the table. Before attempting to append a structure to a table, check to see if a customizing INCLUDE is already in use. If so, maintain the customizing INCLUDE with the appropriate transaction.
A view is like a table with no contents, i.e., it is a virtual table. A view does not physically contain any data. The information is generated when the view is used at run-time. A view is a definition based on the relationship between one or more tables. In the above example, Table 1 and Table 2 are joined together based on field A. The resultant view will contain, for all A in Table 1 and Table 2, the values for fields C, D and E. Benefits of views: Allows for restricting or limiting the access to information by areas, plants, etc. Reduces the need to create new tables with specific data for each application Can be used to improve performance. Using a view is more efficient than programming nested selects or joins.
Search helps offer the advantage of being able to return multiple field values to the underlying screen. The search key is invoked automatically from a search help when the user presses the F4 key to display allowable values for the field. For example, a screen displays the fields for an airline type, flight number, flight date, and number of seats available to be entered in the selection screen. The user presses F4 to display the airline type. The user then selects a row displayed in the search help that causes all of the other fields in the screen to be populated. The following steps are usually carried out when a user calls an input field (F4): The user starts the input help to display the possible input values for a field in a screen mask. The system offers the user a number of possible search paths. The user selects one of these search paths. Each search path offers a number of restrictions to limit the number of possible input values. These values are offered in a dialog box when the search path is selected. The user enters restrictions, if required, and then starts the search. The system determines the values that satisfy the entered restrictions (hits) and displays them as a list. The user selects the most suitable line from the hit list. The input value is copied to the screen mask (possible with other values).
Each field of the selection method (or transparent table) is declared as a component of the search help. The relationship is established as the data element level of the selection method. The components can be import parameters that are used to refine the values returned by the screen help and/or export parameters that return values to the calling screen. The field assignment is repeated for each field that is to be part of the search help. The value supplied in the LPOS field indicates the left-to-right order when the search help is displayed. The value for SPOS indicates the top-to-bottom order when a selection screen is presented for the search help. When the search help is activated, it must be attached to the fields of a transparent table declared as the Selection Method. The assignment is done one at a time. When all of the assignments have been made, the transparent table must be activated. From then on, the search help is invoked automatically when the user presses the F4 key to display allowable values. Selecting a row displayed in the search help will cause all of the fields declared to the search help to be returned to the underlying screen.
The Data Browser is a tool that provides the ability to display, create, and change table contents. The path to get there is Tools -> ABAP Workbench -> Overview -> Data Browser. The Data Browser is fully integrated into the ABAP Development Workbench. It can also be accessed within workbench tools from the Utilities menu or via the menu path Tools -> Workbench, Overview -> Data Browser, or transaction code SE16. If the name of the table is unknown, place the cursor on the table name input field and click on the Possible Entries pushbutton on the Standard toolbar or press F4. This presents the user with a selection screen that allows the user to specify certain search criteria such as Table Short Description, Development Class, etc. Wildcards can be used. The Data Browser will also allow the user to display (but not change) data from clients other than the one they are logged on to. This tool is very useful when testing a report program because tables can be examined to determine what data actually exists in the system.
From the Data Browser initial screen, or via the menu path Settings -> User Parameters from the initial or subsequent screens, it is possible to specify: Width of the resulting list Maximum number of hits - the number of entries to be retrieved from the specific table Check conversion exits - use or not use conversion exits/routines (where they are defined for a field) for outputting the data Field name - checked to show the ABAP Dictionary field names (=Fld name) in the column headings Field ID - checked to show the ABAP Dictionary short text from the Data Element (=Fld name) The values set on this screen are specified to the logged on user and are retained even after the user logs off.
On the Data Browser’s initial screen, click on the Create pushbutton or press Enter (defaults to Display mode). This brings up the selection screen for the table. The system actually generates a report program to interrogate the table specified. This is that program’s selection screen. The selection screen allows values to be entered in order to restrict the entries retrieved from the table. Once data has been entered in the selection criteria, click on the Execute pushbutton and the resulting list is displayed.
The settings remain until they are changed again (even after logging off). The settings can be changed while displaying table entries without having to repeat data selection. The report is merely reformatted (data is held in internal tables to achieve this). The sort sequence and the fields that are to be displayed after the data has been initially selected and displayed can be changed.
![Module Objectives ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)