Lesson 4 of 6
CDS views in plain terms
7 min
You do not need to write a line of code to benefit from understanding CDS views. A business-level picture explains why reports are live, why two people see different numbers in the same report, and what a key user can and cannot change.
What a CDS view is
Core Data Services (CDS) is SAP's way of defining data models on top of database tables. A CDS view is a named, reusable definition of data: which tables to read, how to join them, which fields to expose under business-friendly names, how to calculate some of them, and who may see which rows. It holds no data of its own. Every time an app asks for data, the view reads the current table contents. That is why a posting is visible in the next query.
The virtual data model
SAP delivers thousands of CDS views organized into a virtual data model (VDM). The layers build on each other:
An analysis built on top of this stack reads straight through to the tables at the moment you run it. No overnight extraction, no copy of the data. The trade-off is that very complex queries over huge data volumes are computed on demand, which is one reason report design and filters matter.
Authorizations travel with the data
CDS views carry their own access controls. When Maria runs a sales report, the view applies her authorizations, for example to sales organization 1710, before returning a single row. She does not get an error for the rows she cannot see; they simply are not in the result. This is excellent for security and a classic trap in testing: two users can run the same report with the same filters and get different totals, and both are "correct".
- Do two users see different totals with the same query and filters?Yes → compare their authorizations (organizational restrictions) first · No → continue
- Does the total differ from the sum of the underlying documents?Yes → check the query's filters, dates and included postings · No → continue
- Do the definitions of the compared reports differ?Yes → the difference may be by design; document it · No → investigate as a possible defect
Released views and stability
SAP marks some CDS views as released for customer use, meaning SAP keeps them stable across upgrades. Key user tools such as the custom query and custom view apps, and the Manage KPIs and Reports app, build on released views. That matters for you because custom analytics built on released views is much less likely to break at the next upgrade.
| Plain-language question | CDS answer |
|---|---|
| Why is the report live? | Views read the tables at run time; nothing is copied |
| Why do I see fewer rows than my colleague? | Access controls in the view apply your authorizations silently |
| Why are field names readable? | Views expose business names and texts instead of technical table fields |
| Why are some fields not available to my custom query? | Only fields in the released view you build on are available |
| Why does a custom query survive the upgrade? | Released views are kept stable by SAP |
CDS views explained through the questions business users ask.
What would you do?
In UAT, a Contoso controller in Chicago sees lower revenue in a margin report than Dan sees, with identical filters. Both claim the other's number is wrong. What is the most likely explanation?
- A CDS view is a reusable definition of data over database tables; it stores nothing itself.
- The virtual data model layers basic views, dimension and cube views, and analytical queries.
- Reports are live because views read the tables at run time.
- Access controls in views filter rows by your authorizations without an error.
- Released views are stable across upgrades and are the basis for key user analytics.
Check your understanding · not graded
Lesson check
1. Does a CDS view store its own copy of data?
2. Which layer of the virtual data model sits at the top, closest to reports?
3. Two users get different totals with the same query and filters. What should you check first?
4. Why do key user tools build on released views?