确定了不同的数据源之后,就可以开始分析这些数据源以建立它们的数据概要信息。数据概要信息是一组有关数据内容、结构和质量的信息,这些信息将存储在数据迁移规范中。
建立数据概要信息的详细步骤如下:
数据概要分析的第一步是收集描述数据源的元数据。这可能包括源程序、字典或存储库描述、关系目录信息、先前的项目文档以及其他任何能够明确数据含义的可用信息。如果使用数据的系统是通过 RUP 开发的,则可以使用数据模型、用例和用例实现作为数据源以了解系统使用数据的方式。会见原来的开发人员(如果他们还在)或者负责管理数据的数据库管理员也是很有用的。
但是,文档(作为系统的一部分自动保留或反向设计的信息除外)应当有选择地保留。它曾经是有效的,但是通常会随着时间的推移,逐渐不适用。通常,旧系统在创建时记录得很少,并且文档一般都未与随后的更改保持一致。即使它不是最新的,经常,现有元数据也是有关数据源和数据语义的唯一可用信息。概要分析过程将指出元数据与真实数据之间的不一致处,并且填入最重要的那部分缺少信息。
数据概要分析的第二步是开发数据源的映射。该映射显示了数据字段的存储方式,并确定了处理重新定义数据结构和重复其中数据组的规则。
如果数据源是关系结构,则可以从数据库模式直接抽取映射。因为这些结构由 DBMS 实施,所以无需质疑它们的有效性。
如果数据源不是关系结构,则您需要将元数据与该数据结合起来使用才能获取规范化的数据格式。您特别需要注意“过载”属性。“过载”是将多个事实存储到同一属性的过程。
此概要分析步骤完成后,您可以按规范化的格式执行对数据源完整抽取的采样,以便深入进行数据概要分析过程。通常情况下,该抽取通过迁移组件的抽取脚本执行,因为这也是对这些脚本进行测试的好方法。
数据概要分析的第三步是确定每个属性中数据的内容、域和质量,并确定每个属性后面的语义。对实际源数据执行此操作很重要,因为记录的元数据可能是不正确的。
此操作使您有机会确定以下几点:
-
哪些属性被记录用于某一用途,实际却用于另一用途
-
哪些属性已记录,实际却未使用
-
属性的数据内容与其语义之间有什么不一致
-
数据的什么基数确定固定属性(只包含一个值的属性)
尝试改进性能的结果是旧系统和关系系统通常使用“反向规范化”和数据复制。它们还经常缺少主键和外键支持。这意味着您必须对源表进行分析,确定属性之间的功能依赖关系并找出候选主键和外键。
当属性概要分析结束后,它需要以两种级别进行复审。第一个级别是为了确定是否要迁移该属性。如果属性中不含有用的信息或数据的质量太糟而无法在不损坏目标的情况下迁移,则您可以选择不迁移该属性。第二个级别是为了确定在迁移过程中属性是否需要清理。
如果在概要分析期间发现质量问题,则您需要执行一定的数据清理;除去或修改不正确的、重复的、格式不正确的或不完整的数据。该操作通常称为数据清理。
|