|
|
|
传统数据库在联机事务处理（OLTP）中获得了较大的成功，但是对管理人员的决策分析要求却无法满足。因为管理人员希望对组织中的大量数据进行分析，了解组织业务的发展趋势，而传统的数据库中只能保留当前的管理信息，缺乏决策分析所需要的大量的历史信息。为了满足管理人员的决策分析需要，在数据库基础上产生了能满足决策分析需要的数据环境——数据仓库（Data Warehouse，DW）。
|
|
|
|
虽然数据仓库是从数据库发展而来的，但是二者在许多方面有相当大的差异，二者的比较情况如下表所示。
|
|
|
|
|
|
|
|
|
|
数据仓库有这样一些重要的特性：面向主题的、数据是集成的、数据是相对稳定的、数据是反映历史变化的。
|
|
|
|
|
|
数据仓库中数据是面向主题进行组织的。从信息管理的角度来看，主题就是一个较高的管理层次上对信息系统中数据按照某一具体的管理对象进行综合、归类所形成的分析对象。从数据组织的角度来看，主题就是一些数据集合，这些数据集合对分析对象进行了比较完整的、一致的数据描述，这种数据描述不仅涉及数据自身，还涉及数据间的联系。例如，企业中的客户、产品和供应商等都可以作为主题来看待。
|
|
|
|
数据仓库的创建使用都是围绕主题实现的，因此，必须了解如何按照决策分析来抽取主题，所抽取的主题应该包含哪些数据内容，这些数据应该如何组织。在进行主题抽取时，必须按照决策分析对象进行。例如，在企业销售管理中的管理人员所关心的是本企业哪些产品销售量大、利润高？哪些客户采购的产品数量多？竞争对手的哪些产品对本企业产品构成威胁？根据这些管理决策分析对象，就可以抽取“产品”“客户”等主题。
|
|
|
|
|
|
数据仓库的集成性是指根据决策分析的要求，将分散于各处的原数据进行抽取、筛选、清理、综合等集成工作，使数据仓库中的数据具有集成性。
|
|
|
|
数据仓库所需要的数据不像业务处理系统那样直接从业务发生地获取数据。如在线事务处理系统（OLPT）、企业业务流程重组（BRP）以及基于因特网的电子商务（EC）中的数据是与业务处理联系在一起的，只为业务的日常处理服务，而不是为决策分析服务。这样，数据仓库在从业务处理系统那里获取数据时，并不能将原数据库中的数据直接加载到数据仓库中，而要进行一系列的数据预处理。即从原数据库中挑选出数据仓库所需要的数据，然后将来自不同数据库中的数据按某一标准进行统一，如将数据源中数据的单位、字长与内容统一起来，将源数据中字段的同名异义、异名同义现象消除，然后将源数据加载到数据仓库，并将数据仓库中的数据进行某种程度的综合，进行概括和聚集的处理。
|
|
|
|
|
|
数据仓库的数据主要是供决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时间的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。数据库中进行联机处理的数据经过集成输入到数据仓库中。因为数据仓库只进行数据查询操作，所以在DBMS中的完整性保护、并发控制在数据仓库管理中都可以省去。但是，由于数据仓库的查询数据量往往很大，所以对数据查询提出了更高的要求，需要采用复杂的索引技术。
|
|
|
|
|
|
数据仓库中数据的相对稳定是针对应用来说的，数据仓库的用户进行分析处理时是不进行数据更新操作的。但并不表明在从数据集成输入数据仓库开始到最终被删除的整个数据生存周期中，所有的数据仓库数据是永远不变的。数据仓库的数据是反映历史变化的，这主要表现在如下三个方面：
|
|
|
|
（1）数据仓库随时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库中去。
|
|
|
|
|
|
（3）数据仓库中包含大量的综合数据，这些数据有很多信息与时间有关，如数据经常按时间段进行综合，或隔一定的时间进行抽样等等，这些数据要随时间不断地进行重新综合。
|
|
|
|
|
|
典型的数据仓库具有为数据分析而设计的模式，使用OLAP工具进行联机分析处理。因此数据通常是多维数据，包括维属性、度量属性。包含多维数据的表称为事实表，事实表通常很大。例如，一个表sales记录了零售商店的销售信息，其中每个元组对应一个商品售出记录，这是一个非常典型的事实表的例子。表sales的维包括售出的是何种商品（用商品标识表示）、商品售出的日期、商品售出的地点、哪个顾客购买该商品等等。度量属性包括售出商品的数量和金额。
|
|
|
|
为了减少存储要求，维属性通常是一些短的标识，作为参照其他表的外码。例如，事实表sales含有属性item_key、time_key、branch_key和location_key，以及度量属性units_sold和dollars_sold。其中，属性item_key是一个参照维表item的外码，表item含有商品名称、商品的品牌、商品所属类别等属性；属性time_key是一个参照维表time的外码，表time含有日、月、季和年的属性；属性branch_key是一个参照维表branch的外码，表branch含有出售商品的分销商的名称、分销商的类型属性；属性location_key是一个参照维表location的外码，表location含有销售地点的街道、城市、省份、国家等属性。由此得到一个事实表、多维表以及从事实表到多维表的参照外码的模式称为星型模式，如下图所示。
|
|
|
|
|
|
|
|
更复杂的数据仓库设计可能含有多级维表，例如维表item含有属性supplier_key，作为参照给出供应商的细节信息的另一个维表supplier的外码；维表location含有属性city_key，作为参照给出城市的细节信息的另一个维表city的外码。这种模式称为雪花模式，如下图所示。
|
|
|
|
|
|
|
|
复杂的数据仓库设计可能含有不止一个事实表，下图模式中含有Sales和Shipping两个事实表，共享location、item、time和branch维表。这种模式称为事实星型模式。
|
|
|
|
|
|
|
|
|
|
数据仓库通常采用三层体系结构，底层为数据仓库服务器、中间层为OLAP服务器，顶层为前端工具。底层的数据仓库服务器一般是一个关系数据库系统，数据仓库服务器从操作型数据库或外部数据源提取数据，对数据进行清理、转换、集成等，然后装入数据仓库中。中间层的OLAP服务器的实现可以是关系型OLAP，即扩充的关系型DBMS，提供对多维数据的支持；也可以是多维的OLAP服务器，它是一种特殊的服务器，直接支持多维数据的存储和操作。顶层的前端工具包括查询和报表工具、分析工具、数据挖掘工具等。
|
|
|
|
从结构的角度看有三种数据仓库模型：企业仓库、数据集市和虚拟仓库。
|
|
|
|
企业仓库收集跨越整个企业的各个主题的所有信息。它提供全企业范围的数据集成，数据通常都来自多个操作型数据库和外部信息提供者，并且是跨越多个功能范围的。它通常包含详细数据和汇总数据。企业数据仓库可以在传统的大型机上实现，例如UNIX超级服务器或并行结构平台。它需要广泛的业务建模，可能需要多年的时间来设计和建造。
|
|
|
|
数据集市包含对特定用户有用的、企业范围数据的一个子集。它的范围限于选定的主题，例如一个商场的数据集市可能限定于它的主题为顾客、商品和销售。包括在数据集市中的数据通常是汇总的。通常，数据集市可以在低价格的部门服务器上实现，基于UNIX或Windows NT/2000/XP。实现数据集市的周期一般是数周，而不是数月或数年。但是，如果它的规划不是企业范围的，从长远讲，可能会涉及很复杂的集成。根据数据的来源不同，数据集市分为独立的和依赖的两类。在独立的数据集市中，数据来自一个或多个操作型数据库或外部信息提供者，或者是一个特定部门或地区本地产生的数据。在依赖数据集市中，数据直接来自企业数据仓库。
|
|
|
|
虚拟仓库是操作型数据库上视图的集合。为了有效地处理查询，只有一些可能的汇总视图被物化。虚拟仓库易于建立，但需要操作型数据库服务器具有剩余能力。
|
|
|
