亲爱的后端服务的朋友们，欢迎回到我们的教程系列你已经成功地完成了教程博客1的简易API创建，建站快速，不是吗？是的，但是…你不知怎的不完全满意？嗯我想我知道为什么了：你没有解释清楚你在做什么答对 了！请继续阅读，这是一个让你更快乐的尝试
CDS代表核心数据和服务我怎么知道的？我在文件里查过了谢谢，但这对我没有帮助
CDS定义语言允许定义模型更进一步，淘客推广，开始云，CDS允许在3个方面定义模型：
–定义数据模型–服务定义–附上用户界面信息
我们将完全忽略第三个方面教程示例中还使用了数据模型和服务定义这两个方面
让我们仔细看看
数据模型意味着我们希望以结构化的方式存储数据。在后端服务中，使用了数据库，但您实际上不需要关心它。我只是认为对我们正在做的事情有一个具体的想法是有帮助的。
在CDS文件的数据模型部分，我们说了我们希望如何将数据持久化到数据库中。在我们的示例中，我们说我们想要一个"Products"–具有属性"Name"和"Category"以及"ProductId"的实体，换句话说，我们想要一个具有多个列（"Name"、Category等）的数据库表（"Products"）
换句话说，我们想要执行一个类似
的SQL语句，好的，我明白，我需要学习CDS语言，这样我就能够描述我的应用程序所需要的数据模型。后端服务负责生成数据库表并将数据填充到其中。对的？
是的，我看你是认真的。顺便说一句，后端服务在维护数据和操作数据库方面为您做的更多。但这是一个比我们在这里讨论的更大的话题。
听起来很有希望。
CD不仅允许描述数据模型。它还允许定义服务。它真正的意思是"服务"，在REST服务的意义上。更具体地说：在CDS文件中，您定义了一个"服务"元素，爱回扣返现网，因此您得到了一个OData服务，您可以使用它来读取和创建数据库中的数据。
在CDS文件的服务定义部分，我们说我们希望数据作为服务公开
在我们的示例中，我们说我们希望生成一个名为"MyFirstService"的服务，而且我们定义了应该公开哪些数据
要公开的数据可以引用现有的数据模型。或者，它可以直接在服务主体中定义，这就是我们在教程的示例中所做的。
换句话说，在CD中定义"服务"时，我们说我们需要OData服务。OData服务本身声明了包含"产品"实体类型具有属性和"产品"实体集和"MyFirstService"-命名空间以及其他OData元素。
我们在教程[1]中创建的OData服务的元数据文档如下：
嗯…它看起来与CD非常相似
谢谢你的评论，是的，的确，CD和HANA以及SQL和OData就像是同一个家族的兄弟姐妹……
我们想忽略这个…简短总结：CDS允许将UI注释附加到每个模型元素。然后可以解释注释以生成用户界面。例如，可以声明一个属性（带有注释）用作电话号码，这样在用户界面中它就可以用电话图标和拨号程序来表示但是我们想忽略这个特性。
好的
目标是有一个通用的定义文件，它完全与协议和数据库无关。这样，您就可以描述您的应用程序，而不必考虑如何实现持久性。
具体：在接下来的步骤中，将CDS文件转换为目标格式。在我们的例子中，粗略地说，数据库和OData元数据（edmx）
示例：在您的cd中，您定义了一个服务，但是正如您在结尾所看到的，OData的版本（odatav2或V4）之间没有区别
哦，让我们把这个留到以后讨论就目前而言，我认为知道在引擎盖下，CDS模型被解析并转换为工件，然后这些工件被服务于更在引擎盖下的基础设施（如数据库、OData服务运行时）
我们需要创建一个CDS文件来定义一个数据模型和一个服务。然后我们将其传递给后端服务后端服务读取此输入并：
–根据数据模型，它生成数据库表，将数据存储在数据库中–根据服务定义生成OData服务，允许通过internet标准化访问数据
后端服务为您提供对生成的API（即OData服务）的访问
后端服务希望让您的生活更轻松，因此，您不需要处理数据库、扩展和服务实现之类的事情。其目的是允许用户以人类可读的方式对数据进行建模。因此，后端服务的输入是一个模型定义文件。目前支持3种格式
–OpenAPI是一种被广泛采用的标准，所以可以很好地使用。–EDMX用于定义OData元数据–CD，是的，CD是最好的，因为它是最强大的。您可以将元信息附加到数据模型定义中，它将被自动支持
请参阅概述页以查看更多带有详细示例的CD教程
当然，请跟随我的博客…天鹅会更严肃的回答：SAP官方文档
您还有问题吗？我知道你会毫不犹豫地给我发信息和问题，云机服务器，我会尝试添加这个博客帖子的答案
