数据仓库 - 快速指南

---

数据仓库 - 概述

“数据仓库”一词最早由 Bill Inmon 于 1990 年提出。根据 Inmon 的说法，数据仓库是面向主题的、集成的、时变的、非易失性的数据集合。这些数据可以帮助分析师在组织中做出明智的决策。

由于发生的事务，操作数据库每天都会发生频繁的更改。假设业务主管想要分析之前对任何数据（例如产品、供应商或任何消费者数据）的反馈，那么该主管将没有可用于分析的数据，因为之前的数据已因交易而更新。

数据仓库为我们提供多维视图中的通用且整合的数据。除了通用和统一的数据视图之外，数据仓库还为我们提供了在线分析处理（OLAP）工具。这些工具帮助我们在多维空间中对数据进行交互式和有效的分析。该分析导致数据概括和数据挖掘。

关联、聚类、分类、预测等数据挖掘功能可以与OLAP操作集成，增强多个抽象层次知识的交互式挖掘。这就是为什么数据仓库现在已经成为数据分析和在线分析处理的重要平台。

了解数据仓库

• 数据仓库是一个数据库，与组织的操作数据库分开。

• 数据仓库中不进行频繁的更新。

• 它拥有整合的历史数据，有助于组织分析其业务。

• 数据仓库帮助管理人员组织、理解和使用他们的数据来做出战略决策。

• 数据仓库系统有助于集成多样性的应用系统。

• 数据仓库系统有助于整合历史数据分析。

为什么数据仓库与操作数据库分开

由于以下原因，数据仓库与操作数据库分开：

• 操作数据库是为众所周知的任务和工作负载而构建的，例如搜索特定记录、索引等。在合同中，数据仓库查询通常很复杂，并且它们呈现通用形式的数据。

• 操作数据库支持多个事务的并发处理。运行数据库需要并发控制和恢复机制，以保证数据库的健壮性和一致性。

• 操作数据库查询允许读取和修改操作，而 OLAP 查询只需要对存储的数据进行只读访问。

• 操作数据库维护当前数据。另一方面，数据仓库维护历史数据。

数据仓库功能

下面讨论数据仓库的主要特征 -

• 面向主题- 数据仓库是面向主题的，因为它提供围绕主题而不是组织正在进行的操作的信息。这些主体可以是产品、客户、供应商、销售、收入等。数据仓库不关注正在进行的操作，而是关注用于决策的数据建模和分析。

• 集成- 数据仓库是通过集成来自异构源（例如关系数据库、平面文件等）的数据来构建的。这种集成增强了数据的有效分析。

• 时间变量- 数据仓库中收集的数据以特定时间段进行标识。数据仓库中的数据提供历史角度的信息。

• 非易失性- 非易失性意味着添加新数据时不会删除以前的数据。数据仓库与操作数据库分开，因此操作数据库的频繁更改不会反映在数据仓库中。

注- 数据仓库不需要事务处理、恢复和并发控制，因为它是物理存储的并且与操作数据库分离。

数据仓库应用

如前所述，数据仓库可帮助业务主管组织、分析和使用数据进行决策。数据仓库是企业管理计划-执行-评估“闭环”反馈系统的唯一组成部分。数据仓库广泛应用于以下领域 -

• 金融服务
• 银行服务
• 消费品
• 零售业
• 受控制造

数据仓库的类型

信息处理、分析处理和数据挖掘是下面讨论的三种类型的数据仓库应用程序 -

• 信息处理- 数据仓库允许处理存储在其中的数据。可以通过查询、基本统计分析、使用交叉表、表格、图表或图形进行报告来处理数据。

• 分析处理- 数据仓库支持对存储在其中的信息进行分析处理。可以通过基本的 OLAP 操作来分析数据，包括切片和切块、向下钻取、向上钻取和旋转。

• 数据挖掘- 数据挖掘通过发现隐藏的模式和关联、构建分析模型、执行分类和预测来支持知识发现。这些挖掘结果可以使用可视化工具呈现。

数据仓库 - 概念

什么是数据仓库？

数据仓库是构建和使用数据仓库的过程。数据仓库是通过集成来自多个异构源的数据来构建的，这些数据支持分析报告、结构化和/或即席查询以及决策。数据仓库涉及数据清理、数据集成和数据整合。

使用数据仓库信息

有一些决策支持技术可以帮助利用数据仓库中的可用数据。这些技术可帮助管理人员快速有效地使用仓库。他们可以收集数据、分析数据，并根据仓库中的信息做出决策。仓库中收集的信息可用于以下任何领域 -

• 调整生产策略- 通过比较季度或年度销售额来重新定位产品和管理产品组合，可以很好地调整产品策略。

• 客户分析- 客户分析是通过分析客户的购买偏好、购买时间、预算周期等来完成的。

• 运营分析- 数据仓库还有助于客户关系管理和环境纠正。这些信息还使我们能够分析业务运营。

集成异构数据库

为了集成异构数据库，我们有两种方法 -

• 查询驱动方法
• 更新驱动方法

查询驱动方法

这是集成异构数据库的传统方法。这种方法用于在多个异构数据库之上构建包装器和集成器。这些积分器也称为中介器。

查询驱动方法的流程

• 当向客户端发出查询时，元数据字典会将查询转换为适合所涉及的各个异构站点的适当形式。

• 现在这些查询被映射并发送到本地查询处理器。

• 来自异构站点的结果被集成到全局答案集中。

缺点

• 查询驱动的方法需要复杂的集成和过滤过程。

• 这种方法效率非常低。

• 对于频繁的查询来说，这是非常昂贵的。

• 对于需要聚合的查询来说，这种方法的成本也非常高。

更新驱动方法

这是传统方法的替代方案。今天的数据仓库系统遵循更新驱动的方法，而不是前面讨论的传统方法。在更新驱动方法中，来自多个异构源的信息被预先集成并存储在仓库中。这些信息可供直接查询和分析。

优点

这种方法具有以下优点 -

• 这种方法提供了高性能。

• 数据预先在语义数据存储中进行复制、处理、集成、注释、总结和重组。

• 查询处理不需要接口来处理本地源的数据。

数据仓库工具和实用程序的功能

以下是数据仓库工具和实用程序的功能 -

• 数据提取- 涉及从多个异构源收集数据。

• 数据清理- 涉及发现并纠正数据中的错误。

• 数据转换- 涉及将数据从遗留格式转换为仓库格式。

• 数据加载- 涉及排序、汇总、合并、检查完整性以及构建索引和分区。

• 刷新- 涉及从数据源到仓库的更新。

注- 数据清理和数据转换是提高数据和数据挖掘结果质量的重要步骤。

数据仓库 - 术语

在本章中，我们将讨论数据仓库中一些最常用的术语。

元数据

元数据简单地定义为关于数据的数据。用于表示其他数据的数据称为元数据。例如，一本书的索引充当书中内容的元数据。换句话说，我们可以说元数据是引导我们获得详细数据的汇总数据。

在数据仓库方面，我们可以定义元数据如下 -

• 元数据是数据仓库的路线图。

• 数据仓库中的元数据定义了仓库对象。

• 元数据充当目录。该目录帮助决策支持系统定位数据仓库的内容。

元数据存储库

元数据存储库是数据仓库系统的组成部分。它包含以下元数据 -

• 业务元数据- 它包含数据所有权信息、业务定义和更改策略。

• 操作元数据- 它包括数据流通和数据沿袭。数据的流通性是指处于活动、存档或清除状态的数据。数据沿袭是指数据迁移和应用转换的历史记录。

• 用于从操作环境映射到数据仓库的数据- 它元数据包括源数据库及其内容、数据提取、数据分区、清理、转换规则、数据刷新和清除规则。

• 汇总算法- 包括维度算法、粒度数据、聚合、汇总等。

数据立方体

数据立方体帮助我们以多个维度表示数据。它是由维度和事实定义的。维度是企业保存记录的实体。

数据立方体图示

假设一家公司希望借助销售数据仓库来跟踪有关时间、项目、分支机构和位置的销售记录。这些维度允许跟踪每月销售额以及在哪个分店销售商品。每个维度都有一个关联的表。该表称为维度表。例如，“item”维度表可以具有诸如item_name、item_type和item_brand之类的属性。

下表显示了公司销售数据在时间、项目和位置维度方面的二维视图。

但在这个二维表中，我们仅记录了时间和项目。新德里的销售额按照时间和商品尺寸（根据所售商品类型）显示。如果我们想要以多一个维度（例如位置维度）查看销售数据，那么 3D 视图将会很有用。下表显示了有关时间、商品和地点的销售数据的 3D 视图 -

上面的 3-D 表可以表示为 3-D 数据立方体，如下图所示 -

数据库

数据集市包含对组织中的特定人员群体有价值的组织范围数据的子集。换句话说，数据集市仅包含特定于特定组的数据。例如，营销数据集市可能仅包含与商品、客户和销售相关的数据。数据集市仅限于主题。

关于数据集市需要记住的要点

• 基于Windows或基于Unix/Linux的服务器用于实现数据集市。它们是在低成本服务器上实现的。

• 数据集市的实施周期是在短时间内衡量的，即以周而不是数月或数年为单位。

• 如果数据集市的规划和设计不是在整个组织范围内进行，那么从长远来看，数据集市的生命周期可能会很复杂。

• 数据集市规模较小。

• 数据集市是按部门定制的。

• 数据集市的来源是按部门结构化的数据仓库。

• 数据集市是灵活的。

下图显示了数据集市的图形表示。

虚拟仓库

操作数据仓库的视图称为虚拟仓库。建立虚拟仓库很容易。构建虚拟仓库需要运营数据库服务器上有多余的容量。

数据仓库-交付流程

数据仓库从来都不是静态的；它随着业务的扩展而发展。随着业务的发展，其需求不断变化，因此数据仓库的设计必须能够适应这些变化。因此，数据仓库系统需要灵活。

理想情况下，应该有一个交付流程来交付数据仓库。然而，数据仓库项目通常会遇到各种问题，导致很难按照瀑布方法要求的严格有序的方式完成任务和交付成果。大多数时候，需求并没有被完全理解。只有收集和研究所有需求后才能完成架构、设计和构建组件。

运输方式

该交付方法是数据仓库交付所采用的联合应用程序开发方法的变体。我们已经分阶段进行了数据仓库交付流程，以最大程度地降低风险。我们将在这里讨论的方法不会缩短总体交付时间范围，而是确保通过开发过程逐步交付业务利益。

注- 交付过程分为多个阶段，以降低项目和交付风险。

下图解释了交付过程的各个阶段 -

信息技术战略

数据仓库是需要业务流程才能产生效益的战略投资。IT 战略需要为项目获取和保留资金。

商业案例

业务案例的目标是估计使用数据仓库应获得的业务收益。这些效益可能无法量化，但需要明确说明预计的效益。如果数据仓库没有明确的业务案例，那么业务在交付过程中的某个阶段往往会出现可信度问题。因此，在数据仓库项目中，我们需要了解投资的业务案例。

教育和原型制作

在确定解决方案之前，组织会尝试数据分析的概念并了解数据仓库的价值。这是通过原型设计来解决的。它有助于了解数据仓库的可行性和好处。小规模的原型制作活动可以促进教育进程，只要 -

• 该原型解决了既定的技术目标。

• 在展示可行性概念后，原型可以被丢弃。

• 该活动涉及数据仓库最终数据内容的一小部分。

• 活动时间范围并不重要。

为了尽早发布并带来商业利益，应牢记以下几点。

• 确定能够发展的架构。

• 重点关注业务需求和技术蓝图阶段。

• 将第一个构建阶段的范围限制到能够带来业务收益的最小范围。

• 了解数据仓库的短期和中期要求。

业务需求

为了提供高质量的交付成果，我们应该确保总体要求得到理解。如果我们了解短期和中期的业务需求，那么我们就可以设计一个解决方案来满足短期需求。然后可以将短期解决方案发展为完整的解决方案。

此阶段确定以下几个方面 -

• 要应用于数据的业务规则。

• 数据仓库内信息的逻辑模型。

• 查询配置文件的即时需求。

• 提供此数据的源系统。

技术蓝图

此阶段需要提供满足长期需求的整体架构。此阶段还提供必须在短期内实施才能获得任何业务利益的组件。蓝图需要确定以下内容。

• 系统整体架构。
• 数据保留政策。
• 备份和恢复策略。
• 服务器和数据集市架构。
• 硬件和基础设施的容量计划。
• 数据库设计的组成部分。

构建版本

在此阶段，将产生第一个生产交付物。该生产可交付成果是数据仓库的最小组件。这个最小的组件增加了商业利益。

历史负载

在此阶段，所需历史记录的其余部分将加载到数据仓库中。在此阶段，我们不会添加新实体，但可能会创建额外的物理表来存储增加的数据量。

让我们举个例子。假设构建版本阶段交付了一个具有 2 个月历史的零售销售分析数据仓库。这些信息将允许用户仅分析最近的趋势并解决短期问题。在这种情况下，用户无法识别年度和季节性趋势。为了帮助他做到这一点，可以从档案中加载最近两年的销售历史记录。现在40GB数据扩展到400GB。

注- 备份和恢复过程可能会变得复杂，因此建议在单独的阶段中执行此活动。

即席查询

在此阶段，我们配置一个用于操作数据仓库的即席查询工具。这些工具可以生成数据库查询。

注意- 当数据库被大量修改时，建议不要使用这些访问工具。

自动化

在此阶段，运营管理流程完全自动化。这些将包括 -

• 将数据转换为适合分析的形式。

• 监视查询配置文件并确定适当的聚合以维护系统性能。

• 从不同源系统提取和加载数据。

• 从数据仓库中的预定义定义生成聚合。

• 备份、恢复和归档数据。

扩大范围

在此阶段，数据仓库被扩展以满足一组新的业务需求。范围可以通过两种方式扩展 -

• 通过将附加数据加载到数据仓库中。

• 通过使用现有信息引入新的数据集市。

注- 此阶段应单独执行，因为它涉及大量的工作和复杂性。

需求演变

从交付过程来看，需求总是在变化的。它们不是静态的。交付流程必须支持这一点并允许这些更改反映在系统中。

通过围绕业务流程中数据的使用（而不是现有查询的数据要求）设计数据仓库，可以解决此问题。

该架构旨在更改和扩展以匹配业务需求，该流程作为伪应用程序开发流程运行，其中新的需求不断地输入到开发活动中并生成部分可交付成果。这些部分可交付成果被反馈给用户，然后进行重新设计，以确保整个系统不断更新以满足业务需求。

数据仓库 - 系统进程

我们有固定数量的操作要应用于操作数据库，并且我们有明确定义的技术，例如使用规范化数据、保持表较小等。这些技术适合交付解决方案。但对于决策支持系统，我们不知道将来需要执行哪些查询和操作。因此，应用于操作数据库的技术并不适合数据仓库。

在本章中，我们将讨论如何在 Unix 和关系数据库等顶级开放系统技术上构建数据仓库解决方案。

数据仓库中的流程

数据仓库有四个主要流程 -

• 提取并加载数据。
• 清理和转换数据。
• 备份并归档数据。
• 管理查询并将其定向到适当的数据源。

提取和加载过程

数据提取从源系统获取数据。数据加载获取提取的数据并将其加载到数据仓库中。

注意- 在将数据加载到数据仓库之前，必须重建从外部源提取的信息。

控制过程

控制过程包括确定何时开始数据提取以及数据的一致性检查。控制过程确保工具、逻辑模块和程序在正确的时间按正确的顺序执行。

何时开始提取

数据在提取时需要处于一致的状态，即数据仓库应该向用户表示单一的、一致的信息版本。

例如，在电信行业的客户分析数据仓库中，将客户数据库中周三晚上 8 点的客户列表与周二晚上 8 点之前的客户订阅事件合并起来是不合逻辑的。这意味着我们正在寻找没有关联订阅的客户。

加载数据

提取数据后，会将其加载到临时数据存储中，并在其中进行清理并使其保持一致。

注意- 仅当所有数据源都已加载到临时数据存储中时才会执行一致性检查。

清洁和转型流程

一旦数据被提取并加载到临时数据存储中，就可以执行清理和转换。以下是清洁和改造所涉及的步骤列表 -

• 清理加载的数据并将其转换为结构
• 对数据进行分区
• 聚合

清理加载的数据并将其转换为结构

清理和转换加载的数据有助于加快查询速度。可以通过使数据一致来完成 -

• 在其自身之内。
• 与同一数据源中的其他数据。
• 与其他源系统中的数据。
• 与仓库中存在的现有数据。

转换涉及将源数据转换为结构。结构化数据可以提高查询性能并降低运营成本。数据仓库中包含的数据必须进行转换，以支持性能要求并控制持续的运营成本。

数据分区

它将优化硬件性能并简化数据仓库的管理。在这里，我们将每个事实表划分为多个单独的分区。

聚合

需要聚合来加速常见查询。聚合依赖于这样一个事实：最常见的查询将分析详细数据的子集或聚合。

备份和存档数据

为了在数据丢失、软件故障或硬件故障时恢复数据，有必要定期进行备份。归档涉及以允许在需要时快速恢复的格式从系统中删除旧数据。

例如，在零售销售分析数据仓库中，可能需要将数据保存3年，其中最近6个月的数据在线保存。在这种情况下，通常需要能够对今年和去年进行月度比较。在这种情况下，我们需要从存档中恢复一些数据。

查询管理流程

该过程执行以下功能 -

• 管理查询。

• 有助于加快 queris 的执行时间。

• 将查询定向到最有效的数据源。

• 确保以最有效的方式使用所有系统资源。

• 监视实际的查询配置文件。

仓库管理流程使用此流程中生成的信息来确定要生成哪些聚合。在将信息定期加载到数据仓库期间，此过程通常不会运行。

数据仓库 - 架构

在本章中，我们将讨论数据仓库设计的业务分析框架和数据仓库的架构。

业务分析框架

业务分析师从数据仓库获取信息来衡量性能并做出关键调整，以赢得市场上的其他业务持有者。拥有数据仓库具有以下优点 -

• 由于数据仓库可以快速有效地收集信息，因此可以提高企业生产力。

• 数据仓库为我们提供了客户和项目的一致视图，因此，它可以帮助我们管理客户关系。

• 数据仓库还可以通过以一致且可靠的方式长期跟踪趋势和模式来帮助降低成本。

要设计一个有效、高效的数据仓库，我们需要了解和分析业务需求，构建业务分析框架。每个人对数据仓库的设计都有不同的看法。这些观点如下：

• 自顶向下视图- 此视图允许选择数据仓库所需的相关信息。

• 数据源视图- 该视图呈现操作系统捕获、存储和管理的信息。

• 数据仓库视图- 该视图包括事实表和维度表。它表示存储在数据仓库内的信息。

• 业务查询视图- 这是从最终用户的角度来看的数据视图。

三层数据仓库架构

数据仓库一般采用三层架构。以下是数据仓库架构的三层。

• 底层- 架构的底层是数据仓库数据库服务器。它就是关系数据库系统。我们使用后端工具和实用程序将数据输入底层。这些后端工具和实用程序执行提取、清理、加载和刷新功能。

• 中间层- 在中间层，我们有 OLAP 服务器，可以通过以下方式之一实现。

  • 采用关系型OLAP（ROLAP），这是一种扩展的关系数据库管理系统。ROLAP 将多维数据的操作映射到标准关系操作。

  • 通过多维OLAP（MOLAP）模型，直接实现多维数据和操作。

• 顶层- 该层是前端客户端层。该层包含查询工具和报告工具、分析工具和数据挖掘工具。

下图描述了数据仓库的三层架构 -

数据仓库模型

从数据仓库架构的角度来看，我们有以下数据仓库模型 -

• 虚拟仓库
• 数据库
• 企业仓库

虚拟仓库

操作数据仓库的视图称为虚拟仓库。建立虚拟仓库很容易。构建虚拟仓库需要运营数据库服务器上有多余的容量。

数据库

数据集市包含组织范围数据的子集。该数据子集对于组织的特定组很有价值。

换句话说，我们可以声称数据集市包含特定于特定群体的数据。例如，营销数据集市可能包含与商品、客户和销售相关的数据。数据集市仅限于主题。

关于数据集市要记住的要点 -

• 基于Windows或基于Unix/Linux的服务器用于实现数据集市。它们是在低成本服务器上实现的。

• 实施数据集市周期是在短时间内测量的，即以周而不是数月或数年为单位。

• 如果数据集市的规划和设计不是在组织范围内进行的，那么从长远来看，数据集市的生命周期可能会很复杂。

• 数据集市规模较小。

• 数据集市是按部门定制的。

• 数据集市的来源是按部门结构化的数据仓库。

• 数据集市非常灵活。

企业仓库

• 企业仓库收集整个组织的所有信息和主题

• 它为我们提供了企业范围的数据集成。

• 数据来自操作系统和外部信息提供商。

• 这些信息的大小可以从几 GB 到数百 GB、TB 或更大。

负载管理器

该组件执行提取和加载进程所需的操作。

负载管理器的大小和复杂性因不同数据仓库的特定解决方案而异。

负载管理器架构

负载管理器执行以下功能 -

• 从源系统中提取数据。

• 快速将提取的数据加载到临时数据存储中。

• 对类似于数据仓库中结构的结构进行简单转换。

从源中提取数据

数据是从操作数据库或外部信息提供者中提取的。网关是用于提取数据的应用程序。它由底层 DBMS 支持，允许客户端程序生成在服务器上执行的 SQL。开放数据库连接(ODBC)、Java 数据库连接(JDBC) 是网关的示例。

快速加载

• 为了最小化总加载窗口，需要以最快的时间将数据加载到仓库中。

• 转换影响数据处理的速度。

• 在应用转换和检查之前将数据加载到关系数据库中会更有效。

• 事实证明，网关技术并不合适，因为当涉及大量数据时，它们的性能往往不佳。

简单的转换

加载时可能需要执行简单的转换。完成此操作后，我们就可以进行复杂的检查。假设我们正在加载 EPOS 销售交易，我们需要执行以下检查：

• 删除仓库内所有不需要的列。
• 将所有值转换为所需的数据类型。

仓库经理

仓库经理负责仓库管理流程。它由第三方系统软件、C程序和shell脚本组成。

仓库经理的规模和复杂性因具体解决方案而异。

仓库经理架构

仓库经理包括以下内容 -

• 控制过程
• 存储过程或 C 与 SQL
• 备份/恢复工具
• SQL脚本

仓库经理执行的操作

• 仓库经理分析数据以执行一致性和引用完整性检查。

• 针对基础数据创建索引、业务视图、分区视图。

• 生成新的聚合并更新现有聚合。生成标准化。

• 将源数据转换并合并到已发布的数据仓库中。

• 备份数据仓库中的数据。

• 对已达到捕获寿命终点的数据进行归档。

注意- 仓库经理还分析查询配置文件以确定索引和聚合是否合适。

查询管理器

• 查询管理器负责将查询定向到合适的表。

• 通过将查询定向到适当的表，可以提高查询和响应生成的速度。

• 查询管理器负责调度用户提出的查询的执行。

查询管理器架构

以下屏幕截图显示了查询管理器的体系结构。它包括以下内容：

• 通过 C 工具或 RDBMS 进行查询重定向
• 存储过程
• 查询管理工具
• 通过 C 工具或 RDBMS 进行查询调度
• 通过第三方软件进行查询调度

详细资料

详细信息不会在线保存，而是聚合到下一个详细级别，然后存档到磁带。数据仓库的详细信息部分将详细信息保存在星片模式中。详细信息被加载到数据仓库中以补充聚合数据。

下图直观地展示了详细信息的存储位置及其使用方式。

注意- 如果详细信息离线保存以最小化磁盘存储，我们应该确保数据在归档之前已被提取、清理并转换为星片模式。

摘要信息

摘要信息是存储预定义聚合的数据仓库的一部分。这些聚合由仓库经理生成。摘要信息必须被视为瞬态信息。它会随时变化，以响应不断变化的查询配置文件。

有关摘要信息的注意事项如下 -

• 摘要信息可加快常见查询的性能。

• 它增加了运营成本。

• 每当新数据加载到数据仓库中时就需要更新它。

• 它可能尚未备份，因为它可以根据详细信息重新生成。

数据仓库-OLAP

在线分析处理服务器（OLAP）基于多维数据模型。它允许经理和分析师通过快速、一致和交互式的信息访问来深入了解信息。本章介绍了OLAP的类型、OLAP的操作、OLAP之间的区别以及统计数据库和OLTP。

OLAP 服务器的类型

我们有四种类型的 OLAP 服务器 -

• 关系型OLAP（ROLAP）
• 多维OLAP（MOLAP）
• 混合OLAP（HOLAP）
• 专门的 SQL 服务器

关系型联机分析处理

ROLAP服务器放置在关系型后端服务器和客户端前端工具之间。为了存储和管理仓库数据，ROLAP 使用关系型或扩展关系型 DBMS。

ROLAP 包括以下内容 -

• 聚合导航逻辑的实现。
• 针对每个 DBMS 后端的优化。
• 附加工具和服务。

多维OLAP

MOLAP 使用基于数组的多维存储引擎来实现数据的多维视图。对于多维数据存储，如果数据集稀疏，则存储利用率可能较低。因此，许多MOLAP服务器使用两级数据存储表示来处理密集和稀疏数据集。

混合联机分析处理

混合 OLAP 是 ROLAP 和 MOLAP 的组合。它提供了 ROLAP 更高的可扩展性和 MOLAP 更快的计算。HOLAP 服务器允许存储大量数据的详细信息。聚合单独存储在 MOLAP 存储中。

专门的 SQL 服务器

专用 SQL 服务器为只读环境中星型和Snowflake模式的 SQL 查询提供高级查询语言和查询处理支持。

OLAP操作

由于OLAP服务器基于数据的多维视图，因此我们将讨论多维数据中的OLAP操作。

以下是 OLAP 操作的列表 -

• 卷起
• 深入钻取
• 切片和切丁
• 枢轴（旋转）

卷起

Roll-up 通过以下任一方式对数据立方体执行聚合 -

• 通过爬升维度的概念层次结构
• 通过降维

下图说明了汇总的工作原理。

• 汇总是通过爬升维度位置的概念层次结构来执行的。

• 最初的概念层次是“街道<城市<省<国家”。

• 上滚时，通过将位置层次结构从城市级别提升到国家/地区级别来聚合数据。

• 数据按城市而不是国家分组。

• 执行汇总时，数据立方体中的一个或多个维度将被删除。

深入钻取

向下钻取是上卷的逆操作。它通过以下方式之一执行 -

• 通过逐步降低维度的概念层次结构
• 通过引入一个新的维度。

下图说明了向下钻取的工作原理 -

• 向下钻取是通过逐步降低维度时间的概念层次结构来执行的。

• 最初，概念层次结构是“日 < 月 < 季度 < 年”。

• 向下钻取时，时间维度从季度级别下降到月份级别。

• 执行向下钻取时，会添加数据立方体中的一个或多个维度。

• 它将数据从不太详细的数据导航到非常详细的数据。

片

切片操作从给定的多维数据集中选择一个特定维度并提供一个新的子多维数据集。考虑下图，它显示了切片的工作原理。

• 这里使用标准时间=“Q1”对维度“时间”执行切片。

• 它将通过选择一个或多个维度来形成一个新的子立方体。

骰子

Dice 从给定的立方体中选择两个或多个维度并提供一个新的子立方体。考虑下图，该图显示了骰子的操作。

基于以下选择标准对立方体进行的骰子操作涉及三个维度。

• （地点=“多伦多”或“温哥华”）
• （时间=“Q1”或“Q2”）
• （项目=“移动”或“调制解调器”）

枢

枢转操作也称为旋转。它在视图中旋转数据轴，以提供数据的替代表示。考虑下图，该图显示了枢轴操作。

OLAP 与 OLTP

数据仓库 - 关系型 OLAP

关系型OLAP服务器放置在关系型后端服务器和客户端前端工具之间。为了存储和管理仓库数据，关系型 OLAP 使用关系型或扩展关系型 DBMS。

ROLAP 包括以下内容 -

• 聚合导航逻辑的实现
• 每个 DBMS 后端的优化
• 附加工具和服务

需要记住的要点

• ROLAP 服务器具有高度可扩展性。

• ROLAP 工具跨多个维度分析大量数据。

• ROLAP 工具存储和分析高度不稳定和可变的数据。

关系型OLAP架构

ROLAP 包括以下组件 -

• 数据库服务器
• 罗拉处理服务器
• 前端工具。

优点

• ROLAP 服务器可以轻松地与现有 RDBMS 一起使用。
• 由于无法存储零事实，因此可以有效地存储数据。
• ROLAP 工具不使用预先计算的数据立方体。
• 微策略DSS服务器采用ROLAP方式。

缺点

• 查询性能差。

• 可扩展性的一些限制取决于所使用的技术架构。

数据仓库-多维OLAP

多维 OLAP (MOLAP) 使用基于数组的多维存储引擎来实现数据的多维视图。对于多维数据存储，如果数据集稀疏，则存储利用率可能较低。因此，许多 MOLAP 服务器使用两级数据存储表示来处理密集和稀疏数据集。

要记住的要点 -

• MOLAP 工具以一致的响应时间处理信息，无论所选的汇总或计算级别如何。

• MOLAP 工具需要避免创建关系数据库来存储分析数据的许多复杂性。

• MOLAP 工具需要尽可能快的性能。

• MOLAP服务器采用两级存储表示来处理密集和稀疏数据集。

• 更密集的子立方体被识别并存储为数组结构。

• 稀疏子立方体采用压缩技术。

MOLAP架构

MOLAP 包括以下组件 -

• 数据库服务器。
• MOLAP 服务器。
• 前端工具。

优点

• MOLAP 允许对预先计算的汇总数据进行最快的索引。
• 帮助连接到网络并需要分析更大、定义较少的数据的用户。
• MOLAP 更易于使用，因此适合没有经验的用户。

缺点

• MOLAP 无法包含详细数据。
• 如果数据集稀疏，存储利用率可能会较低。

MOLAP 与 ROLAP

数据仓库 - 模式

Schema是整个数据库的逻辑描述。它包括所有记录类型的记录的名称和描述，包括所有关联的数据项和聚合。与数据库非常相似，数据仓库也需要维护模式。数据库使用关系模型，而数据仓库使用星型、Snowflake型和事实星座模型。在本章中，我们将讨论数据仓库中使用的模式。

星型模式

• 星型模式中的每个维度仅用一维表表示。

• 该维度表包含属性集。

• 下图展示了某公司在时间、项目、分支机构、地点四个维度的销售数据。

• 中心有一个事实表。它包含四个维度中每个维度的键。

• 事实表还包含属性，即销售美元和销售单位。

注意- 每个维度只有一个维度表，每个表保存一组属性。例如，位置维度表包含属性集{location_key, street, city,province_or_state,country}。这种限制可能会导致数据冗余。例如，“温哥华”和“维多利亚”这两个城市都位于加拿大不列颠哥伦比亚省。此类城市的条目可能会导致属性province_or_state 和country 上的数据冗余。

Snowflake模式

• Snowflake 架构中的某些维度表已标准化。

• 规范化将数据拆分到其他表中。

• 与星型模式不同，Snowflake模式中的维度表是标准化的。例如，星型模式中的商品维度表被规范化并拆分为两个维度表，即商品表和供应商表。

• 现在，项目维度表包含属性 item_key、item_name、type、brand 和 seller-key。

• 供应商键链接到供应商维度表。供应商维表包含属性supplier_key 和supplier_type。

注- 由于Snowflake模式的标准化，减少了冗余，因此，它变得易于维护并节省存储空间。

事实星座图

• 事实星座有多个事实表。它也称为星系模式。

• 下图显示了两个事实表，即销售和运输。

• 销售事实表与星型模式中的销售事实表相同。

• 运输事实表有五个维度，即item_key、time_key、shipper_key、from_location、to_location。

• 运输事实表还包含两个度量，即销售美元和销售单位。

• 还可以在事实表之间共享维度表。例如，时间、项目和位置维度表在销售和运输事实表之间共享。

模式定义

多维模式是使用数据挖掘查询语言 (DMQL) 定义的。多维数据集定义和维度定义这两个原语可用于定义数据仓库和数据集市。

多维数据集定义的语法

define cube < cube_name > [ < dimension-list > }: < measure_list >

维度定义的语法

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

星型模式定义

我们讨论的星型模式可以使用数据挖掘查询语言（DMQL）来定义，如下所示 -

define cube sales star [time, item, branch, location]:   
    	   
dollars sold = sum(sales in dollars), units sold = count(*)    	  

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)        	
define dimension branch as (branch key, branch name, branch type)              	
define dimension location as (location key, street, city, province or state, country)

Snowflake模式定义

可以使用 DMQL 定义Snowflake模式，如下所示 -

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

事实星座模式定义

事实星座模式可以使用 DMQL 定义，如下所示 -

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

数据仓库-分区策略

进行分区是为了提高性能并促进数据的轻松管理。分区还有助于平衡系统的各种要求。它通过将每个事实表划分为多个单独的分区来优化硬件性能并简化数据仓库的管理。在本章中，我们将讨论不同的分区策略。

为什么需要分区？

分区很重要，原因如下 -

• 为了方便管理，
• 为了协助备份/恢复，
• 以提高性能。

方便管理

数据仓库中的事实表的大小可以增长到数百GB。如此巨大的事实表很难作为单个实体进行管理。因此需要分区。

协助备份/恢复

如果我们不对事实表进行分区，那么我们必须加载包含所有数据的完整事实表。分区允许我们只加载定期所需的数据。它减少了加载时间并增强了系统的性能。

注- 为了减少备份大小，当前分区以外的所有分区都可以标记为只读。然后我们就可以将这些分区置于不可修改的状态。然后就可以备份它们了。这意味着只备份当前分区。

提高绩效

通过将事实表划分为数据集，可以增强查询过程。查询性能得到增强，因为现在查询仅扫描那些相关的分区。它不必扫描整个数据。

水平分区

事实表的分区方式有很多种。在水平分区时，我们必须牢记数据仓库的可管理性要求。

按时间划分为相等的段

在这种分区策略中，事实表是根据时间段进行分区的。这里每个时间段都代表企业内的一个重要保留期。例如，如果用户查询本月至今的数据，则适合将数据划分为每月段。我们可以通过删除分区表中的数据来重用分区表。

按时间划分为不同大小的段

这种分区是在不经常访问老化数据的情况下进行的。它被实现为一组用于相对当前数据的小分区，用于非活动数据的较大分区。

注意事项

• 详细信息仍然可以在线获取。

• 物理表的数量保持相对较少，从而降低了运营成本。

• 该技术适用于需要混合使用近期历史数据和整个历史数据挖掘的情况。

• 当分区配置文件定期更改时，此技术不太有用，因为重新分区会增加数据仓库的运营成本。

不同维度上的分区

事实表还可以根据时间以外的维度进行分区，例如产品组、区域、供应商或任何其他维度。让我们举个例子。

假设市场功能已被构建为不同的区域部门，就像逐个 州一样。如果每个区域想要查询在其区域内捕获的信息，则将事实表划分为区域分区将被证明更有效。这将导致查询速度加快，因为它不需要扫描不相关的信息。

注意事项

• 查询不必扫描不相关的数据，从而加快了查询过程。

• 如果尺寸将来不太可能改变，则此技术不合适。因此，值得确定尺寸将来不会改变。

• 如果维度发生变化，则整个事实表必须重新分区。

注意- 我们建议仅根据时间维度执行分区，除非您确定建议的维度分组在数据仓库的生命周期内不会改变。

按表大小分区

当在任何维度上对事实表进行分区都没有明确的依据时，我们应该根据事实表的大小对事实表进行分区。我们可以将预定的大小设置为临界点。当表超过预定大小时，将创建新的表分区。

注意事项

• 这种分区管理起来很复杂。

• 它需要元数据来识别每个分区中存储的数据。

划分维度

如果一个维度包含大量条目，则需要对维度进行分区。这里我们必须检查维度的大小。

考虑一个随时间变化的大型设计。如果我们需要存储所有变化以便进行比较，那么该维度可能会非常大。这肯定会影响响应时间。

循环分区

在循环技术中，当需要新分区时，旧分区将被存档。它使用元数据允许用户访问工具引用正确的表分区。

该技术可以轻松实现数据仓库内表管理设施的自动化。

垂直分区

垂直分区，垂直分割数据。下图描述了如何完成垂直分区。

垂直分区可以通过以下两种方式执行 -

• 正常化
• 行分割

正常化

规范化是数据库组织的标准关系方法。在这种方法中，行被折叠成一行，因此减少了空间。查看下表，了解如何执行标准化。

标准化前的表