What is a CDS View?

CDS (Core Data Services) is a next-generation data modelling

infrastructure that allows developers to define semantically rich data
models on top of database tables and views.
CDS is more than just a way to define views—it's a framework for
enhanced data modelling, integrating data access, business semantics,
and UI annotations in one place.
In essence:
A CDS View is an advanced type of database view designed to be
used with SAP HANA and S/4HANA, where data processing logic is
pushed down to the database layer for better performance and
scalability.

Why CDS Was Introduced

Before CDS, ABAP developers used SE11 database views and wrote
business logic in the ABAP layer. But with the arrival of SAP HANA, a
high-performance in-memory database, SAP pushed the paradigm of
Code Pushdown.
Instead of moving data to the application, we move logic to the
data.
CDS is SAP’s solution for this paradigm shift:
 It reduces data transfer between DB and application.
 It enhances performance by leveraging HANA's in-memory
capabilities.
 It combines data access and business semantics.

Advancements in CDS Views

CDS brings powerful features that span across performance, semantics, UI
integration, and more. Here's a categorized view of the advancements:

1. Advanced Data Modelling Features

Feature Description

Replace joins with lazy-load associations;

Associations
reusable and easier to maintain

Full SQL-like join operations (INNER, LEFT OUTER,

Unions & Joins
etc.)

View Parameters Allow dynamic input parameters to filter data

Feature Description

Define expressions or calculated columns within

Calculated Fields
the view

Nested Views
Build modular layers of CDS views for reusability
(Composability)

Group By & Support for SQL GROUP BY and aggregate

Aggregation functions (SUM, COUNT, etc.)

Case Expressions Conditional logic directly in the view

Literal and Cast

Data type conversions and default values
Expressions

Filters on
Filter associated data in a flexible, readable way
Associations

2. Code Pushdown and Performance

Feature Description

Logic runs on the database layer (HANA) for

Pushdown to HANA
better performance

Only needed data is fetched—no ABAP-level

Reduced Data Transfer
filtering

Eliminates Redundant
Avoid nested SELECTs or LOOP ATs in ABAP
Loops

Performance Leverages HANA’s in-memory processing and

Optimization column store

3. Annotations for Metadata and Semantics

Type Example Use Case

Description shown in Fiori or

@EndUserText.label
SE11

Technical SQL view name for

@AbapCatalog.sqlViewName
compatibility

Define how data is displayed

@UI.*
in Fiori
Type Example Use Case

Instantly expose CDS view as

@OData.publish
an OData service

Enable CDS view for

@Analytics.query embedded analytics (as a
query)

Controls whether DCL

@AccessControl.authorizationCheck
authorization is applied

Define navigation and keys in

@ObjectModel.foreignKey.association
UI/OData

4. UI & Fiori Integration

Feature Description

Control table columns, grouping, field

UI Annotations (@UI.*)
importance in Fiori UI

@OData.publish: true exposes view as REST

OData Ready
service

Smart Controls Auto-generate UIs with SmartFilterBar,

Support SmartTable, etc.

Enable navigation between Fiori screens via

Navigation Support
associations

Line Item & Field

Display fields in sections in Fiori Object Pages
Grouping

5. Embedded Analytics & Reporting

Feature Description

Analytics Cube & Build analytical data models for Fiori

Dimension KPIs, reports

Multidimensional
Supports star-schema style modelling
Modelling

Consumption Views Tailor CDS for analytical or UI purposes

Input Parameters and

Enable dynamic report generation
Filters
 6. Security & Authorization
Feature Description

DCL (Data Control Language) Row-level security for CDS views

@AccessControl.authorizationCheck Integrates DCL logic in a view

Automatically applied without

Transparent Authorization
ABAP logic

7. Extensibility & Maintainability

Feature Description

extend view allows adding fields without

View Extensions
modifying the original

Metadata-driven Easy to update, refactor, and scale

Separation of Break logic into layers (basic, composite,

Concerns consumption)

Documentation & Metadata annotations improve documentation

Search and discoverability

8. Integration with Other SAP Technologies

Feature Description

OData Services Direct consumption in SAP Gateway

Fiori Elements Auto-generated UI based on annotations

Combine with AMDP (for complex logic) and BOPF (for

AMDP & BOPF
transactional apps)

BW/4HANA &
CDS can serve as source for BW or SAP Analytics Cloud
SAC
Advantages of using CDS views over SE11
views?
CDS View vs Traditional ABAP View (SE11 View) :

Feature CDS View (DDL) ABAP View (SE11)

Where Created Eclipse (ADT), HANA Studio SAP GUI (SE11)
Underlying
SQL-based DDL on HANA DDIC database view
Technology
Annotations Support ✅ Yes (UI, OData, Analytics) ❌ No
Association Support ✅ Yes (modern JOIN syntax) ❌ No (only joins)
Calculated Fields ✅ Supported ⚠️Limited/Not easy
Modularity (Extend ✅ Possible with EXTEND
❌ Not supported
View) VIEW
Performance ✅ Optimized for HANA ❌ Executes in ABAP
Optimization pushdown layer
Use in OData/Fiori ✅ Easily exposed ❌ Not directly
Activation Object SQL View + CDS Metadata Database View
Transported? ✅ Yes (via DDL source) ✅ Yes (via DDIC)

Annotations in CDS
Annotations in a CDS (Core Data Services) View are metadata expressions
used to add semantic meaning, behaviour, and UI-related instructions to
CDS entities. They guide how CDS views are processed by the system,
consumed by frameworks (like UI5, OData), or exposed externally.
They are written using the @ symbol before the CDS definition elements.

Types of Annotations:
1. @AbapCatalog… – Controls technical DB settings (e.g., buffering,
SQL view name)
2. @EndUserText… – Adds descriptions (e.g., view labels, field labels)
3. @OData.publish: true – Exposes the CDS view as an OData
service
4. @UI… – Defines how the data should appear in Fiori/UI5 apps
5. @Consumption… – Used for analytical/consumption scenarios
6. @ObjectModel… – Links views to BO behaviour or associations

Some commonly used annotations –

1. ABAPCatalog Annotations
Used for technical settings at DB level.
@AbapCatalog.sqlViewName: 'ZMY_SQL_VIEW'
 @AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true

Annotation Purpose
sqlViewName Defines the DB view name
preserveKey Keeps keys in the SQL view
compiler.compareFilter Optimizes filter comparison

2. End User Text Annotations

Adds descriptions for UI & documentation, i.e. Descriptive name for
view/field
@EndUserText.label: 'Sales Order Header View'

3. OData Annotations
Expose CDS views as OData services automatically.
@OData.publish: true
After activation, register service in /IWFND/MAINT_SERVICE.

4. UI Annotations (For Fiori/UI5)

Control field behaviour, grouping, importance in Fiori apps.
@UI.headerInfo: {
typeName: 'Sales Order',
typeNamePlural: 'Sales Orders',
title: { value: 'vbeln' }
}

@UI.lineItem: [{ position: 10 }]
@UI.selectionField: [{ position: 1 }]
@UI.identification: [{ position: 10 }]

Annotation Purpose
headerInfo Info for Object Page
lineItem Field shown in list
Annotation Purpose
selectionField Field for filters
identification Fields in detail page

5. Consumption Annotations
Helpful for analytical and report-oriented views.
@Consumption.filter: true
@Consumption.derivation: { type: #CUSTOM }

Annotation Purpose
filter Allows dynamic filters
defaultValue, mandatory,
Advanced filtering logic
derivation

6. ObjectModel Annotations
Define behaviour for associations and business object models.
@ObjectModel.readOnly: true
@ObjectModel.modelCategory: #BUSINESS_OBJECT
Real-Time Mini Example
@AbapCatalog.sqlViewName: 'ZCDS_SO_HDR'
@AbapCatalog.preserveKey: true
@EndUserText.label: 'Sales Order CDS View'
@OData.publish: true
define view ZCDS_SalesOrder as select from vbak {
@EndUserText.label: 'Sales Order Number'
@UI.lineItem: [{ position: 10 }]
key vbeln,
@EndUserText.label: 'Order Type'
@UI.lineItem: [{ position: 20 }]
 auart,
@EndUserText.label: 'Sales Org'
@UI.selectionField: [{ position: 1 }]
vkorg
}
After activation:
 Go to /IWFND/MAINT_SERVICE
 Add system alias → Activate the service ZCDS_SALESORDER_CDS

Types of CDS Views in SAP

1. Basic View -

 Purpose: Foundation layer to model raw data from database tables.

 Features: Simple joins, projections, renaming fields.
 Reusability: Used by other CDS views (composite or consumption).
 Lightweight and reusable.

Think of this as the “building blocks” of your CDS architecture.

2. Composite View –

 Purpose: Combine multiple basic views, perform calculations, add

business logic.
 Features: Joins, associations, derived fields, aggregations.
 Reusability: Used by consumption views or OData services.

Acts as the middle layer: logic-heavy, but still not exposed to users
directly.

3. Consumption View –

 Purpose: Final layer exposed to UI, analytics, or external

consumers.
 Features: Rich annotations (@UI, @Analytics, @OData.publish),
filtering, sorting.
 Use case: Fiori apps, SmartControls, reporting.

Tailored for end users—polished and semantically meaningful.

4. Analytical View (also known as Cube or Query view)

–
  Purpose: Designed for embedded analytics and reporting.
 Annotations:

a. @Analytics.dataCategory: #CUBE for cubes (facts)

b. @Analytics.dataCategory: #DIMENSION for dimensions
(master data)
c. @Analytics.query: true for queries

 Supports: Aggregation, group by, KPIs, input parameters.

Ideal for real-time analytics in SAP Fiori or SAP Analytics Cloud.

5. Transactional CDS View –

 Purpose: Support transactional Fiori Elements apps

(create/update/delete).
 Annotations:

a. @ObjectModel.compositionRoot
b. @ObjectModel.writeActivePersistence
c. @ObjectModel.draftEnabled (optional)

 Use case: Used in apps like Manage Sales Orders, Create Purchase
Requisition, etc.

Helps power transactional business apps with automatic behaviour using

RAP/BOPF

6. OData-Exposed View –

 Purpose: Expose CDS as an OData service.

 Annotation: @OData.publish: true
 Use case: Integration with frontend apps or third-party systems.

Can be combined with consumption or transactional views for Fiori apps.

Associations in CDS view

In Core Data Services (CDS), associations serve as a powerful tool to
define and manage relationships between entities. They enhance query
flexibility and optimize database operations by enabling relationships
between CDS views or source data sets. This blog provides an in-depth
understanding of associations, their types, usage, and how they differ
from traditional joins. Let’s explore how associations can simplify your SAP
development.

What are Associations?

An association in CDS defines a relationship between entities. It allows the
current CDS view to reference a target data source through
an ON condition. While associations and joins are functionally similar at
the database level, the real power of associations lies in their ability to
streamline query execution and enhance performance.

Key features of associations include:

They are translated into ordinary joins at runtime.
Associations execute only when the associated data source is
explicitly queried, a concept known as “Join on Demand.”
They may include additional semantic information like cardinality.

Types of Associations
1. Exposed Associations
Exposed associations are explicitly declared in the CDS view,
making them visible to consumers.
SQL CREATE statements do not include a JOIN clause for exposed
associations unless they are queried.
Exposing an association ensures efficient database performance, as
the join happens only when needed.
All elements of the association source used in the ON condition
must be included in the field list.

2. Ad-Hoc Associations
These are defined using individual fields of the associated table or
CDS view. The join is built directly into the SQL view when ad-hoc
associations are used.

3. Filtered Associations
Filtered associations allow you to restrict data sets from the
association target using conditions in square brackets ([ ]). This
ensures more focused data retrieval and avoids overloading queries
with unnecessary data.

4. Path Expressions
Path expressions let you use an association by adding a period (.)
and an element name after the association name. This provides
direct access to fields in the associated target.

Cardinality in Associations –
Cardinality specifies the nature and extent of the relationship between two
entities. It defines how many records in one entity correspond to records
in another. It is expressed as [min..max]:
min: Minimum number of data sets (0 or positive integer).
max: Maximum number of data sets (positive integer or * for
unlimited).
Default cardinality is [0..1].
Below is a detailed breakdown of cardinalities with examples and use
cases –
Cardinalit Description Example Use Case
y
1..1 One-to-One Every customer in table A has exactly
one corresponding record in table B
0..1 Zero-to-One or A customer might not have a linked
Optional-to-One address in the address table.
1..* One-to-Many A customer in table A can have
multiple email address in table B
0..* Zero-to-Many or Some customer might have no orders,
Optional-to-Many while others have many

Properly defining cardinality ensures clarity and prevents ambiguities in

data relationships.
Below is a sample CDS view that demonstrates various types of
associations:
define view entity ZEmployee_data
as select from Z_employee
association [1..1] to Z_Department as _Department
on $projection.DepartmentId = _Department.Id
{
key employee_id as EmployeeId,
first_name as FirstName,
last_name as LastName,
department_id as DepartmentId,
_Department.DepartmentDesignation, // Ad-hoc Association & pathexpression

_Department[language = 'E'].name as DepartmentName, // Filtered Association

& pathexpression
_Department // Exposed Association
}

The corresponding ABAP SQL query using path expressions:

SELECT FROM ZEmployee_data
FIELDS EmployeeId,
 DepartmentId,
_Department.head // pathexpression
INTO TABLE @DATA(result).

This example highlights how associations simplify data access and provide
flexibility in querying.
Associations in CDS views are a game-changer for developers, offering
flexibility, performance, and clarity in defining relationships between
entities. By using exposed, ad-hoc, and filtered associations, developers
can achieve highly optimized and intuitive queries.

Basic difference between JOIN and ASSOCIATION in CDS

–
The main difference between join and association comes in terms of data
loading. While using joins, all the data comes at once from all the table
used;
While in association data from the second table comes only it is required,
we can say association is a lazy loading basically.