文档介绍：统一数据交换池工程 ETL 工具软件及产品现场支持效劳竞争性谈判
. 四
ProfileStage 白皮书之一
作系统、等等的数据，为了目标数据库，而被编辑分析，以确定他们的关联性。可能得不到数据源的文档，或者可能文档是不正确的。依据一系列涉及源数据的样品来识别数据的特性。
3) 建立一套源数据到目标数据库的映射：设计一个把各种各样的数据源转换成目标的打算。通常，用 ETL 工具或手编码程序来完成这步。
4) 预备数据：源数据被装载到集结地区，被整理、清洁，并转换为目标数据存储所
需的形式。为标准数据和连接纪录，数据质量软件可以部署在这个阶段。
5) 装载数据：数据从这个集结地区移进目标应用区域。这步包括要报告的格式化数据。
第 4 页
这手工方法的主要弱点在于它做了个假定，应用所必需的数据实际上可以从数据源中获得。很多公司在数据综合工程上已经花费了数百万美元，仅仅觉察源数据不支持他们已经为目标数据库建立的模型。由于整个过程由一系列杂乱无章的、通常由程序员独立小组手工完成的步骤组成，而每步之间的不连续性经常导致灾难发生。
公司通常在第 3 和第 4 步上花费他们的工程预算的 80%。令人圆满的是，具体说明一套源数据到目标数据的映射的实际构造，仅是集成多个数据源整体任务的一小部
第 5 页
中国建立银行统一数据交换池工程-产品白皮书
份。实际工作是决策的智能过程：
在源数据里确实存有什么？
数据是怎样组织的？
数据如何恰当的在目标数据库规划中表示？
我们能怎样将这些源数据和目标数据对应起来？
通常，几乎不了解源数据的性质，步骤 2 的成功可能很小，并且也阻碍了随后步骤的成功。
大多数超出预算或完全失败的数据综合工程是由于缺乏对元数据的理解。假设没有自动化元数据逆向工程工具，开发者要亲自调查源数据。旧系统元数据的文档通常是很不完全的或者根本就不存在。
通常能解释数据的人员已经离开公司。对数据仅使用偶然的推想而不是内容完整的分析。这导致在开发周期中，综合源数据往往被错误地修改调整进入目标数据存储。元数据里的错误不是在设计阶段被觉察而是反映在产品系统中。
正如史蒂夫 McConnell 所指出的, ... 假设一个瑕疵在早期〔在需求或设计期间〕未被觉察，在后期，那么需花费 10 到 100 倍的时间去订正。 (1) 在数据综合状况下, 对试图未真实了解源数据的性质就开头手工建立目标数据库处理数据的企业来说，这将产生重大的经济损失。难怪在 W .H. Inmon 的书里论述数据仓库时说, 一般地，估量建立数据仓库的 80%的工作是任务的提取、转换和装载。 (2) 确实, 花在数据综合上的 50%的时间是设法了解源数据。 (3) 缺乏能在早期查出 ETL 处理过程中存在的问题的工具，就要花费企业数据仓库预算中的大局部资金。
第 5 页
3. 手工处理的危急
只要数据综合进程由很多独立步骤组成，这些工程的故障率和费用将保持一个高水平。数据定义与数据可能不相配，数据可能是无效的，源数据文档可能确实不存
第 6 页
中国建立银行统一数据交换池工程-产品白皮书
在，而且当设法把全部步骤集成到一个高效的实践中时，问题经常消灭。
每当在某些源数据中有致命错误，一系列步骤必需被重复执行，这即费力又费钱。假设没有使用 Ascential ProfileStage，数据综合工程有很多缺陷要抑制，这是昂贵的并且能导致整个工程失败。缺乏能觉察潜在的集成问题并且能给出实际数据的准确说明的数据描述软件，经常导致企业花费他们工程预算中不必要的规模可观的资金，而 Ascential ProfileStage 可避开该问题。例如：
元数据与实际数据不匹配。通过多种方法，数据已经与正确的元数据之间存在差异。因此，数据的描述是错误的，但直到工程结尾的测试/调试阶段才觉察这错误，它是在规格设计时就觉察问题所需费用的 10 到 100 倍。
现有的数据经常无效。例如，在新系统里日期域可能包含无效日期，譬如在 MMDDYY 和 YY YYMMDD 之间的差异。
源数据的文档不存在或者不准确。
开发应用软件生成源数据的那些程序员已经离开公司。
保