DW2.0是随着信息系统架构逐步发展而产生的，它来源于很多公司信息系统架构的实际经验。
在实际构建DW2.0时，尽管有着架构的蓝图，但是DW2.0的不同部件也是要逐步建立起来，即它的不同部件产生的时间是不一样的。
通常DW2.0中第一个构建的部件是整合区（或者实现整合区的前几次少量的迭代过程）。整合区建立好后建立交互区。交互区之后是近线区，接着是归档区。这些不同部件的构建顺序和数据产生的生命周期的顺序是相同的。
DW2.0的另一个构建顺序是先建立ODS再建立数据仓库。即先建立交互区，接着建立整合区，然后是近线区和归档区。
这两种构建数据仓库的步骤的区别是前一种可以更快的看到效果。先建立交互区需要完整的建立好整个交互区，这通常是件很有挑战性的工作。但是先建立整合区，或者实现整合区的前几次少量的迭代过程，相对来说可以很快的得到切实可接受的结果。
所以，前一种构建DW2.0的过程是一种推荐的构建过程。
有时，企业在构建数据仓库时从简单的构建一个整体的数据仓库开始，即不区分各个区。这时，也就不会按照特定的顺序来构建数据仓库的各个部件。
这样构建的数据仓库，通常建立的是“单一通用”（one size fits all）的架构，也就是简单的构建一个数据仓库区满足各种需求。只要数据不是特别多，只要使用系统的用户不是特别多，只要系统提供的使用类别不是特别多，这种架构也能工作的很好。
但事实上的情况是，数据的容量很快就会增长的很大，使用的用户数目也很快就增长的很大。这样，数据仓库应付起来就会很困难，企业就开始优化数据仓库，会购买更好的硬件设备。
但是，随着企业的发展，数据量的增大，这些并不能解决数据仓库的性能问题。这时，能够做的就是将某些特定的操作处理从这种单一的数据仓库架构中分离出去。最容易分离出去的操作处理是那些需要高性能的访问数据的操作。
当数据必须非常及时的进入数据仓库时，例如只有2-3秒的反映时间时，将这部分分离出去是个最佳的选择，也就是将DW2.0中的交互区和整合区分离。
这样数据仓库的构建顺序也就逐步的靠近前边推荐的构建过程上。
另一种构建数据仓库的步骤是先建立数据集市。
企业可能会更倾向与首先建立数据集市，建立数据集市相对建立数据仓库来说也是一件容易一些的事情。数据集市看起来比较小一些，比较容易把握。尤其是数据集市提供商会鼓励你这样做，他们会把握每一次机会去诋毁数据仓库。
所以第一个数据集市就建立好了，满足了需求，看上去也很成功。
紧接着第二个数据集市也建立了。从建立了第二个数据集市开始，有人指出在不同的数据集市种数据出现了冗余，出现了数据不一致的情况。但是没有人关心这些。接着又一个数据集市建立了。随着数据集市的逐步建立，企业内出现更多的冗余数据。不同的数据集市对数据的准确性和有效性提出的不同的观点。第四个数据集市建立起来后，企业内有四个地方的数据出现不一致。而且源系统需要对多个数据集市提供数据，对外接口也不堪重负了。
总结来说，相对建立数据仓库方式，直接建立数据集市给企业带来的更多的是混乱和数据不一致。最终，企业一定会发现他们需要的是一个完整一致的数据仓库，而不是一堆混乱的数据集市。
建立统一的数据仓库只需要有限的数据抽取，并且数据在数据仓库种是整合的，不是冗余的。数据仓库中会保存历史数据。在数据仓库之上，企业可以建立数据集市，数据从数据仓库抽取到数据集市。这样，数据的来源是一致性的，不会出现问题。当新的分析需求来到时，原子粒度的、整合的、历史的数据已经在数据仓库中准备好的，建立一个新的数据集市是件很容易的事情。
建立DW2.0的最好的步骤是先有一个好的架构方案，然后在保证一致性的情况下逐步建立。即使一个企业不想按照DW2.0的方案来架构数据仓库，下面要讨论的架构步骤对建立数据仓库也是至关重要的。下面将对建立数据仓库中各个关键步骤和主要问题进行单独详细的讨论。
DW2.0 and Volumes of Data
DW2.0和数据量
DW2.0中的数据量会逐步的增长，在很短的时间内，数据量会飞快的增长到很大的容量。例如，典型的增长模式为，6个月数据增长50gb，1年增长450gb，2年增长1tb，3年增长10tb，4年增长50tb。
那么为什么数据量的增长会成为一个问题呢？第一个原因是成本。不光是数据本身的保存需要成本，支持这么大量数据的基础结构也需要昂贵的成本。而且获得这些数据需要成本，支持对这些数据的操作也需要成本。
但是成本并不是数据量成为问题的唯一原因。随着数据量的增加，数据仓库维持正常运转的基本功能也会出现问题。
-加载少量的数据并不困难，但是加载超大量的数据是个较难应付的问题。
-访问少量的数据，给少量的数据建立索引性能都不会出现问题，但是访问超大量的数据和给超大量的数据建立索引会给性能带来较大的问题。
-面对少量数据，将它从一种格式转换成另一种格式很容易完成，但是面对超大量的数据，将它从一种格式转换成另一种格式较难完成。
正式由于这些原因，获取和管理超大量的数据不是件轻松的事情。
另一个有趣的问题是，为什么DW2.0中会积累这么多的数据？
答案很简单，DW2.0中保留了原子粒度的数据，保留了大量的历史数据，而且DW2.0需要从各式各样的数据源抽取数据。用公式来表示如下所示，
细节数据×历史×各种类型＝大量的数据
The Processing Workload
数据处理的负载量
在DW2.0的处理数据过程中另一个比较突出的因素是数据处理的负载量。有两种不同的数据处理负载量，分别是对大数据量的处理操作和对小数据量的处理操作。大数据量的处理操作通常需要访问大量的数据，或者在数据访问时需要对数据进行大量内部处理操作。小数据量的处理操作通常只访问少量的数据，而且不对需要访问的数据进行复杂的处理。
理解了大数据量处理操作和小数据量处理操作的区别，我们就可以分清在DW2.0中的不同区中，数据处理的类型和负载量是不同的。
交互区中通常只有小数据量的处理操作。在交互区的数据处理操作达到顶峰的时间段内，小数据量处理的操作个数会变得很大。但是在任何情况下，交互区中都不应该有大数据量的处理操作。
整合区中数据处理的类型是混合的，既有小数据量的处理操作，也有大数据量的处理操作。在整合区中，小数据量的处理操作和大数据量的处理操作是随机出现的。很难预测到什么时候整合区中的数据处理操作会达到顶峰状态。
近线区中只有大数据量的处理操作。而且，这些大数据量的处理操作是随机出现的，出现的几率也很小。近线区中的数据处理操作随机性也很强。
归档区中的数据处理操作和近线区很相似，区别是在归档区中数据处理操作出现的几率更小。
数据仓库中的不同区应该分开建立，各自拥有独立的处理器。
如果数据仓库中的不同区安置在同一台机器上，那么不同区的操作处理会排列在一个队列中。这时，所有的操作处理，不管是大数据量的处理操作还是小数据量的处理操作都将混合在一起。
为了能更好的理解将大数据量的处理操作和小数据量的处理操作混合在一起会出现什么样的后果，我们来做一个对比。假设小数据量的处理操作是保时捷跑车；大数据量的处理操作就是大卡车；那种超大型的数据处理操作，例如统计分析处理或者将大量数据迁移入归档区时的数据处理，就是装满货物的非常长的火车。
现在有了三种不同的交通工具，分别是保时捷、大卡车和火车。
我们来考虑一下交互区，当交互区有自己的处理器时，就好比有了只允许保时捷使用的超级高速公路。通常来说，在这种高速公路上速度是非常快的。唯一需要担心的事情是，高速公路上有太多的保时捷。
当整合区有自己的处理器时，就好比有了只允许保时捷和大卡车使用的高速公路。有时，保时捷可以开得非常快。但是，如果高速公路上有太多的大卡车，那么保时捷的速度也就上不去了。
现在我们来考虑一下所有类型的交通工具都出现在同一条公路上的情形。当我们在DW2.0中将所有的区都建立在一个处理器或者一组处理器上时就和这种情形非常相似。
如果所有的交通工具，火车、大卡车、保时捷和其他交通工具，都出现在同一条公路上，我们面临的问题是该如何去优化这条公路的交通速度。这种非常大，非常复杂的交通流量，在现实中是很难管理的。换句话说，在这样的情形下，想得到好的交通速度是不可能的。类似的，使用一个处理器去处理所有的这些处理操作也几乎是不可能的。
如果我们问保时捷能跑多快，也许你会回答150英里每小时。
但是下一个问题是保时捷在墨西哥城交通高峰时的街道上能跑多快？答案也很简单，在墨西哥城交通高峰时的街道上保时捷和它前面的大卡车跑的一样快。
类推一下，DW2.0中的不同的区应该使用不同的处理器或者处理器组，来保证各个区中的效率。
而且，当不同区分别使用自己的处理器后，整体的硬件价格是下降的。因为，越大的硬件，越强的处理器的价格越昂贵。当大的硬件，大的处理器换成更多的功能相对较弱的硬件时，整体价格会下降。
举例来说，假设我们需要的是10,000个单位的处理器容量。能满足要求的单个的处理器或者复杂的并行处理器组的价格大概在10,000,000美元。如果我们把这10,000个单位的处理器容量需求拆分成三个处理器，A、B和C。A处理器的单位容量为3000，B处理器的单位容量为5000，C处理器的单位容量为2000。A处理器的价格为1,500,000美元，B处理器的价格为4,000,000美元，C处理器的价格为500,000美元。拆分后的总价格为6,000,000美元。
这样的选择在企业中每天都会发生。
Statistical Processing
统计处理
在前面的例子中，我们将统计处理操作比作火车，而把其他处理操作比作保时捷和大卡车。
当统计处理发生时，会和其他处理发生冲突。就好像一辆火车穿过一个城市一样，其他的任何车都得停下来等待火车走过。
统计处理的负载量比较大，主要有以下几个原因：
-统计处理需要访问的数据量非常大。
-统计处理时，为了保证整个统计分析过程中数据的一致性，经常会将需要访问的数据锁定，所以统计处理没有完成时，其他的处理不能访问这些数据。
-统计处理访问数据非常密集，即整个统计处理内数据访问之间的间隔非常小，所以整个统计处理过程中，系统资源基本都被统计处理占用了。
正是因为统计处理的这些特性，导致它像火车一样，而不是大卡车和保时捷。
Data Integrity Across DW2.0
DW2.0的数据完整性
交互区和整合区中对数据的完整性的要求是不一样的，这种差别来自于架构自身，我们需要认清这个问题。
交互区中的数据只有在访问的时刻是准确的，而整合区的数据与访问的时刻无关，也就是说，无论何时访问整合区中的数据都是准确的。例如，交互区中的两个同样的查询，一个是上午10:13，另一个是下午2:26。这两个时点的查询结果很可能是不一样的，因为在这两次查询之间数据可能被更新了。如果在中午时新的信息来到交互区，那么下午的查询结果和上午的查询结果就会不相同。
而整合区的情况与交互区就有很大的差别。整合区中的数据是不更新的，上午9:35的查询和下午4:13的查询结果一定是相同的。不同的时点查询得到的结果相同，是因为整合区加载数据采用的是快照方式存储。
交互区中的数据是受变化影响的，整合区的数据是不受变化影响的。而这种特色正式DW2.0架构的一个基本原则。
当数据不在需要更新或者变化时，可以将它从交互区迁移到整合区。
这种架构方式有几个有趣的特点。其中的一个就是数据并不是很快的进入整合区的，相反，只要数据还趋向于变化，受更新的影响，那它就应该留在交互区。
举例来说，我们考虑交互区中的三类数据，第一类是客户交给电话公司用来付帐的支票，第二类是电话公司每个月的月结余数据，第三类是电话公司的当前数值。这三类数据进入交互区后，我们对它们的处理方法是不同的。
对于第一类数据，电话公司收到的付帐支票。支票收到后数据就会进入交互区。由于这种支票数据不会发生变化，数据可以立刻从交互区进入整合区。
对于第二类数据，电话公司每月发给客户的月结余帐单信息。即使电话公司尽力去保证这个结余帐单的准确性，但是它还是会偶尔发生错误。因此电话公司通常都会等30天，这30天内客户用来确认。这样就有了30天的结算期。过了30天的结算期，数据可以安全的从交互区迁移到整合区。
对于第三类数据，客户的当前帐单信息。由于客户在整个月里都在使用电话服务，每使用一次服务，就会有一次帐单数据，这部分数据可以尽快的以快照的方式进入整合区。而客户这一个月的结余数据要等到月末的时候，才能进入整合区。
对于那些还需要不断更新的数据，让它们直接进入整合区是一种错误的选择。这种还可能会被更新的数据进入整合区后，会降低整合区中数据的稳定性，也会降低整合区的效率。
正确的策略是数据不能尽快的进入整合区，在数据进入整合区前需要给数据留出一定的稳定期，等待数据过了更新时限。
这就意味着，在某些情况下，交互区的数据需要保留相当长的一段时间。交互区的数据进入整合区的时间间隔可能从几秒到几个月。而这段时间间隔在DW2.0中是必要的。
（DW2.0的交互区就相当与Inmon的CIF架构中的ODS，建立的方式和处理数据的策略都基本相同。）
Capacity Planning And DW2.0
DW2.0和数据容量规划
由于DW2.0中需要保存大量的数据，为了能更好的管理这些大量的数据，做一些数据容量的规划是很有必要的。
但是，很多时候有很多与数据容量规划相关的因素是我们无法确定的。这些典型的不能确定的因素如下所示：
-五年后会有多少使用者。
-十年后会有多大的数据量。
-三年后会有什么数据需要添加进来，会出现那些需求需要那些数据。
-五年后会有什么样的竞争出现，需要什么样的数据。
事实上做未来的数据容量规划更是一种艺术，而不是科学。
一种非常简单也非常有效率的数据容量规划的方法是去询问比较友好的供应商，从他们那里了解其他公司数据仓库的实际情况。也就是以实际的经验做类比来预估未来的数据容量规划。
这种类比的方法也有很多问题，如
-这个消息是否是比较敏感的事情，如果是，就不能使用。
-这个信息是否是从直接的竞争对手出得到的，如果是，就不能使用。
-两个企业的业务是否有可比性。
-这个用来类比的企业的数据仓库建立了多久。
-这个用来类比的企业建立的数据仓库是采用的DW2.0的架构还是比较老一点的架构方式。
尽管类比的方式有这么多的缺点，但是这种方式还是一个容易实现而且相对准确的方法。
Trading Up - Machine Capacity
机器容量
解决容量问题的一个最明显有效的补救方式是增加服务器的处理器。
很多企业的数据仓库开始时较小，使用较少的磁盘和一个处理器就可以满足要求。但是很快存储空间不够，需要添加新的磁盘。接着需要更多的磁盘，而且随着磁盘的增加，处理器开始需要升级。
数据还在不断的增加。下一步就会添加更多的磁盘和多处理器（multiplexed processors）。当多处理器也不能满足时，就需要升级到大型多处理器，最终升级到并行处理架构（parallel processing）。
这个进化过程是一个很典型的过程，大部分企业都是这么过来的。
一个有趣的问题是，并行处理架构之后该采用什么样的技术手段？
并行处理架构是目前唯一在理论上没有上限的技术。至少我们可以在理论上认为采用并行处理器能够一直使用下去。在实际中，并行处理架构也只有经济上的上限，而不是技术上的上限。
返回来看数据容量问题，将大量数据迁移到近线存储和归档存储是可以减小大量的数据需求的，也是应该推荐使用的方法。很多企业使用大型的并行处理架构，而不考虑数据是否被使用以及使用频率。这样的企业的数据仓库实际能使用的在线数据反而更少。
An Element of Time
时间元素
从设计的观点来看，DW2.0中的所有记录都应该有一个时间元素。
在记录中保存时间元素的最通常的方法是使用时间戳。建立时间戳后，每一条记录都会有单独的时间元素和自己关联。
当然，还有一些其他的方法也能保存时间元素。例如可以在一个表的级别上建立时间戳，具体一点，如2005年4月的业务表。
还有一些情况下，时间元素是间接出现的。如DW2.0中的不同区保存的数据的历史时间是不同的。交互区中保存的是当前数据。整合区中保存的是次当前数据。近线区中保存的是历史数据。归档区中保存的是更久远的历史数据。
从数据库设计的角度讲，数据上的时间元素有两种保存方式，分别是
-离散时间点。
-连续时间段。
离散时间点的保存方法是通过快照的方式保存的。例如，每个月末的快照。很多变量都是在这个时间点度量的。这个时间点度量的数据既不能说明进行快照保存以后数据可能会发生什么变化，也不能说明进行快照保存以前数据曾有过什么变化。数据表明的仅仅是这一个时间点的状态。这种方式对那些经常变化的变量非常适用。
连续时间段的保存方式是以连续的方式来描述数据。它使用一个起始时间和一个终止时间来描述一个在一段时间内不会变化的变量。这种数据保存方式比较适合那些不经常变化的变量，或者用来保存少数的几个变量，不适合对很多变量的保存。
交互区中的数据不需要考虑这种时间特性，因为交互区的数据是访问时刻准确的，也就是说保存的是当前值。正因为交互区中数据的时间元素都是当前的，所以交互区的数据不需要增加时间元素。
在数据中增加时间元素是DW2.0的一个自然的特点，正因为如此，在DW2.0中的整合区、近线区和归档区的各处都保存着快照数据。
Snapshots
快照
快照记录在DW2.0中是很常见的记录形式。快照记录通常是被一个事件触发而生成的。
当快照被触发时，数据被捕获并和相应的时间字段组合成一条记录保存在数据库中。
触发生成快照记录的方式很多，最常见的就是固定时间触发。也就是说一定的时间过去后，记录被创建。固定的时间可以是月末、周末或者一天结束时等等。时间间隔的长短完全由数据的特性决定。有些情况一天一条记录会生成太多的数据，有些情况一个月一条记录会错过重要的数据波动。因此，触发生成记录的频率需要由数据的特性决定。
触发生成快照的另一种方式是事件的发生。例如有一次销售事件就可以创建一条销售快照。
销售事件的产生是不规则的，所以不能通过周期的方式创建销售快照。这时，快照的创建依赖于事件的发生。
触发快照的另一类事件是数据缓慢的变化或者不经常的变化。例如，Mary Foster在2002年6月16日结婚，在这一事件点，可以创建一条新的记录来将Mary Foster修改为Mary Shoemaker。
时间元素在DW2.0中是非常重要的元素。时间元素在数据仓库中有两种保存方式，分别是离散时间点和连续时间段。离散时间点记录只有一个发生时间字段，连续时间段记录有起始时间和终止时间两个时间字段。时间字段通常是键结构中的一部分。通常DW2.0中的键结构都是复合结构，而时间字段是复合键结构的一部分。
注意，DW2.0中的记录不必须是唯一标识的。在DW2.0中有可能有两条或者更多条记录的标识是一样的。
（最后这一条，不知Inmon怎么去建立表和保存数据，没有主键的表维护起来还是比较困难的。）
DW2.0 Records
DW2.0的记录
DW2.0中的数据记录有一种标准的格式，包括四部分，分别是键、时间元素、直接相关数据和间接相关数据。
下面用人员作为例子来解释一下记录的四部分。人员的键是社会保障号，时间元素是2001年1月1日。直接相关数据包括名字、职务和出生日期等内容。间接相关数据包括电话号码、宠物的名字和车牌号等内容。
记录的另一个特点是记录分为离散记录和连续记录，这种特点是由记录的产生方式决定的。
离散时间变量通常是有固定的产生周期的，如按月产生。离散变量的产生也有可能是没有规律的，如销售事件的发生。这种离散变量的度量方式适合内容变化比较快的变量。
下面我们举一个有很多离散变量都快速变化的例子，道琼斯工业指数。当有股票被销售时，道琼斯工业指数就会发生变化。这就意味着道琼斯工业指数每天会变化几百万次。这种变化太多了，如果都记录下来是不现实的。现实中，道琼斯工业指数是在一天交易结束时被记录下来。也就是说，一个针对股票的离散快照在一个交易日结束时被记录下来了。
这个交易日末的快照记录并不能说明道琼斯工业指数在中午时的情况。而在两个离散快照之间，这种度量值可能会有很大、很复杂的波动。
离散度量是相对与连续度量来说的，而连续度量的基本方式是具有起始日期和截至日期的记录。连续度量方式的记录通常都是变化较少的记录。
连续度量都有一个时间跨度，在这个时间跨度内所有的变量都有一个固定的值。如果任何一个变量发生了变化，那么需要生成一条新的记录。当一条新的记录生成后，它的内容就和前一条记录在时间上连接起来了。
采用连续度量方式的记录，前后记录需要能在时间上连接好，不能有断档出来。后一条记录和前一条记录的日期相差只能是一个单位，例如，如果前一条记录结束与7月20日，那么后一条记录的开始日期一定是7月21日。
要注意到，记录不一定是按天来度量的。它有可能是按月、按年，也可能是按小时、按分钟、按秒来度量的。而按天来度量是最为常见的一种方式。具体的度量单位需要根据需要度量的数据来决定。
需要说明的是，连续度量方式有时候也会出现不连续的情况。以一个士兵的服役期举例来说，士兵开始服兵役，系统生成记录。士兵离开部队，六个月后又决定延长服役时间，那么这个士兵的服役记录中间就会又六个月的断档。
这种中间出现断档的情况是一种正常的情况，但是不同的记录的时间如果出现交叉现象则一定是错误的。
Slowly Changing Dimensions
缓慢变化维
数据的变化有两种方式。一种方式是数据的语义变化，另一种方式是数据的内容变化。
数据语义变化的意思是，数据的定义发生了变化。例如，数据字段的长度由6个字节变成7个字节，数据的含义由收入变成月收入，或者需要添加新的属性（ATTR_1）字段等情况。
语义变化是数据的定义或者基本特征发生变化，这种变化总是存在的。
数据内容变化比较常见，指字段的保存值发生变化。例如，数据值由32变为56。数据内容的变化也是很常见的。
（Inmon也讲缓慢变化维，看来3NF建模领域里英文不好找到一个词来表示这种情况。）
Handling Semantic Change
处理语义变化
在DW2.0架构中有两种处理语义变化的方法。
第一种方法是建立两张表，将两种定义分开。一张表保存语义变化前的数据，另一张表保存语义变化后的数据。这样处理查询要麻烦一些，需要访问两张表。
另一种方法是将所有的旧数据都转换成变化后的数据，保留一致性定义的数据。
这两种处理语义变化的方法都有缺点。
第二种方法中，根据新的数据定义建立一个新的表，这个表保存新的数据，也保存将旧数据转化后的数据，原表保留。这种方法相对来说更好一点，但是也需要相应的系统应用程序进行修改，以适用数据定义的变化。
Handling Content Change
处理内容变化
处理数据内容的变化也有两种方法可以采用。
第一种方法是当数据内容发生变化时，使用新的数据覆盖旧的数据。这种方法在交互区比较受推荐。
另一种方法是当数据内容发生变化时，使用快照记录新的数据，而旧记录不变。
（处理数据内容变化，Kimball的缓慢变化维策略更完善一些，也更灵活一些，但是那些策略需要采用维度建模方法才能使用。而Inmon的数据仓库是3NF建模的，采用的是快照方式。快照方式处理缓慢变化维，有个很大的缺点是访问起来很麻烦，尤其是表结构比较复杂时。所以Inmon一般不建议直接访问数据仓库，而建议在数据仓库之上建立数据集市，探索仓库等，使数据访问变得容易一些。）
Making Data Corrections
修正数据错误
下面讨论当数据仓库中出现错误数据时该如何处理。
数据仓库中的错误数据的危害很大，容易导致信任危机。当用户访问到数据仓库中的错误数据时，他们很可能会怀疑其他数据的正确性。因此，数据仓库的开发要保证数据仓库中数据的准确性，而且要尽可能的保证数据为最新的。
由于数据仓库的数据来源太广，所以难保会有一些错误数据进入数据仓库。这时，就需要对这些错误数据进行处理。
对错误数据进行处理的第一步是评估错误量有多大。即首先需要了解是一条记录出现错误还是10000条记录出现错误。这对数据仓库管理员找到错误数据的来源是非常重要的。数据仓库管理员需要了解源系统中是只有一点数据错误还是大量数据错误。
如果只有一两条记录出现错误，数据仓库管理员会找到这些错误，进行一下单独处理。但是，如果错误数据记录的数量很大，数据仓库管理员就需要考虑是否应该更换数据源了。
回到在DW2.0的环境中，有一个问题是我们是否可以让错误数据直接被覆盖掉呢？
如果可以直接覆盖的话，那就意味着在数据仓库中可以进行更新操作了。当数据仓库中运行更新操作时，数据完整性在一定的程度上受到了破坏。例如，如果发现在数据仓库中的某个数值是100，但是正确的数值应该是150。直接将100更新成150的话，那么与该值相关的任何分析、报表都会被更新为150，以前的分析就不能重现了。
这种情况在有些时候可能不算问题，但是有些时候可能会是大问题。由于这个关于数据完整性的两难的选择，数据仓库管理员需要小心的处理这种错误数据情况。
管理员能采用的第一种方法就是上面提到的覆盖方式，即找到错误数据，使用正确的将其覆盖掉。
第二种方法是将错误数据保留在数据仓库中，同时插入一条“冲销记录”（balancing entry）将错误修改掉。
以上面的例子来说，错误值100仍保留在数据仓库中，同时插入一条新的记录，记录时间是错误发现日期，记录数值是50。这种数据仓库中的净值就正确了。
第三种方法是针对特殊的情况。有时错误的记录太多，实际的数值也无法得到。一般来说正确的数值都能得到，但是偶尔会出现实际数值无法得到的情况。这时，只能将数值更新或者冲销成一个假定的正确值。
本日志来自：http://www.chinabi.net/blog/user1/lastwood/cmd.html?do=blogs&id=142&uid=631
