What is a Virtual Data Model (VDM)?
Figure 120: Virtual Data Model (VDM)
Database tables are generally not built for direct consumption by analytical applications. Database tables are generally consumed directly by transactional applications that need to read, insert, update and delete records. Database tables are often complex and do not easily represent business vies of data without combining them with other database tables. The main goal of a table is to provide a physical and optimal store of data, and this does not take their consumption by analytical applications into account. Optimal storage is their main goal, and this goal cannot always co-exist with the goal of ease of consumption. That is where a virtual data model comes in.
A virtual data model (VDM) is a hierarchy of views, in which each layer adds more business context, until the top layer is consumed by the application.
The lowest VDM layer sits on top of the database tables and consumes the most important data directly from the tables. Here we often see joins that bring the fragmented tables together.
The next VDM layer consumes from the first virtual layer to refine the data, apply filters, add calculations, convert currencies, change the description of the columns, and so on.
A VDM can be developed using scripting tools or graphical modeling tools. The VDM contains views that are fully reusable in any application, and can also be extended by customers. With the introduction of SAP Business Suite on HANA a few years ago, SAP developed their first VDM called SAP HANA Live. SAP HANA Live exposes all key operational tables from the various Business Suite applications such as ERP, CRM etc. and exposes them as views that can easily be consumed by any BI tool so that operational reports can be built. SAP HANA Live is still available and important for customers who run Business Suite on HANA (SoH). But for SAP S/4HANA, SAP HANA Live is not used . We have made huge changes to simplify
the SAP S/4HANA data model compared to Business Suite, and SAP HANA Live is based on the original, non-simplified data model that is used by Business Suite and not SAP S/4HANA. So you might wonder why we didn't just develop a new version of SAP HANA Live for SAP S/ 4HANA. SAP HANA Live is built using the modeling environment objects of SAP HANA, specifically HANA Calculation Views. Whilst there is nothing at all wrong with that, SAP HANA Live does come with many limitations. The key limitation is that SAP HANA Live has only one use case: Business Intelligence (BI). Whilst we do need to support BI, the SAP S/4HANA VDM also needs to support many other use cases, including planning, enterprise search, and so on. We did not want to develop separate VDMs for each of these use cases especially when they have so much in common.
So for SAP S/4HANA, we have a brand new implementation of the virtual data model using a completely different technology from SAP HANA Live that offers more flexibility. That technology is ABAP-managed Core Data Services (CDS) .
CDS-Based VDM for SAP S/4HANA Embedded Analytics
Figure 121: CDS-Based VDM for SAP S/4HANA Embedded Analytics
The SAP S/4HANA VDM is built with ABAP-managed CDS views. ABAP-managed CDS views are developed, maintained, and extended in the ABAP layer of the SAP S/4HANA system. They are ABAP artifacts, and are physically stored in the ABAP repository, where the ABAP programs reside. They do not reside in SAP HANA.
It is advisable to refer to them carefully as ABAP-managed CDS views because there is another type of CDS view that is managed and stored in the SAP HANA platform. These are called SAP HANA native CDS views. These CDS views are not relevant to SAP S/4HANA embedded analytics.
Many SAP S/4HANA embedded analytics tools directly consume the CDS views, but CDS views also generate transient BW InfoProviders. Think of these as dynamic BW InfoCubes that are created at runtime and disappear when the session ends.
This is good news, because it means you can build BW BEx queries using CDS views as the data source. It also means you can build reports with any SAP BI (BusinessObjects) tools, making use of the CDS views, with or without a BEx query.
A key concept behind CDS views is that they are the foundation for all consumption for SAP S/4HANA analytics and remove the need to develop the consumption layer in the database. ABAP-Managed CDS Views
Figure 122: What are ABAP-Managed CDS Views?
A CDS view is built using SQL, but with added annotations. When the CDS view is activated, an SQL view is generated in the SAP HANA database.
Annotations are added to the native SQL to enrich the data when it arrives at the ABAP layer. The annotations describe how the view can be used (for example, for OLAP use only), restrictions (for example, for the country France only), and business context (for example, this account is a supplier, not a customer).
When the CDS view is processed, the result is exposed to a hidden, embedded analytics engine. This is the same engine used by BW. This engine has been developed over many years and is very powerful. It can handle very advanced, multidimensional queries that include complex hierarchies.
This is why a key component of SAP S/4HANA embedded analytics is the embedded BW. The BW analytic engine is necessary for query processing and to generate the transient providers. CDS views do not contain ABAP code, just standard SQL plus annotations to enrich the data. The runtime for CDS views is ABAP, so an SAP NetWeaver stack is required to execute CDS
CDS views are built using the ABAP editor for Eclipse and since 1610 release we can also build CDS view using a simple Fiori application that key users may also be keen to use.
SAP S/4HANA VDM Architecture
Figure 123: SAP S/4HANA VDM Architecture
CDS views are built in layers. The idea is to provide a set of base layer views (called private views) to offer a high degree of reusability of common views. Then you combine these private views to make them more useful at the next layer (interface views).
Finally, you add more business semantics (such as filters and aggregation behavior) to provide a view that is optimal for consumption by the application code or analytic engine (consumption view).
At all layers, extensions can be added. Customers can also add their own views at any layer and combine them with SAP-delivered views.
This layering model is strictly enforced by SAP to provide governance and promote controlled extensibility.
LESSON SUMMARY You should now be able to:
● Describe a Virtual Data Model (VDM) and its implementation with SAP S/4HANA