insiderBOOKS Articles and Insights
insiderBOOKS Articles and Insights RSS FeedRSS

ABAP / Data Management / Development

Introduction to the ABAP Data Dictionary and Managing Data Dictionary Objects

Chapter 5 Excerpt - Introduction to ABAP: A Project-Driven Guide

The ABAP Data Dictionary is a place where you can define and manage all objects (e.g., data elements, domains, structures, tables [database tables], views, search helps, and table types [internal table types]) and use these objects throughout the system. The objects we define in the ABAP Data Dictionary have global visibility, so we do not need to redefine objects every time at the program level. We just need to define an object once in the ABAP Data Dictionary, and we can use this object anywhere in the programs, interfaces of function modules, and methods in the current system. The ABAP Data Dictionary is a central place for the definition of all objects, so it guarantees data consistency and eliminates data redundancy. Whatever object we create and activate in the ABAP Data Dictionary is automatically created in the database we use in our system. The ABAP Data Dictionary shows the logical structure of the created object and displays the mapping of all these objects at the database level.
Let’s review the different ABAP Data Dictionary objects.

Data Elements
A data element is the most basic indivisible unit in the ABAP Data Dictionary. Data elements are used to define the fields of the table and the components of a structure, or they can be assigned to a screen field. A data element has the semantic attributes of the field, such as labels, search help, or parameter IDs. These attributes are automatically available to all fields that refer to the data element. The F1 help of the field also comes from the data element. You can use an elementary or reference type to describe a data element. An elementary type can be a predefined data type or can be copied from a domain. A reference type can be any Data Dictionary object, global class, interface, or predefined type.

A domain defines the technical attributes of any field. For example, technical attributes are the data type, length, decimal places, conversion routine, or value table of a field. A data object in an ABAP program, a field in a database table, or a structure cannot be declared directly using a domain. You have to assign this domain to a data element and then you can declare data objects in an ABAP program, or add a field in a database table or a structure using this data element. This data object gets all its semantic attributes from a data element and its technical attributes from the domain. For example, the Sales Invoice Header table has two fields for cash or card payment types. Both these fields have the same technical attributes, such as data type, length, and decimal places, so we need to have one domain. These two fields have different semantic attributes. The first field label should be Cash, and the second field label has to be Card. Other attributes, including the help you get after pressing F1, should be different for these fields. Therefore, you need to create two data elements that share technical attributes from the same domain. If the properties of the domain are changed, then all the fields or components created by the data element that was using this domain are automatically changed. So be careful while changing any domain and check the where-used list of the domain before making any changes.

Structures consist of fields or other components. An object in a structure can refer to another structure, a data element, and predefined data types. Structures are also called complex data types because they can be nested to any depth. Structures can be used as an interface for function modules, methods, screens, and subroutines.

Tables (Database Tables)
Tables are one of the most important objects in the ABAP Data Dictionary. A table consists of vertical columns and horizontal rows. Columns are called the fields of a table, and rows are the entries of a table. Every field in a table has a unique name and properties. Tables can have one or more key fields. One field or a combination of all key fields is called the primary key of the table. A single value or a combination of values in the primary key uniquely identifies a table entry. You can use a data element to define the field in a table, or a field can be defined using predefined data types. There are three types of tables in the ABAP Data Dictionary: transparent, pooled, and cluster.

Transparent Tables
Transparent tables have a one-to-one relationship between the ABAP Data Dictionary definition and the database. The database table has the same field name, semantic attributes, and technical attributes as the table definition in the ABAP Data Dictionary. Transparent tables are used to hold master or transactional data (e.g., Site Master table, Article Master table, Sales Header table, or Sales Item table). In our POS project development, we use only transparent tables.

Pooled Tables
Pooled tables have a many-to-one relationship between the ABAP Data Dictionary definition and the database. Many small tables at the ABAP Data Dictionary level do not depend on one another and are stored in one table pool in the database. Compared with transparent tables, this type of table has different names, different names of fields, and different numbers of fields in the database, so these tables cannot be accessed using Native SQL. Only Open SQL can handle the data of these tables, and these tables also cannot be used in table joins.

Cluster Tables
Cluster tables are the same as pooled tables in that they also have a many-to-one relationship between the ABAP Data Dictionary definition and the database. Many cluster tables of the ABAP Data Dictionary are stored as one table cluster in the database. Similar to pooled tables, these tables also have different names, different names of fields, and different numbers of fields in the database, so they cannot be accessed using Native SQL and also cannot be used in table joins. However, cluster tables hold functionally dependent data, whereas pooled tables hold functionally independent data. A cluster table is made up of larger tables, but there are fewer of them than in a pooled table. A pooled table has smaller tables, but more of them than a cluster.

The data for any business process is often stored in one or more tables. Most of the time we need to display a specific field or all the fields of this distributed data in one place. Views help to join all these tables and display all or specific fields as per business requirements. If a view has only one table, then we can insert, modify, or delete table records using a view. However, we can display data only if the view has more than one table. We can also apply some conditions in the selection (e.g., display specific fields from the Sales Header, Sales Item, and Article Master tables for sales invoices only). In this case this view does not display return invoices.

Search Help
Search help is a standard SAP function that allows users to display a list with possible input values in the screen field. The value selected from the display list automatically populates that screen field. The F4 key is used to display that possible input value list if search help is available on a field. Search help is an independent ABAP Data Dictionary object that you can attach to screen fields using standard development tools. Possible input values can be enhanced by adding more informative fields in this pop-up search help window. For example, in the Article Number field search help, we can add the article description, unit of measure, or any other properties for a better search.

Table Types (Internal Table Types)
Internal tables are in-memory tables that hold data during program execution. Few of our ABAP Data Dictionary objects can be created locally in a program (e.g., structure, search help, or table type). An internal table can also be defined in a local program, but it does not have global visibility. Objects defined in the ABAP Data Dictionary can have global visibility across the system. We can define a line or structure of a table type and access the type and key fields of this table in the ABAP Data Dictionary. In an ABAP program we can create an internal table with reference to this table type using DATA as a keyword.

To continue reading, please visit the full publication Introduction to ABAP: A Project-Driven Guide

Post a comment to this article

Popular Chapters

View More
  • Chapter 4: The Launch Phase

    This chapter examines the first of four phases every cloud implementation should have, beginning with the Launch phase and opening with an explanation of on-boarding methodology. While not a rehash of project management methodology, it provides best practice recommendations for selecting a project team, finding a partner, establishing project governance, creating project plans, reviewing and defining scope and transition, defining priorities, and refining roles and responsibilities.

    Read More
  • Chapter 3: SAP on the Cloud: In Depth

    This chapter examines SAP’s new cloud platform based on SAP HANA and how it is different not only from other similar applications but even from other SAP implementations. It also makes the case for on-premise implementations versus cloud managed services. It asks the question: If my SAP implementation is mission critical, should it be on the cloud? It also presents an overview of the methodology of moving SAP to the cloud, including a detailed discussion of SAP’s newest cloud platform based on SAP S/4HANA.

    Read More
  • Chapter 8: Software Updates

    This chapter covers the importance of software updates. It may seem like a boring topic, but keeping software up to date is essential to good security. We also talk about how a provider can implement updates without interrupting your service. You'll understand how those updates have prevented issues in the past and where to look for new SAP notes, which detail fixes. You should be able to ask intelligent questions about their update policy to make sure it's as aggressive as you need it to be. 

    Read More
View More