What is a CDS View in SAP? Beginner's Guide (2026)

If you are learning modern ABAP, you will encounter CDS views everywhere — in S/4HANA custom development, Fiori apps, embedded analytics, and OData services. But what exactly is a CDS view, and how is it different from the database views you may already know?

This beginner’s guide explains the CDS concept from the ground up: what it is, how it is defined, what annotations and associations do, and how CDS views are consumed in real applications.

What Is a CDS View?

CDS stands for Core Data Services. A CDS view is a data model defined in a declarative, SQL-like language that sits on top of the database. You describe what data you want and how entities relate — the system figures out the optimal way to execute it.

The key ideas:

Declarative, not procedural — You define the result you want (fields, joins, filters), not the step-by-step procedure to compute it.
Semantically rich — Beyond columns, CDS carries meaning: labels, currencies, units, and relationships, expressed through annotations.
Database-executed — The logic runs inside the SAP HANA database, taking advantage of in-memory, columnar processing (this is the code pushdown principle).
Reusable — CDS views can be stacked: one view builds on another, creating layered, maintainable data models.

In the ABAP world, these are called ABAP CDS views. They are defined in the ABAP repository and consumed from ABAP programs, OData services, and analytics tools.

The DDL Source: Where CDS Lives

A CDS view is defined in a DDL source — a development object written in the CDS Data Definition Language, edited in the ABAP Development Tools (ADT). A simple example:

@AbapCatalog.sqlViewName: 'ZV_FLIGHT'
@EndUserText.label: 'Flight connections demo'
define view Z_C_FlightDemo
  as select from sflight
{
  key carrid   as Airline,
  key connid   as Connection,
      fldate   as FlightDate,
      price    as Price,
      currency as Currency
}
where carrid = 'LH';

What is happening here:

@AbapCatalog.sqlViewName — the technical name of the generated database view.
@EndUserText.label — a human-readable description (an annotation).
define view ... as select from ... — the view selects from table sflight.
key — marks key fields of the view.
as — renames fields to business-friendly names.
where — filters the data at the database level.

When activated, this creates a real database view plus an ABAP-usable entity. You can then simply write:

SELECT * FROM z_c_flightdemo INTO TABLE @DATA(lt_flights).

Annotations: Adding Meaning to Data

Annotations are metadata attached to CDS entities and fields with the @ syntax. They are one of the features that make CDS far more powerful than plain SQL views. Common examples:

@EndUserText.label: '...' — display label for a field or view.
@Semantics.amount.currencyCode: 'Currency' — declares that Price is an amount tied to the Currency field, so tools format it correctly.
@Semantics.unitOfMeasure: true — marks a field as a unit of measure.
@UI.* annotations — control how fields render in Fiori elements apps (which are visible, which are filters, and so on).
@AccessControl.authorizationCheck: #CHECK — enables authorization checks on the view.

Annotations separate data definition from consumption concerns: the same CDS view can feed an ABAP report, a Fiori app, and an analytics query, with each consumer interpreting the annotations it needs.

Associations: Relationships Without Explicit Joins

An association defines a relationship between CDS entities — for example, flights to airlines — without writing a JOIN in the view body:

define view Z_C_FlightWithCarrier
  as select from sflight
    association [0..1] to scarr as _Carrier
      on $projection.carrid = _Carrier.carrid
{
  key carrid as Airline,
  key connid as Connection,
      fldate as FlightDate,
      _Carrier.carrname as CarrierName
}

The important detail: the join to scarr is only executed if the consumer actually uses _Carrier fields. This is called an on-demand join, and it keeps queries efficient — you define all potentially useful relationships once, and the database includes only what is needed.

Associations also make CDS views composable: views expose associations that higher-level views can navigate, building clean layered models.

Parameters: Making Views Flexible

CDS views can accept parameters, letting consumers pass values (like a date range or company code) into the view:

define view Z_C_FlightsByDate
  with parameters p_date : abap.dats
  as select from sflight
{
  key carrid as Airline,
  key connid as Connection,
      fldate as FlightDate
}
where fldate = :p_date;

Consumed from ABAP:

SELECT * FROM z_c_flightsbydate( p_date = @sy-datum )
  INTO TABLE @DATA(lt_today).

Parameters make a single view reusable across many scenarios instead of hardcoding filters.

How CDS Views Are Consumed

A CDS view is not just for ABAP SELECTs. The same artifact feeds multiple consumers:

ABAP programs — SELECT from the view like a table.
OData services / Fiori apps — expose the view (with UI annotations) as an OData service; Fiori elements can generate a full app from it.
Embedded analytics — analytical CDS views (with @Analytics annotations) power analytical queries and KPIs in S/4HANA.
Other CDS views — stack views into layered models: basic interface views, composite views, and consumption views.

This “define once, consume many ways” property is central to SAP’s data strategy.

CDS Views vs Classic Database Views

Aspect	Classic DB view (SE11)	CDS view
Definition language	Graphical / table-based	DDL source code
Semantics	Columns only	Columns + annotations (labels, currencies, units)
Relationships	Explicit joins only	Associations with on-demand joins
Parameters	Not supported	Supported
Reuse	Limited	Designed for layered, stacked models
Tooling	SE11	ADT (Eclipse), version-controlled source
Analytics/Fiori	Manual work	Native via annotations

Classic views still work fine, but all new SAP modeling — and all S/4HANA standard content — is built on CDS.

A Slightly Richer Annotated Example

Here is an example combining several concepts: annotations, an association, and a calculated field:

@AbapCatalog.sqlViewName: 'ZV_BOOKING'
@EndUserText.label: 'Bookings with customer names'
define view Z_C_BookingDemo
  as select from sbook
    association [1..1] to scustom as _Customer
      on $projection.customid = _Customer.id
{
  key carrid    as Airline,
  key connid    as Connection,
  key fldate    as FlightDate,
  key bookid    as BookingId,
      customid  as CustomerId,
      _Customer.name as CustomerName,
      @Semantics.amount.currencyCode: 'Currency'
      forcuram  as Amount,
      forcurkey as Currency
};

This view joins bookings to customers only when CustomerName is selected, carries currency semantics for correct formatting, and is immediately consumable from ABAP, OData, or analytics.

Common Beginner Mistakes

Treating CDS like a 1:1 table replacement — CDS shines when you model relationships and semantics, not when you just rename table fields.
Ignoring annotations — a view without annotations works, but misses most of CDS’s value for Fiori and analytics.
Over-stacking views — layered models are good, but excessively deep view stacks can hurt performance and readability. Keep layers purposeful.
Forgetting authorization checks — decide on @AccessControl.authorizationCheck deliberately; unprotected views over sensitive data are a security risk.
Writing procedural logic in CDS — CDS is declarative. If you need loops or complex algorithms, that logic belongs in AMDP/table functions, exposed through a CDS interface.

Frequently Asked Questions

Q1. What does CDS stand for?

CDS stands for Core Data Services — SAP’s framework for defining semantically rich data models.

Q2. Do I need HANA to use CDS views?

ABAP CDS views are designed around the HANA database and S/4HANA. They are a core part of the S/4HANA programming model; on older non-HANA systems, classic views and traditional ABAP remain the norm.

Q3. What is the difference between a CDS view and an AMDP?

A CDS view is declarative modeling (what data you want). AMDP (ABAP Managed Database Procedures) is for procedural database logic written in SQLScript. They complement each other: AMDP logic can be exposed through a CDS table function.

Q4. Can CDS views be edited or do they only read data?

Standard CDS views are read models. For transactional scenarios, SAP provides BOPF or the ABAP RESTful Application Programming Model (RAP), where CDS defines the data model and behavior is implemented separately.

Q5. How do I create a CDS view?

In the ABAP Development Tools (ADT), create a new DDL Source object, write the define view statement with annotations, and activate it. Activation generates the database view and makes the entity available for consumption.

Q6. Are CDS views transported like normal ABAP objects?

Yes. The DDL source is a repository object transported through the standard ABAP transport system (workbench requests), which is another advantage over database-level artifacts managed outside ABAP.

The Bottom Line

A CDS view is SAP’s modern way of modeling data: a declarative, annotation-rich, reusable definition that runs inside the HANA database and can be consumed from ABAP, Fiori, OData, and analytics alike. Learn the DDL basics, understand annotations and associations, and practice stacking simple views — that foundation carries directly into S/4HANA development, RAP, and Fiori work.

Once you know CDS, the next performance leap is understanding pushdown — and knowing the tables underneath helps too. See our SAP MM tables complete list for the classic entities CDS views are often built on.

What is a CDS View in SAP? Beginner’s Guide with Examples