1.3 什么是数据仓库

1.3.1 数据仓库的定义

W.H.Inmon在1992年出版的《Building the Data Warehouse》一书中，将数据仓库（Data Warehouse，DW）定义为一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（TimeVariant）的数据集合，用于支持管理决策和信息的全局共享。

商业数据处理大致可以分成两大类：联机事务处理OLTP（On-Line Transaction Processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要进行基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观、易懂的查询结果。从面向事务处理到面向分析处理的系统使用中，如何将面向事务系统中的数据与数据仓库中的数据建立联系是建立数据仓库必须解决的问题。

OLTP包含巨量数据的更新，并提供对重要数据的近实时访问，包括让企业更有竞争力的数据。OLAP提供近乎实时的虚拟数据仓库；对主数据管理的负载均衡更新，能提升企业信息化架构的灵活度。

OLTP与OLAP的对比分析如表1-3所示。

表1-3 OLTP与OLAP的对比分析

续表

1.3.2 数据仓库的特点

数据仓库主要有以下特点。

1.面向主题

数据仓库面向不同的主题域进行组织，一个主题通常与多个操作型信息系统相关。例如一个数据仓库可以包含“客户”“产品”“收入”等主题。

2.集成性

数据仓库中的数据从建立时开始，面向整个企业的分析处理，数据仓库中的数据是已经集成的统一数据源或者是经过综合和计算后的数据。

3.相对稳定

若将某个数据记录存入数据仓库，则不能再对其进行修改或删除的操作。数据需要定期加载，加载后的数据极少更新。

4.反映历史变化

数据仓库中的数据能够反映历史变化，许多商业分析要求对发展趋势做出预测，对发展趋势的分析需要访问历史数据。

1.3.3 数据仓库的建模

数据仓库的星型模式、雪花模式描述了数据仓库主题的逻辑实现，即每个主题对应了关系表的关系模式定义。

1.星型模型

（1）星型模型（Star Schema）的定义。星型模型是最常见的模型范例，其中包括了一个包含大批数据和不含冗余的中心表，即事实表；还包括了一组小的附属表，即维表；维表围绕事实表，并显示在中心射线上，如图1-10所示。在实际应用中，随着事实表和维表的增加和变化，星型模型会产生多种衍生模型，包括星系模型、星座模型、二级维表和雪花模型。

星型模型的特点：简化了用户分析所需的关系，从支持决策的角度去定义数据实体，更适合大量的复杂的查询。每个维表有自己的属性。维表和事实表通过关键字相关联。维表的本质是多维分析空间在某个角度上的投影，多个维表共同建立一个多维分析空间。

图1-10所示的星型模式中，位于中心的sales称为事实表，其把各种不同的维表连接起来。它共有四维，分别是time维表、item维表、branch维表和location维表。sales事实表包含了四个维的关键字和两个度量（unit_sold、dollars_sold）。每个维表都分配有一个代理键（Surrogate Key，SK）。作为维表的唯一标识符，代理键没有内在的含义，通常表现为一个整数。

图1-10 sales数据仓库的星型模型

（2）星型模型事实表的特征。事实表的特征归纳为：主键是所有维表主键连接起来的组合键，数据粒度小，有求和计算的关键指标，属性个数与记录条数相比数量非常少，存在稀疏数据。详细描述如下。

① 事实表的主键是所有维表主键连接起来的组合键。例如，在图1-10中，sales事实表中的主键是四个维表主键的组合。

② 事实表中的一条记录应与所有维表中的记录相关。例如，在图1-10中，sales事实表中的一条记录对应了某个产品在某个日子、某个经销商、某个地区的具体销售数据。

③ 事实表数据粒度小。数据粒度是事实表中关键指标的细节程度。事实表中应保存级别尽可能低的细节数据，因为这样可以从OLTP中抽取出数据而不进行汇总，让用户通过数据仓库可以下钻到最低层次的细节数据，另外很多数据挖掘应用程序需要最低粒度的细节数据。

④ 事实表应满足已有关键指标计算和衍生指标计算的需求。

⑤ 事实表中的属性个数较少，而记录条数较多。

⑥ 维表属性的一些组合查询方式可能会造成事实表中关键指标值为空的情况，形成稀疏数据存在的情况。

（3）星型模型维表的特征。维表的特征归纳为：维表主键唯一确定一条记录、有大量的属性、大多为文本格式的属性、有非直接相关的属性、为非规范化的表、具有上钻/下钻功能、具有多层次结构、记录条数比事实表少。详细描述如下。

① 维表的主键应唯一确定该维表的一条记录。

② 维表有大量的属性。一个维表可以有相当多的属性。例如，有些维表属性个数会超过50个。

③ 维表中的属性一般是文本格式的。这是由商业需求及所分析的问题决定的。这些属性代表了商业维度中的组成部分的文本描述，用户可利用这些描述构造查询需求。

④ 维表中的一些属性可不与其中的其他属性直接相关，例如，item表中的brand与type不是直接相关的，但两者都是维表的属性。

⑤ 维表是非规范化的。维表中的一个属性可作为一个约束条件直接应用于事实表中的关键指标查询，以使查询效率更高，即最好直接从维表中获得一个属性，然后直接查询事实表，不需要通过其他中间表。但是如果维表规范化了，就需要建立中间表，从而使查询效率低。

⑥ 维表具有上钻/下钻功能。维表中的属性应具有获取从高层次汇总数据及到低层次细节数据的功能，例如，location表中包含属性street、city、province_or_state、country。用户可以查询country总量，可下钻到province_or_state，也可进一步下钻到city、street。

⑦ 维表中的属性可具有多种多级的层次结构，例如，在item表中，市场部可以按自己的分类方法将产品归类到产品目录及产品部门中，财务部可以按自己的分类方法将产品归类到产品目录及产品部门中。

⑧ 维表中的记录条数通常都比中心事实表中的记录条数少，例如，在图1-10中，time维表、item维表、branch维表和location维表中的记录数是有限的，数量相对稳定，不像事实表随着交易的产生，会不停地增加记录。

（4）星型模型的优势。星型模型能够将用户决策思维问题准确地转换为逻辑上的一个中心事实表和多个维表，并以二维表结构的属性描述方式直观地进行呈现，其优势表现在如下3个方面。

① 用户容易理解星型模型。维表包含了决策者经常查询和分析的属性，而中心事实表又包含了决策者衡量职能部门业绩的指标。这些指标表明了职能部门任务的完成情况。因此，决策者很容易理解数据仓库的星型模型。这就使得数据仓库开发人员能非常方便地与决策者就业务需求进行交流。

② 优化浏览方式。关系表的结构提供了操作数据仓库数据的能力，运用表之间的连接路径，可很快地从一个表转移到另一个表，以加速查询浏览的过程。

③ 适用于查询处理。星型模型的查询处理实际上是使用一些简单的参数过滤维表的过程，以得到一些维表的结果，再从中心事实表中得到相应的结果集。在维表与中心事实表之间存在简单且清晰的连接，使得星型模型适用于以查询为中心的操作环境，适合于追踪查询多条件限制的关键指标。

2.雪花型模型

（1）雪花模型（Snowflake Schema）的定义。雪花模型是由星型模型进一步演化而形成的。它将星型模型中的某些维表进行了规范化，并将数据进一步分解到附加表中。如图1-11所示，该图表示了sales数据仓库从星型模型到雪花模型的分解状态。

图1-11 sales数据仓库的雪花模型

雪花模型和星型模型的主要不同之处在于，雪花模型的维表可能是规范化的，以减少冗余。这种表易于维护，并可节省存储空间。由于在执行查询的过程中，需要进行更多的连接操作，所以，在数据仓库的初步设计过程中，若采用雪花模型，则会降低查询结果的反馈性能，并将直接影响到系统的性能。

（2）雪花模型的特点。雪花模型是对星型模型维表的进一步层次化，是将某些维表扩展成事实表。这样既可以应付不同级别用户的查询，也可以将源数据通过层次间的联系向上综合，从而最大限度地减少数据存储量，因而提高了查询功能。

雪花模型的维度表是基于范式理论的，是界于第三范式和星型模型之间的一种设计模型。通常情况下，部分数据组织采用第三范式的规范结构，部分数据组织采用星型模型的事实表和维表结构。在某些情况下，星型模型在组织数据时，为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成了雪花模型。

雪花模型比较复杂，用户不容易理解，浏览内容相对困难；额外的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”，因为数据仓库需要更加优良的查询性能，而雪花模型会降低数据仓库系统的查询性能。在雪花模型中，有些数据需要连接才能获取，可能效率较低；规范化操作较复杂，导致设计及后期维护复杂。

实际应用中，可以采取上述两种模型的混合体，比如，中间层使用雪花模型以降低数据冗余度，数据集市部分采用星型模型以方便数据提取及分析。

1.3.4 数据集市的定义

数据集市（Data Mart，DM）也称为数据市场，是一个从操作的数据和其他的为某个特殊的专业团体服务的，在数据源中收集数据的仓库。数据仓库是企业级的，能为整个企业各部门的运行提供决策支持手段。数据集市是部门级别的，一般只能为某个局部范围内的管理人员服务，也称为部门级的数据仓库。数据仓库与数据集市的区别如表1-4所示。

表1-4 数据仓库与数据集市的区别

1.3.5 数据仓库的体系结构

构建一个数据仓库体系结构，完成对数据的集成、整合、加工、质量等多方面的基础管理，从而满足分析利用型需求的不断变化、扩展，保证应用系统长久的生命力。构建数据仓库体系结构，往往是项目过程中最难的一项工作。它包括建模、ETL、数据质量、元数据等不同领域的衔接和配合。

图1-12所示的体系架构的重点放在目标端需求，以及对目标端需求的预测和评估上。通过理解不同数据集市层的需求来规划、抽象数据仓库的核心主题，并规划每一个主题下的度量，以及度量对应的最细颗粒度的维度和维度层次、成员。这种架构方法便于快速捕捉业务、理解业务，从而构建出数据模型。但是，在数据仓库的ETL开发时的主要难点在于，将分散在不同数据库的符合第三范式的事务级数据聚合和组织到维度格式的数据仓库模型中。

图1-12 数据仓库的体系架构

1.3.6 数据仓库的数据及组织

数据仓库中存储两类数据：元数据和业务数据。

元数据又称中介数据、中继数据，为描述数据的数据，主要是描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。在数据仓库领域中，元数据按用途分成技术元数据和业务元数据。技术元数据是关于数据仓库系统技术细节的描述数据，是数据仓库开发人员和管理人员需要使用的重要信息，主要包括数据仓库结构的描述等，主要服务对象是技术人员。业务元数据是从业务角度描述数据仓库中的数据。它提供了介于使用者和实际系统之间的语义层定义，使得不懂计算机技术的业务人员也能够理解数据仓库中的数据，主要用户是商务人员。

业务数据又分为细节数据和综合数据。元数据经过抽取、转换后，首先进入当前细节级，再根据具体需要进行进一步的综合，从而进入轻度综合级乃至高度综合级。老化的数据进入早期细节级。业务数据的级别划分如图1-13所示。

图1-13 业务数据的级别划分

粒度是衡量数据仓库中数据综合程度高低的一个度量。数据粒度是数据仓库的重要概念。粒度越小，细节程度越高，综合程度越低。在数据仓库中，多重粒度是必不可少的。确定粒度是数据仓库开发者需要面对的一个重要的设计问题。如果数据仓库的粒度确定合理，则设计和实现中的其余方面就可以非常顺畅地进行。

不同的情况组织数据的粒度会不同。例如，在销售数据中，细节数据——记录每一笔销售情况；轻度综合数据——记录每天的销售情况；高度综合数据——记录每月的销售情况。