在数据仓库技术出现之前，只有事务处理，DBMS系统为这类处理需求提供了支持。然而，在数据仓库中的处理是完全不同的。数据仓库环境中的处理类型可以概括为加载和访问过程。数据从原有的运营数据环境和ODS整合、转化、加载到数据仓库中。一旦进入数据仓库，就可以在那里访问和分析集成数据。在数据仓库中，数据一旦加载，通常不会更新。如果需要对数据仓库进行修正和调整，也是在没有对数据仓库数据进行分析操作的空闲时间进行。此外，这些更改也是通过添加当前数据快照来完成的。传统事务处理数据库环境和数据仓库环境之间的另一个重要区别是，数据仓库环境比典型的操作环境拥有更多的数据，以万亿或千万亿计，而通用DBMS通常管理的数据要少得多传统的事务处理数据库。数据仓库管理大量数据，因为它们包括以下内容：粒度、原子细节。历史信息。详细信息和摘要数据。在基本数据管理功能方面，数据仓库使用一组与标准操作DBMS截然不同的参数进行优化。传统的通用DBMS和特定于数据仓库的DBMS之间的第一个也是最重要的区别是如何执行数据更新。传统的通用DBMS必须将记录级、基于事务的更新作为其正常操作的一部分。由于记录级、基于事务的数据更新是通用DBMS的一个共同特征，它必须提供以下功能：锁定。提交。检查点。日志磁带处理。僵局。反向恢复。这些功能不仅成为DBMS的常规部分，而且它们的开销也很大。有趣的是，当不使用DBMS时也会产生这种开销。换句话说，当一个通用的DBMS只进行只读操作时，DBMS至少还提供了更新和锁定的开销（取决于DBMS）。根据通用DBMS，更新所需的开销可以不同程度地最小化，但不能完全消除。对于专用于数据仓库的DBMS，无需支付任何更新开销。通用DBMS和数据仓库专用DBMS之间的第二个主要区别是基础数据的管理。对于一个通用的DBMS，块级的数据管理包括一些额外的空间，用于以后更新和插入数据时块的扩展。通常，这些空间是空闲空间。对于一个普通的DBMS，空闲空间可能占到50%。对于数据仓库专用的DBMS，完全不需要空闲空间，因为数据一旦加载到数据仓库，就不需要更新，也不需要物理块扩展。事实上，鉴于数据仓库中要管理的数据量，留下大量以后永远不会使用的空间是没有意义的。反映在不同类型的DBMS中的数据仓库和通用环境之间的另一个相关差异是索引的差异。常见的DBMS环境仅限于有限数量的索引。此限制是由于存在更新和插入数据时索引本身所需的空间和数据管理。但是数据仓库环境中没有数据更新，却需要优化数据访问，也有多个索引的必要性（和机会）。事实上，数据仓库可以应用比可操作的、面向更新的数据库更健壮和完整的索引结构。除了物理块级别的索引、更新和基本数据管理外，通用DBMS和数据仓库特定DBMS在数据管理能力和策略方面还存在一些其他根本差异。其中，两种类型的DBMS之间最根本的区别可能是能够以针对不同类型的访问优化的方式物理组织数据。通用DBMS以物理方式组织数据以优化事务访问和处理。以这种方式组织允许根据公共密钥聚合许多不同类型的数据，并使用1或2个I/O进行有效访问。最适合信息访问的数据通常具有非常不同的物理描述。最适合信息访问的数据被组织起来，以便可以使用1或2个物理I/O高效地访问同一类型数据的许多不同值。可以针对事务访问或DSS访问对数据进行物理优化，但不能同时针对两者进行优化。通用的、基于事务的DBMS仅为事务访问优化数据，而特定于数据仓库的DBMS为DSS访问和分析物理优化数据。1.改变DBMS技术对于信息仓库，需要考虑的一个有趣因素是DBMS技术在数据仓库数据加载后发生变化。这种变化有几个原因：当数据仓库首次加载数据时，今天可用的DBMS技术不一定适用。数据仓库的大小已经增长到需要新的技术方法的程度。数据仓库的使用逐渐增多，发生了很多变化，使得目前数据仓库的DBMS技术并不尽如人意。需要不时地审查基本的DBMS选择。您是否应该考虑寻找新的DBMS技术？需要考虑哪些因素？以下几点非常重要：新的DBMS技术是否满足可预见的需求？从旧的DBMS技术到新的DBMS技术应该如何转换？转换程序应如何更改？在所有这些考虑因素中，最后一个是最令人烦恼的。即使在最好的情况下，尝试更改转换过程也是一项复杂的任务。事实上，一旦数据仓库采用了DBMS，就可以在以后进行更改。但这种情况在事务处理过程中是绝对不可能的，因为一旦采用DBMS，只要事务处理系统还在运行，它就必须保持不变。2.多维DBMS和数据仓库数据仓库中经常讨论的技术是多维数据库管理系统处理（有时称为OLAP处理）。多维数据库管理系统或数据集市提供了一种信息系统结构，使企业能够灵活地访问数据，以多种方式对数据进行切片和分块，并动态地检查汇总数据和详细数据之间的关系。多维DBMS为最终用户提供灵活性和控制。因此，它非常适合DSS环境。如图1所示，多维DBMS和数据仓库之间存在一种非常有趣的互补关系。图1数据仓库的传统结构以及当前明细数据如何与部门数据（或多维DBMS、数据集市）相结合。数据仓库中的明细数据为多维DBMS提供了非常健壮和方便的数据源。由于多维DBMS需要定时刷新，为此，数据要定时从数据仓库中导入到多维DBMS中。因为历史应用程序数据在进入数据仓库时被集成，多维DBMS不再需要从操作环境中提取和集成它需要的数据。此外，数据仓库在最低层存储数据，从而为使用多维DBMS的用户可以在需要时执行的低层分析提供“基础”数据。可能有人认为数据仓库数据库技术应该采用多维DBMS技术，实际上，除了一些非常特殊的情况外，这种想法是不正确的。那些优化多维DBMS技术能力的属性并不是数据仓库最根本的重要特征。数据仓库中最重要的特性也不是多维DBMS技术的特性。看一下数据仓库和多维DBMS的区别：数据仓库有很多数据；多维DBMS的数据至少少一个数量级。数据仓库只适合少量的灵活存取；而多维DBMS适用于大量不可预测的数据访问和分析。数据仓库存储数据的时间范围很长（从5到10年）；而多维DBMS只存储较短时间范围内的数据。数据仓库只允许分析师访问受限形式的数据，而多维DBMS允许自由访问。多维DBMS和数据仓库是互补关系，而不是数据仓库建立在多维DBMS之上的关系。关于数据仓库和多维DBMS关系的有趣之处之一是，数据仓库可以为多维DBMS中通常不可见的非常详细的数据提供基础。数据仓库可以容纳非常详细的数据，这些数据在导入到多维DBMS中时经过轻微合成。导入多维DBMS后，数据将被进一步汇总。在这种模式下，多维DBMS可以包含除非常详细的数据之外的所有数据。使用多维DBMS的分析师可以灵活高效地钻取多维DBMS中所有不同级别的数据。如果需要，分析师还可以深入到数据仓库。通过以这种方式结合数据仓库和多维DBMS，DSS分析师可以获得两者的好处，大部分时间都可以享受多维DBMS中运行效率的优势。同时，还可以向下钻取到最低级别的详细数据。另一个优点是聚合信息在多维DBMS中计算和聚合，然后存储在数据仓库中。因此，与在多维DBMS中相比，汇总数据在数据仓库中的存储时间更长。还有另一个方面，数据仓库和多维DBMS是互补的。多维DBMS存储数据的时间中等，从12到15个月不等，具体取决于应用程序。数据仓库存储数据的时间跨度要长得多——从5到10年。基于此，数据仓库成为多维DBMS分析人员进行研究的数据源。多维DBMS分析师可以放心地知道有大量数据可用，而无需在需要时将所有数据存储在他们的环境中。多维DBMS有不同的风格。一些多维DBMS建立在关系模型上，而另一些则建立在优化数据“切片和分块”的基础上，其中数据可以被认为存储在多维立方体中。后一种技术基础可以称为立方体基础或OLAP基础。这两个技术基础都支持多维DBMS数据集市。但是这两个技术基础之间存在一些差异。多维DBMS数据集市的关系基础如下：优点：可以支持海量数据。可以支持数据的动态连接。证明有效的技术。能够支持一般的数据更新处理。如果数据的使用模式不清楚，关系结构和其他结构一样好。缺点：性能不是最优的。无法优化访问处理。多维DBMS数据集市的立方体基础如下：优点：针对DSS处理进行了性能优化。可以针对非常快速的数据访问进行优化。如果已知数据访问模式，则可以优化数据结构。能够轻松切片和切块。可以通过多种方式进行检测。缺点：无法处理与标准关系模式一样多的数据。不支持通用更新处理。加载需要很长时间。如果数据设计不支持所需的访问路径，则此结构不灵活。对数据动态连接的支持存在问题。多维数据库管理系统（OLAP）是一种技术，而数据仓库是一种架构基础。两者之间存在依赖关系。通常情况下，数据仓库作为需要流入多维DBMS的数据的基础，将选定的详细数据的一个子集传输到多维DBMS，在这里对数据进行汇总或聚合。但在某种程度上，有一种观点认为多维DBMS不需要数据仓库作为其数据的基础。如果没有数据仓库作为多维DBMS的基础，加载到多维DBMS中的数据将直接从遗留的遗留应用程序环境中获取。图2显示了数据从历史环境直接加载到多维DBMS的情况。这种方法很有吸引力，因为它简单明了且易于实施。程序员可以立即开始构建它。图2从没有当前详细数据的应用程序构建多维DBMS数据集市不幸的是，图2中显示的体系结构有一些不太明显的主要缺陷。出于各种原因，将当前详细级别的数据从数据仓库加载到多维DBMS环境比从历史应用程序的操作环境加载数据更有意义。图3显示了将当前详细级别的数据从数据仓库加载到多维DBMS环境中。遗留的、历史的、运营数据在导入数据仓库的过程中被集成和转换。图3数据从应用环境流向当前明细级再到多维DBMS数据集市一旦进入数据仓库，集成数据就存储在当前明细级数据中。多维DBMS旨在将数据加载到数据仓库中的这一级别。乍一看，图2和图3所示的两种结构似乎没有本质区别。事实上，首先将数据加载到数据仓库似乎是一种浪费。然而，创建多维DBMS的第一步是将数据集成到数据仓库中，这是有充分理由的。考虑到在正常情况下，一个公司需要建立多个多维的DBMS。金融部门需要自己的多维DBMS，金融部门也是如此。营销、销售等部门也需要自己的多维DBMS。因为公司里面会有很多多维的DBMS，所以图2的情况会变得很复杂。在图4中，图2被扩展为真实情况。许多多维DBMS直接并独立于历史环境获取数据。图4对于许多应用程序和许多数据集市，每对之间都需要一个接口。避免当前详细级别数据的后果是创建一个难以管理的“蜘蛛网”图4显示许多多维DBMS直接从相同的历史应用程序获取数据。那么，这种结构有什么问题呢？这就是问题所在：提取数据所需的开发量是巨大的。每个不同部门的多维DBMS都需要定制开发一套适合自己的抽取程序。提取过程中存在大量重叠。这样一来，浪费的开发精力是巨大的。多维数据库管理系统从数据仓库中提取数据时，只需要一组集成和转换过程。当多维DBMS直接从历史系统环境中抽取数据时，没有数据集成的基础。每个部门的多维DBMS对如何集成来自不同应用程序的数据都有自己的解释。遗憾的是，一个部门集成数据的方式通常不同于其他部门集成相同数据的方式。结果是最终没有单一的集成的、确定的数据源。相反，在构建数据仓库时，有一个单一的、集成的、确定性的数据源可以作为构建的基础。为维护它所做的开发工作量是巨大的。在旧的遗留应用程序中，只需一个更改就会影响许多提取器。凡是有提取程序的地方，都会因为这个改动而做一些改动，而且会有很多这样的改动。当有数据仓库时，由于只需要编写少量程序来处理历史环境与数据仓库之间的接口，应用程序的变化影响也很小。需要消耗的硬件资源量很大。对于每个部门的每个抽取过程，相同的历史数据依次重复传输。在数据仓库中，历史数据只需要传输一次，刷新数据仓库中的数据。将数据从历史环境直接导入多维DBMS环境的复杂性阻碍了对元数据的有效管理和控制。在数据仓库中，捕获和管理元数据非常简单。缺乏数据一致性。当不同部门之间存在意见分歧时，每个部门都有自己的多维DBMS，很难解决。但是有了数据仓库，解决冲突就自然而容易了。每次都要建立一个新的多维DBMS环境，而且必须根据历史环境建立，所需的工作量是相当大的。然而，如果数据库在数据仓库中，那么构建一个新的多维DBMS环境将是快速而容易的。如果企业考虑的是短期方法，那么数据仓库成本的合理性分析将难以进行。从长远来看，构建许多多维数据库环境的成本非常高。而当企业从长远角度构建数据仓库时，数据仓库和数据集市的长期总成本将显着降低。作者简介：WilliamH.Inmon，世界公认的“数据仓库之父”，企业信息工厂的创始人之一。
