CIM模型

云信息模型 (CIM) 是一种开放的、与应用程序无关的数据模型，旨在为企业提供一套共享词汇表，用于描述在 CRM、ERP、营销、服务和分析系统中出现的实体。CIM 定义了一组通用的主题区域、实体和属性，任何系统都可以映射到这些内容，而不是由每个供应商自行发明对象名称和关系。该模型作为 Linux 基金会旗下的一个开源项目进行管理，该基金会托管着广泛的协作数据和基础设施项目组合。

本文解释了 CIM 的结构、其组件如何相互关联、超类型和子类型如何工作以及主题区域如何组织。它还涵盖了架构师在采用 CIM 时面临的实际决策（映射、治理、版本控制和扩展），以及该模型相对于其他行业标准的定位。

关键要点

• CIM 将业务概念组织成主题区域 (Subject Areas)，每个主题区域包含实体组 (Entity Groups)、实体 (Entities) 和属性 (Attributes) —— 这是一个可以清晰映射到模式 (schemas)、表 (tables) 和列 (columns) 的层次结构。
• 超类型 (Supertypes) 和子类型 (subtypes) 让模型能够表达共享特征（例如，一个 Party 可以是个人或组织），同时仍然允许专业化。
• 该模型刻意设计为与应用程序无关：它描述的是业务概念，而非任何单个供应商的实现。
• CIM 以多种格式发布并带有示例图表，因此可以被 建模工具、代码生成器和文档等同样地消费。
• 主题区域的数量和范围随着联盟和社区的贡献而增长，因此在采用时应考虑版本控制和变更管理。
• CIM 是多种选择之一；正确的选择取决于您需要的是一个广泛的跨领域模型，还是一个针对单一行业的狭窄且深入的标准。

CIM 的结构

CIM 被组织成若干组件，以便能够更轻松地导航和消费内容。层次结构的每个级别回答不同的问题，理解该层次结构是高效使用模型的第一步。

• 主题区域 (Subject Area) —— 由 CIM 联盟确定的主要业务概念，例如 Party。每个主题区域包含一个或多个实体组。可以将主题区域视为一个有界上下文 (bounded context)：它将业务需要了解的关于一个广泛主题的所有内容组合在一起。
• 实体组 (Entity Group) —— 主题区域内相关实体的逻辑分组，例如 Account。实体组使大型主题区域保持可导航性，并为团队提供了分配所有权的自然单位。
• 实体 (Entity) —— 组织收集信息的唯一对象，例如 Account Contact。实体类似于标准的数据库表。
• 属性 (Attribute) —— 实体的唯一特征，例如 Account Id 或 Contact Email。属性类似于表中的标准数据库字段。

这个四级层次结构是刻意设计得如此熟悉。曾接触过关系建模、维度建模或实体关系图 (ERD) 的数据架构师会立即识别出这一模式。CIM 带来的价值并非某种新颖的建模技术，而是一套共享的、预先协商好的名称和关系集，可以让多个组织和供应商达成一致。

一个有用的心智模型：主题区域大致相当于一个 schema 或一个 domain；实体组大致相当于一个命名空间 (namespace) 或模块 (module)；实体是一张表；属性是一列。这种映射是近似的 —— 因为 CIM 是一个概念和逻辑模型，而非物理模型 —— 但在您将 CIM 转换为物理实现时，这会很有帮助。

超类型和子类型

除了四个核心组件之外，CIM 设计还利用超类型和子类型将实体进一步定制和扩展为更多分组。这是模型获得强大表达能力的关键所在。

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

• 超类型 (Supertype) —— 由子类型实体扩展的实体，定义了相似概念的公共属性。
• 子类型 (Subtype) —— 扩展另一个实体的实体，并从其超类型实体继承属性。

一个经典的例子是 Party。Party 是指业务往来的任何人或任何事物。个人 (Person) 和组织 (Organization) 都是 Party，它们共享某些属性 —— 如名称、标识符、联系点 —— 但各自又拥有对方没有的属性。将 Party 建模为超类型，将 Person 和 Organization 作为子类型，可以避免重复定义共享属性，并确保关系（例如，“此机会属于该 Party”）无论涉及哪个子类型都保持一致。

这种继承是数据建模中一个成熟的概念，出现在对象管理组 (OMG) 的 UML 等标准以及整个行业使用的实体关系约定中。当您在物理层面实现 CIM 时，必须决定如何表示继承：

• 单表 (Single table) —— 将所有子类型存储在一个带有鉴别器列 (discriminator column) 的表中。查询简单，但可能会产生许多可为空 (nullable) 的列。
• 类表继承 (Class table inheritance) —— 超类型一个表，每个子类型一个表，通过共享键进行连接。规范化且干净，但需要执行连接 (join) 操作。
• 具体表继承 (Concrete table inheritance) —— 每个子类型一个独立的、自包含的表。对于特定于子类型的查询速度很快，但会重复共享属性。

没有绝对正确的答案。正确的选择取决于查询模式、子类型的数量以及共享属性被共同读取的频率。请记录该决策，因为它将影响每一个下游集成。

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

CIM 主题区域

主题区域代表了该联盟迄今为止建模的主要业务概念。每个区域都以自己的图表和格式发布，其中几个带有明确的版本标记（例如 v1.0 或 v0.1.1），反映出某些区域比其他区域更成熟。

Setup (设置) —— 定义您打交道的对象，例如客户 (customer)、供应商 (supplier) 和卖家 (seller)。它还涵盖组织运营的软件和基础设施概念：Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job 和 IoT Device。

Data Model (数据模型) —— 基础建模概念本身。

Hire (雇佣) —— 与建立业务相关的活动，例如内部业务部门 (internal business unit) 和员工 (worker)。实体组包括 Job Application, Employee, Compensation, Training, Location, Work Territory 和 Work Report。

Biz Process (业务流程) —— 业务流程和业务连续性概念。

Produce (生产) —— 处理您将购买、移动和销售的物料，例如产品 (product) 和库存产品 (inventory product)。实体组包括 Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order 和 Sales Agreement。

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

Market (市场) —— 用于推广产品的活动，例如营销活动 (marketing campaign) 和网上商店 (web store)。实体组包括 Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy 和 Web Site。

Sell (销售) —— 用于销售产品的活动，例如创建报价 (quotes) 和机会 (opportunities)。实体组包括 Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program 和 Competitor。

Service (服务) —— 为销售或维修的产品提供支持的活动，例如案例 (case) 或调查 (survey)。实体组包括 AI Assistant, Asset, Asset Subscription, Web Content, Case, Task 和 Event。

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

Fulfill (履行) —— 您为履行客户订单而执行的活动，例如发货 (shipment) 和退货单 (return order)。实体组包括 Fulfillment Order, Shipment, Return Order, Work Order, Work Resource 和 Work Forecast。

Interact (交互) —— 跟踪与最终用户或其他系统互动的活动。实体组包括 Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey 和 Loyalty。

Finance (财务) —— 追踪公司财务信息的活动，例如付款 (payment)、发票 (invoice) 和费用报告 (expense report)。实体组包括 Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar 和 Tax Policy。

Analyze (分析) —— 与分析数据相关的活动，例如分析模式、产品使用、数据移动、数据变更和客户满意度。实体组包括 AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty 和 Journal。

请注意，这些主题区域既涵盖了运营 (operational) 关注点（Sell, Fulfill, Service），也涵盖了分析 (analytical) 关注点（Analyze, Finance）。这种广度正是其核心价值所在：当一个共享模型能够一致地描述相同的客户、产品或订单时，无论数据存储在事务系统还是数据仓库中，其价值都是最高的。

在 CIM 与其他标准之间做出选择

CIM 并不是企业中唯一的共享模型。几个既定标准与其部分范围重叠，成熟的架构通常会同时使用多个标准。这个决定不在于挑选一个“赢家”，而在于将模型的广度和治理与您的问题相匹配。

标准	主要焦点	典型优势	CIM 的不同之处
CIM	跨领域业务概念	对 CRM/ERP/营销/服务具有广泛的、与应用程序无关的覆盖	设计为跨领域的共享保护伞
OMG 通用核心本体 / 基于 UML 的模型	概念建模符号和上层本体	严谨的形式语义	CIM 更直接地面向业务
特定行业模型（如零售、医疗、金融垂直领域）	深度覆盖单一部门	垂直领域内的精准度	CIM 以深度换取广度
供应商数据模型（CRM/ERP 平台）	单一产品的对象	与该产品紧密集成	CIM 在设计上与供应商无关

一个实用的经验法则：

• 如果您需要跨多个系统和供应商的共享词汇表，像 CIM 这样广泛的模型非常合适。
• 如果您需要深入的、受监管的、行业特定的语义，垂直标准通常会更精确，您可以在边界处将其映射到 CIM。
• 如果您是在单个供应商的生态系统内进行集成，该供应商自己的模型可能就足够了 —— 但它无法帮助您连接到下一个供应商。

现实中最常见的模式是中心辐射 (hub-and-spoke) 方法：CIM（或其他规范模型）位于中心，每个源系统都映射到它。这与主数据管理 (MDM) 中的规范数据模型，以及 Ralph Kimball 在维度建模中推广的“一致维度 (conformed dimension)”理念背后的原理相同。

采用 CIM 的实用指南

采用共享模型既是一项组织活动，也是一项技术活动。几个关键决策将决定这项工作是否能产生回报。

从有限的范围开始。 不要尝试一次性将每个系统映射到每个主题区域。选择一个高价值领域 —— Party 和 Sell 是常见的起点，因为客户和机会数据被广泛重复 —— 并证明端到端映射的可行性。

尽早决定扩展策略。 CIM 旨在随联盟和贡献而增长，但您的组织不可避免地需要模型尚未定义的属性。建立一套本地扩展约定（例如，使用命名空间前缀），以便自定义属性能与标准属性清晰区分，并在以后进行协调。

将版本控制视为首要关注点。 主题区域带有 v1.0 和 v0.1.1 等版本标记，这表明模型在不断演进。固定您构建时所依据的版本，跟踪变更并规划迁移。这与您处理任何依赖项时采用的纪律相同。

映射，而非复制。 CIM 是一个概念和逻辑模型。请抵制直接从中生成物理模式的诱惑，而忽略性能、索引以及消费数据的系统的访问模式。使用该模型来统一含义，然后为您的工作负载设计物理存储。

治理映射。 源系统与 CIM 之间的映射本身就是一项资产。对其进行版本控制、审查并分配所有权。数据集成领域的工具 —— ETL 和 ELT 平台、数据目录和沿袭 (lineage) 工具 —— 可以帮助您跟踪每个属性的来源及其流动方式，这正是 Analyze 主题区域通过 Data Lineage 等实体所预期的元数据类型。

参与社区。 由于 CIM 是开源且由联盟驱动的，您发现的缺失通常也是其他人发现的。向项目贡献提议的实体或属性既是良好的公民行为，也是减轻您长期维护负担的一种方式。

格式、图表和消费

CIM 设计为每个领域提供多种格式，包括示例图表。这很重要，因为不同的受众消费数据模型的方式不同：

• 架构师需要图表和关系视图来推理结构。
• 工程师希望能够将机器可读的定义输入到代码生成、模式验证或映射工具中。
• 分析师和数据管家需要能够解释每个实体和属性在业务术语中含义的文档。

以多种格式发布是一种深思熟虑的设计选择，可以降低采用的障碍。在评估任何共享模型时，请检查它是否以您的工具链实际可以读取的格式提供 - 仅以 PDF 形式存在的模型远不如具有结构化定义的模型有用。

常见问题

什么是云信息模型 (CIM)？

云信息模型是一种开放的、与应用程序无关的数据模型，它定义共享业务概念（例如当事方、帐户和销售订单），以便不同的云和本地系统可以使用通用词汇交换数据。它被组织成主题领域、实体组、实体和属性，并作为 Linux 基金会下的开源项目进行管理。

CIM 中的超类型和子类型有什么区别？

超类型是由子类型实体扩展的实体，它定义了类似概念所共有的属性。子类型扩展另一个实体并继承其超类型的属性。例如，Party 可以充当超类型，而 Person 和 Organization 作为子类型，因此共享属性定义一次，而专用属性则存在于子类型中。

CIM 与数据库模式有何关系？

CIM 是一个概念和逻辑模型，而不是物理模式。它的实体类似于数据库表，其属性类似于字段，这使得转换直观，但您仍然应该围绕您自己的查询模式设计物理存储（索引、分区、非规范化），而不是逐字复制模型。

CIM 是否可以替代行业特定的数据标准？

不是。CIM 广泛且跨领域，而垂直标准则深入且针对特定行业。许多组织使用星型拓扑方法，其中 CIM 作为中心的规范模型，行业标准或供应商模型在边缘映射到它。

为什么 CIM 主题区域有版本号？

v1.0 和 v0.1.1 等版本标记表明模型不断发展，并且某些主题领域比其他主题领域更加成熟。固定版本、跟踪更改和规划迁移与应用于任何共享库或模式的依赖管理规则相同。

如何处理 CIM 未定义的属性？

建立文档化的扩展约定，例如命名空间前缀，以便自定义属性可以与标准属性清楚地区分。然后考虑将缺失的部分回馈给项目，因为该模型旨在随着联盟和社区的贡献而增长。