【数据建模】Salesforce数据模型符号

介绍

本文档概述了Salesforce实体关系图（ERD）表示法和约定，以帮助您清楚地解释

 architecture gallery at architect.salesforce.com.

ERD，也称为数据模型，是信息系统的图形表示。它展示了这个系统中人、物、地、概念和事件之间的关系。它是一个逻辑模型，用于传达数据的功能结构。在Salesforce ERD中，实体通常映射到Salesforce数据库中的对象。

修改后的信息工程符号

Salesforce ERD使用信息工程（IE）表示法的修改形式。信息工程符号是由澳大利亚的克莱夫·芬克尔斯坦和英国的CACI共同发明的，后来由詹姆斯·马丁改编。IE存在不同版本，没有单一的标准，但IE受到许多数据建模工具的支持，是数据库设计中最流行的符号之一。

(Source: Information Modeling and Relational Databases, 2008 by Terry Halpin and Tony Morgan.)

实体

实体是一种重要的事物或对象，无论是真实的还是概念上的，都需要了解或掌握有关信息。

实体在图中表示为带圆角的方框。每个实体框通常提供两个标签（如适用）：

• 实体的逻辑名称（例如，此处示例中的“Salesforce实体”）。这可能对应于所表示的Salesforce对象的单数标签，但并不总是如此。
• Salesforce组织中对象的“物理”API名称或开发人员名称（例如示例中的“API名称”）。对于托管包对象，图中列出的API名称通常不包括托管包命名空间（例如“vlocity_ins**”），除非Salesforce或Industry云使用多个托管包。托管包对象的API名称结尾表示使用的自定义对象的类型：“**c”表示常规自定义对象和自定义设置，“**mdt”表示自定义元数据，“**x”表示外部对象。

实体框还可以列出代表该实体的属性的一个或多个属性。属性前面有一个“#”或一个“-”字符。

• “#”表示一个属性，该属性是实体的逻辑唯一键的一部分。在示例图中，“用户密钥属性”被视为实体的用户主键。
• “•”表示非关键属性。

实体格式

每个实体关系图从指定云（如销售云、服务云或营销云）的角度说明Salesforce数据模型。图表的配色方案反映了焦点中的云。金融服务云、健康云和媒体云等所有行业云都使用相同的行业配色方案。

图表上给定实体的颜色也有特定的含义。焦点云的颜色是用Salesforce品牌的颜色表示的，包括下面的一些例子。

以下部分将参考下面的Sales Cloud示例图例来查看不同的实体格式：

云实体

具有焦点云颜色的实体表示该云的许可证附带的对象。

关联实体

具有白色填充和黑色边框的实体表示具有与焦点云不同的许可证并且未由焦点云许可证扩展的对象。例如，销售或服务云ERD上显示的帐户和联系人实体将显示为带黑色边框的白色，因为这些对象具有平台许可证。

扩展相关实体

具有浅灰色填充和黑色边界的实体表示与焦点云具有不同许可证的对象，但焦点云扩展了该对象。例如，Commerce Cloud使用附加字段扩展了基本Product2对象。扩展包括其他字段、关系和记录类型。

外部实体

没有边界的实体是虚拟的。当在图中使用时，这些框确认域的逻辑模型中存在实体，但该实体在Salesforce中未实现为物理对象。此实体的数据预计将通过部署的解决方案中的外部API调用或Salesforce Connect访问。

记录类型实体

带有虚线边框的实体在Salesforce中被建模为记录类型。在此处显示的示例中，“业务帐户”、“计费帐户”、消费者帐户和“服务帐户”子类型有一个虚线边框，因为它们映射到使用通信云管理包交付的记录类型。

概念实体

带有虚线边框的实体是虚拟的。在Salesforce解决方案中，既不使用记录类型也不使用单独的对象来区分这些子类型。这些子类型从逻辑上描述了域中的一个概念，该概念有助于说明数据模型的功能。

超类型和子类型实体

实体的子类型是其引用的子集的定义。当在超类型实体中添加一组子类型时，超类型实体描述公共属性和关系，而子类型实体显示特定于该子类型的属性和关系。在图表表示法中，子类型是互斥的，这意味着任何单个记录都必须是单个子类型。

子类型可以具有嵌套的子类型，以进一步区分出现的情况。图表中的子类型是合乎逻辑的，但它们可以通过以下三种方式之一映射到物理表示。子类型实体边界的坚固性定义了如何在Salesforce数据模型中实现子类型。

具有实体边界的子类型实体具有一个实际对象，用于跟踪该子类型的出现。在此处显示的示例中，“联系人”的“外部用户”子类型有一个实心边界，因为注册为“外部用户的联系人”将使用“用户”对象中的记录进行跟踪。

关系

关系是两个实体之间的一种命名的、重要的关联。

线条上或周围的标记和文本描述了关系的基数、可选性和含义。

关系基数

基数表示关系每一侧出现的相对次数。在表示法中，关系线的两端表示该端关系的基数。一端的鱼尾纹表示该端的许多实体出现可以与另一端的每个出现相关。一端没有鱼尾纹表明，该端最多有一个实体发生可以与另一端的给定发生相关。

亲子关系

Salesforce支持两种relationship fields:

查找字段和父子（也称为主细节）字段。父子字段类似于必需的查找，但它们在相关实体之间应用了额外的耦合。当父记录被删除时，关系的许多方面的记录被级联删除。此外，明细记录的可见性由父记录的可见性控制。

为了说明父子关系和查找关系之间的区别，Salesforce ERD借用了UML中的菱形表示法。关系中唯一一方的钻石意味着该方的实体在关系中发挥着主导作用。在这种关系的许多方面的实体是细节或子实体，并且可以被认为包含在父实体中。

关系选择性

可选性表示每端发生的事件是否需要关系。作为一个概念，可选性与基数密切相关，符号反映了这种紧密性。可选性在关系的每一端通过关系另一端直线上的圆圈或条形来表示。为什么在关系的另一端？将可选性标记包括在与基数相同的线上。

在关系的许多方面（也就是鱼尾纹），线上几乎总是有一个圆圈。这意味着对于关系的奇异侧上的每次出现，在关系的多个侧上可以有零到多个出现。

在关系的单数侧，圆圈和条形表示关系鱼尾纹侧实体的可选关系。圆和条形表示，对于多个边上的每一次出现，在关系的奇异边上可以出现零次或一次。

或者，在关系的单数侧，双杠表示关系的多方实体所需的关系。双杠意味着在关系的单数侧，对于多个侧的每一次出现，都必须有一次并且只有一次出现。

即使Salesforce中的基本物理关系是可选的，关系的可选性也可以根据需要显示。例如，Contact上的AccountId字段在物理上是可选关系，但如果忽略Private Contacts，则逻辑上需要Contact与Account的直接关系。期权性指标使用较少。在大多数情况下，ERD中显示的期权性反映了关系的潜在期权性。

关系含义

除了基数和可选性之外，两个实体之间的每一种关系都表达了某种意义，将这种关系与同两个实体间的其他关系区分开来。关系端名称，如上图中的“part of”和“composed of”，定义了关系的性质。

当你将关系的基数、可选性和结束名组合在一起时，它们可以用来组成一个描述关系的句子。

从左到右：每个（可能/必须）都是＜end name 1＞（一个且只有一个/一个或多个）。

从右到左：每个（可能/必须）都是＜end name 2＞（一个且只有一个/一个或多个）。

例如

从左到右：“每个联系人必须主要是一个且只有一个帐户的联系人。”从右到左：“每个帐户可能主要由一个或多个联系人代表。”

关系颜色编码

关系线是用颜色编码的。由图的焦点云中添加的关系以颜色绘制。黑线表示与焦点云不同的许可证所附带的关系。

递归关系

关系可以是同一实体的两个实例之间的关系。这被称为递归关系。曲线关系线用于表示递归关系。

互斥关系

Salesforce ERD通常会排除大多数业务规则，以便专注于数据模型的结构，但互斥关系是一种对结构有信息的业务规则，因此值得注意。互斥关系表示弧中包含的几个关系中只有一个关系将用于任何给定的事件。请注意，两个、三个或更多的关系可以参与同一个互斥关系。描述此处显示的互斥关系的一句话可以是：“每个实体可能是一个且仅一个第一其他实体或一个且仅有一个第二其他实体的实例。”

请注意，在Salesforce ERD中，穿过圆弧的断开关系线不是互斥关系的一部分。

布局惯例

Salesforce官方产品ERD遵循布局约定以提高可读性。这些布局约定包括以下内容：

• 关系线应该始终是直的。
• 关系线应垂直或水平绘制。在极少数情况下，如果无法做到这一点，请使用对角线上的直线。
• 为了使关系线保持直线，可以调整实体框的大小（更高或更宽），为两个实体之间的关系提供一个平台。更重要的实体（有更多的关系）在图中显示得更大，从而增强了它们的重要性。
• 在整个ERD中，关系上的鱼尾纹应始终位于关系线的左侧和/或上侧（倒置布局），或始终位于关系线上的右侧和/或下侧（右侧向上布局）。这种约定提供了清晰性，因为它导致类似的实体聚集在图的同一区域，这有助于理解这些实体。使用倒置布局确实会导致图表出现倒置，子实体位于父实体的上方或左侧——然而，这确保了图表中最具体的实体位于图表的左上角，从而使图表易于识别。使用右侧向上布局约定会导致相同的公共实体位于每个图的左上角，但子实体将位于父实体的下方或右侧。

严格遵守这些布局惯例可以得到一个清晰易读的图表。

Be sure to check back regularly on the template gallery at architect.salesforce.com for the latest Salesforce product data models that follow this standard.

Learn More

• Getting Started with Saleforce Diagrams on YouTube
• Trailhead: Diagramming Essentials