ABAP/4 - DATA DICTIONARY - TABLES IN REVIEW

Knowledge learned in this article can be put to use when:

• Users require an understanding of the various tables within SAP R/3
• Users require an understanding of the various features regarding Sap R/3 tables
• Users require an understanding of how to use the SAP R/3 Data Dictionary in concert with Crystal Reports

Tables are created using the DYNPRO technique (implemented as step-loops or as table controls) and we use them for reporting/interacting with the entered data. Lists are created with ABAP/4 statements and are used to display and print tabular data. These are 'classical' R/3 reports – the typical SAP 'green bar' printed report.

However, the distinction between tables and lists can be blurred – tables can be used for display-only purposes and lists can provide a method of 'interactive' reporting ('drill down' and 'drill across').

Entry Tables vs. Display Tables
There is another flavor to be added to the basic methodology of SAP tables: Entry Tables and Display Tables.

The distinction between Entry Tables and Display Tables refers to their use and not to their structure. Tables are used primarily for entering data and lists are used for displaying the data.

Tables and the Data Dictionary
The central data structure of the ABAP/4 Data Dictionary is the table. A table consists of a list of fields.

As each table field is assigned a data element (which describes the meaning of the field), the data element is assigned a domain, which determines the technical characteristics of the field.

Data elements and domains are independent objects within the ABAP/4 Data Dictionary – meaning data elements may be used for several fields from different tables.

Tables are defined within the ABAP/4 Data Dictionary and subsequently created in the database. The construction of data produced when calculations are carried out within programs (as with a client's 'business rules') or when data is transferred between programs can be accomplished and defined globally in the ABAP/4 Data Dictionary.

This is achieved by means of structures within the ABAP/4 Data Dictionary. A structure is defined within the ABAP/4 Data Dictionary like a table, but no one table corresponds to it.

The relational data model contains not only tables, but also the relationships existing between the tables. These definitions are defined and maintained within the ABAP/4 Data Dictionary by its foreign keys.

Within the ABAP/4 Data Dictionary, tables can be defined in a way that is not database dependant.

When a table is created and then 'activated' (made available to the R/3 System), a physical table definition in the database is added to the table definition stored in the ABAP/4 Data Dictionary.

For the majority of the tables, the ABAP/4 Data Dictionary provides a fully transparent interface to the database. This means all of the fields of a Dictionary table correspond to a field in the real database table. Since the data structure is visible in the Dictionary corresponds entirely to the structure of the table created by the database system, these tables are called transparent tables. A transparent table is a normalized table. SAP is slowly evolving all R/3 tables into transparent tables.

Using this schema, several logical tables are combined into a single real database table. Although the data structure of each set is lost during the write to the table pool, it is restored during the read by the ABAP/4 Data Dictionary. The ABAP/4 Data Dictionary utilizes its meta-data to accomplish this.

Since information must be prepared (defined) within the ABAP/4 Data Dictionary when it is read or written to (or accessed), this process itself defines these as not transparent tables.

As mentioned above, these table types require special data handling, therefore they are not transparent tables.

Note: Both Pooled and Cluster Tables are stored as tables within the database. Only the structures of the two table types which represent a single logical view of the data are defined within the ABAP/4 Data Dictionary. The data is actually stored in bulk storage in a different structure. These tables are commonly loaded into memory (i.e., 'buffered') due to the fact they are typically used for storing internal control information and other types of data with little or no external (business) relevance.

• Database view
  - defined just as a table is defined within the database
  - one or more related tables may be used
  - only transparent tables may be used
• Help view
  - accessed from within transactions
  - accessed only from within SAP Help
  - Open SQL and Native SQL cannot access
  - only 1:1 and 1:C relationships are possible
• Projection view
  - allows suppression of some fields within transparent table displays
• Maintenance view
  - enables table maintenance via SM30
  - allows specific customizing transactions

A view is like a table but lacking content – it is a virtual table. A view is a definition based upon the relationship between one or several tables using the permitted relational database operations (i.e., select, join or projections). Using a view permits restricting or limiting the access to information by areas, employees, plants, etc. It permits authorized users a 'snap-shot' of the data within their functional area (finance (FI) or production planning (PP)).

A view reduces the need to create new tables with only the specific data for each application ( FI , SD , PP, etc.). A view reduces redundancy of tables (which are costly to maintain) and is a preferred method for relating specific modules of business applications which may be logically separated.

Many views are generated automatically. The names of many of the views delivered with R/3 begin with the letter V and usually contain the name of the primary table, such as VZZB.

Example of a Database view
The Database view UNADA summarizes the data shared among the tables UPERS, UNAMA and UFACH on administrative employees.

The data in these tables are linked by the identification of the personnel numbers in tables UPERS and UNAMA (join condition UPERS-EUNR = UNAMA-NAMNR) and the identification of the faculty numbers in tables UNAMA and UFACH (join condition UNAMA-FABR = UFACH-FABNR).

Written by Geoffry Houze, Data Management Group SAP Practice Manager