The virtual data model (VDM) represents the semantic data model of the business applications in SAP S/4HANA. It aims at exposing all the business data in a way that eases its understanding and consumption.
It is called a virtual model because it abstracts data from the database tables. This way, existing tables can be transformed into an aligned uniform data model where necessary.
Besides describing the business semantics of the applications, the SAP S/4HANA VDM is also an executable model that provides access to the corresponding data at runtime. The VDM is implemented using specifically classified Core Data Services (CDS) entities, which comply with the VDM rules. Among others, these VDM rules include fundamental naming rules and rules for structuring the VDM entities.
On the one hand, the rules foster the consistency of the models; on the other hand, they allow efficient development of applications and APIs that cover analytical consumption, transactional processing, and search-related consumption scenarios. In addition to providing the data model for applications, VDM views are also used for other tasks, such as CDS-based extraction.
The VDM is not intended only to be used for developing applications at SAP. Instead, released SAP VDM models and released SAP services built on them offer a stable interface with a well-defined lifecycle. As an SAP customer or partner, you can use them to build your own applications and for enhancing SAP applications.
Core Data Services (CDS) support the definition of semantically rich data models. These models are managed by the Data Dictionary of the ABAP platform and can be executed in the database system.
CDS views represent the most important CDS entity type. They capture select statements in a syntax that is closely related to that of structured query language (SQL). CDS views can be used, for example, as the data source in ABAP select statements. The results of querying a CDS view can be restricted by attaching access control models to the CDS view. This means that the query only returns the data that the current user is authorized to read. These access control models are defined using the CDS data control language (DCL). CDS views support the definition of supplementary metadata by means of annotations.
Furthermore, CDS views allow modeling associations, which represent directed relations to other CDS entities. Both the annotations and the associations are interpreted by the various consumers of the CDS models. In specific, the ABAP infrastructure uses the corresponding information for deriving additional functionality and services from the CDS models. For example, a CDS view annotated accordingly can be executed by the analytic engine. The analytic engine provides advanced features such as exemption aggregations and hierarchy handling, which are not modeled by the plain select statement of the CDS view itself.
The VDM is based on a set of common naming rules. Applying the following rules ensures consistent and self-explanatory naming:
The naming rules are applied to all CDS entities and their parts—for example, names of fields, associations, parameters, or CDS views.
The figure below illustrates an example of an SAP Fiori app that uses an OData service, which in turn is based on a VDM view stack. As you can see, the first VDM view (at the bottom) maps the technical field name MATNR from the database table onto the semantic name Product, which is then used on several layers up to the user facing SAP Fiori UI.
Within the VDM, CDS entities serve distinct purposes. They are classified accordingly by means of VDM annotations. Note that a CDS entity becomes a VDM entity if it uses VDM annotations and if it adheres to the VDM guidelines.
VDM views are organized in a hierarchical structure following a layered approach. The upper layers select from and define associations to the same or lower layers, but not vice versa. The VDM views are assigned to layers with a special CDS annotation (@VDM.viewType).
The next figure depicts the admissible dependencies between the views as data sources and the different types of views. Along with the dependencies, the typical prefixes of the names of the CDS views are visible here too. Consumption views have name prefix C_ and remote API views have the prefix A_. Basic views and composite views form an interface layer that can be used for building applications. The views of this interface layer have name prefix I_. As we will explain in the following sections, basic views and composite views can also be restricted reuse views, indicated by name prefix R_. These views are intended to be reused locally within their own applications only.
The lowest level of the VDM view stack is defined by basic views. Basic views are the most important constituents of the VDM. They establish what you may call the entity relationship model of the applications, from which they get information about data structures, dependencies, and metadata. The main purpose of the basic views is to serve as reusable building blocks for any other nonbasic VDM views. Because the basic views expose all data, there is no need for any other nonbasic view to directly select from the database tables. In fact, accessing database tables from nonbasic VDM views is forbidden in the VDM. This way, basic views provide a complete abstraction from the database tables to higher layers.
Composite views comprise additional functionality on top of the basic views. Like the basic views, they are primarily intended to serve as reusable building blocks for other views. However, they can already be defined in such a way that they support a specific consumption domain. For example, they can define analytical cube views, which consolidate data sources for usage in multiple analytical queries.
Transactional views are a special flavor of composite views. Transactional views define the data model of a business object and act as an anchor for defining its transactional processing-related aspects. Transactional views may contain elements that support the transactional processing logic like additional fields that help preserving user input temporarily. Therefore, transactional views are only used in the context of transactional processing—for example, when consumed by other transactional views or by consumption views, which delegate their transactional processing logic to the transactional views.
Regular basic views support any use case. This means they are defined independent of a specific use case. In contrast, consumption views are deliberately tailored for a given purpose. Consumption views are expected to be directly used in a specific consumption scenario. For example, a consumption view can provide exactly the data and metadata (through annotations) that is needed for a specific UI element.
By default, basic and composite views define an interface layer (named with the I_ prefix), which any SAP application may use. Once released, they can also be used by SAP customers and partners. However, development teams sometimes define basic and composite views that are only for local use in their own applications. Such views are not meant to be reused by developers from other application areas. In such a case, a restricted reuse view (named with the R_ prefix) is defined. Examples of restricted reuse views are transactional processing-enabled views, which expose all functions and operations of a business object, including the internal ones.
Enterprise search uses special CDS views as search models.
Remote API views project the functionality of a single business object for external consumption. They decouple the regular, system-internal VDM model, which can evolve over time, from its external consumers, establishing a stable interface. Based on the remote API views, OData services are defined, which can be consumed by remote applications. The corresponding OData services are published on the SAP API Business Hub (https://api.sap.com).
The most prominent consumption scenarios supported by CDS entities are as follows:
The following figure shows a typical VDM view stack for analytical and transactional processing-enabled applications. Use case-specific views are defined on top of basic and composite reuse views to adapt the data model and functionality to the individual application needs.
Analytical applications are based on cube views and a network of associated dimension views, which themselves can associate text and hierarchy views. The actual analytical application is defined by an analytical query view, which projects the envisioned functionality from its underlying cube view. Note that unlike other CDS views, the analytical query views themselves are not executed on the database. Instead, the analytic engine interprets their logic and directly executes selections from the cube and dimension views.
The data model is captured by transactional views, which are related through compositional associations to form an entire business object. Therein the actual data selection logic is defined by the CDS view models. The behavior model specifying the supported Create, Read, Update, Delete (CRUD) operations is defined in an attached behavior definition model and implemented in ABAP classes. The consumption view projects relevant functionality and augments the data model with annotations that provide the metadata for rendering the UI application built on the view. Associated interface views can be used to enrich the data model where appropriate. The recommended way to develop transactional applications is using the ABAP RESTful application programming model.
Editor’s note: This post has been adapted from a section of the book SAP S/4HANA Architecture by Thomas Saueressig, Tobias Stein, Jochen Boeder, and Wolfram Kleis.