Virtual Data Model (VDM): How SAP Models Business Data in S/4HANA

As SAP S/4HANA evolved, SAP faced a significant challenge.

Thousands of applications, reports, APIs, analytical applications, and Fiori apps required access to the same business data.

If every application directly accessed database tables, several problems would arise:

• Duplicate Business Logic
• Inconsistent Calculations
• Difficult Maintenance
• Upgrade Risks
• Tight Coupling with Database Structures

SAP needed a standardized data access layer that could be reused across the entire system.

This led to the introduction of the Virtual Data Model (VDM).

The Virtual Data Model is SAP's standardized CDS-based representation of business data.

Instead of exposing database tables directly, SAP exposes business entities through CDS Views that follow strict modeling guidelines and naming conventions.

Today, the VDM forms the foundation of:

• SAP Fiori Applications
• RAP Applications
• OData APIs
• Embedded Analytics
• Standard SAP APIs
• SAP S/4HANA Business Processes

The word Virtual often creates confusion.

The VDM does not store data separately.

Data continues to reside in the underlying database tables.

The VDM simply provides a business-oriented representation of that data through CDS Views.

Think of the VDM as a semantic layer that sits between database tables and applications.

Instead of reading raw technical tables, applications consume business-friendly CDS entities.

Consider a Sales Order.

The underlying data may be distributed across multiple tables:

• VBAK
• VBAP
• KNA1
• MARA
• VBKD

A developer could manually join these tables every time data is required.

However, SAP provides a CDS-based representation of the Sales Order business object through the VDM.

Applications consume the business object rather than dealing with individual tables.

This improves consistency, maintainability, and reuse.

The VDM was designed to achieve several objectives:

Standardization

Provide a single, consistent representation of business data.

Reusability

Allow multiple applications to consume the same CDS models.

Simplification

Hide technical database complexity behind business-oriented entities.

Upgrade Stability

Applications consume released CDS APIs rather than internal database tables.

Clean Core Compliance

Encourage developers to use released interfaces instead of directly accessing SAP implementation tables.

The Virtual Data Model follows a layered architecture.

Each layer serves a specific purpose.

This separation improves maintainability and promotes reuse.

Basic Views sit closest to database tables.

They expose foundational business data and establish relationships between entities.

Examples include:

• Product
• Customer
• Supplier
• Material
• Sales Document

These views are primarily designed for reuse by higher-level CDS models.

Composite Views combine multiple Basic Views and introduce additional business logic.

They often perform:

• Joins
• Calculations
• Aggregations
• Business Transformations

Composite Views help create meaningful business structures from multiple underlying entities.

Consumption Views sit at the top of the hierarchy.

These views are designed specifically for consumption by:

• Fiori Applications
• OData Services
• Analytics
• APIs

They contain UI-related annotations, search capabilities, filters, and consumption-specific metadata.

This layered approach allows SAP to separate technical modeling from application-specific requirements.

SAP follows standardized naming conventions within the VDM.

These conventions help developers immediately understand the purpose of a CDS View.

Interface Views.

These are reusable business entities intended for consumption by other CDS Views.

Examples:

• I_Product
• I_BusinessPartner
• I_Customer
• I_Supplier

These are among the most commonly used released APIs in SAP S/4HANA.

Consumption Views.

These are designed for direct consumption by applications, analytics, and reporting tools.

Examples:

• C_SalesOrderItem
• C_BillingDocument

API Views.

These views are specifically released as public APIs for external consumption.

Examples:

• A_SalesOrder
• A_BusinessPartner

These APIs are frequently used in RAP and ABAP Cloud development.

The relationship between RAP and the Virtual Data Model is extremely important.

RAP Business Objects are built on top of CDS entities.

SAP's standard business objects are already represented through VDM views.

When building RAP applications, developers often:

• Consume released VDM views
• Extend VDM entities
• Create custom CDS entities following VDM principles

This ensures consistency with SAP's architecture and Clean Core strategy.

ABAP Cloud development encourages developers to use released APIs rather than directly accessing SAP tables.

Many of these released APIs are implemented as VDM CDS Views.

As a result, understanding the VDM is essential for:

• RAP Development
• ABAP Cloud
• Clean Core Compliance
• SAP S/4HANA Extensibility

Developers who understand the VDM can build applications that remain upgrade-safe and aligned with SAP's future direction.

RAP is built on top of CDS entities.

In most cases, RAP Business Objects are not created directly on database tables.

Instead, they are built on top of CDS entities that often follow VDM principles.

This provides:

• Business Semantics
• Reuse
• Security
• Clean Core Compliance
• Future Compatibility

Understanding the VDM therefore becomes essential for every RAP developer.