7.9 主数据与参考数据管理

概述与动机

如果你问五个系统本组织有多少客户，会得到五个不同的数字。一个系统统计电子邮件地址，一个统计合同数量，一个统计登录次数，还有两个系统对“Acme Corp”和“ACME Corporation”是否是同一家公司意见不一。主数据管理（Master data management，MDM）是一门学科，用于把业务中共享的核心实体（）客户、产品、供应商、员工、地点（）协调成一个所有系统都可以信赖的权威版本。

首先应把数据分成三类，因为它们需要不同的处理方式。主数据描述业务中的“名词”：众多流程所引用的人、地点和事物。参考数据是这些流程所使用的受控词汇：货币代码、国家代码、计量单位列表、产品类别。事务数据记录的是“动词”：一笔已下达的订单、一笔已完成的付款、一次已发出的发货。主数据和参考数据的数量级低于事务数据，但被到处引用，因此它们中的一个错误会污染下游的一切。

出错的代价是具体可见的。当同一个客户以四条略有差异的记录存在时，你会寄出四份目录，看不到一段本值得维护的关系，你的每客户收入数字也会悄悄出错。黄金记录（）从多个来源汇总而成、唯一可信的实体版本（）正是用来取代这些相互冲突的副本，使每一次集成不必重新求解同一个匹配问题。

对于那些因数十年增长和并购而积累了众多系统的企业来说，MDM 决定了你得到的是一个连贯的客户视图，还是一项永久性的对账税。对于政府而言，风险更高：一位在三个机构中呈现为三个不同人的公民，可能因此被拒绝领取福利、被重复征税，或在部门之间被遗漏。本章与数据战略与治理（第 7.1 章，确定所有权和政策）、数据建模与语义层（第 7.7 章，定义实体的含义）以及数据质量与可观测性（第 7.8 章，长期保持记录干净）互为补充。

关键原则

将数据划分为主数据、参考数据和事务数据；每一类都需要不同的处理方式。
每个现实世界实体对应一条黄金记录，经过有意识地组装而成，而不是偶然发现的。
根据你的控制力和延迟需求，而不是根据潮流，来选择一种 MDM 架构风格。
匹配和存续（survivorship）规则是业务规则，因此要把它们写下来，并让数据管家（steward）去调整。
参考数据是共享词汇；要像对待 API 一样对其进行版本管理和发布。
治理与管家职责是 MDM 的引擎；软件只是工具。
以事件的形式传播黄金记录，使下游系统保持同步，而不是陈旧过时。
用“改善了多少决策”和“消除了多少重复”来衡量 MDM，而不是用“加载了多少记录”。

建议

首先对主数据、参考数据和事务数据进行分类

你无法管理你尚未分类的东西，因此应从对你的数据域进行分类开始。判断某项数据是否属于主数据的一个有用测试是：一个错误值是否会扩散？如果一个错误的地址会波及账单、物流和法律通知，那你面对的就是主数据。这决定了你的投入方向：你会为客户实体建立一个匹配引擎，而不是为订单行项目建立。明确地为这些数据域命名，按照重复数据造成的痛苦程度对它们排序，并从最痛的一两个开始，通常是客户和产品，因为它们直接影响收入。

有意识地选择一种 MDM 架构风格

常见的架构风格有四种，正确的选择取决于你能集中多少权威、以及变更需要多快地传播。注册表（registry）风格将数据留在源系统中，只构建一个已匹配标识符的索引，因此它能够回答“这五条记录是同一个客户”，而不需要移动任何数据；它成本低、风险小，但是只读的，因此无法修复源系统。归并（consolidation）风格将副本拉入一个中央枢纽，并将它们合并为用于报告的黄金记录，但不会将修正写回源系统，因此源系统仍然保持混乱。共存（coexistence）风格更进一步：它将清理后的值同步回源系统，使源系统随着时间推移不断改善，同时仍然独立运作。集中式或事务型枢纽（centralized or transactional hub）风格让 MDM 枢纽本身成为记录系统，实体在其中被直接创建和编辑，其他所有系统都从它那里消费数据；这带来了最强的一致性和控制力，也是最难采用的，因为它改变了工作发生的地点。许多组织会从一个证明价值的注册表逐步发展到共存模式，随着信任的增长而演进，并在不同的数据域中并行运行不止一种风格。

明确地设定匹配、合并与存续规则

MDM 的核心在于判断两条记录何时描述的是同一个现实世界事物。这就是记录链接，它很少像精确的键匹配那么简单，因为真实数据中充满了拼写错误、缩写和缺失字段。确定性匹配对选定字段使用精确规则（相同的税号，或相同的电子邮件加邮政编码）。概率性匹配则使用近似字符串匹配和权重，对许多字段的相似度打分，因此“Bob Smith, 12 Main St”和“Robert Smith, 12 Main Street”可以被判定为超过阈值的可能匹配。判断哪些记录指向同一个实体被称为身份解析（identity resolution），它驱动着从客户视图到欺诈检测的一切应用。

一旦记录匹配成功，你就必须决定哪些值会存续进入黄金记录。这些存续规则是业务逻辑，因此要把它们明确写下来：对于电话号码，优先使用最新的值；对于地址，优先使用最完整的值；对于法定名称，优先使用最可信来源的值。设定一个自动合并的阈值区间、一个自动拒绝的较低区间，以及一个由人来决定的中间区间，这正是管家职责发挥作用的地方。让每一次合并都可撤销、可审计，因为一次错误地将两个真实客户融合在一起的合并，比一次遗漏的匹配更糟糕。

把参考数据当作有版本管理的共享词汇来对待

参考数据是你的系统所使用的共享词汇，而漂移的词汇会造成悄无声息的错位：当一个系统使用 ISO 国家代码“GB”、另一个使用“UK”时，连接（join）会失败，计数会出现分歧。将每个参考列表维护在一个受治理的地方，向每个消费者发布它，并且（）关键的是（）对它进行版本管理。代码会随时间被添加、废止、拆分和合并，如果你就地覆盖这份列表，就会破坏那些在旧代码下本是正确的历史报告。

要像对待带有契约的 API 一样对待参考数据集。发布时附带生效日期，使消费者能够询问“在这个日期，有效的区域代码是什么”；保留已废止的代码而不是删除它们；当某个代码的含义发生变化时，记录其映射关系。在存在公认外部标准的地方，优先使用它们，例如 ISO 国家代码和货币代码，因为标准能免费为你带来互操作性，并与第 3.8 章所讨论的开放标准纪律相呼应。

对层级结构和关系建模，而不仅仅是扁平记录

主数据不是一堆彼此独立的行；它是一张关系网。一位客户属于一个家庭，也属于一个企业母公司。一件产品归属于一个类别和一个品牌。这些层级结构承载着真实的业务含义：按企业母公司汇总销售额，和按单个账户汇总，得到的图景截然不同。要显式地为这些关系建模，使消费者能够以一致的方式遍历它们，而不是让每个团队各自发明自己的汇总方式。

要留意一个实体需要同时拥有多个层级结构的情况。一件产品在财务视角下可能按一种方式汇总，在销售视角下可能按另一种方式汇总，两者都是合理的，因此应支持多个具名的层级结构，而不是强行只保留一棵“唯一正确”的树。数据域之间的关系同样重要，例如哪个供应商提供哪件产品。

把黄金记录接入语义层和数据质量体系

MDM 产生的黄金记录，正是第 7.7 章的语义层在定义指标时所引用的可信实体：只有当“客户”这个概念没有歧义时，“活跃客户”这个说法才有意义。要把你的黄金记录输送到语义层，使每一个指标统计的都是同一批已去重、已解析的实体。

MDM 与数据质量（第 7.8 章）是一枚硬币的两面：质量检查发现 MDM 随后要解决的重复项、空值和格式违规，而 MDM 的匹配过程也会揭示质量检查未能发现的问题。要专门对你的主数据运行持续的质量监控：重复率、匹配置信度分布、关键字段的完整性，以及待审队列的规模，这样漂移才能在消费者察觉之前就浮现出来。

通过事件传播黄金记录

一条没有任何下游系统看到的黄金记录，对任何人都没有帮助。最强的模式是事件驱动的传播：当一个实体被创建、合并或修正时，MDM 枢纽发布一个变更事件，订阅的系统随即更新它们的本地副本。这建立在第 7.2 章所讨论的事件驱动架构和流式处理模式之上，使数十个系统保持一致，而不必依赖每晚让所有人都落后一天的脆弱批处理同步。

发布事件时要附带足够有用的上下文：实体标识符、发生了什么变化、新的存续值，以及一个版本号，使消费者能够为更新排序并检测出自己错过的更新。让消费者具备幂等性，使重放一个事件不会造成危害，并为无法订阅的系统提供一个 API。第 3.4 章数据架构与存储中的原则同样适用：要为黄金记录的流动而设计，因为一条无人消费的黄金记录只是一张昂贵的电子表格。

在引入工具之前先明确管家职责和治理

MDM 作为一个技术项目会失败，作为一个治理项目才会成功。其中的关键角色是数据管家：一个对特定数据域的质量和规则负责的人，他/她负责解决模糊的匹配、调整存续规则，并在两个部门对“供应商”的含义存在分歧时进行裁定。数据管家通常是具备深厚领域知识的业务人员，而不是工程师，他们需要真正的权力和分配的时间，因为一个没有授权的兼职管家职位，恰恰会产生 MDM 本应阻止的那种漂移。

要把数据管家纳入第 7.1 章所描述的治理结构中：为每个数据域指定一位负责的数据所有者，设立一个委员会来解决跨域争议，并制定谁可以创建或合并主记录的明确政策。把这些决策记录下来，因为匹配一个客户的规则是必须在人员流动中留存下来的机构知识。工具是为治理服务的；在指定数据管家之前购买一个 MDM 平台，等于买了一台没有司机的引擎。

权衡：优点与缺点

MDM 风格	优点	缺点
注册表（仅索引）	成本低、风险小、源系统不受影响	只读；无法修复源数据
归并（中央副本）	能快速为分析提供干净的记录	源系统仍然混乱；不写回
共存（回写源系统）	源系统持续改善；控制力均衡	集成工作更多；需要管理同步冲突
集中式 / 事务型枢纽	最强的一致性和控制力	成本最高；改变工作发生的地点
确定性匹配	可预测、可解释、可审计	会遗漏拼写错误、变体和混乱的数据
概率性匹配	能捕捉现实世界中的变化	需要调优；不慎会导致错误合并

MDM 中的核心张力是控制力与干扰性之间的矛盾。那些能给你带来最干净、最一致数据的风格（共存和集中式枢纽）恰恰是对源系统及其所有者的工作方式干扰最大的风格，而这种干扰正是 MDM 项目停滞的地方。务实的路径是先用一种低风险的风格赢得信任，只在业务论证清晰的地方才转向更强的控制力。匹配方面的权衡与此平行：确定性规则可审计但脆弱，概率性打分强大但需要管家职责，也需要容忍偶尔出现的错误合并。大多数成熟的项目会将两者结合使用。

与团队讨论的问题

哪些主数据域确实给我们带来了痛苦，我们是否已经按成本对它们排序，而不是想要同时处理所有数据域？ 许多 MDM 项目因为野心过大而崩溃，试图同时掌控企业中的每一个实体，结果两年内什么都没交付。有成效的做法是找出重复和冲突确实让你付出真金白银或信任代价的一两个数据域，通常是客户或产品，并量化这种代价：浪费的邮寄、对账所耗费的工时、错误的收入数字、审计发现的问题。请带来同一个实体在你的系统中以多种方式出现的具体例子，让这个排序告诉你从哪里开始，因为一个范围狭窄、可衡量的胜利，会建立起你扩展所需要的公信力。
谁拥有每个主数据域，我们的数据管家是否拥有真正完成这项工作所需的权力和时间？ 没有被赋权的管家职责所配上的 MDM 工具，就像一辆没有司机的汽车，最常见的失败模式是在幻灯片上指定了一位管家，却没有给他们任何真正的授权，也没有分配任何时间。负责解决模糊匹配、裁定“什么算作一个客户”这类争议的人，需要领域专长、决策权力和受保护的时间。请带来你的组织架构图，并追问：对于你最重要的数据域，究竟是谁在决定两条记录是否是同一个人，谁在销售部门和财务部门意见不一时进行裁定。如果你说不出这个人的名字，也指不出他们被分配的时间，那你就找到了将会拖垮这个项目的缺口。
当我们把两条记录合并成一条黄金记录时，我们能解释并撤销这个决定吗？存续下来的值来自哪里？ 存续规则是大多数团队从未写下来的业务逻辑，这意味着合并往往是由加载顺序或工具默认值偶然决定的，而一次将两个真实客户错误融合的合并很难撤销。请带来一条真实的合并记录，追溯每个存续字段回到它的来源和规则：为什么是这个地址、为什么是这个姓名、为什么是这个电话号码。确认每一次合并都被记录且可撤销，确认处于中间不确定区间的匹配会交给人来处理，而不是自动合并。如果你无法解释一条具体的黄金记录，你的数据管家就无法向审计人员或受损的客户为它辩护。
对于我们计划掌控的每个数据域，哪种 MDM 架构风格是合适的，我们能否为这个选择所带来的、对源系统所有者的干扰进行辩护？ 你所选择的风格决定了你能在多大程度上清理数据，以及你会对拥有源系统的团队造成多大干扰，而根据潮流或供应商的推销来选择，而不是根据控制力与干扰性的现实来选择，正是项目半途而废的原因。注册表能廉价地证明价值，但永远无法修复源系统；集中式枢纽能带来最强的一致性，但会转移记录被创建的地点，这是一种伪装成技术变革的组织变革。请为每个候选数据域带来一个诚实的评估：你对源系统所有者实际拥有多少权威、下游副本需要多“新鲜”，以及一次回写会在现有工作流程中破坏什么。在企业和政府场景中，还要加上迁移记录系统的变更管理成本，因为那些日常工作会被转移的团队会抵制一个未曾被征询意见的枢纽，而一个停滞的共存推广，代价比一个能够交付的适度注册表更高。
我们如何调优匹配阈值，我们是否已经就每个数据域中可以接受的错误合并率和遗漏匹配率达成一致？ 每一个概率性匹配引擎都在错误合并（把两个真实实体融合在一起）和遗漏匹配（让一个实体保持分裂）之间做权衡，这种平衡是一项业务决策，而不是某人在工具中留下的默认值。把自动合并和自动拒绝的区间设得太宽，你会悄悄地损坏黄金记录；设得太窄，人工审核队列的增长速度会超过管家清理它的速度。请带来当前的置信度分布、审核队列的规模和积压时长，以及两类错误的样例，让讨论现场能够看到每个方向的真实代价。在政府身份数据域中，应当大力偏向遗漏匹配和人工审核，因为一次错误的合并可能导致拒绝某人的福利，或把一位公民的数据暴露给另一位公民，而那种错误所带来的申诉和审计成本，远远超过一个数据管家下周就能解决的重复记录的成本。
下游系统如何得知一条黄金记录发生了变化，在决策出错之前，每个系统能够容忍多“陈旧”？ 一条被完美解析、却没有任何系统消费的黄金记录，只是一张昂贵的电子表格，而传播机制（）无论是变更事件、订阅式 API，还是每晚批处理（）都在悄悄决定每一个依赖它的决策有多“新鲜”。事件驱动的传播能让数十个消费者接近实时保持同步，但要求消费者具备幂等性并使用带版本的事件；每晚同步更简单，但会让所有人落后一天，这对营销名单也许无妨，对欺诈检测却很危险。请带来消费系统的清单、每个系统实际需要的新鲜度，以及一个今天错过更新的消费者如何恢复。对于一个大型或公共组织，请指明谁拥有这些事件的契约、订阅者如何检测到一条被丢失的消息，因为一次悄悄未能送达某个机构的实体变更，会重新制造出 MDM 本来出资要消除的那种碎片化。

行业视角

初创企业。 只有少数几名工程师、没有多余的资金跑道，不要购买一个 MDM 平台。掌控那个正在污染你数字的单一实体，通常是自助注册和销售渠道之间重复的客户，用你已经在运行的数据仓库中的一个匹配作业，加上每周由一个人审核不确定匹配的方式来处理。让每一次合并都被记录且可撤销，这样一条糟糕的规则付出的代价只是一个下午，而不是一段客户关系；只有当人工审核队列的规模超出一个审核人员的处理能力时，才考虑更重的工具。

小型企业。 你没有数据管家，预算也很紧张，因此应把这当作一个“购买而非自建”的决策，并依靠你能免费获得的标准。优先选择那些已经能够对联系人去重、并说 ISO 国家和货币代码“语言”的工具，而不是一个你无法维护的定制枢纽，并选定一个数据域（）通常是客户或产品（）重复数据在那里让你付出真金白银。即使只是某个人每周工作时间的一小部分，也要把这项责任分配给一个明确的负责人，因为没有人看守而漂移的词汇，正是悄悄搞坏你报表的原因。

企业。 面对通过并购积累起来的十几个 ERP 和 CRM 系统，这里的工作是组合层面的治理：按重复数据的代价对数据域排序，在业务部门中建立被赋权的数据管家，并将存续规则和参考数据版本管理标准化，使各个小组不再重复求解同一个匹配问题。明确为集成和长期的管家职责成本做预算，以带版本的事件形式传播黄金记录，使源系统随时间不断改善，并把 MDM 当作一个被度量的项目来管理，使用重复率和审核队列指标，而不是一次性的清理工作。

政府。 采购规则、严格的数据共享法律和公众问责制塑造着每一个选择。以一个受治理的国家标识符为自然人实体建立主键，按生效日期对参考数据进行版本管理，使历史记录保持正确，并让身份解析刻意保持保守：不确定的匹配要交给经过培训的数据管家处理，绝不自动合并，因为一次错误的合并可能导致拒绝某人的福利，或把一位公民的数据泄露给另一位公民。为审计和申诉记录每一次匹配，向供应商要求数据可移植性和公开的匹配逻辑，并使整个能力保持在公共部门已经承诺遵守的互操作性标准之内。

示例

初创企业。 一家快速增长的软件公司同时通过自助注册和销售团队进行销售，这两个渠道在略有不同的公司名称下把同一个客户创建了两次。每账户收入看起来不对，销售团队还在不断给已有用户打陌生电话。他们没有购买一个笨重的平台，而是从一个轻量级注册表开始：在自己的数据仓库中运行一个匹配作业，通过电子邮件域名和规范化后的公司名称来连接记录，一位兼职的数据管家每周审核不确定的匹配。它成本很低，修复了报表错误，并证明了随着公司成长值得追加投资的价值。

企业。 一家全球制造商通过并购不断成长，运行着十几个各自拥有独立供应商记录的 ERP 和 CRM 系统，因此同一个供应商以十五种不同方式出现，公司无法以单一买家的身份谈判，也看不到真实的支出情况。它为供应商和产品数据域建立了一个共存风格的 MDM 枢纽，对税号和注册标识符使用确定性匹配，对名称和地址使用概率性打分。采购部门中指定的数据管家调优存续规则并处理审核队列，黄金记录以变更事件的形式发布，回流到每一个 ERP 系统中，使清理后的数据反过来改善源系统。整合后的支出可视性带来了更好的合同条款，每个季度都消耗财务部门大量精力的对账税也大幅下降。

政府。 一个国家的政府希望各机构把一位公民当作同一个人来对待，而不是在每个窗口都当作陌生人，同时又要遵守严格的数据共享法律限制。它为自然人实体构建了一个集中式主数据枢纽，以一个受治理的国家标识符为主键，参考数据按生效日期进行版本管理，使历史记录保持正确。身份解析刻意保持保守：不确定的匹配交给经过培训的数据管家，而不是自动合并，因为一次错误的合并可能导致某人被拒绝领取福利，或暴露他们的数据，每一次匹配都会被记录以供审计和申诉。回报是重复记录减少、因身份分裂而产生的欺诈减少，公民也不必在每一扇门前都重新证明自己是谁，同时仍然遵守第 3.8 章所述的互操作性标准。

商业案例：动机、投资回报率与总体拥有成本

MDM 的回报来自消除一项大多数组织在支付、却从未命名的税。重复和冲突的记录会以明显的方式浪费金钱（对同一个人重复五次的浪费营销、因过期地址造成的发货错误、错失的批量折扣），也会以不那么明显的方式浪费金钱（分析师核对计数、高管依据悄悄出错的数字做决策、审计人员为厘清哪条记录才是真的而计费工时）。一个整合后的供应商视图，往往仅凭更好的合同条款就能收回整个项目的成本。

总体拥有成本包含三部分：平台或自建成本、与源系统及消费者的集成成本，以及随时间推移占比最大的持续管家成本。集成成本很容易被低估，因为连接十几个老旧的源系统正是 MDM 项目消耗进度和预算的地方；管家成本也很容易被遗忘，因为它是一项永久性的运营支出，而不是一次性的建设投入。要向领导层论证这一点，应把 MDM 与他们已经在跟踪的数字联系起来：收入准确性、营销效率、采购节省、审计成本和监管风险，然后从一个范围狭窄的领域开始，让一个高痛点数据域上被度量出来的胜利，为后续扩展提供资金。

反模式与陷阱

贪大求全的范围： 试图同时掌控每一个数据域，数年内毫无交付，在取得第一个胜利之前就失去了赞助支持。
先上工具，后谈治理： 在指定数据管家和数据所有者之前购买一个 MDM 平台，导致引擎没有司机。
没有权力的兼职管家： 在幻灯片上分配了管家职责，却没有给予任何真正的授权或受保护的时间。
无声的存续决策： 依靠工具默认值或加载顺序来合并记录，没有成文的规则，也无法解释某条黄金记录。
不可撤销的合并： 在没有撤销机制的情况下自动合并不确定的匹配，使两个真实实体的错误融合变成永久性的损害。
就地覆盖参考数据： 在不进行版本管理的情况下编辑代码列表，破坏了所有在旧代码下本是正确的历史报告。
无人消费的黄金记录： 建立了一个无懈可击的枢纽，却没有任何下游系统订阅它，使干净的数据从未到达任何决策。
重新发明标准代码： 在 ISO 标准已经存在的情况下，自己创造国家或货币列表，无端失去了互操作性。

成熟度模型

第 1 级，启动（Initiate）： 主数据和参考数据处于无人管理的状态。同一个实体多次存在，没有权威版本，代码列表相互分歧，匹配靠人工且被动进行，没有人拥有这个问题，因此核心实体的计数彼此不一致，也没有人能说清哪个是对的。
第 2 级，发展（Develop）： 关键数据域已被识别，有人在对它们去重，通常是在数据仓库中为报表目的而做。存在基本的确定性匹配，参考列表已被收集，少数人扮演非正式的管家角色，但实践因团队而异，源系统仍然混乱，规则存在于人们的脑海中，而不是写在纸面上。
第 3 级，标准化（Standardize）： MDM 是一个在整个组织中被一致应用的受治理项目。主数据域拥有指定的所有者和被赋权的数据管家，匹配和存续规则被记录并被强制执行，黄金记录被生产出来并传播给消费者，参考数据像 API 一样被版本管理并附带生效日期发布。
第 4 级，管理（Manage）： 该项目被对照基线进行度量和控制。重复率、匹配置信度分布、错误合并率和遗漏匹配率、关键字段完整性，以及审核队列的规模和积压时长，都被作为指标进行跟踪；阈值根据这些数字来调优，而不是凭感觉；MDM 的价值（收入准确性、采购节省、审核成本）被量化，并按固定节奏向所有者报告。
第 5 级，编排（Orchestrate）： 黄金记录以带版本的事件形式接近实时地流动，输送到语义层，并在整个组织中被信任。匹配根据可度量的结果持续改进，掌控能力作为一种可重复的能力扩展到新的数据域，MDM 与治理及风险规划相集成，使该项目能随着源系统、标准和实体格局的变化而调整。

讨论思路

如果你的两个系统对你有多少客户意见不一致，哪一个是对的，你会如何证明？
如果先掌控一个主数据域，哪一个能带来最大的可衡量胜利？这个胜利值多少？
概率性匹配今天能在哪里帮到你？你是否能接受它所隐含的偶尔出现的错误合并？
你如何对参考数据进行版本管理？当一个代码的含义发生变化时，你的历史报告会出现什么问题？
谁是你最重要实体的指定数据管家？他们是否拥有真正完成这项工作所需的权力和时间？
当一条黄金记录发生变化时，你的下游系统是如何得知的？在造成损害之前，它们能容忍多“陈旧”？

关键要点

将数据划分为主数据、参考数据和事务数据；在重复数据代价最高的地方投入匹配和治理资源。
每个现实世界实体产出一条黄金记录，由明确、可撤销、可记录的存续规则组装而成。
根据你对控制力和干扰性的容忍度，选择一种 MDM 架构风格（注册表、归并、共存或集中式枢纽）。
把参考数据当作有版本管理的共享词汇来对待，优先使用公认的标准，切勿就地覆盖代码列表。
MDM 靠治理和管家职责而成功，而不是靠工具；以事件形式传播黄金记录，并用改善了多少决策来衡量这个项目。

参考文献与延伸阅读

David Loshin, Master Data Management
Alex Berson and Larry Dubov, Master Data Management and Data Governance
Dan Power, The Definitive Guide to Master Data Management
John Talburt, Entity Resolution and Information Quality
Peter Christen, Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection
Ivan P. Fellegi and Alan B. Sunter, “A Theory for Record Linkage,” Journal of the American Statistical Association
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge
Ralph Kimball and Margy Ross, The Data Warehouse Toolkit