雲端資訊模型

(Cloud Information Model, CIM) 是一種開放的、與應用程式無關的綱要 (schema)，用於描述在現代企業中流動的實體：當事人 (parties)、產品、訂單、付款以及將它們聯繫在一起的關係。CIM 並非為每次整合而發明客製化的資料模型，而是提供一套共享詞彙表，以便 CRM、ERP、商務平台和分析資料倉儲能夠就「銷售訂單 (Sales Order)」或「產品關係類型 (Product Relationship Type)」的實際含義達成一致。本文將逐步介紹構成該模型的實體群組，然後深入研究一個代表性實體 — ProductRelationshipType — 以展示 CIM 在實踐中如何表達關係、角色和鍵 (keys)。

要點

• CIM 將企業資料組織成實體群組（當事人、產品、銷售訂單、付款等），這些群組可以逐步採用，而非一次性全部導入。
• 每個實體都由 術語 URI (Term URI)、描述、標量屬性 (scalar properties) 和連結屬性 (link properties) 定義 — 這種結構可以清晰地映射到 JSON-LD、RDF 和屬性圖 (property-graph) 儲存庫。
• 諸如 ProductRelationshipType 之類的關係實體對角色（父/子）進行編碼，以便在無需硬編碼業務邏輯的情況下，對組合包 (bundles)、選項和覆蓋範圍 (coverings) 進行建模。
• 該模型刻意設計為與應用程式無關：它描述資料的含義，而非特定供應商如何儲存資料。
• 採用 CIM 是一項映射工作，而非推倒重來 (rip-and-replace) — 您只需將現有系統與共享術語對齊並協調差異即可。

為什麼共享模型很重要

企業整合有一個常見的失敗模式：每個系統都說自己的「方言」。Salesforce 稱之為 Account，SAP 稱之為 Business Partner，而自研的計費服務則稱之為 Customer。當您在每對系統之間建立點對點映射時，轉換數量會隨著涉及系統數量的平方而增加，且每個新系統都會成倍增加維護負擔。

規範模型 (canonical model) 解決了這個二次方問題。您只需將每個系統一次性映射到共享模型，而共享模型則成為中心樞紐。這與 OAGIS (Open Applications Group Integration Specification)、OMG 的通用倉庫元模型 (Common Warehouse Metamodel) 以及 schema.org 的商務詞彙表背後的架構邏輯相同。CIM 承襲了這一傳統，但其範圍針對雲端時代的互通性而設計，並以具有可解引用 (dereferenceable) URI 的開放術語形式發布。

實際效益在於，資料架構師可以使用單一參考點來回答諸如「哪些系統持有當事人的權威記錄？」或「我們如何在目錄和訂單中一致地表示產品組合包？」之類的問題。

實體群組概覽

CIM 並非單一的龐大綱要，而是一組鬆散耦合的群組。模型中定義的群組包括：

• 帳戶 (Account) — 當事人的商業關係上下文。
• 聯絡點 (Contact Point) — 電話號碼、電子郵件地址及類似的聯絡管道。
• 潛在客戶 (Lead) — 尚未獲得資格的潛在當事人。
• 當事人 (Party) 與 當事人角色 (Party Role) — 參與者及其所扮演角色（顧客、供應商、員工）的一般概念。
• 付款 (Payment) 與 付款方式 (Payment Method) — 資金流動方式及使用的工具。
• 產品屬性 (Product Attribute)、產品目錄 (Product Catalog) 與 產品 (Product) — 可銷售且可描述的商品與服務。
• 銷售訂單 (Sales Order) 及其龐大的子實體系列 — 模型的交易核心。
• 出貨 (Shipment) — 履行與物流。

銷售訂單群組是最細緻的，這是有原因的。訂單是業務規則最集中的地方：定價、稅金、調整、交付分組和每行註釋都附加在其中。CIM 將訂單分解為許多小實體 — Sales Order Product、Sales Order Price Adjustment、Sales Order Tax、Sales Order Delivery Group、Sales Order Payment Summary、Sales Order Change Log 等 — 而非一張寬表。這種分解是刻意的設計選擇：它讓每個關注點能獨立演進，並讓系統僅訂閱其關心的部分。

相關： Boomi AtomSphere — 用於雲端到本地混合整合的企業 iPaaS.

CIM 實體剖析

CIM 中的每個實體都遵循相同的結構，這使得模型在程式化消費時具有可預測性。以 ProductRelationshipType 為例，該實體描述了兩個產品為什麼相關。

• 術語 URI (Term URI) — http://cloudinformationmodel.org/model/ProductRelationshipType。這是該概念的全域唯一識別碼。因為它是 URI，所以可以被解引用並直接用於 RDF/JSON-LD 圖譜中。
• 描述 (Description) — 「產品相關的原因，例如組合包、選項或覆蓋範圍。」這告訴您該實體是一個類型或分類，而非關係實例本身。
• 標量屬性 (Scalar Properties) — 攜帶資料的原始欄位。
• 連結屬性 (Link Properties) — 對其他實體的引用。ProductRelationshipType 沒有連結屬性，這本身就具有資訊意義：它是一個葉實體 (leaf entity)，是一個受控詞彙表而非樞紐。

標量屬性如下：

屬性	術語 URI	範圍	強制	描述
id	.../model/id	guid	是	主鍵
parentProductRole	.../model/parentProductRole	string	是	關係中的第一個角色，例如「由…組成」
childProductRole	.../model/childProductRole	string	是	關係中的第二個角色，例如「…的組成部分」

id 使用 GUID 是一個有意義的約定：這意味著識別碼在無需系統間協調的情況下即可全域唯一，這正是記錄在不同雲端建立隨後合併時所需要的。

我們的選擇： Workato — 業務團隊實際上可以在此基礎上建立自動化主導的 iPaaS.

使用角色建模關係

ProductRelationshipType 中最具啟發性的部分是一對角色屬性。產品關係是有方向性的，CIM 使用兩個命名角色而非單一不透明的「類型」字串來捕捉這種方向性。

考慮一下捆綁包（bundle）。一個「入門套件（Starter Kit）」由一個「路由器（Router）」和一條「電纜（Cable）」組成。用 CIM 術語來說：

• **父產品（parent product）**扮演 parentProductRole 所描述的角色 — 例如，「由…組成（Consists of）」。
• **子產品（child product）**扮演 childProductRole 所描述的角色 — 例如，「…的元件（Component of）」。

將這兩個角色儲存為 type 上的字串，您將獲得一個可重複使用的定義。任意數量的實際產品對產品連結都可以引用相同的 ProductRelationshipType 行，因此詞彙量保持精簡且一致，同時關係實例可以保持大量。這是一個經典的正規化模式：將關係的*類型（type）與其實例（instances）*分開。

該描述明確命名了三種形式 — 捆綁（bundle）、選項（option）和覆蓋（covering） — 這暗示了該模型打算涵蓋的商業語義範圍：

• 捆綁（Bundle） — 作為一個單元一起出售的產品（父項「由…組成」子項）。
• 選項（Option） — 與基礎產品相關的選擇或附加元件。
• 覆蓋（Covering） — 包裹或保護另一個產品的產品，常見於保險和保固情境中。

如何確定您的角色詞彙

由於 parentProductRole 和 childProductRole 是自由格式的字串，因此模型不會規定您的確切措辭。這種靈活性既是特點也是風險。以下是一些實用規則：

1. 選擇一個受控詞彙並將其固定。 就一小組角色短語（例如 “Consists of” / “Component of”, “Optional add-on to” / “Has option”）達成一致並記錄下來。自由文本會導致定義漂移。
2. 保持角色對稱且在兩個方向上都具備可讀性。 一個很好的測試：您能否從兩端大聲讀出這種關係且其意思通順？
3. 不要將業務邏輯過載到角色中。 如果角色需要條件行為，該邏輯應屬於消費端應用程式，而非字串本身。
4. 對詞彙表進行版本控制。 當您新增角色時，請將其視為具有遷移路徑的結構（schema）變更，而非隨意的插入。

在實務中採用 CIM

採用規範模型是一種映射（mapping）規範，而非遷移。一個可行的步驟序列：

相關： Matillion — 為雲端資料倉儲所建構的下推式 ELT.

• 盤點您的記錄系統（systems of record）。 對於每個實體群組，確定哪個系統具有權威性。例如：當事人（Party）可能存在於 CRM 中；產品（Product）在 PIM 中；銷售訂單（Sales Order）在 ERP 中。
• 將每個來源對應到 CIM 術語。 建立一張「來源欄位 $\rightarrow$ CIM 屬性」的對照表。若來源沒有對等項，請記錄差距；若 CIM 沒有對等項，請記錄擴充（extension）。
• 協調識別碼。 CIM 的 GUID 約定意味著您通常需要在原生鍵（native keys）和 CIM id 值之間維護一張交叉對照表（crosswalk）。
• 選擇序列化方式。 CIM 基於 URI 的術語自然對應到 JSON-LD 和 RDF；它們也可以清晰地轉換為關聯式資料表或屬性圖（property graph）。該模型不強制要求特定的儲存技術。
• 治理詞彙。 您新增的角色字串、列舉（enumerations）和擴充是最容易發生漂移的部分，因此請將其納入變更控制。

一個有用的思維模型是將 CIM 視為交換（interchange）模式，而將您的營運儲存視為記錄系統（system of record）。您並非要求每個應用程式放棄其原生模型，而是要求它們在邊界處發布並消費一個共享的模型。

注意事項與權衡

沒有任何規範模型是沒有成本的，CIM 也不例外。

• 抽象化是有代價的。 一個足以跨行業的通用模型無法完美契合任何單一行業。請預期需要添加擴充功能。
• 銷售訂單群組較為沉重。 其細粒度的分解功能強大，但意味著需要更多連接（joins）和更多實體來映射。訂單流程簡單的團隊可能僅採用其中的子集。
• 自由格式的角色字串需要治理。 如前所述，parentProductRole 和 childProductRole 的靈活性取決於圍繞它的紀律。
• 開放模型會演進。 由於 CIM 是面向社群的，術語會隨著時間增加或精煉。請固定在某個版本並審慎地審查變更。

這種權衡本質上是**對特定系統的保真度（fidelity）與跨系統的可移植性（portability）**之間的經典權衡。CIM 針對可移植性進行了最佳化，當互通性（interoperability）是目標時，這是正確的選擇。

我們從哪裡開始： Fivetran — 完全託管的 ELT 管道持續運行.

常見問題

什麼是雲端資訊模型（Cloud Information Model）？

雲端資訊模型是一種開放的、與應用程式無關的資料模型，它定義了企業資料（如當事人、產品、訂單和付款）的共用實體和術語。它提供了一套通用詞彙，使不同的雲端和地端系統可以在無需自訂點對點映射的情況下交換數據。

ProductRelationshipType 的用途是什麼？

ProductRelationshipType 定義了兩個產品相關的原因 — 例如捆綁包、選項或覆蓋物。它儲存父角色和子角色，以便定向的產品對產品連結可以引用可重複使用的共享定義，而無需在每個連結上重複定義語義。

為什麼 CIM 使用 GUID 作為主鍵？

使用 GUID 作為 id 屬性意味著識別碼在無需中央協調的情況下即可全域唯一。這在多雲和多供應商環境中至關重要，因為記錄是在不同系統中創建並隨後合併的，這樣可以有效避免衝突。

CIM 是資料庫結構（schema）還是資料交換格式？

最好將其理解為概念模型和交換模型，而非實體資料庫結構。其基於 URI 的術語自然對應到 JSON-LD、RDF、關聯式資料表或屬性圖，因此您可以使用架構中已有的任何儲存技術來實現它。

CIM 與 OAGIS 或 schema.org 等其他標準有何關係？

CIM 與這些努力的目標相同——建立一套用於互通性的共享詞彙表——但其範圍針對雲端時代的企業整合，並以開放且可解引用的術語形式發布。在實務上，您可以在合作夥伴有要求的邊界處將 CIM 對應到其他標準。

我必須一次採取整個模型嗎？

不必。CIM 被組織成鬆散耦合的實體組，因此您可以先採用所需的組（例如：參與方 Party 和產品 Product），隨後再行擴展。大多數團隊會從造成最大整合痛點的實體開始，並從那裡逐步成長。

進一步閱讀

• 銷售訂單 — 維基百科
• 資源描述架構 (RDF) — 維基百科
• JSON-LD — 維基百科
• schema.org — 網路上結構化資料的共享詞彙表