数据仓库的基本观念之一是,当数据从业务系统或其他数据来源提取出来时,应该先经过
变换或清洗,才能将它加载到数据仓库中。然而,对于数据转移的目的和实现转移的最优方法
却存在很多混乱的看法。在数据仓库环境中进行数据转移的目的应该有两个:第一,改进数据
仓库中数据的质量;第二,提高数据仓库中数据的可用性。
所谓数据转移,也称为数据转换或数据变换,就是把多种传统资源或外部资源信息中不完
善的数据自动转换为商务中准确可靠的数据。为了便于讨论,我们将把业务数据加载到数据仓
库之前经历的内存和结构的变化都纳入数据转移。
在建立数据仓库的过程中,数据转移是个重要的步骤。实施数据转移的好方法有很多,既
有定制代码的程序,也有用于转移仓库数据的专门工具。无论采用什么方法,转移的几个基本
方面是必须实现的。转移远远不止是在你把数据移入数据仓库时改变它的数据结构,真正好的
转移在数据进入数据仓库时能够检验并提高它的质量和可用性。
为了对数据转移的复杂性进行深入的讨论,我们必须定义数据转移的几个基本类型。每一
类都有自己的特点和表现形式。为了便于讨论,应该考虑以下四种转移类型:
(1)简单转移。简单转移是所有数据转移的基本构成单元。这一类中包括的数据处理一次
只针对一个字段,而不考虑相关字段的值。
(2)清洗。清洗的目的是保证前后一致地格式化和使用某一字段或相关的字段群。例如,
它可以包括地址信息的适当格式化。清洗还能检查某一特定字段的有效值,通常是通过进行范
围检查或是从枚举清单中做出选择。
(3)集成。集成是指将业务数据从一个或几个来源中取出,并逐字段地将数据映射到数据
仓库的新数据结构上。
(4)聚集和概括。聚集和概括是把业务环境中找到的零星数据压缩成仓库环境中的较少数
据块。有时对细节数据进行聚集是为了避免仓库存入业务环境中那样具体的数据,有时则是为
了建立包括仓库的聚集副本或概括副本的数据商场’
顾名思义,简单转移代表了数据转移中最简单的形式。这些转移一次改变一个数据属性而
不考虑该属性的背景或与它相关的其他信息。简单转移有如下形式:
(1)数据类型转换。最常见的简单变换是转换一个数据元的类型。除了将一个空值改为空
白或零之外(或反之),通常不必改变该数据元的语义值就可以完成一次简单的数据类型转换。
当应用程序存储的某个类型的数据只在该应用程序的背景下才有意义,在企业水平上却没有意义时,就常常要求进行这类变换。这类转换可以通过编码程序中的简单程序完成,或者运用数
据仓库数据转换工具完成。所有转换工具都能轻松、迅速完成这类简单转换。另外,许多简单
变换可以通过数据库卸载或加载设施完成,这种设施可以在从平面文件中取出数据并加载到数
据库中时进行简单数据类型转换。
<2)日期/时间格式的转换。一般而言,在设计和构造业务应用程序时,对各程序内日期/时间很
少进行统一的处理。应用程序设计人员常常选择用最适合的包含业务数据的数据库管理系统的
格式表示日期和时间。在某些情况下,甚至在同一应用程序内口期和时间的处理也不一致。程
序模块的设计者按照他们认为合适的方式随意设计口期和时间字段,很少考虑到一致性。在处
理业务系统中时间和日期的格式差异的背后,无论有什么原因,有一件事是清楚的:数据仓库
必须用单一的模式识别日期和时间信息。正如2000年问题所显示的,我们必须用稳健的方式
存入日期,包括完整的年份。选择日期和时间的实际物理表示法取决于许多因素,但无论选择
了哪种表示方式,它都应该存入年份的四个数字,必须在整个数据仓库中一致地使用它。
(3)字段解码。最后一类简单变换是编码字段的解码。简单地说,数据一般不应该以编码
的格式存放在数据仓库中。我们在业务数据库中建立代码是为了节省数据库存储空间。虽然人
不理解这些代码,但这并不是个大问题,因为我们与那些代码的交互作用是由应用程序管理的,
这些程序在必要的时候会为我们破解那些值的代码。在数据仓库环境中,情况就大不一样了。
因为有些查询工具能破解数据库值,所以无法保证应用程序逻辑一定能将用户与数据仓库数据
库中的编码值隔绝开。考虑到杳询工具的不断增加以及大多数数据仓库的用户自己编写的查询
时,情况确实如此。当他们编写或运行特别查询,用户将看到的信息就像存储在数据库中一样。
因为用户可能来自公司的任何部门,所以数据仓库的所有用户不可能都有足够的背景知识和培
训,使他们能够理解在业务数据库中使用的编码值。因此,业务系统和外部数据中的编码值在
存入数据仓库之前,应该转换为经过解码的、易于理解的相应值。当然,这样做必须遵循正确
的路线。一方面,我们想把编码值充分扩展,使它们为大多数的用户理解;另一方面,把一个
值扩展得太多要占用额外的存储空间,而且把该值当作查询中的检索标准也很困难。还必须考
虑到用户对于数据元业务含义的熟悉程度。从技术角度看,字段解码是一个非常易于实现的过
程。它可以很容易地结合到转移程序中去,也可以在数据转移工具中轻松地完成。然而,确定
应该进行多少解码工作是很难的。
清洗指的是比简单变换更复杂的一种数据转移。在这种转移中,要检查的是字段或字段组
的实际内容而不仅是存储格式。
一种清洗是检查数据字段中的有效值。这可以通过范围检验、枚举清单和相关检验来完成。
这里给出了每种方法的例子。
范围检验是数据清洗的最简单形式。它是指检验一个字段中的数据以保证它落在预期范围
之内,通常是数字范围或日期范围。例如,可以检验一个发票编号,看它是否是有效的发票编
号,即编号是否介于1000和99999之间;或者可以检验发票日期,看它是否落在2005年4月
1日(公司开业之日)和当前日期之间,任何日期在该范围之外的发票都应该剔除出去。
枚举清单也相对容易实现。这种方法是对照数据字段可接受值的清单检验该字段的值。例如,可以检验一下送货类型代码,看看它是否包括有效值“快递"或“普通"之中的一个,任
何与这张清单不符的值将被剔除出去以待进一步调查。
相关检验稍微复杂一些,因为它要求将一个字段中的值与另一个字段中的值进行对比。例
如,我们可以检验发票记录上的采购订货编号字段,看看它是不是我们系统中存在的采购订货。
任何含有采购订货编号却没有相应采购订货的发票记录应该留待进一步调查。
数据清洗的另一主要类型是重新格式化某些类型的数据。这种方法适用于可以用许多不同
方式存储在不同数据来源中的信息,必须在数据仓库中把这类信息转换成一种统一的表示方
式。最需要格式化的信息之一是地址信息。由于没有一种获取地址的标准方式,所以同一个地
址可以用许多不同方式表示出来。当然,当人读这些地址时,他们能认出它们指的是同一地点。
但在数据仓库中,地址可能按不同方式存储起来,那种对应关系就丢失了。因此我们必须把地
址转变成一种共同的格式,这样我们才能在数据仓库中确定哪些地址其实是相同的。
集成是要把从全然不同的数据源中得到的业务数据结合在一起,困难在于将它们集成为一个
紧密结合的数据模型。这是因为数据必须从多个数据源中提取出来,并结合成为一个新的实体。
这些数据来源往往遵守的不是同一套业务规则,在生成新数据时,必须考虑到这一差异。因为不
可能识别出每种可能发生的集成,所以这里只讨论字段水平的简单映射。
字段水平的简单映射在必须执行的数据转移总量中占去了大部分。在一个典型的数据仓库
里,指定进行的转移中有80%〜90%是字段水平的简单映射。这种映射的定义是指数据中的一
个字段被转移到目标数据字段中的过程,例如从一个业务数据库中得到的一条记录,把它的一
个字段转移到数据仓库的数据结构中。在此过程中,这个字段可以利用前面讨论过的任何一种
简单变换进行变换。这些字段水平的映射很容易实现,并且占了数据集成工作的大部分。
大多数数据仓库都要用到数据的某种聚集和概括。这通常有助于将某一实体的实例数目减
少到易于驾驭的水平,也有助于预先计算出广泛应用的统计概括数字,以使每个查询不必计算
它们.虽然聚集和概括往往被当作可以互换的名词来使用,但在数据仓库中,这两个名词的含义
还是有一些差异的。概括是指按照一个或几个业务维将相近的数值加在一起,例如商店把每口的
销售额加在一起,生成按地区计算的月销售额。聚集指将不同业务元素加在一起成为一个公共总
数。但是为了便于讨论,我们不区分聚集和概括,在数据仓库它们是以相同的方式进行的。
有时,数据仓库中存放的具体数据的具体程度往往不如业务系统中存放的细节数据。这时,
就有必要在变换业务数据的过程中加入一些数据聚集功能。这可以减少存储在数据仓库中的行
数。有时,聚集也可以用于建立数据商场,这类数据商场是从仓库中存储的更具体的数据中衍
生出来的。聚集还有一个作用是去除数据仓库中的过时细节。在许多情况下,数据在一定时期
内要以很具体的水平存放着。一旦数据到达某一时限,对这些细节的需求就大大减弱了。此时,
这些非常具体的数据应该传送到存储器中,而数据的概括形式则可以存放在数据仓库当中。
当然,对于各种细节数据,有许多种概括方法,每一种概括或聚集都可以在某一个或几个
维进行。例如,一家零售组织保存着每次单个销售事务的事务处理数据。以这一细节数据为基
础,可以从许多维进行概括。例如产品大类、销售事务类型、地理区域、顾客和时间期限。生
成的每一个总和都是在一个或几个维上进行聚集的结果。这样,用户通过访问元数据,就能够得知每种概括数据的衍生方法,这一点是极为重要的,这样他们才能知道哪些维已经得到了概
括以及概括的程度。
日前可以得到的数据清洗工具,许多都已内置了概括功能,尤其是在时间维上进行聚集的功
能。当然,通过使用分类设施就可以轻松地做到这一点,这类设施中含有复杂的概括逻辑能力。
不管如何做到这一点,重要的是用户能够轻松地访问元数据,了解生成总和数据所用的标准。
在数据仓库环境中,实现数据转移的方法当然不止一种。但最主要的是选择转移方式,是
使用为数据仓库提供数据的专用数据转移工具,还是建立能实现转换逻辑的手工编制程序。哪
一个才是最佳选择要取决于很多因素,包括:
(1)时间范围。虽然使用数据转移工具能大大方便建立和维护数据仓库的过程,但获取、
配置和学习这些工具都要花些时间。如果生产第一个仓库应交付成果的时间约束很紧,那么这
样的项目往往选择人工编码,在仓库建设得较完善、项目小组的可信度较高时再迁移到数据转
移工具中。
(2)预算。数据仓库工具可能会很贵,但编程人员编写变换程序的时间也一样宝贵,因此
最佳选择取决于哪类预算近期在组织中更容易得到。但从长期来看,投资可以比手工编制和维
护变换程序的成本要节省得多。
(3)数据仓库的规模。范围很小的数据仓库(即数据源很少,要实现的转移也很少)可能
无法证实使用数据转移工具的成本合理性。然而,当数据仓库的范围逐渐扩大时,维护手工编
写的变换程序将变得越来越困难,工具就会发挥更大的作用。但对于一个规模很小的初始数据
仓库来说,当然就不需要变换工具了。
(4)数据仓库项目小组的规模和技能。如果仓库小组足够大,而且具有适当的编程技巧,
建立和维护转移逻辑就容易一些。但是大多数数据仓库小组都受到资源的限制,无法得到足够
的开发时间维护所有的变换代码。因此他们发现转移工具特别有用,因为数据仓库分析人员可
以不要编程人员的帮助自己建立并维护大多数的转移。
当然,使用数据转移工具的最主要原因之一与节省时间和有效利用成本没有太大的关系。
这个原因是,好的数据转移工具能自动地生成并维护宝贵的元数据。