Why the VDM exists
To understand why Atlas plans against the Virtual Data Model rather than the underlying tables, it helps to know what programming against SAP looked like before the VDM existed. The answer is not a nostalgic aside — the habits that grew up in that era are the reason SAP had to invent the VDM, and those same habits are what Atlas refuses to reintroduce.
The world before
Section titled “The world before”Classic ECC stored data in roughly ninety thousand tables with cryptic
German-abbreviation names. A sales order did not live in one place —
it lived across VBAK for the header, VBAP for the items, VBEP
for the schedule lines, VBPA for partners, VBUK for header status,
VBKD for business data, with joins to MARA for material, KNA1
for customer, and several dozen more. The field names were equally
opaque: VBELN for document number, MATNR for material, WAERK for
currency. They only made sense if you had memorized the German words
they abbreviated.
The consequence was that every report a customer wrote — and there were thousands of them across every installation — had to discover those joins for itself, hardcode those field names, and encode its own version of the business rules for currency conversion, unit conversion, status interpretation, and organizational hierarchies. Two reports written in different years by different consultants would implement the same logic differently, and neither of them could change without breaking whatever downstream process depended on its exact output.
SAP inherited the other side of that problem. Every table had become a de-facto public API. Renaming a column, splitting a table, or adding a new status value could break thousands of customer reports the next time the upgrade ran. So SAP did not rename, split, or add — the tables became frozen, and everyone paid the cost.
What the VDM changed
Section titled “What the VDM changed”The Virtual Data Model is a strict hierarchy of CDS views that sits on
top of those physical tables and gives every concept a business name.
SalesOrder.NetAmount is a field on a view, not on a table.
SalesOrder.Customer.Name is a three-hop traversal through declared
associations, not a four-table join a reporter has to remember. The
business logic — currency conversion, unit conversion, status
interpretation — is implemented once inside the view and inherited by
everyone who consumes it.
The consequence for SAP is that the tables stop being the public API and the views become it. SAP can change a table internally as long as the view that sits over it continues to honor its published contract. The consequence for the customer is that reports no longer rediscover the joins; they consume the views and move on.
Why Atlas refuses to read the tables
Section titled “Why Atlas refuses to read the tables”Atlas will not emit a generated artifact that reads a physical table directly. Every view Atlas writes starts at the basic-interface layer of the VDM or higher, and the gate that protects this rule runs on every plan. The reason is exactly the reason the VDM was invented: code that bypasses the VDM reinherits the old problem — cryptic names, rediscovered joins, frozen upgrades. Atlas is not going to put new code into that trap on your behalf.
Which takes us to the next question worth asking: if the VDM is a strict hierarchy, what are the layers and which one is the right home for a given view? That is the subject of VDM layer architecture.