CIM 模型

雲端資訊模型 (Cloud Information Model, CIM) 是一種開放的、與應用程式無關的資料模型，旨在為企業提供一套共享詞彙，用於描述出現在 CRM、ERP、行銷、服務和分析系統中的實體。CIM 定義了一組通用的主題區域 (subject areas)、實體 (entities) 和屬性 (attributes)，讓任何系統都能對應至此，而非由每個供應商自行發明物件名稱和關係。該模型作為 Linux 基金會旗下的開源專案進行管理，該基金會託管著廣泛的協作資料和基礎設施專案組合。

本文解釋了 CIM 的結構、其組件如何相互關聯、超類型 (supertypes) 和子類型 (subtypes) 如何運作，以及主題區域如何組織。它還涵蓋了架構師在採用 CIM 時面臨的實際決策（映射、治理、版本控制和擴展），以及該模型相對於其他行業標準的定位。

要點

• CIM 將業務概念組織成主題區域 (Subject Areas)，每個主題區域包含實體群組 (Entity Groups)、實體 (Entities) 和屬性 (Attributes) —— 這是一個能清晰映射到 schema、資料表和欄位的層次結構。
• 超類型和子類型讓模型能表達共享特徵（例如一個 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 設計還使用超類型和子類型將實體自訂並擴展為進一步的分組。這是模型獲得強大表達能力之處。

相關： Fivetran — 完全託管的 ELT 管道持續運行.

• 超類型 (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) —— 每個子類型擁有一個單獨且獨立的表。對於特定子類型的查詢速度較快，但會重複共享屬性。

沒有絕對正確的答案。正確的選擇取決於查詢模式、子類型的數量以及共享屬性被同時讀取的頻率。請記錄此決策，因為它將影響所有下游的整合。

如果您正在購物： Boomi AtomSphere — 用於雲端到本地混合整合的企業 iPaaS.

CIM 主題區域

這些主題領域代表了該聯盟迄今為止建模的主要業務概念。每個領域都以其自身的圖表和格式發布，且其中幾個帶有明確的版本標記（例如 v1.0 或 v0.1.1），反映出某些領域比其他領域更成熟。

Setup (設定) — 定義您的交易對象，例如客戶、供應商和賣家。它還涵蓋了組織營運的軟體和基礎設施概念：Software Host、Software Tenant、Software User、Software App、Software Test、Software Service、Software Batch Job 和 IoT Device。

Data Model (資料模型) — 基礎建模概念本身。

Hire (僱用) — 與建立業務相關的活動，例如內部業務單位和員工。實體組包括 Job Application、Employee、Compensation、Training、Location、Work Territory 和 Work Report。

Biz Process (業務流程) — 業務流程與業務連續性概念。

Produce (生產) — 處理您將購買、移動和銷售的物料，例如產品和庫存產品。實體組包括 Supplier Product、Inventory Received、Inventory Product、Inventory Transfer、Electronic Media、Purchase Order 和 Sales Agreement。

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

Market (市場) — 用於推廣產品的活動，例如行銷活動和網路商店。實體組包括 Party Resolution、Privacy Consent、Market Audience、Campaign、Promotion、Trade Event、Ad Buy 和 Web Site。

Sell (銷售) — 用於銷售產品的活動，例如建立報價和商機。實體組包括 Price Book、Shopping Cart、Quote、Contract、Opportunity、Opportunity Forecast、Sales Order、Loyalty Program 和 Competitor。

Service (服務) — 為銷售或維修的產品提供支援的活動，例如案例或調查。實體組包括 AI Assistant、Asset、Asset Subscription、Web Content、Case、Task 和 Event。

讀者最愛： Airbyte — 具有託管雲端選項的開源 ELT.

Fulfill (履行) — 您為履行客戶訂單而執行的活動，例如出貨和退貨單。實體組包括 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 (財務) — 追蹤公司財務資訊的活動，例如付款、發票和費用報告。實體組包括 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。

請注意這些主題領域如何同時涵蓋營運考量（Sell, Fulfill, Service）和分析考量（Analyze, Finance）。這種廣度正是其目的所在：當共享模型能夠一致地描述相同的客戶、產品或訂單時，無論資料位於交易系統還是資料倉儲中，它都最具價值。

在 CIM 和其他標準之間進行選擇

CIM 並不是企業中唯一的共享模型。多個既定標準與其部分範圍重疊，而成熟的架構通常會使用多個標準。這個決定與其說是選擇一個獲勝者，不如說是將模型的廣度和治理與您的問題相匹配。

標準	主要焦點	典型優勢	CIM 的差異
CIM	跨域業務概念	廣泛且與應用程式無關的 CRM/ERP/行銷/服務覆蓋範圍	設計為跨領域的共享保護傘
OMG Common Core Ontologies / 基於 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），這表示模型在不斷演進。請固定您所建構的版本、追蹤變更並規劃遷移。這與您對任何依賴項（dependency）採用的規範相同。

映射而非複製。 CIM 是一個概念與邏輯模型。請抵制直接從中產生物理模式（physical schemas）的誘惑，而忽略將使用資料的系統之效能、索引和存取模式。請使用模型來統一含義，然後針對您的工作負載設計物理儲存。

管理映射。 來源系統與 CIM 之間的映射本身就是一項資產。請對其進行版本控制、審查並分配所有權。資料整合領域中的工具（如 ETL 和 ELT 平台、資料目錄和血緣工具）可以幫助您追蹤每個屬性的來源及其流動方式，而這正是「分析（Analyze）」主題區域透過「資料血緣（Data Lineage）」等實體所預期的元資料類型。

參與社群。 由於 CIM 是開源且由聯盟驅動的，您發現的缺失通常也是其他人發現的缺失。將建議的實體或屬性貢獻回專案，既是良好的公民行為，也是減少長期維護負擔的一種方式。

格式、圖表與消費

每個領域的 CIM 設計都有多種格式提供，包括範例圖表。這很重要，因為不同的受眾消費資料模型的方式不同：

• 架構師需要圖表和關係視圖來推論結構。
• 工程師需要可由機器讀取的定義，以便將其輸入到程式碼產生、模式驗證或映射工具中。
• 分析師和管理員需要能以業務術語解釋每個實體和屬性含義的文件。

以多種格式發布是一種刻意的設計選擇，旨在降低採用的門檻。在評估任何共享模型時，請檢查它是否以您的工具鏈實際可以攝取的格式提供——僅以 PDF 形式存在的模型，其效用遠低於具有結構化定義的模型。

常見問題

什麼是雲端資訊模型 (CIM)？

雲端資訊模型是一種開放的、與應用程式無關的資料模型，它定義了共享的業務概念（例如 Party、Account 和 Sales Order），以便不同的雲端和地端系統可以使用通用詞彙交換資料。它被組織成主題區域、實體群組、實體和屬性，並在 Linux 基金會下作為一個開源專案進行管理。

CIM 中的超型別 (supertype) 和子型別 (subtype) 有什麼區別？

超型別是由子型別實體擴展的實體，定義了相似概念共有的屬性。子型別擴展另一個實體並繼承其超型別的屬性。例如，Party 可以作為超型別，而 Person 和 Organization 作為子型別，這樣共用屬性只需定義一次，而專屬屬性則存在於子型別中。

CIM 與資料庫模式 (database schema) 有什麼關係？

CIM 是一個概念和邏輯模型，而非物理模式。它的實體類似於資料庫表，屬性類似於欄位，這使得轉換非常直觀，但您仍應根據自己的查詢模式來設計物理儲存（如索引、分區、反正規化），而非逐字複製模型。

CIM 是否可以取代特定產業的資料標準？

不會。CIM 是廣泛且跨領域的，而垂直標準則是深入且針對特定產業的。許多組織採用「中心輻射型 (hub-and-spoke)」方法，將 CIM 作為中心的規範模型 (canonical model)，而產業標準或供應商模型則在邊緣映射至 CIM。

為什麼 CIM 主題區域有版本號碼？

v1.0 和 v0.1.1 等版本標記表示模型在不斷演進，且某些主題區域比其他區域更成熟。固定版本、追蹤變更和規劃遷移，與您對任何共享函式庫或模式採用的依賴管理規範相同。

我該如何處理 CIM 未定義的屬性？

建立一套記錄在案的擴充約定（例如使用命名空間前綴），以便自訂屬性能與標準屬性清楚區分。接著考慮將此缺失貢獻回專案，因為該模型旨在透過聯盟和社群的貢獻而成長。