在这个博客里，你会发现更多关于CD的信息

为什么？

因为本教程是一个系列的一部分，旨在支持您使用后端服务创建许多API。

如果您访问本博客纯属偶然，您应该首先进入入门教程–您最终会爱上后端服务。

在本教程中，我们将介绍定义所需的模型定义实体之间的关系。这被称为CDS方面的关联和OData方面的关联。同一个名字？是的，但是在OData中我们通常称之为导航，因为这是一个优点：我有一个指向我想要导航的实体的链接（也可以是一个实体列表）。这允许用户界面有一个导航到相关信息的按钮

我们需要2个教程来介绍关联主题，国内云服务器，因为CD至少支持3种类型的关联。我们将关注其中的3个–非托管一对一–一对一管理（下一个博客）–管理一对多（下一个博客）

在本教程中，我们将详细讨论第一种类型：非管理到一个关联

为什么是非管理的？

请耐心等待…。现在你可以把它看作是一个普通的联想

模型

首先，我想把模型介绍给你。之后，我会详细解释一切。在这里：

请注意：我给模型元素起了不寻常的名字。像"ContactEntity"或linkToContact这样的名字是愚蠢的，但是，你会看到这对理解这个概念有多大帮助。请在以后的型号中使用通常的命名或者，至少不要告诉任何指导过你使用这种不寻常命名的人……；—）

这个模型包含一个定义关联的例子：非托管一对一非托管意味着，CD不能管理任何东西。一旦在下一个教程中看到托管关联的示例，您就会更好地理解它。

还有一个从无到有关联（又称"无关联"）的示例，但我认为我们不需要讨论这个问题？（在示例模型中，我们没有从联系人到客户的任何导航，保持简单）

场景

在我们的应用程序中，我们希望维护有关客户的信息。客户就是公司。因此，我们对一个实体建模并称之为CustomerEntity。（通常的名称是"客户"）它保存了公司的信息：姓名、网站、位置、税务等等，但没有个人数据

相反，还有另一个实体，ContactEntity，它保存了负责该公司的个人的信息

，公司本身只需要保留负责该公司的联系人的标识符。这是CustomerEntity中的属性"contactProperty"（通常我们称之为"contact"）

顺便说一句，这是外键的概念。

总结：我们的应用程序的用户可以看到一个包含客户详细信息的客户列表，如果他想查看联系人的详细信息，可以获取contactProperty的号码并在联系人列表中进行搜索。

还是有点不舒服…

是的，是的……但是……

解释是

……但是因为我们是幸运的，所以我们不需要关心数据库和表…。我们有后台服务，它为我们生成OData服务…

所以如果我们想查看公司的联系人，我们只需要跟随导航链接。

听起来好多了…

好的。这就是为什么我们有联系：我们定义了CustomerEntity和ContactEntity之间的关联

现在有一个问题我们在上面没有问：我们假设"contactProperty"的值是现有联系人的标识符。这就是隐性知识现在我们需要明确它。

步骤：

在"CustomerEntity"中，添加一个名为linkToContact的属性此属性与所需的目标实体"ContactEntity"

关联，即：我们可以通过"linkToContact"属性从"CustomerEntity"导航到"ContactEntity"

还有一个开放点：目标是一个表，一个联系人列表。但只有一个人是当前客户/公司的正确联系人哪个是正确的？

我们知道：与公司存储的号码（contactProperty）具有相同识别码的人对吗？我们如何在建模层面上表达这种情况？这样：

我们表达的正是上述条件：

contactID=contactProperty

与公司中存储的号码（contactProperty）具有相同识别码（contactID）的人

列表中现有人员的唯一识别码，对应于存储在"contactProperty"

"contactID"中的值是我们要导航到的目标人"contactProperty"保留此号码，返利软件，它是当前客户/公司的财产。来源：

我担心订单可能会混乱……

对不起，这里的一切都很混乱……

我试着这样理解：在我们的应用程序中，我们选择了一个客户，并希望导航到联系人。我们通过其标识符（contactID）找到正确的联系人哪个是正确的标识符？与所选属性匹配的属性（contactProperty）像这样的：contactID=contactProperty

OK？

这里有一个彩色的尝试：

grmpfh…

好的，别担心：习惯它。

或者回到我的博客，记住

下一个主题：还需要一个信息：我们在CustomerEntity中定义了一个关联：

contactID=contactPerson