CDS Views Part 1: What a CDS View Entity Is and Why It Matters

📌 KEY POINTS
✅ CDS = data model executed on the database (code pushdown).
✅ Use "define view entity" — classic views with sqlViewName are obsolete.
✅ Layers: I_ (reuse) → C_ (per app); R_ for RAP business objects.
⚠️ CDS is read-only; changes go through RAP.

▶ WHAT THIS SERIES COVERS

• Part 1 — what a CDS view entity is and why it matters (this lesson)
• Part 2 — build your first view entity in ADT (a sales order item view)
• Part 3 — performance: joins, associations, filters and aggregation
• Part 4 — authorization with DCL and clean-core data access

After this series continue with CDS Associations and CDS Annotations, then RAP Business Objects.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT CDS IS
Core Data Services (CDS) is SAP's language for defining data models directly on the database. You write a CDS definition in ADT; on activation it becomes a database object (on SAP HANA, an SQL view) plus ABAP metadata. When anybody reads it, the database executes it — joins, filters, calculations and aggregations run where the data is ("code pushdown"), not in the ABAP application server.

A CDS view does not store data. It is a named, reusable query with business meaning: readable field names, keys, relationships (associations), semantics (this field is an amount, that one its currency) and annotations for UI, analytics, search and authorization.

━━━━━━━━━━━━━━━━━━━━
▶ VIEW ENTITY VS CLASSIC CDS VIEW
There are two generations:

• Classic CDS view — "define view" with @AbapCatalog.sqlViewName. Activation creates an additional DDIC SQL view. This is the older approach and is obsolete for new development.
• CDS view entity — "define view entity". No separate DDIC SQL view, faster activation, stricter and cleaner syntax checks, and it is the basis for RAP and ABAP Cloud.

For new development always use view entities. Existing classic views keep working and can be migrated with an ADT tool when you touch them.

━━━━━━━━━━━━━━━━━━━━
▶ THE PARTS OF A VIEW ENTITY

• Header annotations — label, access control (@AccessControl.authorizationCheck), and others.
• Data source — "as select from" a table, another CDS view, or a join.
• Associations — declared relationships to other views ("association [0..1] to ZI_Customer as _Customer"). They are only joined when used (CDS Associations series).
• Element list — the fields in braces. Rename columns to CamelCase business names with "as"; mark keys with "key".
• Expressions — CASE, CAST, arithmetic, string and date functions, calculated fields.
• Element annotations — e.g. @Semantics.amount.currencyCode to connect an amount to its currency.
• Optional: parameters ("with parameters"), WHERE conditions, GROUP BY for aggregation.

THE VIRTUAL DATA MODEL (VDM) — WHY YOU SEE I_, C_, R_ PREFIXES
SAP organizes CDS views in layers, and projects copy the idea:

• Basic / interface views (I_) — one business entity close to the table, clean names, keys and associations. Reused everywhere. Example: I_SalesOrder, I_Currency.
• Composite views — combine basic views for a purpose (e.g. an item with product and customer data).
• Consumption views (C_) — shaped for one app or report, with UI or analytics annotations.
• RAP base BO views (R_) — the root and child views of a transactional business object (RAP Business Objects series).

Released SAP views (with a release contract) are the stable way to read SAP data in ABAP Cloud and clean-core development (Part 4).

━━━━━━━━━━━━━━━━━━━━
▶ WHO CONSUMES A CDS VIEW

• ABAP code: SELECT ... FROM zi_salesorderitem like a table.
• RAP: base and projection views of business objects; OData services are generated from them.
• Fiori Elements: via OData and UI annotations.
• Analytics: analytical queries and embedded analytics on top of CDS cubes.
• Enterprise search and other frameworks via annotations.

One model, many consumers — that is the main reason CDS matters.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT CDS IS NOT

• Not a place for transactional logic — creates and updates are done by RAP business objects, not by CDS views.
• Not a cache — every read runs on the database.
• Not automatically fast — a badly designed stack can be slow (Part 3).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP — READ THE EXAMPLE
Look at the code example: a view entity over a sales-order header table with renamed fields, a CASE expression that turns a status code into a readable text, a calculated field, an association to a customer view, and semantic annotations. At the bottom, an ABAP SELECT reads it like a table. Part 2 builds a similar view step by step in ADT.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 1
A clear picture of what a CDS view entity is, where it sits, and why RAP, Fiori and analytics all build on it.

A finance team had five custom ABAP reports that each selected sales orders from tables, joined customers and calculated the order age and status text in ABAP loops. The logic differed slightly between reports, so the numbers never matched, and one report took 12 minutes because it read all orders into ABAP before filtering.
The team built one interface view ZI_SalesOrder with the status text, age calculation and customer association, and a consumption view per report. The reports became simple SELECTs with WHERE clauses that run on HANA. Runtime of the slowest report dropped to seconds, all reports showed identical figures, and the same view was later reused for a Fiori app without rewriting the logic.

• Creating new classic CDS views with @AbapCatalog.sqlViewName instead of view entities.
• Treating CDS as a copy of the table: keeping cryptic column names and no semantics.
• Putting all logic into one huge view instead of layering interface and consumption views.
• Doing calculations and filtering in ABAP loops after reading everything from the view.
• Expecting a CDS view to insert or update data — that is RAP's job.
• Reading SAP tables directly in clean-core code instead of released CDS views.

• Use "define view entity" for all new CDS development.
• Give every element a business name and mark real keys.
• Follow a layer model: interface (I_) views reused, consumption (C_) views per use case, R_ views for RAP business objects.
• Push filters, calculations and aggregations into CDS so the database does the work.
• Declare relationships as associations instead of hard joins where possible.
• Annotate amounts, quantities and texts with their semantics from the start.

Typical questions: "What is CDS and why is it important?", "What is the difference between a CDS view entity and a classic CDS view?", "What is the VDM?"
Strong answer: CDS defines semantically rich data models executed on the database (code pushdown). View entities replace classic DDIC-based CDS views: no SQL view object, faster activation, stricter checks, and they are required for RAP and ABAP Cloud. Explain the layers (interface, composite, consumption, and R_ views for RAP) and name several consumers of the same model: ABAP SQL, RAP/OData, Fiori, analytics. Mention that CDS is read-only; transactions go through RAP.