The virtual data model sits between the database tables and the analytical applications.
But why do we need a virtual data model? Why can't analytics read data directly from the database tables?
The SAP S/4HANA database contains a very large number of tables. There are tables to store transactional data such as sales orders and financial postings. There are tables to store master data, such as customer and product information. Data is spread out across these tables. Even a simple business report would require data from many transaction and master data tables. Tables need to be combined to create a meaningful data set. Also, the data in the tables is held in a raw, technical state and is usually not ready for immediate consumption by a business user. The virtual data model is responsible for combining the tables and preparing the data so it is ready for consumption by analytics.
The virtual data model is built entirely from ABAP CDS views. No data is persisted in the virtual data model, which is why is why it has the word virtual in its name. There are a huge number of views provided. It would be technically possible to generate a meaningful data set using just one view. But this would mean the view would become extremely complex having to take on all the tasks of combining tables, refining and converting data and calculating new values.
The approach taken by the SAP S/4HANA embedded analytics virtual data model is to stack the views in layers. Each layer provides a service to the next layer. The lowest layers take on the job of combining data from tables to create a data set. Master data is assembled into dimensions and transactional data is assembled into facts. But the data is still raw and so the next layer of views generates cubes of data that are ready to be queried. The highest layer of the virtual data model takes on the role of the query. This where the data is organized into shapes that are focused on each specific business scenario. Each view has a Data Category setting which defines its role, such as query or dimension.
One of the key objectives of layering is to ensure each view is as reusable as possible. For example, a dimension view that projects general product master data, would be consumed multiple times by many different cubes, such as sales and purchasing cubes. Same for a cube, which would have many query views built on top.
In addition to the Data Category, each view is defined with a View Type to further define its role. View types include:
- Consumption Views - a view (dimensions, cube, query) that is ready to be consumed directly by applications or analytical tools. (SAP standard views use the name prefix C_).
- Composite Views - Can only reads other views to form cubes or dimensions, and cannot read tables directly. Cannot be consumed directly by applications or analytical tools. SAP standard views use the name prefix I_ (this means 'Interface' view) with the view type composite setting.
- Basic Views - Consume tables directly to form dimensions, cubes. Also uses the name prefix I_ with the view type basic setting
Customers can create their own CDS views, and should use the prefix 'Z'.
Below is an example of an ABAP CDS view:
The views are code-based. The code is a mixture of SQL and SAP-specific syntax. The SQL provides the basic mechanics of selecting data from tables and views. The SAP-syntax add rich semantics that add meaning to the raw fields, such as providing a monetary value field with a currency. The SAP-specific syntax also defines associations to other related data sources to provide access to additional fields.
SAP S/4HANA embedded analytics includes tools to maintain and develop the ABAP CDS views. The tools are either using free-format code editors, or they are simpler, form-based tools where an understanding of the code syntax is not needed.
Note
To develop skills in ABAP CDS views, refer to the course Acquiring ABAP Core Skills on learning.sap.com. Look for the section Data Modeling in ABAP Dictionary and ABAP Core Data Services.