前言——这篇文章是 资本资产定价管理 系列。

介绍

SAP CAP 中的域模型是根据实体关系模型描述问题域的静态、数据相关方面的模型。 在本文中，我们将详细研究 SAP CAP 中的域建模。

领域建模

简而言之，SAP CAP 中的 CDS 以这样一种方式生成域模型，即它根据键、字段和注释来定义业务问题。 生成域模型的代码以 CDS 模式 (db/schema.cds) 编写。 这些领域模型可用于服务定义、持久性模型、数据库，甚至可以在另一个领域模型中重用。

示例示例：

命名空间empInfo； 使用来自“@sap/cds/common”的{货币，托管}； 实体员工：托管{键ID：整数； firstName：本地化字符串（111）； lastName：本地化字符串（1111）； 经理：经理协会； 加入日期：整数； 工资：十进制（9,2）； 货币：货币； }

在此示例中，我们创建了一个文件 schema.cds，我们在其中创建了一个实体Employees，其中包括Employee 的基本详细信息

整个模式都被赋予了一个命名空间，即 empInfo

此模式使用标准数据类型，即货币。 使用像这样的标准数据类型有助于我们带来与其相关的所有预定义值帮助。

我们使用 CDS 创建模型。 在那个 CDS 中，我们使用

1. 表示一组唯一对象的实体，例如：
   1. 员工基本信息
   2. 员工沟通信息
   3. 员工工资信息
2. 定义关系的关联
   1. Manager 与另一个实体 Manager 的关联，该实体将拥有所有 Managers 列表

命名约定和建议

1. 实体名称应以大写字母开头，并且应易于阅读且一目了然——例如，员工
2. 以小写字母开头的元素——例如，firstName
3. 建议使用实体的复数形式——例如，Employees
4. 建议使用单数形式的类型——例如，货币
5. 不要重复上下文 - 例如，Employees.name 而不是 Employees.EmployeeName
6. 喜欢单字名称——例如，salary 而不是salaryAmount
7. 将 ID 用于技术主键——例如，ID 用于员工 ID
8. 您可以使用命名空间使您的实体独一无二。 这就像 SAP 中的客户端概念，您可以使用具有唯一命名空间的重复模式（cds 文件）来区分它们。 命名空间是可选的，如果您的模型可能在其他项目中重用，请使用命名空间。 归根结底，它们只是前缀，会自动应用于文件中的所有相关名称。 - 例如，

命名空间笔记本电脑；实体戴尔 {}

..... 相当于：

实体笔记本电脑.Dell {}

9. 您可以将上下文用于嵌套的命名空间部分。 - 例如，

命名空间笔记本电脑；实体戴尔 {}           //>笔记本电脑.Dell上下文 Apple { 实体 MacBookPro {}       //>笔记本电脑.Apple.MacBookPro     实体 MacBookAir {} }

实体

实体就像带有主键的表。 我们可以使用这些实体执行 CRUD 操作。 尽可能保持平坦。 不要过度规范化它。 不要使用不可重用的类型。 本节仅用于建模，仅应添加与各个字段相关的注释，不应添加技术细节（逻辑）。

类型

类型类似于 SAP ABAP 中的域，用于定义数据元素的类型。

方面

方面是模型的扩展，主要用于扩展现有的定义和注释。 一旦定义了模型，我们就可以使用不同的 cds 文件（Aspect）在它们之上为特定任务添加注释。

例如-

• CDS– 你的核心领域模型，保持干净、简单和易于理解
• 审计模型.cds- 在文件中添加审核所需的其他字段
• 授权模型.cds- 添加授权注释。

主键

像 SAP ABAP 中的表和 CDS 一样，我们使用关键字维护实体的主键 键。

通过使用通用定义的方法，可以在模型中重用主键。

我们可以创建一个 common.cds 模型，其中可以存储所有常见的定义。

// 常用定义

实体 StandardEntity { 键 ID：UUID； 现在这些通用定义可以如下重用： using { StandardEntity } from './common'; 实体员工：标准实体{名称：字符串； ... } 实体管理器：标准实体 { 名称：字符串； ... }

默认情况下，已使用名为的预定义实体创建公共文件 cuid.

将 UUID 映射到 OData

默认情况下，CDS 在所有 OData 模型中将 UUID 映射到 Edm.Guid。 但是，OData 标准对 Edm.Guid 值提出了限制性规则——例如，只允许使用连字符的字符串——这可能与现有数据发生冲突。 因此，我们允许按如下方式覆盖默认映射：

实体书{

密钥 ID：UUID @数据.Type:'Edm.String';

...

}

如有必要，您也可以添加注解@odata.MaxLength 来覆盖相应的属性。

社区

它用于定义两个实体之间的关系。 像 ABAP CDS 一样，我们在这里也使用这个词 协会。 在这里，关键字 许多 表示一个 0..* 基数。 基数的限制可以添加为一个约束（where 条件）——例如，使用 不为空.

成分

与我们将实体的字段与整个实体的对象相关联的关联不同，组合仅引用另一个实体的特定字段。 它具有自我管理的深度操作（插入/更新）和级联删除（多依赖表删除）的额外优势。

// 定义包含 OrderItems 的订单实体订单{键ID：UUID； Items : Items.parent=$self;}entity Order_Items { // 只能通过订单访问  关键父级：与订单的关联； 关键书：与书籍的关联； 数量：整数；}

最佳实践

1. 不要在模型中添加技术细节，我们使用 方面为了那个原因
2. 使用 简称 和 简单的平面模型
3. 不要过度规范化模型中的实体
4. 如果您确实要处理高负载和高容量，请使用本地整数序列。 否则，更喜欢 UUID

到现在为止我们学到了什么：在它之上创建模型和方面。