VDM layer architecture
The VDM is not a pile of views — it is a small, strict hierarchy with rules about what each layer is allowed to do. Atlas’s planner follows the hierarchy exactly, because the hierarchy is what makes the whole model stay consumable across upgrades. This page is about what the layers are, why they exist, and what it means that each one has a job it cannot delegate.
The three main layers
Section titled “The three main layers”Basic interface views are the foundation. Each one — prefixed
I_ and annotated @VDM.viewType: #BASIC — maps one physical table
one-to-one. I_SalesOrder sits on VBAK. I_Product sits on MARA.
I_CompanyCode sits on T001. The work a basic view does is quiet
but load-bearing: it renames cryptic fields to business names, attaches
labels and currency and unit annotations, and declares associations to
related basic views. Importantly, the association joins are not
executed until a downstream view actually reads a field across them.
This lazy evaluation is why the VDM scales to enterprise queries that
touch hundreds of tables.
Composite interface views — also prefixed I_ but annotated
@VDM.viewType: #COMPOSITE — combine multiple basic views into
richer business objects. I_SalesOrderItem joins I_SalesOrder with
item-level data and consumes the associated product and customer
basic views. Composite views have one rule they cannot violate: they
must not read physical tables. Every field they expose comes from a
basic view underneath. That is the invariant that keeps the database
abstraction airtight, and it is one of the invariants Atlas gates
every plan against.
Consumption views — prefixed C_ and annotated
@VDM.viewType: #CONSUMPTION — are use-case specific. A single
composite view might feed half a dozen consumption views: one for a
Fiori list tile, one for an analytical query, one for a KPI card, one
for an OData service. Consumption views carry the annotations that
tell downstream runtimes how to present the data — the UI layout, the
analytical role, the service binding.
The three side branches
Section titled “The three side branches”Three more prefixes show up inside the VDM but sit outside the core hierarchy. They are worth knowing about because they carry different stability guarantees, and Atlas treats each one differently.
R_ (restricted reuse) is a view intended only for reuse inside its own application domain. When Atlas sees a plan that would reach an R_ view from outside its domain, it flags the node amber and surfaces the boundary crossing on the evidence trail.
P_ (private) is SAP-internal. It can change between releases
without notice. Atlas refuses to emit artifacts that bind to P_ views
without an explicit override; the gate G-112 is the rule. See
SAP API stability tiers
for the full picture.
A_ (remote API) is a stable, versioned, public-facing variant of
an interface view. When SAP publishes an A_ for something Atlas would
otherwise bind to an I_, Atlas prefers the A_ — the upgrade contract
is stronger there.
Why Atlas plans from the bottom up
Section titled “Why Atlas plans from the bottom up”When you ask Atlas for a consumption view, it does not start by writing that view. It asks Keystone which composite views the view will depend on, which basic views sit under those, and which physical tables ultimately underlie the basics. The plan Atlas emits is that dependency order: basic nodes first, composites on top, consumption last. The build proceeds bottom up because that is the order the rules permit, and the gates that check the rules run top down to catch any attempt to break them.
If you find this layered picture familiar, you are right to — it is the same three-tier structure that most mature database applications end up with, just with SAP-specific names and a CDS-specific language for expressing it. The difference is that in the VDM the rules are enforced by annotations and by the stability contract SAP publishes, not by conventions a team agrees to among themselves.
What this enables next
Section titled “What this enables next”Once you can place a view on the layer grid, the question becomes how the view reaches across to data in other views. The answer is associations, and they are important enough to deserve their own page: CDS associations.