DW2.0-下一代数据仓库架构,DW2.0 - The Architecture for the Next Generation of Data Warehouse

DW2.0 - The Architecture for the Next Generation of Data Warehouse

数据仓库始于20世纪80年代中期。在1990年第一本关于数据仓库的图书出现后，数据集市、ODS、DSS应用等与数据仓库相关的概念开始依次出现。

在数据仓库概念出现的同时，技术的进步促进了数据仓库的商业化进程。DBMS处理超大量数据的能力逐步增强。存储数据用的磁盘的价格大幅度下降。新的存储介质如磁带等出现。商业智能供应商的出现。数据仓库在短短的几年内就由理论步入了现实应用中。

然而，随着数据仓库的逐步建立，人们对数据仓库的理解逐步出现了偏差。很多咨询公司正在建立一些不是真正数据仓库的数据仓库。有些供应商在谈论着建立实时数据仓库，而在他们建立的数据仓库方案中根本没有这一部分。一些面向数据仓库技术的研讨会探讨着事实上并不是数据仓库的数据仓库解决方案。从那些人对数据仓库表述的概念中可以看出，他们建立的一种简化而无效的数据仓库形式，而事实上并不能称之为数据仓库。

总结来说，人们对数据仓库的理解正在逐步走向错误。人们正在使用一些过时的数据仓库概念或者与数据仓库很相似但不是真正数据仓库的概念在销售他们的产品和服务，这些人在销售他们产品和服务时不会去考虑他们自己提出的这些概念到底是正确的还是错误的。

在人们对数据仓库具有着混乱的理解的同时，DW2.0诞生了。

本日志来源于Inmon的网站。

附：Inmon的DW2.0好像一个宣战书，至于文中是否有些文字有些偏颇，其实是智者见智的事情。个人觉得，工程上的东西没有绝对的正确和错误，主要是看是否能解决实际问题。有关DW2.0的内容可以参照Inmon的网站。

DW2.0 - the arthitecture of the next generation of data warehousing - 对现代数据仓库进行了简明而又清晰的描述。DW2.0已经被Bill Inmon和Inmon Data Systems注册为商标，未得到允许不能用于商业用途。通过DW2.0，大家可以知道现代的数据仓库到底是什么样子的，不是什么样子的。那些供应商、咨询商未得到Bill Inmon的书面许可是不可以为了自己的目的而去曲解DW2.0的本意。

在过去的二十年中，数据仓库的概念一直在逐步的进化中，而DW2.0是对数据仓库概念最现代的理解和描述。

Bill Inmon的网站包含了DW2.0详细的定义和描述。所有的内部被分为不同的章节。其中的每一个章节都相当于该部分内容的白皮书。在阅读时，大家可以根据自己的需要顺序阅读或者挑选某些章节阅读。

网站中的DW2.0的内容是为非商业目的读者提供的。对于出于商业目的而需要使用DW2.0的人或企业，可以通过交相应的费用得到许可。

如需要DW2.0更详细的信息或者对DW2.0有任何疑问，请联系Carol Renne（303.973.3788），电子邮件为crenne@inmondatasystems.com。

附：这段文字只是照搬过来的，虽然它看起来更像是广告，但广告并不是我的本意，我只是想了解一下数据仓库领域的新动态。

DW2.0的章节目录如下：

简介 - 对现代数据仓库的一个整体描述。

中心数据仓库的区域划分相关章节：

1．交互区（Interactive Sector） - 数据仓库中对性能要求较高的处理所在的区域，是DW2.0中心数据仓库的一部分。

2．整合区（Integrated Sector） - 数据仓库中整合数据的区域，是DW2.0中心数据仓库的一部分。

3．近线区（Near Line Sector） - 数据仓库中访问频率较低的数据的保存区域，是DW2.0中心数据仓库的一部分。

4．归档区（Archival Sector） - 数据仓库中访问频率非常低的数据的保存区域，是DW2.0中心数据仓库的一部分。

开发相关章节：

5．DW2.0中的System of Record - DW2.0中维护数据完整性和可信性的数据。

6．建立DW2.0 - 建立DW2.0的相关技术和方案。

7．DW2.0建立方法学 - 关于螺旋式开发方法学的讨论。

8．模型 - 在开发过程中，业务模型和数据模型的角色及作用。

9．从时间价值来考虑数据 - 考虑到时间的因素，数据应该被如何构建。

DW2.0内容相关章节：

10．DW2.0 - DW2.0内容的定义。

11．DW2.0的联通性 - 描述DW2.0中各部分是如何联系在一起的。

12．非结构化数据 - 描述DW2.0中的非结构化数据。

其他组件相关章节：

13．虚拟操作数据存储（VODS） - 虚拟操作数据存储（The virtual operational data store）相关内容。

14．探索仓库（Exploration Warehouse） - 为执行大量统计程序方便而建立的一个区域。

15．ETL - 描述操作数据整合到数据仓库的过程。

16．数据集市（Data Marts） - 从多维的角度分析数据的一个区域。

17．粒度管理器（Granularity Manager） - 描述当数据的粒度太低时应该作些什么处理。

18．元数据（Metadata） - DW2.0中本地元数据和企业元数据的概念。

其他主题相关章节：

19．全局数据仓库（Global Data Warehouse） - 当企业需要多个数据仓库时如何来处理。

20．从多个存储设备（Multiple Storage Media）上访问数据 - 从多个存储设备上访问数据的技术和方案。

21．性能 - 充分使用数据仓库。

22．移植 - 从第一代数据仓库移植到第二代数据仓库。

23．成本判断 - 关于为什么要建立数据仓库的内容，也是企业需要知道的内容。

本日志来源于Inmon的网站。

附：本部分列出了DW2.0中各部分的内容。有个事情要注意一下，Inmon的数据仓库体系中有些名词和Kimball的名词之间是有些差别的，差别最大的就是数据集市（Data Marts）。

中心数据仓库的区域划分相关章节：

1．交互区（Interactive Sector） - 数据仓库中对性能要求较高的处理所在的区域，是DW2.0中心数据仓库的一部分。

交互区（interactive sector）是DW2.0中最有用的部分之一，它在DW2.0中的位置处于中心数据仓库和源系统之间的最前沿，是在线处理事务发生的地方。在交互区中，我们可以得到真正的OLTP的反映时间。

（在DW2.0中，Inmon把中心数据仓库区分成了四部分，分别是交互区、整合区、近线区和归档区，而交互区是中心数据仓库和源系统最近的区域，能最先反映出源系统的数据变化。）

交互区环境的另一个特色是会有更新操作发生在这个区域。

当更新和在线处理事务出现时，这些操作需要尽快的反映在交互区中。为了实现这个目的，交互区的数据更新方式有两种，第一种处理方式是在交易级别进行更新，即业务系统的交易完成后直接提供交互区，交互区的数据在交易的粒度同步。另一种处理方式是尽可能短的后台批量处理级别。

正因为数据加载到交互区需要非常短的时间间隔，所以加载到交互区的数据通常是未经过完全整合的。

尽管进入交互区的数据未经过完全的整合，但是这部分数据的用处是非常大的。

在数据从交互区进入整合区（integrated sector）时，需要对数据进行完全的整合。数据整合的过程是通过一系列的ETL过程完成的。

交互区中的数据是保存当前信息的，也就是说，交互区的数据在用户访问的时刻是准确的。下面列出的是交互区数据的例子，

- 客户的帐户余额。

- 航线上飞机的当前状态。

- 保险政策的当前状态。

- 贷款的金额。

由于对交互区的数据有很高的性能要求，所以交互区中的数据量是比较小的。在交互区中，很少会保留历史数据。

一般来说，交互区的数据是秒级别的细节数据，它的直接用户在大多时候是一般办公人员（clerical community，估计应该指的是操作人员以外的职员，如行政人员、办公人员等）。

在交互区中常用的查询大多很小，只需要小量的数据，执行起来会非常的快。而统计分析类的查询很少发生在交互区。商业智能程序可以访问交互区，也就是说，报表和OLAP可以从交互区获得数据，当然，其他类似的分析也可以。

对于在交互区使用OLAP处理的人员来说，有一个问题一定要注意，交互区的数据是会发生变化的，所以在交互区的分析只是在分析的当时是准确的。

举例来说，如果一个分析查询发生在上午9:15，而相同的另一个分析查询发生在下午2:39，这两个发生在交互区的相同的查询由于查询时间的不一样，得到的结果很可能不一样。查询所基于的数据在这个时间段内很可能已经变化好几次了。所以交互区的分析查询者一定要注意，这里的查询是反映当前值的查询。

交互区的数据是可以被更新的。当交互区中的数据过了它的更新时限后，就需要将它迁移到整合区。（也就是说，我们需要定义或者找到数据的更新时限，即我们不能假定操作环境中的数据可以无限期的更新，当数据过了这个更新时限后，我们认为这个数据就是稳定的了，将其迁移如整合区。这里和Inmon的原来架构中的数据仓库有些不同，更像是原来架构中的ODS部分。）

交互区的设计要综合考虑数据模型和业务处理模型（process model）。（在Inmon以前的架构中进行数据仓库建模时，只需要考虑数据模型，而业务处理模型是建立操作型系统要考虑的事情，这里Inmon提出交互区要考虑两种模型，是对数据仓库和操作型系统的一个融合。）

交互区中有些部分是对性能要求很高的，有些部分是需要满足一些操作型要求的，这些部分的建模会受业务处理模型影响较多。而其他部分则主要受数据模型的影响。

交互区的数据存储方式应该放到磁盘上。（和后面提到的近线存储、磁带等相比。）能直接访问到最重要的处理过程数据的能力对交互区是非常重要的，所以要尽可能的保证这部分的访问速度。

通常访问交互区中的数据的模式是随机方式的。也就是说，由于各自源系统都会不时的产生交易，而这部分数据在交互区中也是随机保存在磁盘的各个位置的。（也就是说交互区的数据保存方式是随机，查询需要的数据可能保存在磁盘的任何地方，这对于小量数据的查询影响不大。）

2．整合区（Integrated Sector） - 数据仓库中整合数据的区域，是DW2.0中心数据仓库的一部分。

DW2.0的中心数据仓库包含四部分，分别是交互区、整合区、近线区和归档区。数据在各种情况下进入DW2.0的交互区，当交互区中的数据稳定后，即过了更新时限后，数据进入整合区。

整合区（integrated sector）有两个主要的数据来源，一个是交互区，另一个是操作型源系统。整合区的数据流向为近线区。

当数据从任何地方进入整合区时，都需要进行整合处理。整合的过程通常是ETL处理过程。而保留在整合区中的任何数据都是整合后的数据。

从另一个角度来考虑，整合区中的数据都是企业数据（corporate data）。企业数据的意思是数据是可以在企业的视角上查看的整合后的数据。（整合区应该是DW2.0的核心区域，和Inmon原来数据仓库架构中的EDW应该比较相似。）

整合区中的数据可以分为两部分，分别是当前整合数据（current integrated data）和活动分析数据（active analytical data）。

当前整合数据是比较细粒度的数据，它在DW2.0环境中是其他分析应用的基础。粒度数据在各种处理中被广泛应用。

活动分析数据也是以粒度数据为基础的，用来支持可预见的统计分析过程。当一个企业定期的做一些统计处理时，就需要建立活动分析数据区给这些统计处理提供数据。（我的理解是当前整合数据和活动分析数据都是原子粒度数据，其中的当前整合数据是给各种应用使用的，而活动分析数据是专门为统计处理准备的。统计处理需要的数据量大，所以单独准备数据提高性能。换句话说，当前整合数据和活动分析数据应该有很多是重合的，即为了不同的目的分别存储了两份。）

在几乎所有的情况下，当前整合数据和活动分析数据都需要在物理上分开存储。有很多理由可以说明将它们从物理上分开是有好处的。

当前整合数据区为数据仓库系统中其他各种部件提供数据，包括数据集市、报表系统、DSS应用等。

更经常的情况是，当前整合数据区中的数据是非直接使用的。作为一个非直接使用的例子，我们可以考虑在当前整合数据区中保存着一些数据，这些数据会被处理成另一种形式的数据保存到数据集市中。在数据集市中，分析程序和展现程序都可以直接使用这些数据。

有时，报表系统会直接从当前整合数据区直接读取数据。通常来说，只有在其他地方都不能完成的数据读取操作，才会到当前整合数据区读取。

当前整合数据区和活动分析数据区中的数据互相也需要是整合的，至少在关键粒度上应该上整合的，而能在最低粒度上整合是最好的。

当数据进入当前整合数据区，就需要将它们整合简化为粒度模式。用户可以为了满足各种需求将这种粒度模式的数据很容易的改造成其他模式。这种重新改造包括摘要（Summarize），聚集（Aggregate），结构重整（Restructure）等操作方式。

整合区中数据的另一个特色是对这部分数据的访问频率非常高，并且对整合区中每部分的数据的访问频率都很高。当然，数据访问频率的高低和数据保存的时间也有很大的关系。在整合区中，当前整合数据区的数据通常保存的时间是从当前到36个月。活动分析数据区的数据保存时间通常是不确定的，是个比较宽的范围。

不同数据区保存数据的时间长短不一样，主要是因为不同数据区的使用者不同，农场主（Farmers）主要使用当前整合数据区的数据，而探险家（Explorers）主要使用活动分析数据区的数据。

活动分析数据区的数据支持可以预见到的统计分析处理。

活动分析数据区中的数据的保存时间可能会大于36个月，而且活动分析数据区的还会根据访问数据的类型的不同而不同。例如，如果我们预见的统计分析处理需要的是分析客户的数据，那么像销售数据、产品数据、人力资源数据等就可以不保存到活动分析数据区中。

由于在整合区中，分析数据的范围比较广泛，所以我们需要去监测这些数据的访问情况。

监测整合区中数据的访问情况，对我们理解数据的用途是很有好处的。通常的监测如下所示，

-哪个表被访问了。

-哪个行被访问了。

-哪个字段被访问了。

通过这些监测情况，管理员还可以判断出另外一些情况，

-哪个表没有被访问。

-哪个行没有被访问。

-哪个字段没有被访问。

理解整合区中数据的使用情况是非常重要的，这些数据的访问频率决定了这些数据是否应该保留在整合区中。这些数据的访问频率也决定了数据是否应该进入活动分析数据区。根据数据的访问频率，我们会将当前整合数据区中的数据迁移入活动分析数据区。

整合区中的数据存储形式一般是快照数据。这因为整合区中保存的是快照数据，所以在整合区中是没有更新操作的。

和交互区的查询不同，整合区中的查询通常是需要访问大批量的数据。整合区中每个查询访问的数据量都不小，有些查询可能会访问相当大量的数据。

整合区使用最多的用户是办公人员（clerical community）。办公人员是使用整合区最多的分析人员，他们一般来说是间接使用整合区的数据，即通过数据集市和DSS应用来访问这些数据。

商业智能程序可以直接在整合区上运行。

商业智能程序运行在交互区和整合区有着较大的不同。在交互区，结果反映的是分析当时的情况。而在整合区，分析的过程是可以复现的。也就是说，我们在早晨运行的分析，如果在下午同样的运行一遍，结果会是同样的。即不会由于运行时间的不同产生不同的结果。

交互区和整合区另一个较大的不同是它们设计的基础不同。交互区的设计需要综合考虑业务过程模型和数据模型。而整合区则只需要考虑数据模型。（整合区的建模和Inmon原来的数据仓库建模比较像，和Kimball的维度建模有着较大的差别。Kimball一直在批评Inmon在建模时只考虑数据模型，导致建好的模型很难让用户理解。当然，这也是由于他们架构数据仓库的方式不同造成的。）

整合区中数据的存储介质是磁盘，保证较好的访问速度。

整合区中数据的访问模式是顺序随机（sequentially random）访问的。也就是说，当第一条记录被随机的找到后，通常会顺序的访问第一条记录后面一大批其他数据。所以整合区中，访问数据一般都是先随机的找到一条数据，然后在顺序的访问这条数据后的一系列数据。

3．近线区（Near Line Sector） - 数据仓库中访问频率较低的数据的保存区域，是DW2.0中心数据仓库的一部分。

在DW2.0中，近线区是位于整合区和归档区中间的一部分区域。

近线区的数据直接来自与整合区，并且全部来自与整合区。当整合区中的数据访问频率下降到一定程度后，或者整合区中的数据到达一定年龄后（如超过36个月），就可以迁移到近线区中。

也就是说，数据从整合区迁移到近线区需要综合考虑两个因素，一个是数据的年龄，另一个是数据的访问频率。

当数据迁移到近线区时，需要注意的一点是，数据要保持在整合区中的结构形式。这样做的原因是，当近线区中的数据需要返回整合区时，可以很快的完成迁移操作。

在数据迁移到近线区时，需要创建元数据。数据进入近线区时创建元数据是非常重要的，因为以后访问近线区中的数据需要通过元数据来进行。另外在数据进入近线区时，创建索引也是很重要的一步。通过元数据我们可以知道各类数据保存在什么地方，通过索引我们可以数据的具体内容。所以，在数据进入近线区时，强烈建议创建元数据和索引。

数据进入近线区的方式之一是直接从整合区复制记录。通过这种复制方式进入近线区的数据在需要时可以很容易的返回整合区。

数据进入近线区的另一种方式是经过结构重整（restructured）后进入近线区。除了在近线区中有其他的处理需要对数据进行结构重整外，不建议对数据进行结构重整，结构重整给近线区中的数据返回整合区带来了较大的麻烦。

近线区中使用的存储设备是比较便宜的设备，所以可以考虑为了满足各种需求引入冗余数据进入近线区。

近线区中数据组织规则中之一是，数据应该按照高级别的日期进行组织，通常来说是按照年来进行组合存储。

近线区的元数据覆盖面比较广，类别也比较多。

近线区的元数据包括通常的元数据条目，如

-表名。

-属性。

-物理特征（physical characteristics）。

近线区的元数据还包括其他元数据条目，如

-数据加载日期。

-数据展现日期。（date represented by the data，感觉应该是加载到近线区以前数据曾经用来展现使用的时间。）

-加载的数据量。

-编码值（encoding values）。

-使用的参照表（reference tables used）。

-数据源信息。等等。

在很多情况下，近线区和整合区中的数据都会有数据块的交换，通过这些数据块的交换，近线区和整合区紧密的连接在一起。

整合区和近线区的数据交换是双向的，当认为数据的访问频率降低到一定程度后，数据从整合区进入近线区，当发现事实上数据的访问频率比预想的要高时，数据从近线区返回整合区。

通过这种双向的数据交换，近线区就相当于整合区的缓存，相当于整合区的扩展。

为了能无缝的进行这种数据交换，必须要保证两边的数据在记录级别是相兼容的。

关于这部分，经常会有下列问题被提出来：

-什么时候需要将近线区中的数据返回到整合区？

-将数据从近线区回迁到整合区是否需要大量的时间？

-这种将数据从近线区回迁到整合区的处理方式是否会引起整个数据仓库系统的性能下降？

数据从近线区回迁到整合区，一定会引起数据仓库系统的性能下降。但是事实上，这样的数据回迁发生的频率是非常小的。数据之以要迁入近线区，就是因为它的访问频率非常低，如果访问频率高的话，就没必要将数据从整合区向近线区迁移。

当数据从近线区回迁入整合区时，数据的移动是随机顺序方式（random sequential manner），所以在回迁中寻找第一个记录时会有较大的性能下降，找到第一条记录后的顺序访问记录对性能的影响不大。

正是由于这种随机顺序的回迁方式，及很低的数据访问频率，所以近线区到整合区的数据回迁对数据仓库的整体性能的影响并不大。

近线区中的数据也可以独立的被访问，而不需要回迁到整合区中。

近线区中的数据保存在近线存储器（near line storage）上，而不是磁盘存储器上。（近线存储器没接触过，感觉可能是联机的磁带之类。）

近线区中的数据存储结构和整合区类似，保存的是数据的快照。当在近线区的数据中发现错误时，需要建立新的快照数据进行错误勘误。

为了查询数据的方便，需要在近线区中建立索引。近线区中的索引可以在数据加载到近线区时建立，也可以在加载完后建立。这些索引可以称为“被动式”（passive）索引。（被动式的索引指不是根据已知的查询需求来定制索引，而是预测将来可能使用的情况来定制索引。）

近线区应该建立在独立的硬件环境中。近线区中的处理器应该保证有充足的空闲资源，这些空闲资源可以用来建立索引，也可以用来使用索引。当需要近线区的数据时，通过索引可以快速的查找到需要的数据位置，然后可以从这个位置迅速的顺序读取大块数据。

对于数据仓库中相对不经常使用的数据来说，可以将它们保存在散装存储器（bulk storage）上，散装存储器相对于磁盘存储器是一种较慢的、较便宜的、可以长时间保存大量数据的存储设备。散装存储器通常也称为近线存储器（near-line storage），通常是顺序读取的存储器。

近线存储相当于数据仓库的逻辑扩展。有时，数据的真正位置可以做到对用户是透明的。举例来说，当用户提交一个查询时，她不需要知道返回的数据是保存在磁盘存储器还是近线存储器中。这时，磁盘存储和近线存储的数据切换应该由系统完成。

近线区和整合区的数据交换通常有三种方式，

第一种方式是数据库管理员手工迁移数据。这种方式的优点是实现起来比较简单，可操作的数据级别细，如在记录的级别进行迁移。缺点是容易出错，需要人机交互。

第二种方式是使用分级存储管理（hierarchical storage management，HSM）机制来进行。这种方式的优点是可以实现全自动的数据交互，实现相对比较简单，价格也不是很昂贵。缺点是操作的数据级别太粗，不能在记录级别进行交互。

第三种方式是使用交叉存储管理（cross-media storage management，CMSM）机制来进行。这种方式的优点是可以实现全自动的数据交互，可以操作的数据级别细，到记录的级别。缺点是实现复杂、价格昂贵。

后两种实现方式都是自动实现数据交互的，这是一个发展趋势。

4．归档区（Archival Sector） - 数据仓库中访问频率非常低的数据的保存区域，是DW2.0中心数据仓库的一部分。

DW2.0环境中的第四个区域是归档区，处于中心数据仓库的最后端的位置。

归档区（archival sector）中的所有数据都来源于近线区。

当近线区中的数据访问频率继续大幅度下降后，数据从近线区迁移入归档区。事实上，归档区中的数据访问频率几乎为零。

很多情况下，是出于法律的原因，即使数据的访问频率已经接近零了，但是数据还需要保留下来，这时数据进入归档区。也就是说，归档区中的数据不是因为访问频率而是由于法律的原因才被保存下来。

从哲学的观点来看，企业既然已经费力将数据保存成电子格式，那么再将这些数据抛弃不是一个很好的选择。而且在数据的保存过程中，很多数据进行了结构重整，将这些数据抛弃掉，如果回头还需要使用的话，就很有可能就再也找不到这些数据了，即使找到，也需要高昂的成本来重整这些数据。所以，如果数据有一点点的可能将来使用，就不应该将数据抛弃掉。

归档区保存数据的另一个原因是，使用归档区保存数据相对来说是价格比较低廉的。归档区的数据不会保留在磁盘上。

归档区的数据通常保存的时间比较长，10年、20年或者更长。这些数据都是按时间来保存的，通常是按年来保存。

正因为归档区中的数据非常的多，而且是按照时间来保存的，所以在归档区中，元数据显得更为重要。我们需要通过元数据来定位归档区中的各种类型的数据。

归档区中如果没有建立元数据，数据就只能顺序访问，必须花费大量的资源从整个文件中扫描。建立了元数据，就可以通过一种相对高效的方式定位数据。

从数据保存的结构来看，归档区中的数据可以采用多种格式保存。可以直接复制近线区的记录进行保存，可以将记录进行拆分（split），也可以将记录进行合并（combine）。

和元数据的功能相似，索引也是归档区中定位数据的有用工具。元数据描述了归档区中的数据的类型，索引描述了数据的内容。

通常归档区也有单独的处理器来管理数据，而且大多数时候，这些处理器是空闲的。可以利用这些空闲的处理器在归档区中建立索引。因为归档区中的数据的使用情况是未知的，所以只能预测可能出现的使用情况来定制索引，也称之为被动式索引。

当归档区中的被动式索引和元数据都创建完成后，归档区就可以提供一个相对可以接受的访问效率了。

归档区的元数据需要和数据一样保存在归档区中，这样可以防止将来元数据和数据分离，出现对不上的情况，给将来读取数据带来麻烦。归档区中的数据需要保存很久的时间，所以将元数据和数据保存在一起是非常必要的。如果元数据丢失了，归档区中的数据读取会变得非常麻烦，数据的用处也就不大了。

归档区中的数据的读取模式也是顺序随机模式。访问归档区中的数据，通常都是先定位第一条记录的位置，这个位置是随机的，定位后顺序的读取大量的数据。

一般需要访问归档区的数据时，都是大批量的数据访问。

归档区中的数据保存方式也是以快照的模式进行保存。

当归档区中出现错误数据时，通常是将错误的数据删除，再建立正确的快照数据。

偶尔归档区中的数据访问频率变大，需要将归档区中数据回迁到前面的几个数据区中，这时，数据回迁到DW2.0的交互区、整合区或者近线区都可以。

本翻译日志来自：http://www.chinabi.net/blog/user1/lastwood/index.html