数据库与数据仓库的比较

传统的数据库技术是以单一的数据资源，即数据库为中心，进行从事务处理、批处理到决策分析等各种类型的数据处理工作。然而，不同类型的数据有着不同的处理特点，以单一的数据组织方式进行组织的数据库并不能反映这种差异，特别是满足不了现代商业企业数据处理多样化的要求。随着数据库应用的广泛普及，人们对数据处理的这种多层次特点有了更清晰的认识。总结起来，当前的商业企业数据处理可以大致地划分为两大类：操作型处理和分析型处理。操作型处理也叫事务处理，是指对数据库联机的日常操作，通常是对一个或一组记录的查询和修改，主要是为企业的特定应用服务的，人们关心的是响应时间、数据的安全性和完整性。分析型处理则用于商业企业管理人员的决策分析。两者之间的巨大差异使得操作型处理和分析型处理的分离成为必然。这种分离，划清了数据处理的分析型环境与操作型环境之间的界限，从而由原来的以单一数据库为中心的数据环境发展成为一种新环境：体系化环境。

数据库系统作为数据管理手段，主要用于事务处理。在这些数据库中已经保存了大量的日常业务数据。传统的DSS（决策支持系统）一般是直接建立在这种事务处理环境上的。数据库技术一直力图使自己能胜任从事务处理、批处理到分析处理的各种类型的信息处理任务。尽管数据库在事务处理方面的应用获得了巨大的成功，但它对分析处理的支持一直不能令人满意，尤其是当以业务处理为主的联机事务处理（OLTP）应用与以分析处理为主的DSS应用共存于同一个数据库系统时，两种类型的处理发生了明显的冲突。人们逐渐认识到，事务处理和分析处理具有极不相同的性质，直接使用事务处理环境来支持DSS是行不通的。 具体来说，事务处理环境不适合DSS应用的原因概括起来主要有以下5条：

1、事务处理和分析处理的性能特性不同

在事务处理环境中，用户的行为特点是数据的存取操作频率高而每次操作处理的时间短，因此，系统可以允许多个用户按分时方式使用系统资源，同时保持较短的响应时间，OLTP是这种环境下的典型应用。

在分析处理环境中，用户的行为模式与此完全不同，某个DSS应用程序可能需要连续运行几个小时，从而消耗大量的系统资源。将具有如此不同处理性能的两种应用放在同一个环境中运行显然是不适当的。 2、数据集成问题

DSS需要集成的数据。全面而正确的数据是有效的分析和决策的首要前提，相关数据收集得越完整，得到的结果就越可靠。因此，DSS不仅需要整个企业内部各部门的相关数据，还需要企业外部、竞争对手等处的相关数据。

事务处理的目的在于使业务处理自动化，一般只需要与本部门业务有关的当前数据。而对整个企业范围内的集成应用考虑得很少。当前绝大部分企业内数据的真正状况是分散而非集成的。造成这种分散的原因有很多种，主要有事务处理应用分散、“蜘蛛网”问题、数据不一致问题、外部数据和非结构化数据。 （1）事务处理应用的分散

当前商业企业内部各事务处理应用间实际上几乎都是的，之所以出现这种现象有多种原因。有的原因是设计方面的，例如：系统设计人员为了减少系统开发 费用和加快开发进度，总是采用简单而“有效”的设计方案，这种“有效”仅指对解决当前面临的问题有效，而不能保证对以后新出现的问题继续有效。有的原因是经济方面的，当经费有限时，一些商业企业总是考虑对关键的业务活动建立应用系统，然后再逐步建立其他业务的信息处理系统。还有的原因是历史、地理

方面的，例如：某个大公司由分散在各地的多个子公司组成、企业的兼并等等。由于这种事务处理应用分散状况的存在，DSS应用需要对分散在多个事务处理应用中的相关数据进行集成，以向分析人员提供统一的数据视图。 （2）“蜘蛛网”问题

DSS应用中为了避免与其他用户的冲突和简化用户的数据视图，一种称为“抽取程序”的方法目前被广泛应用，用户利用抽取程序从文件或数据库中查找有用的数据，然后这些数据被提取出来放入其他文件或数据库中供用户使用。这些经抽取得到的新文件或数据库又被某些用户再进行抽取，这种不加控制的连续抽取最终导致系统内的数据间形成了错综复杂的网状结构，人们形象地称为“蜘蛛网”。企业的规模越大，“蜘蛛网”问题就越严重。

虽然网上的任意两个节点的数据可能归根结底是从一个原始库中抽取出来的，但其数据没有统一的时间基础，抽取算法各不相同，抽取级别也不相同，并且可能参考不同的外部数据。因而对同一问题的分析，不同节点却会产生不同甚至截然相反的结果。这当然使决策者无从下手。 （3）数据不一致问题

前述的应用分散和“蜘蛛网”等多个问题，导致了多个应用间的数据不一致。这些数据不一致的形式是多种多样的：

有时，同一字段在不同应用中具有不同的数据类型。例如：字段Sex在A应用中的值为M/F”，在B应用中的值为“0/1”，在C应用中又为“Male/Female”。有时，同一字段在不同应用中具有不同的名字。例如：A应用中的字段balance在B应用中名称为bal，在C应用中又变成了currbal。

有时，同名字段，不同含义。例如：字段weight在A应用中表示人的体重，在

B应用中表示汽车的重量，等等。

为了将这些不一致的数据集成起来，必须对它们进行转换后才能供分析之用。数据的不一致是多种多样的，对每种情况都必须专门处理，因此，这是一项很繁重的工作。

（4）外部数据和非结构化数据

商业企业高层管理者在决策中经常用到外部数据，这部分数据不是由事务处理系统产生的，而是来自于其它外部数据源。例如：权威性刊物发布的统计数据、业界的技术报告、市场比较和分析报告、股票行情等，这些数据通常都是非结构化数据。在事务处理系统中，由于没有对外部数据进行统一管理，用到这些数据的DSS应用必须自行集成。

上述问题是事务处理环境所固有的，尽管每个单独的事务处理应用可能是高效的，能产生丰富的细节数据，但这些数据却不能成为一个统一的整体。对于需要集成数据的DSS应用来说，必须自己在应用程序中对这些纷杂的数据进行集成。可是，数据集成是一项十分繁杂的工作，都交给应用程序完成会大大增加程序员的负担。并且，每做一次分析，都要进行一次这样的集成，将会导致极低的处理效率。DSS对数据集成的迫切需要可能是数据仓库技术出现的最重要动因。 3、数据动态集成问题

由于每次分析都进行数据集成的开销太大，一些应用就仅在开始对所需数据进行了集成，以后就一直以这部分集成的数据作为分析的基础，不再与数据源发生联系，我们称这种方式的集成为静态集成。静态集成的最大缺点在于，如果在数据集成后数据源中数据发生了改变，这些变化将不能反映给决策者，导致决策者使用的是过时的数据。对于决策者来说，虽然并不要求随时准确地探知系统内的任

何数据变化，但也不希望他所分析的是几个月以前的情况。因此，集成数据必须以一定的周期（例如24小时）进行刷新，我们称其为动态集成。显然，事务处理

系统不具备动态集成的能力。 4、历史数据问题

商业企业的事务处理一般只需要当前数据，在数据库中一般也只存储短期数据，且不同数据的保存期限也不一样，即使有一些历史数据保存下来了，也被束之高阁，未得到充分利用。但对于决策分析而言，历史数据是相当重要的，许多分析方法必须以大量的历史数据为依托。没有历史数据的详细分析，是难以把握商业企业的发展趋势的。

通过2、3、4所述可见，DSS对数据在空间和时间的广度上都有了更高的要求，而事务处理环境难以满足这些要求。 5、数据的综合问题

在事务处理系统中积累了大量的细节数据，一般而言，DSS并不对这些细节数据进行分析。这主要有两个原因：一是细节数据数量太大，会严重影响分析的效率；二是太多的细节数据不利于分析人员将注意力集中于有用的信息上。因此，在分析时，往往需要对细节数据进行不同程度的综合。而事务处理系统不具备这种综合能力，根据规范化理论，这种综合还往往因为是一种数据冗余而加以。以上这些问题表明，在事务型环境中直接构建分析型应用是一种失败的尝试。数据仓库本质上是对这些存在问题的回答。但是数据仓库的主要驱动力并不是改正 过去的缺点，而是市场商业经营行为的改变，即市场竞争要求捕获和分析事务级的业务数据。建立在事务处理环境上的分析系统无法达到这一要求。要提高分析

和决策的效率和有效性，分析型处理及其数据必须与操作型处理及其数据相分离。必须把分析型数据从事务处理环境中提取出来，按照DSS处理的需要进行重新组织，建立单独的分析处理环境。数据仓库正是为了构建这种新的分析处理环境而出现的一种数据存储和组织技术。

如前所述，传统的数据库系统面向以事务处理为主的OLTP应用，不能满足DSS的分析要求。事务处理和分析处理具有极不相同的性质，因而两者对数据也有着不同的要求。W.H.Inmon在其BuildingtheDataWarehouse（《建立数据仓库》） 一书中，列出了操作型数据与分析型数据之间的区别，如表1所示。

操作型数据 细节的 分析型数据 综合的，或可提炼在存取瞬间是的 准确的 可更新的 代表过去的数据 不更新 操作需求事先操作需求事先不知可知道 道 对性能要求高 对性能要求宽松 一个时刻操作一个时刻操作一集一个单元 事务驱动 面向应用 合 分析驱动 面向分析 一次操作数据一次操作数据量大 量小 支持管理需求 支持日常操作 表1操作型数据和分析型数据的区别

上述操作型数据与分析型数据之间的区别从根本上体现了事务处理与分析处理的差异。传统的数据库系统由于主要用于商业企业的日常事务处理工作，存放在数据库中的数据也就大体符合操作型数据的特点。而为适应数据分析处理要求而产生的数据仓库中所存放的数据就应该是分析型的数据。表1所列出的分析型数据的特点可以概括为4点，也就是数据仓库数据的4个基本特性：数据仓库的数据是面向主题的；数据仓库的数据是集成的；数据仓库的数据是不可更新的；数据仓库的数据是随时间不断变化的。

如果我们将数据库系统和数据仓库系统结构的各个组成部分作一个简单比较，即如表2所示：

数据库系统 数据仓库系统 数据库：操作型数据，增、数据库仓库：分析型数据，极删、改操作频繁 少有更新操作 数据库核心：功能强大，面数据仓库管理系统：因极少有向OLTP应用 更新操作，故功能简单 数据库工具：以查询工具为数据仓库工具：以分析工具为主 主 表2数据库系统与数据仓库系统的比较 数据仓库的特征

1、数据仓库的数据是面向主题的

与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主

题进行组织的。什么是主题呢？首先，主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整、一致的描述，能完整、统一地刻划各个分析对象所涉及的企业的各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有 更高的数据抽象级别。 2、数据仓库的数据是集成的

数据仓库的数据是从原有的分散的数据库数据抽取来的。在前面的表1中我们已经看到，操作型数据与DSS分析型数据之间差别甚大。第一，数据仓库的每一个主题所对应的源数据在原有的各分散数据库中有许多重复和不一致的地方，且来源于不同的联机系统的数据都和不同的应用逻辑捆绑在一起；第二，数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：

（1）要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。

（2）进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。

3、数据仓库的数据是不可更新的

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，

一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。数据库中进行联机处理的数据经过集成输入到数据仓库中，一旦数据仓库存放的数据已经超过数据仓库的数据存储期限，这些数据将从当前的数据仓库中删去。因为数据仓库只进行数据查询操作，所以数据仓库管理系统相比数据库管理系统而言要简单得多。数据库管理 系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提出了更高的要求，它要求采用各种复杂的索引技术；同时由于数据仓库面向的是商业企业的高层管理者，他们会对数据查询的界面友好性和数据表示提出更高的要求。

4、数据仓库的数据是随时间不断变化的

数据仓库中的数据不可更新是针对应用来说的，也就是说，数据仓库的用户进行分析处理时是不进行数据更新操作的。但并不是说，在从数据集成输入数据仓库开始到最终被删除的整个数据生存周期中，所有的数据仓库数据都是永远不变的。

数据仓库的数据是随时间的变化而不断变化的，这是数据仓库数据的第四个特征。这一特征表现在以下3方面：

（1）数据仓库随时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库中去，也就是要不断地生成OLTP数据库的快照，经统一集成后增加到数据仓库中去；但对于确实不再变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，而

不会对

原有的数据库快照进行修改。

（2）数据仓库随时间变化不断删去旧的数据内容。数据仓库的数据也有存储期限，一旦超过了这一期限，过期数据就要被删除。只是数据仓库内的数据时限要远远长于操作型环境中的数据时限。在操作型环境中一般只保存有60~90天的数据，而在数据仓库中则需要保存较长时限的数据（如5~10年），以适应DSS进行趋势分析的要求。

（3）数据仓库中包含有大量的综合数据，这些综合数据中很多跟时间有关，如数据经常按照时间段进行综合，或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行重新综合。

因此，数据仓库的数据特征都包含时间项，以标明数据的历史时期。