跳至主要内容

MDM Merge、Split 與 Re-Point

Merge、split 和 re-point 會改變 MDM 身分結構。只有在來源系統證據已經審閱後才應執行這些動作。

這些動作會影響依賴穩定身分的融合、AI Agent 證據、Inspector 記錄、BI 和報表。

如何選擇動作

動作適用情況結果
Merge兩筆 golden records 代表同一真實物件。一筆記錄成為 survivor,別名移動到 survivor。
Split一筆 golden record 包含多個真實物件的別名。被選中的別名移動到新的 golden record。
Re-point單個 alias 指向錯誤 golden record。舊對應關閉,新對應指向正確記錄。

變更控制流程

生產身分變更應使用該流程,把身分動作、下游刷新和稽核記錄連接起來。

操作前確認

  • 來源系統證據;
  • entity type;
  • active 和 superseded aliases;
  • 依賴該實體的下游資料集和工作流;
  • 歷史記錄是否需要按時間處理;
  • 誰批准了結構性變更。

影響評估

執行動作前列出受影響範圍:

範圍檢查內容
DFS Pro datasets哪些 fusion tasks 使用該 entity ID 或 alias join?
Inspector巡檢工作流、點位或工單記錄是否連接該實體?
AI Agent身分更新後回答或證據檢索是否會變化?
BI 和報表哪些圖表、計數或篩選按該實體彙總?
外部整合下游系統是否儲存 master entity ID 或 source alias?
歷史記錄舊事實是否需要按更早 alias period 解析?

如果影響範圍不清楚,應先暫停結構性動作。快速改身分通常不值得換來靜默的報表變化。

Merge

  1. 開啟 Master Entities
  2. 選擇不應保留的重複記錄。
  3. 選擇 Merge into
  4. 選擇 survivor。
  5. 確認。
  6. 重新開啟 survivor,檢查 aliases、canonical 屬性和 lineage。

Merge 後,非 survivor 記錄會保留為 tombstone,不應再接收新 alias。

Split

  1. 開啟被過度聚類的 golden record。
  2. 查看 active aliases。
  3. 選擇屬於另一真實物件的 aliases。
  4. 選擇 Split
  5. 如有可用資訊,填寫新實體的 canonical 屬性。
  6. 確認。
  7. 檢查原記錄和新記錄。

Split 必須在原記錄上至少保留一個 active alias。

Split 後,檢查每筆結果記錄是否有足夠 canonical 屬性讓使用者識別。拆分後產生的空白或缺證據記錄,可能需要先修正來源系統再交付下游。

Re-point

  1. 開啟目前擁有錯誤 alias 的 golden record。
  2. 在 alias 列上選擇 Re-point
  3. 選擇正確目標實體。
  4. 確認。
  5. 檢查目標實體是否顯示該 alias。

下游驗證

身分結構變更後:

  • 重新執行或重新驗證受影響的 fusion tasks;
  • 檢查按實體彙總的看板或報表;
  • 通知使用該實體作為證據的 AI Agent workflow owner;
  • 記錄尚未解決的歷史身分問題;
  • 在交接中保留 steward 決策。

變更後證據

每次結構性動作後附一段簡短記錄:

Action: re-point
Reason: work-order target mapped to retired equipment
Source evidence: CMMS asset number and inspection checkpoint history
Old entity: equipment-0172
New entity: equipment-0441
Effective period: from 2026-04-01
Downstream refresh: work-order fusion rerun; AI Agent evidence cache refreshed
Reviewer: facility data steward

記錄應簡潔、具體且便於稽核,說明決策原因、所用證據和下游刷新狀態。

下一步

繼續閱讀 Entity Resolution Tasks