Data Modeling

In the development of business application software, parts of the real world must be represented in data form. A business unit represents an entity here. These entities exist in relationships with each other, which are fixed in the underlying data model. We also refer to an entity relationship model (ERM).

You use this data model as the basis for implementing appropriate table definitions (transparent tables) including their relationships with each other in the ABAP Dictionary.

By activating the table definitions, corresponding database tables are automatically created in the database. The actual application data is entered into those tables later on.

ABAP training courses, online documentation, and ABAP keyword documentation all use the same flight data model as an example. The Repository objects for the flight data model are in the package SAPBC_DATAMODEL.

In the context of this course it is sufficient to show a simple excerpt from this data model: If customers of a travel agency want to travel from one place to another, they require the travel agency to find out:

• Which connection offers the best and most direct flight?
• What the acceptable flight times are on the proposed day of travel?
• Whether, dependent on individual conditions, there is an ideal solution, such as the cheapest flight, the fastest connection, a connection with a particular arrival time.

This perspective differs from that of a travel agency: In the data model that is designed for managing the required data, the data is stored according to technical criteria in tables in a central database. The amount of data stored far exceeds the requirements of a customer.

You therefore need to be able to compile the data to meet the individual requirements of the customer using application programs.

The flight data model contains entities for all business information that is logically connected, such as:

• Cities
• Airports
• Airlines
• Flight routes
• Flights
• . . .

These entities all relate to each other in certain ways:

• Each flight schedule contains exactly one airline, one departure airport, and one destination airport.
• Each bookable flight always belongs to exactly one existing flight schedule.
• Assignments can be set between cities and nearby airports.

You can manage all necessary data, without redundancies, using these relationships. At the same time, the travel agency is able to obtain all the data requested by the customer.

For each entity fixed in the data model, the developer creates a transparent table in the ABAP Dictionary. This is merely a platform-independent description of a database table, not the database table itself. However, when the transparent table is activated, a table of the same name is automatically created on the database.

A transparent table contains different fields (columns) to allow you to store and manage data records in a structured way. You have to declare table fields as key fields when their content is to be used for the unique identification of data records within the database table. The key of a table (table key) consists of key fields. This is also called a primary key. Data records in the same table have to be unique with regard to the primary key values. The key value of a data record is thus a unique ID within the table.

Transparent Tables

In the ABAP Dictionary, a transparent table is an implemented description of the corresponding database table that contains the actual application data. The fields of the transparent table form the identically-named columns of the corresponding database table. Data elements, with which you are already familiar as global elementary data types, are normally used to describe the individual fields. The data elements themselves refer to domains for their technical properties.

As well as the list of fields, the transparent tables contain other information that is required in order to create a table of the same name on the database and describe its properties in full:

• The determination of the key for the database table (key fields)
• The technical properties that are required by the database in order to create the database table (expected size, expected frequency of access)
• Settings for technologies that can speed up access to the database table (secondary indexes, buffering)

At first glance, the definition of a transparent table appears very similar to the definition of a global structure type. In actual fact, transparent tables can be used in programming in the same way as structure types, for example, for defining a structured data object (structure variable), for typing an interface parameter, or as the line type of a global or local table type. Only the list of fields is important here, however. Other properties of the transparent table, such as the key definition or the technical properties, are irrelevant when using it as a data type.

As well as the additional properties relating to the database, there is another difference between transparent tables and structure types:

A transparent table is always a list of elementary fields, whereas the components of a structure type can themselves be structured again (nested structures). The component of a structure can even be typed with a table type (deep structures).