白皮书主数据管理和数据迁移本文档含有 Informatica Corporation 的保密、专有信息和商业秘密信息（“机密信息”），事先未经Informatica 的书面同意，不得进行拷贝、散发、复印或以任何其它方式复制。

尽管我们尽最大努力确保本文档中信息的准确性和完整性，但仍可能存在一些印刷错误或技术误差。

如因使用本文档所含信息而造成任何损失，Informatica 概不负责。

本文档中包含的信息随时可能更改，恕不另行通知。

Informatica 自行决定将这些材料中讨论的产品属性纳入其任何软件产品的发布或升级中，并自行决定任何此类发布或升级的时间安排。

受下列一项或多项美国专利保护：6,032,158；5,794,246；6,014,670；6,339,775；6,044,374；6,208,990；6,850,947；6,895,471；或受下列正在申请的美国专利保护：09/644,280；10/966,046；10/727,700。

此版本发布于 2014 年 11 月白皮书目录MDM 对数据迁移为何至关重要 (2)第 1 个问题：进行苹果与苹果的比较 (2)按时启动：中间步骤 (3)案例：若干产品 (4)第 2 个问题：质量至关重要 (4)案例：整合公司总部系统和本地系统 (5)数据迁移是提升 MDM 价值的途径 (5)主数据管理和数据迁移1本白皮书描述主数据管理对数据迁移项目日益增长的重要性、有用之处和最佳部署选项，其中包括相关案例研究。

MDM 对数据迁移为何至关重要每个新系统均需要数据来促进活动的启动。

大多数新系统需要若干数据。

如今，除了通过邮局地址文件等外部源丰富新系统以外，我们正在将大量遗留源中的数据迁移至新系统。

Informatica 数据迁移工具套件将部署一整套技术和最佳实践流程，旨在解决当今数据迁移场景中涌现的一系列挑战。

但首先，我们一起来看看市场背景。

尽管目标系统可能会涵盖各种功能，但数据源就好比是烟囱式解决方案，每一款解决方案均围绕不同的业务流程、不同的业务领域而设计。

尽管目标系统要求数据一致，但遗留环境中的数据结构和内容却经常不一致。

这给我们带来了以下两个问题，不过二者均可使用 MDM 技术加以解决。

第 1 个问题：进行苹果与苹果的比较下面，我们一起来看个示例。

假设我们正在安装新生产规划应用系统。

该系统通过将会计和人力资源应用系统链接在一起，旨在增强车间管理并提高效率。

但我们发现，涉及的每个部门及其背后的运行体系对于完全相同的事物具有不同的看法。

会计人员看到的是某一成本中心、利润中心、折旧、资本资产和运营资产。

而生产工程师则通过以下属性来定义同一物理空间：自动化流程、半自动化流程和手动流程；工作流；维护计划；生产定额。

与此同时，人力资源部门则会将同一场景视为内部员工、外部员工、培训需求、技能级别、付款协议和医疗保健问题。

他们都在观察同一个事物，但都站在不同的角度。

因此，在选择和设计系统时，他们将采取截然不同的系统建模方式，这一点不足为奇。

这并不是说他们谁有错，但毫无疑问，他们肯定不一致。

因此，在执行数据迁移时，我们确实会发现，我们事实上并不是在比较苹果和苹果。

相反，我们是在比较苹果和梨。

若要成功，我们仅需一种水果。

这并不仅仅像摒弃这种或那种观点。

从绝对意义上来说，这些真实的观点都没有错。

另一方面，即便我们认定生产部门的观点最恰当（假设在这种情况下，这些观点正好是我们的变更驱动因素），但我们也无法认定要其他遗留数据存储，才能在不重新设计这些数据的前提下、以潜在基于迁移本身规模的方式符合生产部门的模型。

在任何情况下，我们更可能会采取一种观点，即：每个遗留数据存储对于其自身域的建模范围正好合适。

因此，生产部门从生产的角度来看觉得合适，而人力资源部门则从人力资源的角度来看觉得合适，依此类推。

因此，我们需要一款能够考虑到所有各方观点的模型。

有趣的是，这种挑战与交付目标系统的项目挑战完全相同。

为何不能等到目标准备妥当并执行相应的差距分析？2按时启动：中间步骤如果第一个问题是协调支离破碎的数据环境，那么我们还可以回过头来思考一下正常迁移的时间表。

如果我们假设新系统的设计和安装需要一年时间，那么目标系统最快在八个月后才能问世，而且仅仅是第一轮雏形。

（假设标准的项目方法包括：项目启动活动、当前状态分析、新系统的配置和业务流程的重新设计）据经验表明，我们有望可在第 10 个月实现稳定的目标交付，即便在移交之后还有可能会出现变更。

根据以前得出的经验，我们只剩下两个月的时间执行差距分析；提取、转换和加载数据；编写和测试负载脚本等。

不幸的是，我们几乎没有足够的时间对遗留数据存储之间的结构差异进行优质的分析，只能让系统生成负载文件中所需的复合数据项。

对于此时间问题，有一种解决方法是：创建一个中间阶段模型（我们称之为“迁移原型”）。

我们记录每个遗留数据存储和原型之间的差异，并开始执行清除和数据准备活动。

然后，当最终交付目标模型时，我们可以看出原型和目标之间的差异。

由于我们已掌握遗留数据存储和原型之间的转换，因此我们可以隔离原型和最终目标之间的差异，因而在最繁忙、压力最沉重的时期显著简化自身的活动。

因此，这里有一个小诀窍，即：构建一款针对目标状况做出最佳猜测的迁移模型，分析遗留模型和迁移模型的差异，并执行数据转换、数据扩充和增强等操作。

然后，当真正的目标出现时，我们根据最终出现的微调问题调整这些转换数据。

这样一来，如果原型只有 80% 的正确性（经验告诉我们必须进一步提高正确性），则在项目最后冲刺的几周时间里，我们必须设计 80% 的转换逻辑。

但是，主数据管理解决方案为何能够在此模型中提供帮助？据维基百科指出：“MDM 旨在提供在整个企业范围内收集、聚合、匹配、整合、质量保证、保留以及分发数据的流程，确保持续维护和应用系统使用此信息时的一致性和可控性”从数据角度来看，所举示例中的三大领域观点（会计人员、生产工程师和人事专员）将使用相关数据存储内的编码值加以实例化。

因此，我们对提供数据“收集、聚合、匹配、整合和质量保证”流程非常感兴趣。

在这一项目中，我们并不会如此直接关注“保留以及在整个企业范围内分发数据”（原因我们已提及）。

但是，确保“持续维护和应用系统使用此信息时的一致性和可控性”是我们迁移项目时所要考虑的主要问题。

换句话说，我们将采用 MDM 数据迁移方法，其原因除了我们是希望更换（而不是增强）系统以外，还在于我们不可能闭合使用这些数据项的系统循环。

主数据管理和数据迁移3案例：若干产品下面，我们一起来看看一个真实的示例，更清楚地了解上述所有信息。

某大型电信公司正准备进行数据迁移。

为了大致了解迁移规模，他们对数千万名客户和数十亿的安装系统进行编号。

除此以外，还有许多数量十分庞大的零散产品，每种产品高达上万个。

为了使整个迁移项目变得更有趣，我们假定该电信公司在某些产品的基础上构建产品。

这样一来，我们必须处理的零件版本数量便呈爆炸式增长。

此外，该电信公司还面临着因遗留系统数量过于庞大而带来的严峻挑战。

由于订购、设计、交付和计费涉及多个层面的物理活动和逻辑活动，因此，该公司每个步骤均已配备一个传统的构建点解决方案。

结果，潜在的遗留系统池高达 400 多个。

通常，每次安装大约需要处理 30 个左右。

当然，其中每个遗留系统均具有自身的整体视图，展示它在整个流程流中的具体位置，并指出其视图是逻辑视图，还是物理视图或财务视图。

在此白皮书中，我们仅阐述产品结构问题以及为何迫切需要基于 MDM 的解决方案。

面对数以万计的产品，而且其中某些产品以另一些产品为基础构建，因此各项规则的数量之多令人感到恐怖。

当某一遗留应用系统正在进行某次电话安装时，另一系统可能会涉及电话听筒、拨号音、外拨电话、向内拨号、回复电话、接听电话等。

换句话说，即便是一个简单的内线电话，也会涉及多达 10 余种产品，更不用说复杂的语音和数据网络。

配置流程中的每个系统似乎均会涉及不同的电话。

我们必须保持一致，必须尽快启动。

坐等目标实现并非明智之举。

该解决方案旨在为产品和产品内部版本创建主数据管理中心。

每周更新数据可解决日新月异的行业需求，随时设计并添加新产品。

该中心允许我们检查遗留数据存储以查看匹配产品，并始终支持我们查看交付链中不同点的显示差距。

随着每一迁移阶段的出现，我们可以清楚地看到源系统结构和目标系统结构的差距，并相应地针对映射和转换重新编码。

第 2 个问题：质量至关重要下面，我们一起来看看第二类问题：内容或数据值问题。

对于同一业务对象，遗留数据存储可能具有多种结构，因此我们很可能具有多个值。

下面，我们一起看看几个相关的常见示例。

客户列表中包含的重复数据，这可能是令所有市场营销部门头疼的一个大问题。

这些数据是从客户各个孤岛的多个数据存储中收集的。

有些数据很容易发现并清除。

但有些数据可能存在可怕的同音异义或同义词问题。

John Smith 是否就是 J Smith，或者在其他位置可能是 J P Smith 或 Jonnie Smith？执行迁移时，我们都会遇到同样的问题。

这些问题就好像同一数据存储内可能出现的状况一样，即：同一个人可能会出现多个副本。

这些问题经常因为结构问题而变得更加扑朔迷离。

例如，在企业对企业 (B2B) 环境中，经常会因为该客户到底是谁而感到困惑。

我们是否应将该客户视为第一合法实体？（即：如果确实如此，我们会将该公司告上法庭。

）或者，该客户是我们打交道的交易部门吗？或者是当地仓库或商店？再次重申一下，您的观点将随着您在企业中所处的位置而变化。

物流团队将查看供应点；计费团队则需查看供应点和计费地址详细信息。

您可能拥有许多在不同地域开展业务的销售团队，但只有一层专门为大客户服务的战略关系经理。

因此，从法律的角度来说，可能只有一个合法实体，但却有几百个当地订购点、交付点和计费点。

4再强调一次，更正源系统中的这类异常并不可行，特别是在源系统并没有错误的情况下更是如此。

（当然，如果同一客户被创建两次，则此缺陷流程将直接导致出现重复数据。

这些数据甚至从遗留数据存储角度来看便已出错，但可在其中予以更正。

）那么，您应在哪些位置启动 MDM 解决方案？它如何提供帮助？不言而喻，MDM 是掌控主要实体的完美解决方案。

下面，我们将执行完全成熟的 MDM 中的几乎所有功能（其中包括确保“持续维护和应用系统使用此信息时的一致性和可控性”）。

至少，我们将展示它如何确保遗留数据集中不存在任何重复数据。

案例：整合公司总部系统和本地系统下面，我们再来看一个示例，更清楚地了解其中涉及的挑战。

某中型银行需要迁移。

该银行的办事处地理位置十分分散，且每个办事处内均存在总公司系统的分散实例，由一系列批处理流程链接至总部。