在从了解CDS的第一篇文章，CDS入门必看，但此介绍太过于理论化，好多看不太明白，所以我建议直接了解一下就行，等有一定理解了回头再来看，我是直接看的实例，也可以直接看进价篇CDS的类型介绍得了。
1.SQL基础知识和ABAP的经典方法
从应用程序编程中访问数据库管理系统（DBMS）时，结构化查询语言（SQL）已将自身确立为一种首选。SQL在很大程度上被标准化为ANSI SQL，但是每个供应商都添加了自己的功能。
1.1.1.结构化查询语言（SQL）
- 访问数据库管理系统（DBMS）
- 高度标准化（SQL-92）
- 三种子语言：DML，DDL，DCL
数据处理语言（DML）
- 读取和更改数据库表中的数据
- 语句SELECT，INSERT，UPDATE，DELETE
数据定义语言（DDL）
- 创建和维护数据库表和视图
- 语句CREATE，ALTER，DROP。
数据控制语言（DCL）
- 定义授权和交易控制
- 声明授予，撤销
整个SQL涵盖了可能与应用程序有关的所有任务。SQL有三种子语言：
数据处理语言（DML）
提供用于读取和更改数据库表内容的语句，并包含诸如SELECT，INSERT，UPDATE和DELETE之类的语句。
数据定义语言（DDL）
提供用于创建数据库对象（如表和视图）并维护其属性的语句。诸如CREATE TABLE，CREATE VIEW，ALTER TABLE，DROP TABLE之类的语句属于SQL的DDL部分。
数据控制语言（DCL）
涵盖了数据完整性和安全性方面。DCL允许应用程序定义授权规则，并将DML语句捆绑到事务中（ABAP开发人员最好将其称为逻辑工作单元（LUW）。DCL语句例如是GRANT和REVOKE。
1.1.1.1.ABAP的SQL经典方法
ABAP中的DML
- 开放SQL，以编程语言集成
- 独立于数据库的语法
- 与数据库无关的行为
- 与SQL-92相比，功能集减少
ABAP中的DDL
- ABAP字典
- 独立于数据库的工具
- 基于表格的表格定义和视图编辑
ABAP中的DCL
- ABAP不需要
- 授权和事务控制永远不在数据库级别
- 始终在应用程序中完成（权限检查，提交工作，…）
原则上，运行时ABAP程序只能使用SQL的DML部分。Open SQL是ABAP语言中内置的SQL变体，仅涵盖DML方面。
当ABAP开发人员想要定义数据库表和视图时，不应在运行时发出DDL语句。他们必须使用ABAP词典工具，该工具为表和视图定义（例如，存储库对象“透明表”和“数据库视图”）提供基于表单的编辑器。在激活这些定义的过程中，系统创建特定于数据库的DDL语句，并将其发送到数据库。
在ABAP中不需要标准SQL的DCL部分。在ABAP的经典方法中。该子语言涵盖的所有任务都远离数据库。ABAP应用程序逻辑应该负责授权检查，锁定和事务（LUW）。
经典开放式SQL的局限性
Open SQL不仅限于SQL的DML部分。当我们查看标准SQL（例如SQL-92标准）时，Open SQL缺少其中描述的许多DML功能。
7.40之前版本的Open SQL的局限性
在常规Open SQL的许多限制中，在字段列表或WHERE子句中缺少对表达式的支持是应用程序程序员最明显也最想念的。
一般限制
- 无固定值
- 没有计算值
- 没有CASE表达式
- 没有SQL功能
有限的加入支持
- 仅内部联接和左侧外部联接
- 仅等于联接（与运算符“ =”联接的条件）
- 在左外部联接中：WHERE子句中的右表没有字段
更多限制
- 没有UNION或UNION ALL
存在这些限制的两个重要原因：
Open SQL希望独立于数据库，不仅在语法方面，而且在结果方面更为重要。必须保证Open SQL，才能确保Open SQL语句在所有数据库上提供相同的结果。最简单的方法是避免标准SQL的那些功能，数据库供应商对结果的外观会有不同的看法。一个示例是算术表达式，其中在所有数据库上舍入规则都不相同。
ABAP编程的基本性能规则一直是：使不必要的负载远离数据库。通常的假设是，即使遵循Open SQL，应用程序程序员也不会遵循此规则过多使用更复杂的SQL功能。
ABAP词典视图的局限性
在ABAP词典中对视图的定义时，ABAP与标准SQL之间的差距曾经更大。
数据库视图的与数据库无关的定义
- 在ABAP词典中定义（基于表单的工具）
- 在数据库上创建（CREATE VIEW语句）
对SQL功能的支持非常有限
- 仅内部联接与等联接
- 仅是简单的投影（没有计算字段，没有转换，函数等）
- 仅简单选择（使用文字值）
- 仅数据库表作为源（不支持“按视图查看”）
一些ABAP 专业
- 正在缓冲
- 标签（通过数据元素）
- 搜索帮助和外键关系（从基础表继承）
从版本7.4开始，ABAP系统完全支持SAP HANA，
借助SAP HANA，SAP结合了硬件和软件技术的最新发展，从而提供了最新的内存数据库。
但是，SAP HANA不仅仅是数据库。几个数据分析引擎和一个内置的应用程序平台允许在数据库层本身上执行详细的数据分析甚至应用程序逻辑。为了从SAP HANA的功能中获得最大收益，有必要更改编程范例以及传统的应用程序设计
经典ABAP编程的基本方法是：
- 保持数据库负载
- 在应用程序服务器上获取所需的所有数据，并
- 在ABAP中进行处理
但是要从SAP HANA的功能中受益最大，尤其是从其使用并行性以及优化的数据结构和传输中受益，最好在数据库本身上进行昂贵的计算和聚合，而不是将大量数据传输到ABAP应用程序服务器上。这是ABAP编程范例的根本变化。现在它变成了“逻辑到数据”或“代码到数据”，而不是“数据到逻辑”。
ABAP应用程序的经典设计将功能强大的应用程序服务器与相对笨拙的关系数据库和类似的简单表示层结合在一起。所有逻辑都位于应用程序服务器上。
受SAP HANA改进功能的启发，新的应用程序设计将部分逻辑（在上图中称为“数据中心逻辑”）传输到数据库中。另一方面，逻辑的大部分（图中称为UI应用程序逻辑）从应用程序服务器转移到智能客户端。
整体逻辑（服务逻辑）中只有中间部分保留在应用程序服务器上。注意：
甚至有可能在SAP HANA本身上实现剩余的服务层。SAP HANA XS使用此方法。
随着SAP HANA的兴起以及直接在数据库上开发应用程序（不再使用应用程序服务器）的可能性，出现了直接在数据库上创建元模型存储库的需求。与应用程序服务器上的ABAP词典一样，与使用本机SQL的CREATE TABLE或CREATE VIEW相比，框中应该有更多的内容。特别是关于需要用语义丰富纯技术定义的需求。这就是采用SAP核心数据服务的主要原因之一
CDS增强功能
有许多技术可以在SQL之上引入更高级别的模型以增加语义并简化使用-例如，OData EDM模型，BI平台中的语义层，Java中的JPA和企业对象或ABAP中的业务对象框架。 。这些较高级别的模型具有许多共性，但通常特定于它们的技术。这样可以防止它们在堆栈之间重用，并增加了应用程序开发人员的工作量。
为了解决这个问题，SAP HANA引入了一组特定于域的语言（DSL）和服务（称为核心数据服务），用于定义和使用语义丰富的数据模型。
这些语言中包括增强的数据定义语言（DDL），用于定义语义丰富的数据库表/视图（CDS实体）和数据库中用户定义的类型。
一些增强功能包括：
2.表达方式
用于数据模型中的计算和查询
3.社团协会
从概念上讲，用查询中的简单路径表达式替换联接
4. 注解
用其他（特定于域的）元数据丰富数据模型
ABAP核心数据服务
从一开始，CDS并不是专为SAP HANA设计的。与基于表单的ABAP词典工具相比，ABAP应用程序服务器还应该能够从CDS的DDL提供的增强功能中受益。
由于具有定义表，视图和数据类型的能力的ABAP词典已经存在，因此在ABAP应用程序服务器上引入CDS的自然方法是将其添加到ABAP词典中。
基于ADT的源代码编辑器允许您创建DDL源。激活后，在此类DDL源中定义的CDS实体将成为完整的公民ABAP词典对象。它们用作ABAP类型，可以在添加TYPE之后进行命名，并且可以在Open SQL中进行访问。
第一步，已经在ABAP CDS中实现了CDS的高级视图构建功能。由于ABAP词典中已经定义了许多表格，ABAP CDS的DEFINE VIEW语句使CDS领域的全部财富可轻松用于现有的ABAP数据模型。
您可以定义复杂的新视图，也可以将现有表包装在CDS视图中以在语义上丰富表。例如，ABAP CDS根据在DCL源代码中用DEFINE ROLE定义的角色提供了一个新的授权概念。为了让现有表参与新的授权概念，您可以简单地为连接到角色的表创建一个CDS视图。其他示例是具有关联的表的高级联接或使用特定的注释，以便将现有表连接到OData或UI5等新技术。
在纯技术层面上，ABAP CDS视图与ABAP词典视图相比提供以下附加功能：
- 增强了对合并查询的支持，例如UNION和OUTER联接
- 支持使用列列表中的表达式进行计算和选择
- 数据模型中的聚合和分组
- 嵌套视图（View-on-View）
使用HANA CDS和ABAP CDS，我们有两种基于相同规范的实现。它们非常相似，但并非100％相等。这主要是因为两个实现追求不同的目标：
HANA CDS直接位于SAP HANA数据库上，旨在支持SAP HANA本机应用程序（SAP HANA XS）的开发。它可以自由使用SAP HANA独有的功能。
ABAP CDS位于Application Server ABAP上，在此完全集成在ABAP字典中，因此也完全集成在ABAP传输系统，生命周期管理等中。ABAPCDS的目标是支持ABAP应用程序的实现-独立于数据库系统。因此，它的最初重点是视图构建，而不是从头开始构建模型，尽管将来可能会实现。