云信息模型

(CIM) 是一种开放的、与应用程序无关的模式，用于描述现代企业中移动的实体：各方、产品、订单、付款以及将它们联系在一起的关系。 CIM 不是为每个集成发明定制的数据模型，而是提供共享词汇表，以便 CRM、ERP、商务平台和分析仓库能够就“销售订单”或“产品关系类型”的实际含义达成一致。本文将逐步介绍构成该模型的实体组，然后深入研究一个代表性实体“ProductRelationshipType”，以展示 CIM 在实践中如何表达关系、角色和键。

要点

• CIM 将企业数据组织成实体组（当事人、产品、销售订单、付款等），这些实体组可以逐步采用，而不是一次性全部采用。
• 每个实体都使用 术语 URI、描述、标量属性和链接属性进行定义 - 一种清晰映射到 JSON-LD、RDF 和属性图存储的结构。 -诸如“ProductRelationshipType”之类的关系实体对角色（父/子）进行编码，以便可以对捆绑包、选项和覆盖进行建模，而无需硬编码业务逻辑。
• 该模型故意与应用程序无关：它描述数据的含义，而不是特定供应商如何存储数据。
• 采用 CIM 是一项映射工作，而不是一种推倒重来 - 您可以根据共享术语调整现有系统并协调差距。

为什么共享模型很重要

企业集成有一个熟悉的故障模式：每个系统都有自己的方言。 Salesforce 将其称为“帐户”，SAP 将其称为“业务合作伙伴”，本土计费服务将其称为“客户”。当您在每对之间构建点对点映射时，转换数量会随着所涉及系统的平方而增加，并且每个新系统都会增加维护负担。

规范模型打破了这个二次问题。您将每个系统一次映射到共享模型，共享模型就成为中心。这与 OAGIS（开放应用程序组集成规范）、OMG 的通用仓库元模型和 schema.org 的商业词汇表等标准背后的架构本能相同。 CIM 秉承了这一传统，但其范围仅限于云时代的互操作性，并作为具有可解引用的 URI 的开放术语发布。

实际的回报是数据架构师可以回答诸如“哪些系统持有当事人的权威记录？”之类的问题。或“我们如何在目录和订单中一致地表示产品包？”使用单个参考点。

实体组概览

CIM 不是一个单一的整体模式；它是一组松散耦合的组。模型中命名的组包括：

• 帐户 — 一方的商业关系背景。
• 联系点 — 电话号码、电子邮件地址和类似的联系渠道。
• 潜在客户 — 尚未获得资格的潜在一方。
• 当事人和当事人角色 — 参与者及其扮演的角色（客户、供应商、员工）的一般概念。
• 付款和付款方式 - 资金如何流动以及使用的工具。
• 产品属性、产品目录和产品 - 可销售且可描述的商品和服务。
• 销售订单及其庞大的子实体系列 - 模型的交易核心。
• 货运 — 履行和物流。

销售订单组是迄今为止最细化的，并且值得了解其原因。订单是业务规则集中的地方：定价、税收、调整、交付分组和每行注释都附加在订单上。 CIM 将订单分解为许多小实体——“销售订单产品”、“销售订单价格调整”、“销售订单税”、“销售订单交货组”、“销售订单付款汇总”、“销售订单更改日志”等等，而不是一张宽表。这种分解是一个经过深思熟虑的设计选择：它让每个关注点独立发展，并让系统只订阅它们关心的切片。

Related: Boomi AtomSphere — Enterprise iPaaS for hybrid cloud-to-on-prem integration.

CIM 实体剖析

CIM 中的每个实体都遵循相同的形状，这使得模型可预测并以编程方式使用。考虑“ProductRelationshipType”，它是描述“为什么”两个产品相关的实体。

• 术语 URI — http://cloudinformationmodel.org/model/ProductRelationshipType。这是该概念的全局唯一标识符。因为它是一个 URI，所以可以解引用并直接在 RDF/JSON-LD 图中使用。
• 描述 — “产品相关的原因，例如捆绑、选项或覆盖范围。”这告诉您实体是类型或分类，而不是关系实例本身。
• 标量属性 — 携带数据的原始字段。
• 链接属性 — 对其他实体的引用。 ProductRelationshipType 没有，它本身就提供了信息：它是一个叶实体，一个受控词汇表而不是一个中心。

标量属性为：

属性	术语 URI	范围	强制	描述
id	.../model/id	指导	是的	主键
parentProductRole	.../model/parentProductRole	字符串	是的	关系中的第一个角色，例如“由…组成”
childProductRole	.../model/childProductRole	字符串	是的	关系中的第二个角色，例如“组成部分”

“id”作为 GUID 是一个有意义的约定：它意味着标识符是全局唯一的，无需系统之间的协调，这正是在不同云中创建记录并随后合并时您想要的。

Our pick: Workato — Automation-led iPaaS that business teams can actually build on.

角色关系建模

ProductRelationshipType 中最具指导意义的部分是一对角色属性。产品关系是有方向的，CIM 使用两个命名角色而不是单个不透明的“类型”字符串来捕获该方向。

考虑一下捆绑。 “入门套件”由“路由器”和“电缆”组成。用 CIM 术语来说：

• 父产品扮演“parentProductRole”所描述的角色 - 例如，“由…组成”。
• 子产品扮演“childProductRole”所描述的角色 - 例如，“的组件”。

通过将这两个角色存储为 type 上的字符串，您将获得可重用的定义。任意数量的实际产品到产品链接都可以引用相同的“ProductRelationshipType”行，因此词汇量保持较小且一致，同时关系实例保持大量。这是一个经典的规范化模式：将关系的类型与其实例分开。

该描述明确命名了三种风格——捆绑、选项和覆盖——这暗示了该模型打算涵盖的商业语义范围：

• 捆绑 — 作为一个单元一起出售的产品（父项“由”子项组成）。
• 选项 — 与基本产品相关的选项或附加组件。
• 覆盖 — 包裹或保护另一个产品的产品，常见于保险和保修环境中。

如何确定你的角色词汇

由于“parentProductRole”和“childProductRole”是自由格式的字符串，因此模型不会规定您的确切措辞。这种灵活性是一种特征，也是一种危险。一些实用规则：

1. 选择一个受控词汇并冻结它。 就一小部分角色短语（“由……组成”/“组成部分”、“可选附加组件”/“具有选项”）达成一致并记录下来。自由文本会导致漂移。
2. 保持角色对称并在两个方向上具有可读性。 一个很好的测试：你能从两端大声读出这种关系并让它有意义吗？
3. 不要让角色超载业务逻辑。 如果角色需要条件行为，则该逻辑属于使用应用程序，而不是字符串。
4. 对词汇表进行版本控制。 添加角色时，请将其视为具有迁移路径的架构更改，而不是临时插入。

在实践中采用 CIM

采用规范模型是一种映射规则，而不是迁移。一个可行的序列：

Related: Matillion — Push-down ELT built for cloud data warehouses.

• 盘点您的记录系统。 对于每个实体组，确定哪个系统具有权威性。当事人可能存在于 CRM 中； PIM 中的产品； ERP 中的销售订单。
• 将每个源映射到 CIM 术语。 构建源字段 → CIM 属性的表。如果来源没有同等内容，请记下差距；如果 CIM 没有等效项，请记下扩展名。
• 协调标识符。 CIM 的 GUID 约定意味着您通常需要在本机键和 CIM“id”值之间保持交叉。
• 选择序列化。 CIM 基于 URI 的术语自然映射到 JSON-LD 和 RDF；它们还可以清晰地转换为关系表或属性图。该模型不强制采用存储技术。
• 管理词汇。 您添加的角色字符串、枚举和扩展是最有可能发生变化的部分，因此请将它们置于变更控制之下。

一个有用的思维模型是将 CIM 视为“交换”模式，并将您的运营商店视为“记录系统”。您并不是要求每个应用程序放弃其原生模型，而是要求它们在边界上发布和消费一个共享模型。

注意事项和权衡

没有任何规范模型是免费的，CIM 也不例外。

• 抽象是有代价的。 一个足以跨越行业的通用模型并不完全适合其中任何一个。预计会添加扩展。
• 销售订单组很重。 其细粒度分解功能强大，但意味着需要更多连接和更多实体来映射。具有简单订单流的团队可能只采用其中的一个子集。
• 自由格式的角色字符串需要治理。 如前所述，“parentProductRole”和“childProductRole”的灵活性取决于围绕它的规则。
• 开放模型不断发展。 由于 CIM 是面向社区的，因此可以随着时间的推移添加或完善术语。固定到某个版本并仔细检查更改。

这种权衡本质上是对特定系统的保真度和跨系统的可移植性之间的经典权衡。 CIM 针对可移植性进行了优化，当以互操作性为目标时，这是正确的选择。

Where we would start: Fivetran — The fully managed ELT pipeline that just keeps running.

常见问题

什么是云信息模型？

云信息模型是一种开放的、与应用程序无关的数据模型，它定义企业数据（例如各方、产品、订单和付款）的共享实体和术语。它提供了通用词汇表，以便不同的云和本地系统可以交换数据，而无需定制的点对点映射。

ProductRelationshipType 的用途是什么？

“ProductRelationshipType”定义了两个产品相关的“原因”——例如捆绑包、选项或覆盖物。它存储父角色和子角色，以便定向产品到产品链接可以引用可重用的共享定义，而不是在每个链接上重复语义。

为什么 CIM 使用 GUID 作为主键？

使用 GUID 作为“id”属性意味着标识符是全局唯一的，无需中央协调。这在多云和多供应商环境中很重要，在这些环境中，记录是在不同的系统中创建并随后合并的，因为可以有效地避免冲突。

CIM 是数据库模式还是数据交换格式？

最好将其理解为概念和交换模型，而不是物理数据库模式。其基于 URI 的术语自然映射到 JSON-LD、RDF、关系表或属性图，因此您可以在您的架构已使用的任何存储技术中实现它。

CIM 与 OAGIS 或 schema.org 等其他标准有何关系？

CIM 与这些努力的目标相同——互操作性的共享词汇表——但其范围适用于云时代的企业集成，并作为开放的、可取消引用的术语发布。在实践中，您可以在合作伙伴需要的边缘将 CIM 映射到其他标准。

我必须立即采用整个模型吗？

不会。CIM 被组织成松散耦合的实体组，因此您可以采用所需的组（例如，当事人和产品）并在以后进行扩展。大多数团队从造成最大集成困难的实体开始，并从那里开始发展。

进一步阅读

• 销售订单 — 维基百科
• 资源描述框架 (RDF) — 维基百科
• JSON-LD — 维基百科
• schema.org — 网络上结构化数据的共享词汇表