Show TOC

Background documentationGlobal Data Types Locate this document in the navigation structure

 

Introduction

Business application modeling is oriented towards business objects (BOs): a BO defines part of the data that a business area works with. BOs are modeled without overlaps (more information: Basics).

To work with BO data in a business area at a later date, its data structure must be defined using data types in the Enterprise Services Repository. Despite there being no overlap of BOs, there are data structures that you will repeatedly need in different business areas, for example, describing address data (delivery address, customer address, billing address and so on). To achieve a high level of reusability for data types, SAP has defined global data types (GDTs), the semantics of which are independent from their use in a special application. In the case of the address data example, this means that there is an Address GDT which can be reused for either a delivery, customer, or billing address.

Note Note

To use Address and apply it in an application-specific way (data type name, for example) the application copies it to an application-specific namespace. Here it can be adapted in an application-specific way, such as when specific fields are not required.

End of the note.

If different data structures are defined for the same type of data in different components of a company or cross-company, then this can lead to an increase in costs when integrating applications. It is therefore essential to develop GDTs according to international standards to improve efficiency and to reduce development costs. At SAP this is ensured through a unification and standardization process (governance process). The whole process has two steps:

  1. Modeling the GDT. During the unification and standardization process, the modeling facilitates discussion and review of the structure of the GDT. After finalizing a GDT, the model documents the use of the GDT itself and any additional attributes and characteristics of the element that were modeled.

  2. Specifying the GDT in the ES Repository as a core data type or an aggregated data type is a prerequisite.

    More information: Core Data Types and Aggregated Data Types

SAP delivers both descriptions of GDTs as ESR content to customers. Customers can create their own data types in the ES Repository and use SAP GDTs.

The following sections describe the concepts for modeling GDTs to help customers understand the GDTs that are delivered.

Overview of Global Data Type Modeling

In the modeling environment there are the following model types for modeling global data types:

  • SAP Data Type Model

    For modeling global data types (GDTs). A distinction is made between “core data types”, “basic GDTs”, and “aggregated GDTs”.

  • SAP Qualifier List

    For assigning “qualifiers” to describe the different uses of the same global data type.

  • SAP Code List

    For assigning a list of “codes” that are valid as language-independent values for variables of a global data type.

The following graphic gives an overview of which model elements are modeled in which model types, and how the model elements are related to each other.

This graphic is explained in the accompanying text.

Model Types and Modeling Elements

A global data type is modeled with attributes, elements, qualifier lists, and code lists. Qualifier and code lists refer to models in which the global data type qualifiers or codes are stored. A cardinality is specified for the majority of connection types between modeling elements:

Target Cardinality

Meaning

1

Mandatory relationship. There must be exactly one target entity.

C

Optional relationship. There can be one target entity.

CN

Optional relationship. There can be more than one target entity.

N

Mandatory relationship. There can be more than one target entity, but there must be at least one.

Note Note

The graphical display of cardinality corresponds to the display of the ABAP Workbench in the Data Modeler.

End of the note.

The following sections discuss core data types, a specialization of a global data type, and which model items are relevant. All these types are shown with the following symbol:

Core Data Type, Basic GDT, or Aggregated GDT (Core Data Type, Basic GDT, or Aggregated GDT)

Aside from semantics, which are described in detail below, data types can be characterized in the following ways:

  • Core data types and basic GDTs are unstructured and can have additional attributes, depending on the representation term.

  • An aggregated GDT describes a data structure using elements that reference other aggregated data types, basic GDTs or core data types.

Core Data Type

Each core data type belongs to a representation term that comes from the Core Component Technical Specification (CCTS). Core data types are therefore not specific to SAP and do not determine any business semantics. Until now there have been the following representation terms and each had its own core data type modeled for it: Amount, Attachment, BinaryObject, Code, Date, DateTime, Description, Duration, Graphic, Identifier, Indicator, Measure, Name, Note, Numeric, Percent, Picture, Quantity, Ratio, Sound, Text, Time, URI, Value, Video.

Note Note

For some of these core data types, there are variants to help distinguish between the different formats of the same data in the modeling. For example, there is the variant YEAR_Duration for the core data type Duration. Variants like these do not specify how it is to be used in a business context.

End of the note.

The following figure provides an example:

This graphic is explained in the accompanying text.

Core data type for represenation term code.

Attributes (Attributes)

An attribute is a value or relationship for some, or all, instances of an entity and it is directly assigned to this instance.

Only core data types or basic GDTs can have attributes. Aggregated data types do not have any elements with attributes, but instead reference core data types or basic GDTs that are already available.

Basic GDTs

The name of a core data type is often not very helpful for using it in an aggregated data type. More specific GDTs are created for SAP applications - they are modeled using a projection connection to the original core data type (connection type: is projection of). “Basic GDTs” have their own name, qualifier, and code lists and can do without the attributes of the original core data types, if not required. You cannot model additional attributes, or rename attributes of the original core data type, for a basic GDT.

The following figure provides an example:

This graphic is explained in the accompanying text.

Projection CountryCode for Core Data Type Code

Code Lists

Icon

Use

For

Code Lists (Code Lists)

Code lists describe the language-independent valid “codes” for a basic GDT. This means that later language-dependencies for translation (English, German, French, Japanese, and so on) do not need to be taken into consideration in the program code.

Basic GDTs

Example Example

The code list for CountryCode contains the country code that is normally used in SAP applications:

This graphic is explained in the accompanying text.

Section from CountryCode Code List

End of the example.
Qualifier Lists

Icon

Use

For

Qualifier List (Qualifier List)

List of qualifiers that can be used for a global data type.

The data described by a global data type is there, basically, to ensure a high level of reusability. This is also true for the global data type name. SAP works with different qualifiers for different uses of the global data type. Each qualifier consists of a prefix to restrict its use and the original name of the global data type. This means that you do not have to create several global data types with different names if they have the same data structure.

Core data types, basic GDTs, and aggregated GDTs

Example Example

For the basic GDT CountryCode there is a qualifier list that contains, for example, the qualifier BankCountryCode and BirthCountryCode:

This graphic is explained in the accompanying text.

Section from CountryCode Qualifier List

End of the example.
Aggregated GDTs

Aggregated GDTs are made up of elements that reference other aggregated GDTs, basic GDTs, and core data types. Aggregated GDTs do not have attributes or code lists. Aggregated data types are structured.

The aim of data type modeling is to be able to reuse as many core data types, basic GDTs, and aggregated GDTs in other aggregated GDTs as possible.

Element (Element)

Element of an aggregated GDT.

An element either refers to a basic GDT, a core data type, or to another aggregated data type.

Example Example

The following figure provides an example: The aggregated data type Address has eleven elements. The PhysicalAddress element refers to a further aggregated GDT of the same name (the graphic only shows a section of PhysicalAddress):

This graphic is explained in the accompanying text.

Aggregated Global Data Type Address

End of the example.