MDM 主数据实体

主数据实体是代表真实对象的 golden record。每条记录包含稳定 ID、实体类型、canonical 属性、lineage、状态、版本和源系统别名。

在数据进入融合、AI Agent、Inspector、BI 或报表前，应使用该页面检查身份质量。

准备工作

• 查看实体需要 dfs:read。
• 新增或重定向别名需要 dfs:write。
• merge 和 split 等结构性动作只应授予有治理责任的用户。
• 明确要审阅的 entity type。
• 确认应该贡献别名的源系统。
• 明确负责身份决策的 steward。

打开页面

Data Integration > DFS Pro > Master Entities

左侧是 entity types，右侧是 golden records。选择一行可打开详情抽屉。

实体审阅流

在 master entity set 交付给 fusion tasks、Inspector、AI Agent 工作流或报表前，应按该流程抽样检查。

查看列表

列	含义
Entity	稳定主数据实体 ID 的短形式。
Canonical	canonical 属性预览。
Status	active 或 merged。
Version	canonical record 版本。

如果某个类型没有记录，先确认该 tenant 下 entity type 是否存在，以及导入或解析任务是否已经生成记录。

查看详情

重点检查：

• 完整 entity ID；
• 状态和版本；
• 生效时间范围；
• canonical 属性；
• active 和历史别名；
• match method 与 confidence；
• lineage。

Canonical 属性应足够稳定，让下游用户能识别对象；它不需要复制每个源系统的所有字段。

实体质量检查

从每个源系统和高影响资产类别中抽样：

检查项	良好状态
稳定身份	记录在生命周期内代表同一个真实对象。
Alias 覆盖	预期源系统有 active aliases，或有已记录缺口。
Canonical 清晰度	名称、类别、位置和状态能帮助用户识别对象。
Lineage 完整性	用户能看到记录来自哪些源、何时形成。
Steward decisions	Fuzzy approvals、rejections、merges、splits、re-points 可解释。
下游准备度	依赖数据集和工作流知道应该使用哪个 entity ID。

生产交接时，应基于关键样本证据批准实体集，重点抽查会影响报表、工单、AI Agent 回答或运营看板的记录，而不是只看记录数。

交接示例

简洁交接记录可以采用以下形式：

Entity type: equipment
Active records: 1,248
Source systems: BMS, CMMS, Inspection
Open candidate queue: 37 pending, 12 rejected this run
Known gaps: 18 BMS tags without maintainable-object alias
Recent structural changes: 4 merges, 1 split, 9 re-points
Downstream refresh: inspection fusion rerun; BI refresh pending
Owner: facility data steward group

交接记录应保持事实性，帮助下一组人员判断是否可以使用该身份集、继续审阅，或重新运行下游工作流。

交接内容

交接一组主数据时，应说明：

• entity type；
• active records 数量；
• 覆盖的源系统；
• 未解决或已拒绝候选数量；
• 已知 alias 缺口；
• 是否发生 merge、split 或 re-point；
• 依赖该身份的下游数据集或工作流。

常见问题

现象	可能原因	处理
同一真实对象出现两次	存在重复 golden records。	比较别名和 lineage，确认后再 merge。
一条记录包含不同对象的别名	身份被过度聚类。	使用 split 将部分别名拆到新记录。
源 ID 指向错误记录	crosswalk 错误。	核对源证据后 re-point。
canonical 属性过少	源字段不足或 survivorship 未选出值。	审阅源映射并按流程补充。
下游仍出现旧身份	下游读取了历史事实或未重新验证。	确认是否按 current entity 解析或重新运行任务。

下一步

继续阅读 Cross-Source Aliases。