简介

MDM 解决方案使企业能够治理、创建、维护、使用和分析主数据信息，并在所有参与者（比如业务线系统、数据仓库和商业伙伴）之间保持主数据信息的一致性、完整性、上下文相关性和精确性。它提供一个可定制的框架，其中的组件控制主数据的生命周期管理、数据的质量和完整性，并通过无状态服务控制数据的消费和分发。MDM 解决方案：

• 对整个企业中使用数据的方式进行标准化，把主数据当作一种独特的企业资产对待，从而提供业务价值
• 在企业中提供权威性的主数据源
• 通过数据提供高价值且可操作性强的服务，它们可以触发数据治理策略以解决名称冲突，以及在数据发生变化时（比如在姓名和地址发生变化时）触发操作，从而产生业务价值

MDM 解决方案不仅仅是在企业内维护主数据的中心存储库。MDM 参考体系结构提供一种灵活的具有适应性的体系结构，能够提供并确保高性能和价值。影响解决方案体系结构设计的一些关键因素包括：

• 它应该提供一个管理和维护主数据的框架，能够作为主数据的权威性数据源，能够在整个企业范围内向得到授权的用户和系统可靠地提供精确的最新的主数据。
• 它应该支持主数据生命周期 的协调 和管理。
• 它应该以服务的形式提供精确的关键业务信息，企业中任何得到授权的用户、应用程序或过程都可以在适当的时候在业务过程的上下文中使用这些服务。
• 它应该能够清理 操作所使用的数据，从而提高数据的质量并使操作环境中使用的数据更加一致。
• 它应该能够探测和生成用来管理主数据、实现数据治理策略和产生业务价值的操作，从而让主数据发挥积极作用。

在 参考资料 中可以找到与 IBM 的 MDM 产品相关的更多信息的链接。

术语

在详细讨论 MDM 体系结构模式之前，先明确一下体系结构、模式、体系结构模式、主数据、MDM 和 MDM 解决方案这些术语代表的含义。尽管本文使用 MDM 解决方案和 MDM 解决方案模式这些术语，但是主要讨论 MDM 体系结构模式。

• 主数据：从非常高的层面上看，实际上有三种数据管理系统：处理事务性数据的事务性数据管理系统（比如订单输入系统）、处理分析性数据的分析性数据管理系统（比如数据仓库）和处理主数据的主数据管理系统。
  • 事务性数据 描述与业务事务相关的操作活动和状态，比如付款、存款/取款、开发票、申请、运输以及服务和销售活动。事务性数据代表在特定时间段或时间点发生的业务操作和活动。
  • 分析性数据 有助于从历史和未来的角度分析客户的行为模式和绩效。预先准备好这些分析性数据，然后使用它们生成销售和市场分析报告、分析每个业务部门的盈利能力和研究买家的行为模式。
  • 主数据 是在整个企业范围内描述关键业务实体的数据和事实。有许多不同类型的主数据，比如关于客户、职员、合作伙伴和供应商的事实和关系，以及产品、商品、原材料和账单的详细信息、事实和层次关系。主数据还可以是关于地点、实体、设备和装置的事实和关系。例如，对于客户，主数据包括客户的静态属性（比如身份属性）、详细的个人信息以及客户之间的关系。
• 主数据集成 (MDI)：MDI 是一套用于执行以下任务的规则、战略、技术和解决方案：
  • 理解：理解和分析数据，包括发现主数据、主数据建模以及治理信息质量和结构。
  • 清理：对主数据进行标准化、合并和纠正。
  • 转换和转移：转换、补充、放置和同步主数据。
  • 联合：在异类数据环境中提供对主数据的访问。
• MDM：MDM 是一套规则、战略、技术和解决方案，用于为整个企业内和企业外的所有参与者（用户和应用程序）创建和维护一致、完整、上下文相关且精确的业务数据。这些规则和战略可以与信息管理产品和服务组合在一起，从而为所有不同类型的主数据（比如客户和产品）提供单一视图。MDM 的一个重要组件是在 MDM 系统的整个生命周期中构建和维护这种单一视图的过程。这可以通过物理或逻辑的主信息 hub 来实现。这包括用于访问、更新、治理数据和信息以及在信息 hub 和其他系统之间执行数据同步和协调的策略和过程。这个视图甚至可以扩展到多个企业。MDI 被认为是任何 MDM 解决方案都应该包含的部分。在某些情况下，客户只希望实现 MDI 解决方案，从而整合、合并、迁移和评估他们的主数据。
• 体系结构：在 IT 环境中，“体系结构” 这个词可以代表多种含义，除非用其他术语进一步加以限定，比如企业体系结构、解决方案体系结构或应用程序体系结构。这些体系结构针对特定的场景或要解决的问题；其他一般化体系结构定义（比如参考体系结构、技术体系结构或产品体系结构）可以作为定义与场景相关的体系结构的起点。体系结构蓝图 是一种通过利用现有的可重用资产、方法、模式和模型开发具有适应性的体系结构的描述性方法。企业体系结构是业务战略、IT 战略和 IT 实现之间的联系。
• MDM 体系结构：MDM 体系结构把用于实现 MDM 解决方案的最佳实践集中在一起。MDM 体系结构包含一组详细描述 MDM 解决方案的体系结构视图，可以通过跨行业和与行业相关的应用程序以一致、高质量且可支持的方式反复构建和部署它们。MDM 体系结构还应该考虑各种企业主数据业务和技术战略、主数据实现方法和 MDM 使用方法。可以使用 MDM 参考体系结构、技术体系结构、MDM 体系结构模式和设计模板描述 MDM 体系结构，可以针对特定类型的客户问题调整它们。
• 模式：在一般情况下，模式是已经在大多数反复出现的场景（80:20 规则）中使用、测试且证明有效的工件。这些场景可以通过给定上下文中问题和解决方案之间的关系来表述，见图 1。当然，有不同类型的模式，比如主要关注过程、工作流、流程等的业务模式。还有部署模式、安全模式、应用程序模式以及处理操作和运行时问题的模式。最后，还有体系结构模式，它们处理在各种体系结构中反复出现的场景，比如企业、参考、集成和应用程序体系结构等。应该在原则、最佳实践和服务、蓝图以及框架中包含模式，最重要的是 在工具中使用模式，从而加快模式的使用和部署。
  
  图 1. 模式
  
  
  

• 体系结构模式：在一般情况下，体系结构模式应该描述已经证明有效的系统模型，并定义组成系统的典型元素和子系统。可以使用这些模式解决各种体系结构问题。基本和复合体系结构模式可以作为模板，在它们的基础上进一步完善、细化、调整和定制。最后，应该在最佳实践、蓝图以及解决方法中包含模式，最重要的是 在工具（比如 Rational Software Architect）中使用模式，从而促进重用。
• MDM 体系结构模式：在 MDM 上下文中，体系结构模式应该解决 MDM 的整个体系结构及其组成部分（比如 MDI）的问题。MDM 体系结构模式还应该考虑到各种企业主数据业务和技术战略、主数据实现方法和 MDM 使用方法。
• MDM 解决方案模式：MDM 解决方案模式描述反复出现的 MDM 问题的解决方案。这些解决方案常常由一个或多个与 MDM 相关的或其他体系结构模式组成。
• MDM 解决方案：MDM 解决方案由相互补充的 MDM 组件组成：
  • MDM 战略：MDM 战略是业务和技术组件的有力组合。它应该包含参与业务的方式、业务动机和总体业务方针。当然，可以针对特定的客户场景定制 MDM 战略。
  • 体系结构：这包括各种体系结构，比如系统体系结构、参考体系结构、技术体系结构。它还包括产品和组件映射。
  • 产品和技术：当然，产品和技术是任何 MDM 解决方案的基本部分（IBM 在这方面处于领先地位，参见 参考资料）。这包括用于构建和操作信息 hub 的 MDM 产品以及属于 MDM 范围的所有功能。MDI 技术还包括企业应用程序集成 (EAI)、企业信息集成 (EII) 以及提取、转换和装载 (ETL) 技术。
  • 最佳实践：这些最佳实践解决集成、构建、部署、治理和操作方面的问题。另外，还需要主数据最佳实践（比如用来满足主数据分类需求的最佳实践）。这些最佳实践常常属于系统集成师的专业领域。

价值主张和解决方案目标

通过把 MDM 体系结构和 MDM 解决方案模式组合成全面的 MDM 解决方案，可以实现以下价值主张：

1. 提供数据的单一版本（保证一致性和质量）：MDM 解决方案在企业中作为权威性的主数据源，避免孤立的应用程序中不一致的数据影响主数据的质量。
2. 对主数据进行全面的生命周期管理：通过构建 MDM 解决方案为主数据提供可操作的服务，它们可以触发数据治理策略以解决名称冲突，以及在数据发生变化时（比如在姓名和地址发生变化时）触发操作，从而产生业务价值。
3. 提高可重用性：正如 简介 一节中指出的，各种各样的客户都需要访问主数据及相关功能。MDM 解决方案为主数据实体创建一个权威可信的信息源。它还提供一套用于访问主数据的标准化服务，在整个企业内和企业外都可以使用这些服务。这样就可以保证以一致的方式使用企业中最重要的信息。
4. 改进数据治理：MDM 解决方案包含专门用来确保主数据实体的数据治理水平的功能。

体系结构原则是全面和基础性的规律、原理或假设，它为开发解决方案指明方向。良好的体系结构原则不会由于技术的发展而过时，而且应该具有客观的依据。在开发 MDM 解决方案时，应该以下面这些核心体系结构原则指导开发：

• MDM 解决方案应该能够把信息与企业应用程序和过程分隔开，使信息成为供企业使用的战略性资产。这是 Information on Demand 的基本概念之一，它基于面向服务原则，其目的是在适当的时间在适当的上下文中向适当的应用程序或用户提供信息。
• MDM 解决方案应该为企业提供主数据的权威性数据源，可以跨整个企业以标准化的 方式管理信息的完整性并控制主数据的分发，从而促进重用。这条原则的主要目的是集中地管理 主数据，从而降低数据管理成本并提高数据的精确性和完整性。
• MDM 解决方案应该提供灵活性，从而适应主数据模式、业务需求和法律法规的变化并支持添加新的主数据。这会提高企业快速响应业务变化 的能力，支持添加新的主数据元素或修改现有的主数据。
• 在设计 MDM 解决方案时，应该高度重视在整个数据生命周期中维护数据的所有者、完整性和安全性。这条原则的目的是，确保对企业的成功至关重要的 核心业务数据是可靠的，而且符合私密性法律法规的要求。
• MDM 解决方案应该基于行业普遍接受的开放计算标准，从而支持通过多种技术与企业内外的各种系统进行交互。这条原则要求体系结构的开发保持开放性和灵活性，这样就可以轻松地与企业中现有的各种厂商软件和未来可能出现的 “未知技术” 集成。
• MDM 解决方案应该基于体系结构性框架 和可重用的服务，从而利用企业中现有的技术。这条原则要求体系结构决策利用现有的技术投资，比如利用现有的连接、互操作或信息集成技术帮助实现 MDM 解决方案。
• MDM 解决方案应该支持以渐进方式 实现 MDM 解决方案，从而让 MDM 解决方案能够立即体现出价值。

MDM 的使用方法

MDM 是一套软件、信息标准和治理基础结构，它使企业能够为所有参与者创建、维护、使用和分析一致、完整、上下文相关且精确的信息。MDM 要求在所有企业应用程序中对主数据进行合理化，把主数据当作一种独特的企业资产对待，在结构化和非结构化数据之间建立联系。MDM 可能使企业的思维模式产生重大变化，因为它要求生成主数据的前瞻性企业视图，必须提供新技术和治理，从而跨多个数据领域以多种使用方法（包括协作性、操作性 和分析性）管理和使用主数据。

MDM 支持在主数据的整个生命周期中管理主数据。这要求能够协调、定义和发布主数据，在各个事务阶段通过操作性过程管理和维护主数据，通过分析功能更好地挖掘和利用隐含的信息。多形式 MDM 这个词是指 MDM 支持多种使用主数据的风格（协作性、操作性和分析性），可以跨多个数据领域，比如客户和产品。在大型的企业环境中，同时应用多种使用方法（甚至是对同一数据领域）并不罕见。

使用方法：协作性风格

协作性风格的 MDM 支持定义、创建和同步主数据。这种风格常常涉及主数据的创建、添加或修改，从而支持新产品定义过程或数据专员等过程。无论是定义新产品、雇用新职员还是管理供应商，都有与维护主信息相关的业务过程。MDM 系统会参与这些过程，要么是由 MDM 系统驱动整个过程，要么是由另一个系统调用它。

协作性 MDM 提供在单一位置维护信息的能力，而且这些信息通常是跨许多内部应用程序维护的，使用单一主过程维护信息可以确保信息的完整性和有效性。协作性 MDM 需要支持工作流的服务以及签入/签出服务，从而控制主数据的创建、管理和质量。在确保信息的完整性和有效性的基础上，协作性 MDM 支持与企业中的遗留系统、企业应用程序和数据存储库集成和同步主数据，支持与业务伙伴交换和同步信息。

使用方法：操作性风格

操作性风格的 MDM 支持操作性系统消费主数据以执行事务，而 MDM 存储库作为主数据的权威性数据源。另外，在操作性模式中，应用程序通过服务使用主数据，这些服务控制主数据的创建、管理、质量和访问。例如，在添加新客户的业务过程中，业务线 (LOB) 系统通过一个 MDM 服务检查这位客户是新客户，还是现有的客户。这个 MDM 服务会清理和标准化新客户的信息，并针对 MDM 存储库执行匹配逻辑，从而判断在 LOB 系统或企业中是否已经存在此客户。

如果它发现此客户是 LOB 的新客户，LOB 系统就可以把新客户信息提交给它的事务数据库。MDM 系统现在在 MDM 存储库和 LOB 系统中都保存了新客户信息。在成功地处理信息之后，操作性 MDM 支持与企业中的遗留系统、企业应用程序和数据存储库集成和同步新的主数据，支持与业务伙伴交换和同步信息。

使用 MDM 系统提供主数据对象的完整视图，但是不需要把所有信息都保存在 MDM 系统本身中。操作性 MDM 提供业务和信息服务，从而使用和维护 MDM 系统中的主数据，并支持跨多个系统引用主数据。可以跨异类系统使用 MDM 服务维护对主数据（包括结构化和非结构化数据）的交叉引用，提供主数据对象（比如一个人员）的完整视图。例如，可以使用 MDM 存储库中的注册信息访问一个联合查询服务，从而创建一个由分布在异类系统中的结构化和非结构化数据组成的虚拟记录，然后把结果返回给得到授权的用户、应用程序或过程。

操作性 MDM 对于面向服务体系结构（Service-Oriented Architecture，SOA）尤其重要。MDM 系统包含许多公用的主数据服务，其他系统可以调用这些服务（例如，任何应用程序都可以通过调用一个集中的过程来查询客户信息、调整产品价格或创建新的供应商），这有助于确保信息的质量和一致性。MDM 通过提供公用的服务，跨所有应用程序支持以信息为中心的过程。MDM 能够降低使用主数据的过程的成本和复杂性，从而帮助公司提高内部效率。它可以减少手工转换和分析，提高分析的可重复性和速度。另外，MDM 有助于快速共享、整合和分析全球和地区性业务信息。它还支持用精确的主信息和可重用的业务过程快速地组合新的复合应用程序。

使用方法：分析性风格

在分析性 MDM 中，使用来自 MDM 系统的主数据作为准确的主数据源，为分析环境提供维 数据源，并用内联 决策支持分析补充 MDM 操作性服务。内联 决策支持分析可以用来支持合法性检查、执行冲突管理以及探测威胁和欺骗。因此，减少成本上升的风险并减轻企业名誉的潜在损失。内联 分析是一种在事务性基础上执行的分析活动，它要求了解应用程序使用 MDM 服务提供的主数据的方式。例如，可以通过身份分析探测威胁和欺骗或执行反洗钱 (AML) 活动，从而降低风险和提高合法性。

分析性 MDM 还支持精确的业务智能化，可以与数据仓库和分析应用程序自动地同步数据对象和结构。在历史上，数据仓库曾经试图解决应用程序产生的数据质量问题。但是，数据仓库不能纠正那些在应用程序中产生不精确的主数据的业务过程，也不能纠正返回给应用程序的主数据。MDM 能够纠正错误数据和产生错误数据的过程。反过来说，在数据仓库中通过分析产生的数据（例如，客户寿命值、交叉销售和延伸销售建议）可能是非常重要的数据，可以通过数据仓库 feed 把这些数据保存到 MDM 系统中。

实现企业 MDM 解决方案是一个迭代式的过程，要求能够以渐进方式为企业提供价值，满足所有参与者的需要。如果希望 MDM 系统不断地为企业提供价值，就需要提供多形式 MDM 支持，帮助在主数据的整个生命周期中管理主数据和支持所有参与者的需要。

MDM 体系结构模式属性

使用属性进一步描述各种体系结构模式。下表解释 MDM 体系结构模式常用的一些属性：

模式的名称 是模式的惟一标识符，在讨论模式时使用。模式的类型 表示此模式属于哪组 MDM 模式。使用方法 把模式与前面讨论的一种或两种 MDM 使用风格关联起来，指出在哪些使用风格中常常遇到此模式。目标 简要说明此模式的主要目标。问题 列出此模式要解决的最重要的问题。阻力 指出此模式要解决的问题为什么难以解决。上下文 提供关于模式的部署上下文的信息。例如，此模式通常部署在 SOA 体系结构还是非 SOA 体系结构中，环境可能会如何影响模式的部署。解决方案 比较详细地说明在哪些情况下此模式是可行的，描述可能的解决方案空间。结果 描述使用此模式的优点和缺点。相关 描述此模式与其他模式的关系。例如，此模式可能使用的其他模式，以及为什么此模式与另一个模式相关但又有差异。这个属性还列出此模式的已知的子类型。MDM 解决方案 列出常常使用此模式的 MDM 解决方案。最后，在注释 中提供其他相关信息。

MDM 体系结构模式分类法

MDM 体系结构模式有助于加快 MDM 解决方案的部署，使企业能够为所有参与者（比如 LOB 系统、数据仓库和商业伙伴）治理、创建、维护、使用和分析一致、完整、上下文相关且精确的主数据。作为复合模式，MDM 模式有时候会使用信息集成模式并提供其他功能，比如治理、主信息生命周期管理和主信息业务服务。MDM 体系结构模式帮助数据、信息和应用程序架构师对企业体系结构做出合理的决策，帮助记录重要的决策方针。

根据前面讨论的术语定义，MDM 体系结构模式是 MDM 体系结构（以及各种企业主数据技术战略、主数据实现方法和 MDM 使用方法等考虑因素）和体系结构模式（已经证明有效的描述性的工件、示例、模型、解决方法等）之间的交集。

模式分类法

因为有多种 MDM 体系结构模式，需要按照一种模式分类法 把它们归入不同的类别，帮助架构师更快地找到解决问题所需的模式。下面是推荐的三个 MDM 体系结构模式类别：

• MDM 应用程序集成模式：这个类别中的所有模式都以 EAI 为中心，主要关注由 MDM 用例驱动的过程。这里的模式与基于发布/预订的集成和基于消息的集成技术相关。最重要的是，这些模式处理事务拦截，从而支持部署事务性 MDM 解决方案模式。
• MDM 信息集成模式：这些模式也是 EAI 模式，但是主要关注信息集成。这些模式处理 MDM 解决方案的构建和操作阶段，因此包括与 ETL、初始数据装载和构建 MDM hub 相关的模式。另外，这些 MDM 信息集成模式也常常使用与 EII 相关的模式。例如，实现 hub 式信息同步或与事务性系统进行混合型（双向）同步。
• MDM 企业系统部署模式：这个类别中的 MDM 模式与各种部署场景相关，主要关注与其他企业系统的集成，比如分析系统、数据仓库、数据集市、企业资源规划 (ERP)、客户关系管理 (CRM)、产品生命周期管理 (PLM) 等系统。它们的重点不是实现 MDM hub 所需的事务拦截，而是与其他系统的协作，例如用分析系统提供的信息补充客户信息 hub 中的信息。

下面列出这三个类别中的模式。随着 MDM 解决方案逐渐成为主流技术以及部署范围的扩大，这个列表中可能会增加新的模式，或者出现已知模式的新的子类型。

• MDM 应用程序集成模式：
  1. MDM 事务拦截模式
  2. MDM 发布/预订模式
  3. 基于消息的 MDM 集成模式
• MDM 信息集成模式：
  1. MDI 模式
  2. MDM 信息同步模式
• MDM 企业系统部署模式：
  1. MDM 业务智能化 (BI) 分析模式
  2. MDM 数据仓库模式
  3. MDM 多系统模式

下面简要介绍这些模式的主要用途和典型的使用场景。本文只介绍 MDM 模式的基本知识，完整详细的描述（包括实现考虑事项和技术映射）超出了本文的范围。

MDM 事务拦截模式

MDM 事务拦截模式 与 事务性 MDM 解决方案模式 上下文中的应用程序系统集成（比如 SAP）相关。使用此模式的假设包括：

1. 存在使用主数据的应用程序系统，而且在建立 MDM hub 之后仍然要使用它们。
2. 部分或所有用户要通过现有应用程序的 UI 维护和处理主数据记录的部分属性或所有属性。出现这种情况可能是因为项目的预算不允许在 MDM 项目中开发新的 UI 和工作流，或者因为涉及的用户太多，无法为他们提供使用新的主数据应用程序前端的培训。
3. 处理主数据的部分或所有应用程序用本地数据库存储这些信息，并可能同时存储非主数据。
4. 采用 事务性 MDM 解决方案模式 并在整个企业范围内实施相关的检验和业务规则，这要求通过主数据系统获得信息的单一版本，并向下游系统提供主数据。对主数据的所有修改直接或间接地对此系统执行。

如果这些假设大多数都成立，就需要拦截业务事务。部署事务性 MDM hub 之后，事务拦截模式可以提供实时或接近实时的集成。在应用程序业务事务提交对主数据的修改之前，会通知事务性 MDM hub（比如通过消息传递）。然后，MDM hub 执行检验或在需要时消除重复的数据，把修改提交给本地的事务性 MDM hub 数据库，最后通知（比如通过消息传递）业务应用程序可以提交主数据修改了。当然，在这种情况下，发送给应用程序系统的通知必须包含中心 MDM 系统对从业务应用程序接收的记录所应用的所有修改，这意味着业务应用程序可能会提交主数据记录的不同版本，而不是它原来发送给 MDM hub 的版本。只有在收到事务性 MDM hub 的答复之后，业务应用程序才会把修改提交给自己的本地系统。注意，应用程序系统中的 “提交” 不一定意味着数据库或应用程序提交。例如，如果使用主数据记录的状态??那么可以像下面这样做：

如果应用程序系统创建了一个新的主数据记录，那么通过事务拦截机制把此事件报告给事务性 MDM hub。但是，在执行拦截之后，应用程序事务马上把修改提交给它的数据库 —— 把新主数据记录的状态设置为 created。当收到事务性 MDM hub 的响应时，用 hub 提供的经过检验的信息更新应用程序本地创建的记录。在这个操作完成之后，修改记录的状态，比如由 created 改为 active。在此之后，应用程序的所有用户才能看到这条新的主数据记录。

MDM 发布/预订模式

此模式用于集成纯粹的下游系统，比如电子商务网站或目录印刷系统，这些系统使用主数据，但是本身并不创建或修改主数据。用注册 MDM 解决方案模式、混合型 MDM 解决方案模式 或事务性 MDM 解决方案模式 实现的 MDM 系统把对 MDM 数据的修改发布到队列中，而下游系统使用此模式预订队列。

基于消息的 MDM 集成模式

主要用于引用的 MDM 系统常常使用此???式。这种 MDM 系统只作为引用存储库，只实施最少的检验和业务规则，跨所有系统提供最小的公用数据集。此模式只从处理主数据的应用程序系统向中心 MDM 系统发送消息，执行特定的主数据修改，从而让中心引用 MDM hub 能够提供最新数据。在应用程序系统已经在本地存储了修改之后，才会更新中心 MDM hub。如果 Siebel 或 SAP 等业务应用程序系统继续作为处理主数据的主系统，而中心 MDM 系统只作为引用主数据系统，就可以应用此模式。

MDI 模式

此模式描述构建 MDM hub 所需的主数据集成。实现此模式要利用数据整合模式等模式（见 参考资料）。此模式与基本的数据整合模式的不同之处在于，在企业范围内集成元数据管理和数据治理功能。这意味着，如果应用 MDI 模式，那么不但使用 ETL 领域的模式构建 MDM 系统，还要通过部署技术基础结构来管理元数据生命周期和管理集中的企业词汇表，从而改进业务职员和技术职员之间的交流。根据部署的 MDM 解决方案不同，还可能要求在构建 MDM 系统之后可以重用清理和转换功能，从而确保在填充 MDM 系统之后以相同的方式把主数据从应用程序移动到 MDM 系统（因此保持一致性）。IBM Information Server（见 参考资料）可以使清理和转换功能成为可重用的服务。部署这些基础结构组件并与 MDM 系统集成是成功应用此模式的关键。所以在 EAI 基础结构中重用相同的清理和转换功能，从而确保构建后的中心 MDM 系统与用来构建它的业务和检验规则保持一致（只要这些规则仍然是有效的）。此模式总是与一个或多个 MDM 体系结构模式一起使用，构建 MDM 解决方案。

MDM 信息同步模式

在事务性系统和中心 MDM 系统都要修改主数据的情况下，常常遇到 MDM 信息同步模式。这种场景的问题在于，为了保持主数据的一致性，这些系统需要同步。根据需求的不同，同步可以是实时的，或接近实时的。另外，可能会遇到以下拓扑结构：

• 主从拓扑
• 对等拓扑

例如，MDM 系统是主系统，而事务性系统是从系统。如果反过来，就意味着只在事务性系统中修改主数据，而 MDM 系统是只读的。在零售业中，有一个应用此模式的用例。全局数据池（比如 1Sync）存储产品主数据领域的属性和层次结构。这些信息对于零售商非常重要，零售商必须利用它们把供应商发布的必需的产品属性输入这些全局数据池。因此，零售商需要以同步方式与这些全局数据池集成。对于这种用例，此模式有一种已知的子类型全局数据同步模式，这是因为全局数据池的接口是标准化的，并要求同步基础结构符合这些接口。关于全局数据同步的更多信息，参见 参考资料。

MDM BI 分析模式

此模式与用于构建数据仓库或数据集市的标准信息集成模式不同。传统上，BI 数据仓库从源系统（常常是操作性联机事务处理 [OLTP] 系统）接收数据，但是从不向它们返回数据。由于客户或产品领域的主数据 hub 也可以把客户或产品的核心属性发送给数据仓库，因此出现了一个???题：是否在某些情况下在 BI 系统中发现的信息也与 MDM 系统相关？在这些情况下，在 MDM hub 和 BI 分析系统之间就需要双向集成。例如，公司在 BI 分析系统中发现在前一季度或前一年中 10% 的客户对销售业绩贡献最大，那么公司可能希望修改 MDM hub 中这些客户的某些属性，从而为他们提供更好的客户服务响应时间或更好的信用卡。应该使用此模式以双向数据交换方式集成的分析系统还有实体分析解决方案 (EAS) 系统，这种系统也应该把在客户数据中发现的信息返回给 MDM 系统，例如 “Know Your Customer” [KYC] 方面的需求。处理 AML 过程的系统需要把发现的金融交易异常返回给 MDM 系统。这些分析系统可能需要与 MDM 系统实时或接近实时地集成。

MDM 数据仓库模式

此模式描述 MDM 系统与数据仓库和数据集市之间的集成，这些系统是下游系统而且不向 MDM 系统返回更新。不向 MDM hub 提供反馈是此模式与 BI 分析系统模式的不同之处。另外，此模式与用于构建数据仓库的传统 ETL 模式也不一样，因为主数据在输入数据仓库时需要的清理和转换比较少。

MDM 多系统模式

如果在发生企业并购之后，至少两个中心 MDM 系统需要集成，就需要此模式。这种场景的问题是，MDM 系统常常是用不同厂商的不同技术构建的。另一个用例是，对于某个厂商提供的一组应用程序系统，如果把此厂商提供的相关领域的 MDM 解决方案与这些应用程序系统集成，就可以简化 MDM 任务。这种方式可以简化集成，因为不必把每个应用程序系统连接到企业范围的 MDM 系统，只需把这个部分的 MDM 系统与企业范围的 MDM 系统集成起来，这可以减少 EAI 方面的工作量。另外，LOB 可能已经整合了所有与 MDM 相关的应用程序系统，然后才决定实现企业范围的 MDM 系统。那么，就不需要把这个 LOB 的所有应用程序系统分别与企业范围的 MDM 系统集成，只需集成这个 LOB 已经创建的 MDM 系统，这样做更容易、成本更低而且效果也足够好。

如果出现这些情况，就可以应用此模式。

MDM 解决方案模式

仅仅了解这些 MDM 体系结构模式还不足以构建和操作 MDM 系统 —— 成功的 MDM 解决方案的关键是适当地组合 MDM 体系结构模式。体系结构模式的组合产生体系结构蓝图，而体系结构蓝图是企业 MDM 系统和解决方案的基础。MDM 企业系统部署模式以及 MDM 应用程序和信息集成模式是开发这些 MDM 解决方案的关键因素。但是如果需要，这个组合需要包含其他体系结构模式领域中的体系结构模式。MDM 解决方案模式包含用于完整的 MDM 解决方案的模式。它们的主要特点是，它们常常需要许多 MDM 体系结构模式或其他体系结构模式。例如，MDM 零售解决方案模式需要 MDI 模式、全局数据同步模式和 MDM 发布/预订模式，从而集成下游电子商务系统。

下面是四种基本的 MDM 解决方案模式：

1. 引用 MDM 解决方案模式：这种主数据系统设置意味着应用程序系统仍然是记录的主系统。每个应用程序系统在把修改提交给本地系统之后，把更新（常常是以批处理模式）发送给引用主数据系统。这个主数据系统的用途仅仅是在其中保存所有系统使用的所有主数据记录的引用，但是仍然在应用程序系统中管理和存储主数据。它只标识特定的主数据记录，而不支持实时访问。
2. 注册 MDM 解决方案模式：构建至少一个骨架 主数据系统，从而提供支持实时引用访问的记录系统。数据仍然存储在应用程序系统中，但是可以从主数据系统链接所有属性，允许动态地组合主数据记录的完整视图。这个视图常常是只读的，因为修改访问只能通过应用程序系统执行；应用程序系统仍然是主数据的主系统，但是通过链接集成在一个集中的视图中。这种主数据系统的用途是提供实时引用访问。
3. 混合型 MDM 解决方案模式：混合型主数据 hub 用单一数据模型把主数据记录整合在一个集中的数据库中（至少在某种程度上）。但是，正如混合型 这个词所表明的，为应用程序提供服务的数据库仍然存在。在把更新从本地应用程序源传输到混合型主数据 hub 时需要执行转换，因为不同的应用程序在本地存储相同的实体时常常包含略有差异的属性。使用这种模式创建和发布每个主数据记录的完整视图，但是不保证提供的是主数据的最新版本。另外，这种主数据 hub 风格常常只提供只读访问（很少支持写访问），对主数据记录的修改仍然通过应用程序系统执行。这种主数据 hub 风格能够跨系统协调数据，能够作为中心引用系统。
4. 事务性 MDM 解决方案模式：这种风格实现真正的主信息 hub，hub 是记录的主系统。它存储所有主数据记录的所有属性，支持所有应用程??（从遗留应用程序到 SOA）对主数据记录进行事务性访问，常常通过面向服务的接口进行这些访问。在主数据记录的整个生命周期中，都通过主数据 hub 的事务性接口创建、修改和删除主数据，主数据 hub 为需要访问主数据的所有应用程序提供主数据的单一版本。

本文不进一步讨论这些 MDM 解决方案模式。

结束语

后续文章将深入讨论上述 MDM 体系结构模式的细节，尤其重点关注实现和部署方面以及技术映射。以后还将详细介绍 MDM 解决方案模式和蓝图。