任务:指定数据迁移
此任务描述了如何将旧数据源迁移到目标数据库。
用途
  • 此任务的目的是通过定义数据迁移的范围、数据概要信息以及在数据源与目标数据库之间的映射来指定数据迁移。
关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
步骤
定义迁移范围
目的: 定义迁移的范围

如果您计划将数据迁移到新的数据库中,则首先要执行的任务就是定义迁移的范围。此任务的一些具体组成部分为:

  • 确定要迁移的数据源以及它们的位置。
  • 确定使用当前数据源的系统以及将使用新数据库的系统。
  • 确定当前未以电子形式存放的数据以及将这些数据输入新系统的方法。
  • 确定源数据是否在迁移之后引退。如果继续使用源数据,则同时维护原始数据和新数据库中的数据可能将成为一个问题。

此外,您还应当确定源数据的相关子集。数据迁移项目并不是单独发生的。它们而是衍生自其他开发工作,如演进或替换旧系统的项目。需要迁移的历史数据的数量由这些开发工作的需要决定,因为一般情况下没有必要将现有系统中的数据全部迁移。以下几点可以帮助确定迁移范围:

  • 旧系统中的历史数据可能无法转换为新系统的格式。例如,由于数据结构的改变,数据的含义与原先可能不再相同。
  • 前几年的历史数据可能只需要以汇总级别保存。
  • 可能有一些强制的要求,例如税务规定要求保存详细的历史信息,但未必需要对特定时间段的数据进行转换。

理想情况下,数据迁移应当在新系统投入生产运行之前完成。但是,如果数据频繁产生变化或数量非常庞大,或者对迁移结果的验证是一个很长的过程,则对迁移数据进行修改可能是必需的。这一点尤其适用于必须对手工数据进行收集、验证然后输入到自动系统中的情况;在这些情况下,数据捕获可能花费好多个月的时间。

在这种情况下,您需要对维护过程进行规划和定义,以便在完成数据迁移到投入生产运行之间的这段时间内,迁移的数据时刻保持最新状态。这些过程需要在经济性(正常情况下不使用很久)和精确性(不能将错误带入已转换的数据中)之间取得平衡。它们还应结合控制和审计跟踪(如果适用)。

通过数据概要分析了解数据源
目的: 建立不同数据源的数据概要信息

确定了不同的数据源之后,就可以开始分析这些数据源以建立它们的数据概要信息。数据概要信息是一组有关数据内容、结构和质量的信息,这些信息将存储在数据迁移规范中。

建立数据概要信息的详细步骤如下:

收集信息

数据概要分析的第一步是收集描述数据源的元数据。这可能包括源程序、字典或存储库描述、关系目录信息、先前的项目文档以及其他任何能够明确数据含义的可用信息。如果使用数据的系统是通过 RUP 开发的,则可以使用数据模型用例用例实现作为数据源以了解系统使用数据的方式。会见原来的开发人员(如果他们还在)或者负责管理数据的数据库管理员也是很有用的。

但是,文档(作为系统的一部分自动保留或反向设计的信息除外)应当有选择地保留。它曾经是有效的,但是通常会随着时间的推移,逐渐不适用。通常,旧系统在创建时记录得很少,并且文档一般都未与随后的更改保持一致。即使它不是最新的,经常,现有元数据也是有关数据源和数据语义的唯一可用信息。概要分析过程将指出元数据与真实数据之间的不一致处,并且填入最重要的那部分缺少信息。

分析数据源

数据概要分析的第二步是开发数据源的映射。该映射显示了数据字段的存储方式,并确定了处理重新定义数据结构和重复其中数据组的规则。

如果数据源是关系结构,则可以从数据库模式直接抽取映射。因为这些结构由 DBMS 实施,所以无需质疑它们的有效性。

如果数据源不是关系结构,则您需要将元数据与该数据结合起来使用才能获取规范化的数据格式。您特别需要注意“过载”属性。“过载”是将多个事实存储到同一属性的过程。

此概要分析步骤完成后,您可以按规范化的格式执行对数据源完整抽取的采样,以便深入进行数据概要分析过程。通常情况下,该抽取通过迁移组件的抽取脚本执行,因为这也是对这些脚本进行测试的好方法。

对数据源属性进行概要分析

数据概要分析的第三步是确定每个属性中数据的内容、域和质量,并确定每个属性后面的语义。对实际源数据执行此操作很重要,因为记录的元数据可能是不正确的。

此操作使您有机会确定以下几点:

  • 哪些属性被记录用于某一用途,实际却用于另一用途
  • 哪些属性已记录,实际却未使用
  • 属性的数据内容与其语义之间有什么不一致
  • 数据的什么基数确定固定属性(只包含一个值的属性)

尝试改进性能的结果是旧系统和关系系统通常使用“反向规范化”和数据复制。它们还经常缺少主键和外键支持。这意味着您必须对源表进行分析,确定属性之间的功能依赖关系并找出候选主键和外键。

当属性概要分析结束后,它需要以两种级别进行复审。第一个级别是为了确定是否要迁移该属性。如果属性中不含有用的信息或数据的质量太糟而无法在不损坏目标的情况下迁移,则您可以选择不迁移该属性。第二个级别是为了确定在迁移过程中属性是否需要清理。

如果在概要分析期间发现质量问题,则您需要执行一定的数据清理;除去或修改不正确的、重复的、格式不正确的或不完整的数据。该操作通常称为数据清理。

定义数据源与目标数据库之间的映射
目的: 描述源数据库元素与对应的目标数据库元素之间的映射

此步骤中的两个主要输入是上一步中精化的数据概要信息以及目标数据库的物理数据模型。

很多人错误地认为可对逻辑数据模型执行数据映射。但是,由于源数据是物理数据格式表示的,并且我们需要将该数据迁移到新的物理数据模型中,因此在这些物理格式之间进行映射比通过逻辑数据模型进行间接映射更可行。

以下是重要的考虑事项:

  • 如果同一目标属性有多个源,则如何处理冲突。
  • 如果某个属性没有任何源,则如何提供数据。

为成功执行此步骤,rup_database_designer_legacy 需要一个业务设计人员(他对需要迁移的数据必须有深入的了解)和一个系统分析员(他必须了解源系统和目标系统)。

映射应当记录在数据迁移规范中。

此步骤的两个主要输入源是上一步中精化的数据概要信息和目标数据库的物理数据模型。

确定手工和自动数据迁移
目的: 确定哪些数据源可以自动迁移,而哪些应当手工迁移。

如果您已对数据概要信息和各种数据源的数据映射进行了精化,则应当确定哪些数据迁移可自动执行,而哪些需要通过手工过程迁移。

技术:设计数据迁移子系统简要介绍了如何设计组件来执行自动数据迁移。

应尽可能使用新系统的标准数据输入过程输入手工转换的数据。但是,有时候使用专门构建的转换过程是不可避免的。典型的例子就是批量输入数据,正常情况下这些数据是以交互方式输入的,但是数据量过大而无法进行交互式输入。

手工迁移的数据可以在“数据映射表”中确定,该表包含在数据迁移规范中。

属性
多次出现
事件驱动
正在进行
可选
已计划
可重复