创建和使用数据仓库概述

单位在正常的业务运作过程中需要收集数据。数据仓库的目的是合并和组织这些数据，以便可对其进行分析并用来支持业务决策。在许多情况下，数据仓库包含单位的动态历史记录。

数据仓库通常包含历史数据，这些数据经常是从各种完全不同的来源收集的（如联机事务处理 (OLTP) 系统、传统系统、文本文件或电子表格）。数据仓库组合这些数据，对其进行清理使其准确一致，并进行组织使其便于轻松高效地查询。

有些数据仓库定义包括多个元素，如数据准备区、清理进程、含有数据仓库数据的数据库以及组织数据并将其提供给客户端应用程序的工具。有些定义则将数据仓库限制为包含数据仓库数据的数据库。在大型数据仓库应用程序中，通常将数据分段为称为数据集市的专用组件，而数据集市处理单位的个别组件。有些定义将数据集市作为数据仓库的一部分；有些定义则将其作为单独的实体。术语 "数据仓库"的本来含义通常视其所在的上下文而定。本节中的主题一般使用最广泛的定义，并将个别元素作为数据仓库上下文的内部组件进行讨论。

数据仓库是一种高级、复杂的技术。在本文档中不可能完整地描述数据仓库，但有许多极好的参考书和培训课程可提高您对数据仓库的理解。本节中的主题讨论数据仓库的元素和进程，并标识许多由 Microsoft® SQL Server™ 2000 提供的强大工具，可帮助您完成创建、使用和维护数据仓库的任务。

主题 | 描述
SQL Server 2000 数据仓库工具 | 描述 SQL Server 2000 所提供的、常用于数据仓库应用程序的工具。
数据仓库的组成部分 | 描述构成数据仓库的元素。
创建数据仓库 | 描述数据仓库的创建步骤。
使用数据仓库 | 描述用于准备显示数据以及为客户端提供信息访问能力的工具和方法。
维护数据仓库 | 描述更新数据仓库数据以及修改给用户显示的信息所涉及的进程。


SQL Server 2000 数据仓库工具

Microsoft® SQL Server™ 2000 提供了许多支持数据库应用程序的工具。这些工具中有些工具在数据仓库中使用得较频繁，而有些则是专用于解决数据仓库的特殊要求。这里列出的工具常用于数据仓库应用程序，但是大多数工具还可用于其它的数据库应用程序。这里没有提到的许多其它工具通常可用来解决数据仓库应用程序中的特定问题。

这里对数据仓库应用程序中常用的工具做了一般性的描述，并且提供了到有关工具本身的更详细信息的链接。数据仓库应用程序中的这些工具的用法在本节的其它主题中专门讨论。

关系数据库

数据仓库使用关系数据库技术作为其设计、结构和维护的基础。SQL Server 2000 的核心组件是强大的、全功能的关系数据库引擎。SQL Server 2000 提供很多设计和操作关系数据库的工具，与该数据库所用于的应用程序无关。有关很多关系数据库管理工具的信息遍及整个 SQL Server 2000 文档内。有关更多信息，请参见 SQL Server 2000 功能。

数据转换服务

数据仓库应用程序需要将来自许多源的数据转换为聚合在一起的、一致的数据集，这些数据集经过了适当配置可用于数据仓库操作。SQL Server 2000 为这类任务提供了一个强大的工具，即数据转换服务 (DTS)。DTS 可以访问来自各种不同源的数据，并使用内置的自定义转换规范转换这些数据。有关更多信息，请参见 DTS 概述。

复制

数据库复制是具有许多用途的强大工具。复制通常用于分发数据和协调联机事务处理系统 (OLTP) 中分布式数据的更新，还可用于数据仓库。一些潜在的数据仓库的复制应用是将数据从中央数据仓库分发到数据集市，以及从数据准备区更新数据仓库数据。有关更多信息，请参见复制概述。

Analysis Services

数据仓库收集和组织企业数据以支持组织通过分析作出决策。SQL Server 2000 Analysis Services 提供联机分析处理 (OLAP) 技术，用以组织大量的数据仓库数据供客户端工具进行快速分析，并提供先进的数据挖掘技术以分析和发现数据仓库数据内的信息。有关更多信息，请参见 Analysis Services 概述。

English Query

English Query 通过用英语进行查询，如 "Show me the sales for stores in California for 1996 through 1998"（显示加利福尼亚州的商店从 1996 年到 1998 年的销售额），提供对数据仓库数据的访问。English Query 是用于创建客户端应用程序的开发工具，使客户端应用程序可以将英语转换为 SQL 语法以查询关系数据库，或者转换为多维表达式 (MDX) 语法以查询 OLAP 多维数据集。可以开发专用于您的数据仓库的 English Query 模型，以便将高级复杂的 SQL 或 MDX 查询简化为简单的英文问题。有关更多信息，请参见 English Query 概述。

Meta Data Services

在 SQL Server 2000 的多种不同工具中，有许多可将中央知识库的元数据存储在 msdb 系统数据库中。SQL Server 2000 Meta Data Services 提供用于查看这些元数据的浏览器，并提供用于开发自定义元数据应用程序的应用程序接口。有关更多信息，请参见 Meta Data Services 概述。


数据仓库的组成部分

有几个构成数据仓库的物理元素和功能元素：本节中的主题就是讨论这些元素。

主题 | 描述
数据集市 | 描述数据集市，包含用于特殊目的的数据仓库数据部分。
关系数据库 | 描述关系数据库在数据仓库中的作用和使用。
数据源 | 描述数据仓库中通常使用的各种结构化数据源。
数据准备区 | 描述从数据源中析取出来准备用于数据仓库的区域。
显示服务 | 描述组织和分析数据仓库信息并使其可由客户端应用程序使用的服务。
最终用户分析 | 描述如何使用客户端应用程序访问和分析数据仓库中的信息。


数据集市

在有些数据仓库版本中，数据集市是微型的数据仓库；而在有些版本中，数据集市仅仅是数据仓库的一段。数据集市通常用于为单位的职能部门提供信息。典型示例是销售部门、库存和发货部门、财务部门、高级管理部门等的数据集市。数据集市还可用于将数据仓库数据分段以反映按地理划分的业务，其中的每个地区都是相对自治的。例如，大型服务单位可能将地区运作中心视为单独的业务单元，每个这样的单元都有自己的数据集市以补充主数据仓库。

在有些设计中，数据集市是完全独立的数据仓库，作为分布式数据仓库的成员补充总体结构。而在有些设计中，数据集市则通过定期更新接收来自主数据仓库的数据，在这种情况下，数据集市的功能经常受限于客户端的显示服务。

无论数据集市提供何种功能，它们都必须被设计为主数据仓库的组件，以使数据的组织、格式和架构在整个数据仓库内保持一致。表的设计、更新机制或维度的层次结构如果不一致，可能会使数据无法在整个数据仓库内重新使用，并可能导致由相同的数据生成不一致的报表。例如，由财务部门的数据集市（该数据集市按管理报表结构组织销售队伍）生成的汇总报表不大可能与由销售部门的数据集市（该数据集市按地理区域组织相同的销售队伍）生成的汇总报表保持一致。没有必要为获得一致性而将一个数据视图强加在所有数据集市上；通常可以设计一致的架构和数据格式，使得可以有很多不同的数据视图同时保持互操作性。例如，使用时间、客户和产品数据的标准格式及组织方式，不会妨碍数据集市以库存、销售额或财务分析等不同的角度显示信息。

应从作为数据仓库组件的角度设计数据集市，而无需考虑它们各自的功能或构造。这使得信息在整个单位内保持一致和可用。

根据数据集市的设计方式，Microsoft® SQL Server™ 2000 中用于数据集市的工具可以包括任何用于数据仓库的工具。如果数据集市在本地创建和维护并作为独立的实体参与单位的数据仓库，则数据集市的创建和维护将涉及对数据仓库的所有操作。如果数据集市是从中央数据仓库分发数据的本地访问点，则只可能包含工具的子集。

将数据仓库数据分发到数据集市

如果数据仓库的数据在中央数据仓库中维护，则准备该数据并将其装入中央位置的数据仓库中，然后分发到本地数据集市。

SQL Server 代理程序和数据转换服务 (DTS) 可用于调度和执行数据转换，包括筛选出适合数据集市的数据和更新数据集市中适当的表。还可以创建和调度 DTS 包，使其在收到来自中央数据仓库的新数据之后，更新数据集市中的 OLAP 多维数据集。

某些数据仓库分发方案还可以通过复制来协调和维护数据集市的数据。

请参见

DTS 概述

SQLServerAgent 服务

复制概述


关系数据库

关系数据库是为数据仓库提供强大功能的基础引擎。许多特性和功能已经开发出来并得到增强，使得关系数据库成为联机事务处理 (OLTP) 系统的主力，而且这些特性和功能可直接应用于数据仓库。

关系数据库用于数据仓库系统，其作用是在数据准备数据库中临时存储、清理和转换传入的数据，容纳和管理数据仓库数据库中的大量数据，并支持数据集市。

数据仓库存储、管理和操作巨大的数据量，这些数据常由数亿行历史信息组成。关系数据库必须提供快速的数据传输和更新、灵活高效的索引以及先进高效的查询能力，以便组织和检索数据仓库的数据。在 OLTP 系统中，先进的锁定机制和高度的多表事务吞吐量可能比在数据仓库中更重要，但这样的功能通常基于极其高效的关系引擎进行设计，而这在数据仓库操作中非常重要。

Microsoft® SQL Server™ 2000 为 OLTP 系统和数据仓库数据存储提供了非常强大的关系数据库。还包括许多对数据仓库至关重要的强大功能，如数据转换服务 (DTS)、复制管理、支持多维联机分析处理 (OLAP) 和数据挖掘服务器及管理的 SQL Server 2000 Analysis Services、SQL Server 2000 Meta Data Services以及可使用普通语言对关系数据和多维数据进行查询的 English Query。

请参见

创建和维护数据库概述

数据库性能优化概述


数据源

数据仓库用于为决策者提供信息。为此，数据仓库必须将来自单位中许多源的数据聚集和合并为一致的数据集，以准确地反映单位的业务运作情况和历史记录。

单位通常有多个联机事务处理 (OLTP) 系统来捕获日常的业务运作情况。这些 OLTP 系统很少与数据仓库同时设计。它们甚至可能是由不同单位设计的，尤其当单位是通过并购得到壮大的情况下。数据库架构和数据元素标识键在数据库之间通常是不同的。例如，被收购公司的 OLTP 中的客户表可能包含与收购公司相同的客户和产品，但使用的标识系统不同。从这些 OLTP 系统中析取的数据必须转换为常用表示法。

已使用多年的传统系统常常包含不规范的数据和不常见的数据标识设计，而且在查询上不够灵活。

对业务分析至关重要的数据甚至可能驻留在个别台式机上的个人数据库和电子表格中，尤其当单位是在没有中央信息技术组的情况下发展壮大的时候。必须将这样的数据捕获到数据仓库中。

数据仓库中使用的数据源必须被标识，并且进行技术开发以便从中析取数据。数据转换服务 (DTS) 提供功能强大的工具，可从多种不同的数据源中析取和转换数据。有关更多信息，请参见 DTS 概述和 DTS 基础。


数据准备区

用于数据仓库的数据必须从数据源中析取，进行清理及格式化以保持一致性，并转换为数据仓库架构。数据准备区有时称为数据中间存储区，它是关系数据库，在这里从数据源中析取数据，将数据转换为常用格式，检查一致性和引用完整性，并准备装入数据仓库数据库。在某些数据仓库实施方案中，数据准备区和数据仓库数据库可以组合在一起，只要清理和转换操作不影响为数据仓库数据的最终用户提供服务的性能或操作。由于数据源不同以及数据准备操作强加在联机事务处理系统上的处理负荷，几乎无法选择在源数据库中执行准备操作。用于数据准备操作的关系数据库无论在何处执行，都必须具有强大的数据操作和转换功能，比如 Microsoft® SQL Server™ 2000 所提供的功能。

最初装载数据仓库后，需不断地利用数据准备区为更新数据仓库准备新数据。在大多数数据仓库系统中，这些不断进行的操作是定期执行的，常被调度为使性能对可操作的数据源系统的影响减到最小。

使用数据仓库和独立于数据源的数据准备区可提高管理数据仓库的效率。尝试转换数据源系统中的数据会对联机事务处理 (OLTP) 的性能造成不良影响，而许多传统系统没有高效的或容易执行的转换功能。很少能够协调从不同数据源中析取的不一致的数据，直到将数据收集到公用数据库中，这时可以更轻松地识别和纠正数据完整性错误。

数据准备区应将原始数据同数据仓库数据隔离开，以保护数据仓库的完整性，并允许数据仓库执行其准备显示信息和支持客户端访问的主要功能。在将数据仓库数据库用于数据准备时应小心，避免将错误引入数据仓库数据并尽量减少数据准备处理对数据仓库性能的影响。许多数据仓库数据库操作要求高级的查询和能够处理大量数据；数据清理会对这些操作造成不良影响。

数据准备区是关系数据库，它作为数据准备操作的常规工作区提供服务。它包含使源数据键与用于数据仓库的代理键相关的表、转换数据的表以及许多临时表。还包含从源数据系统中析取数据的进程和过程，如数据转换服务 (DTS) 包。

请参见

创建和维护数据库概述

访问和更改关系数据概述


显示服务

数据仓库的目的是表现业务信息供单位的决策者使用。如果没有工具帮助分析和评估，包含数亿条数据的数据仓库对决策者将毫无用处。这些分析工具在简单的报表和高级的数据挖掘算法之间可能有所不同。应用程序接口 (API) 还必须能够支持开发使用数据仓库信息的自定义应用程序。

预定义报表

简单的预定义汇总报表可以定期或根据需要，为管理人员提供某个即时点的业务状态快照。更高级的报表可以显示预定义的业务变化的趋势。这样的报表很有用，并且一直都是从联机事务 (OLTP) 系统中生成。若要捕获最新状态，必须不断地从数据源系统中生成快照的详细信息和汇总报表。定期报表与数据仓库的更新相协调，并且可以转换到数据仓库以减少可操作系统的负荷。使用历史数据评估趋势的报表应在数据仓库中完成，数据仓库中包含具有适当格式且随时可用的历史数据，并且可以处理大量的汇总数据。

可以通过开发客户端应用程序来访问由 SQL Server 2000 Analysis Services 准备的关系数据库或多维数据集，在 Microsoft® SQL Server™ 2000 数据仓库中准备预定义报表。有关更多信息，请参见生成 SQL Server 应用程序概述。

联机分析处理

预定义报表很适合其特殊目的，但不适合探测分析。分析者希望在数据中发现趋势和异常，并探测数据的不同区域以找到趋势和异常的根源。联机分析处理 (OLAP) 是一个分析工具，旨在帮助对大量的数据仓库数据进行这种分析。

本例说明探测分析和 OLAP。管理人员注意到在预定义汇总报表中有大于正常值的销售额并想找到原因。可能是由于业务的外部条件，如异常的天气情况推动了相关商品的销售，或者是内部原因，如促销活动。增加的销售额可能是在整个地区内或在单个商店实现的，而且可能是在短时间或相对较长的时间内发生的。

为探测数据仓库中的数据，管理人员询问有关数据的问题，然后根据答案询问相关的或不同的问题。管理人员可以先询问所探测的季度中的按周汇总的销售数据，然后深化到周中的每一天，查明不寻常的销售量是否为以前的事件。发现事件发生的时间后，管理人员按产品浏览销售额并查明特定产品的大量销售额是否发生在那一天。然后管理人员根据这些答案按地区查询销售额，并深化以查明具体某个商店是否在特定的日期完成了特定产品的大订单。

为帮助进行这种探测分析，开发出了 OLAP 技术。Analysis Services 包括一个分析服务器，它使用 OLAP 技术为实时探测准备大量的数据仓库数据。预定义和创建称为多维数据集的多维数据结构，用以组织和汇总数据仓库数据，所采用的方式使得很少或无需查询关系数据库，即可回答典型的探测分析问题。在典型的数据仓库 Analysis Services 实施方案中，本例的管理人员可以在不到一分钟内找到答案，因为即使所探测的数据中有数百万项，分析服务器也可以在一两秒内回答每个示例问题。有关更多信息，请参见 Analysis Services 概述。

挖掘模型

OLAP 是将数据组织为预定义的多维结构以便于探测，而数据挖掘与 OLAP 相反，其目的是执行探测分析并识别信息中有趣且有价值的东西，如将数据分组以供分析者或管理人员检查。数据挖掘还可创建决策树，用于根据现有数据元素的特性预测将来的数据。

Analysis Services 包含高级的数据挖掘算法，可用于分析关系数据库或 OLAP 多维数据集中的数据。数据挖掘分析的结果还可用于 OLAP 多维数据集以提高探测分析能力。例如，可以让数据挖掘根据客户的特性查找客户的分组，然后使用这些分组创建 OLAP 多维数据集的其它维度视图，并从这些分组的角度探测数据。有关更多信息，请参见 Analysis Services 概述。

应用程序接口

SQL Server 2000 提供了许多 API，可用于根据数据仓库的需要开发客户端应用程序。有些 API 提供数据库访问能力和工具对象模型，以便可以开发自定义管理应用程序。有些 API 则通过标准接口（如 OLE DB），为自定义最终用户应用程序提供了数据访问能力。有关更多信息，请参见生成 SQL Server 应用程序概述。


最终用户分析

Microsoft® SQL Server™ 2000 及其组件提供了一个用于访问数据仓库数据的开放式环境。这为独立的软件制造商提供了机会，使其可为最终用户开发高级的数据分析和显示应用程序。有许多适用于 SQL Server 2000 及其组件的第三方客户端应用程序。

SQL Server 2000 还与 Microsoft Office 2000 很好地集成，使得最终用户可以轻松使用工具分析数据仓库数据。使用 Microsoft Office 2000 的组件可查询 SQL Server 2000 数据库，将数据仓库数据合并到 Microsoft Excel 电子表格、Microsoft Access 数据库或其它文档中。Excel 2000 PivotTables® 可直接连接到 SQL Server 2000 Analysis Services 多维数据集以探测数据，而且用户可以创建本地多维数据集，以便在从数据仓库脱机时用它们。


创建数据仓库

创建数据仓库是一项重大工程，其中涉及许多步骤。本节中的主题就是讨论这些步骤。

主题 | 描述
设计数据仓库 | 描述设计数据仓库和使用维度建模时的特殊考虑。
创建数据准备区 | 描述用于为数据仓库准备数据的关系数据库的创建。
创建数据仓库数据库 | 描述容纳数据仓库数据的关系数据库的创建。
从可操作系统中析取数据 | 描述将数据从可操作系统析取到数据准备区的过程。
清理和转换数据 | 描述在将数据装入数据仓库之前，清理和转换数据准备区数据的过程。
将数据装入数据仓库数据库 | 描述将数据从数据准备区装入数据仓库数据库的过程。
准备显示信息 | 描述准备数据仓库数据以显示给用户的过程。
将数据分发到数据集市 | 描述将数据从数据仓库分发到数据集市的过程。


设计数据仓库

设计数据仓库与设计联机事务处理 (OLTP) 系统有很大的不同。OLTP 系统的目的是捕获高比率的数据更改和添加，而数据仓库与 OLTP 相反，其目的是组织大量的稳定数据以便于分析和检索。由于目的不同，在数据仓库设计中有许多不同于 OLTP 数据库设计的考虑。

必须将数据仓库数据组织起来以符合数据仓库的目的，即快速访问信息以进行分析和创建报表。维度建模用于数据仓库数据库的设计中，其目的是组织数据以提高旨在分析和汇总大量数据的查询的效率。与使用实体关系建模设计的 OLTP 系统架构相比，数据仓库架构几乎总是有很大的不同而且简单得多。

在 OLTP 系统中用于验证数据输入事务的验证表在数据仓库数据库中不是必需的。这是因为数据仓库数据在发布到数据仓库数据库之前已被清理和验证过，并且历史数据一旦存在于数据仓库中，就不大可能频繁更改。

事务锁定考虑和事务本身在数据仓库数据库中的作用很小。OLTP 系统专用于大量数据的更新事务。相反，数据仓库专用于从稳定的数据中快速检索信息，而数据更新主要包括定期添加新数据。

数据仓库的备份和还原策略也不同于 OLTP 系统所必需的备份和还原策略。数据仓库中的许多数据是不变的历史数据，不需要反复备份。可以在更新时完成对新数据的备份，在某些情况下，也可以从数据准备数据库中备份新数据，以使对数据仓库数据库的性能影响减到最小。数据仓库的还原策略也可能与 OLTP 的不同，具体取决于对一个单位来说连续访问数据仓库数据的重要程度。

如果计划在 OLAP 和数据挖掘中使用 Microsoft® SQL Server™ 2000 Analysis Services，则当设计数据仓库时需要考虑一些事项。有关更多信息，请参见 Analysis Services 概述以及 OLAP 和数据仓库。

数据集市设计

有两种方法可以为单位创建数据仓库系统。可以先开发并实现中央数据仓库，然后再创建数据集市；或者可以实现数据集市，使其加入自己的信息以补充数据仓库。另一种方法是，必须进行集中设计以便单位的所有数据仓库信息都保持一致和可用。遵守集中设计规范的数据集市将生成一致的报表，即使数据驻留在不同的位置。例如，销售数据集市与库存数据集市必须使用以相同的方式排列的相同产品表，否则汇总信息在两者之间将不一致。

请参见

使用维度建模

事实数据表

聚合表

维度表

索引


使用维度建模

实体关系建模通常用于为单位的所有进程创建一个复杂的模型。这种方法已被证实在创建高效的联机事务处理 (OLTP) 系统方面很有效。相反，维度建模针对零散的业务进程创建个别的模型。例如，销售信息可以创建为一个模型，库存可以创建为另一个模型，而客户帐户也可以创建为另一个模型。每个模型捕获事实数据表中的事实，以及那些事实在链接到事实数据表的维度表中的特性。由这些排列产生的架构称为星型架构或雪花型架构，已被证实在数据仓库设计中很有效。

维度建模将信息组织到结构中，这些结构通常对应于分析者希望对数据仓库数据使用的查询方法。例如，问题 "What were the sales of food items in the northwest region in the third quarter of 1999?"（1999 年第三季度西北地区的食品销售额是多少？）表示使用三个维度（产品、地理、时间）指定要汇总的信息。

数据仓库模型

销售信息的简单维度模型可能包括一个名为 Sales_Fact 的事实数据表，每个产品项的每个销售在该表中有一条记录，该表还包含售出的数量、单位成本和销售额。有关销售记录的各种信息可能包括客户、销售发生的商店、售出的时间和日期以及售出的产品。这些信息中的每一类都可组织为自己的维度表。客户信息放在 Customer 维度表中，商店信息放在 Store 维度表中，时间和日期信息放在 Time 维度表中，产品信息放在 Product 维度表中。

在星型架构中，每个维度表都有一个由一个部分组成的主键，该主键链接到事实数据表中由多个部分组成的主键的一个部分。在雪花型架构中，一个或多个维度表分解为多个表，每个表都有联接到主维度表而不是事实数据表的相关性维度表。在大多数设计中，星型架构比雪花型架构更可取，因为前者包含的用于信息检索的联接更少，并且更容易管理。


事实数据表

每个数据仓库或数据集市都包括一个或多个事实数据表。星型架构或雪花型架构的中心是一个事实数据表，用以捕获衡量单位业务运作的数据。事实数据表可能包含业务销售事件，如现金登记事务或非赢利组织的捐款和支出。事实数据表通常包含大量的行，有时当事实数据表包含大型机构一年或几年的历史数据时，可能有数亿条记录。

事实数据表的主要特点是包含数字数据（事实），而这些数字数据可以汇总以提供有关单位运作历史的信息。每个事实数据表还包括一个由多个部分组成的索引，该索引包含作为外键的相关性维度表的主键，而维度表包含事实记录的特性。事实数据表不应包含描述性信息，也不应包含数字度量字段以及使事实与维度表中的对应项相关的索引字段之外的任何数据。

在随 Microsoft® SQL Server™ 2000 Analysis Services 提供的 FoodMart 2000 示例数据库中，有一个事实数据表 sales_fact_1998，它包含以下各列。

列 | 描述
product_id | 维度表 product 的外键。
time_id | 维度表 time_by_day 的外键。
customer_id | 维度表 customer 的外键。
promotion_id | 维度表 promotion 的外键。
store_id | 维度表 store 的外键。
store_sales | 包含销售额的货币列。
store_cost | 包含销售商店成本的货币列。
unit_sales | 包含销售数量的数字列。

在这个事实数据表中，每一项都表示特定的商店以特定的促销方式，在特定的日期销售给特定客户的特定产品的销售情况。捕获的业务度量值是销售额、商店成本和销售数量。

包括在事实数据表中的最有用的度量值是累计的数字。累计的度量值使可以通过添加各种度量值（如具体时间段内一组商店的特定项目的销售情况）获得汇总信息。非累计度量值（如库存中现货的数量）也可用于事实数据表，但必须使用不同的汇总技术。

事实数据表中的聚合

聚合是通过详细记录计算汇总数据的过程。在创建事实数据表时，可将数据聚合为汇总记录以减小事实数据表的大小，这通常是很诱人的。但是，如果将数据汇总到事实数据表中，则分析者不再能直接使用详细信息。如果需要详细信息，则必须标识并定位已汇总的详细信息行，详细信息行可能在提供数据的源系统中。应在可能最细的粒度级别上维护事实数据表数据。应在考虑了这些结果之后，再将数据聚合到事实数据表中。

将聚合数据和详细数据混合在事实数据表中，可能导致在使用数据仓库时出现问题和并发因素。例如，销售订单通常包含多个产品项，而且可能包含折扣、税款或运输成本，这些都算在订单总计中而不是个别的产品项中，而销售数量和产品项标识则记录在产品项级上。在这种情况下，汇总查询变得更复杂，Analysis Services 这类工具通常需要创建特殊的筛选器以处理粒度混合。

有两种方法可以处理这种情况。一种方法是根据销售额、销售数量或发货量给产品项分配订单级的值。另一种方法是创建两个事实数据表，一个包含产品项级的数据，另一个包含订单级信息。详细信息事实数据表中应包含订单标识键，以便这两个表可以建立关系。于是，订单表可以作为维度表用于详细信息表，并将订单级的值视为维度层次结构中订单级的特性。


聚合表

聚合表是包含事实数据表的汇总信息的表。当 SQL 作为查询机制使用时，这些表可用于提高查询性能。OLAP 技术（如 Microsoft® SQL Server™ 2000 Analysis Services 所提供的 OLAP 技术）消除了对这种表的需要。Analysis Services 创建包含预聚合汇总的 OLAP 多维数据集，这样，不论需要什么级别的汇总来回答查询，都可以快速回答查询。当 Analysis Services 用于提供显示服务时，不必在数据仓库中创建聚合表。Analysis Services 在必要时创建聚合，并将其存储在数据仓库数据库中的表内或内部多维结构中。有关更多信息，请参见Analysis Services 概述。


维度表

维度表包含描述事实数据表中的事实记录的特性。有些特性提供描述性信息；有些特性则用于指定如何汇总事实数据表数据以便为分析者提供有用的信息。维度表包含帮助汇总数据的特性的层次结构。例如，包含产品信息的维度通常包含将产品分为食品、饮料、非消耗品等若干类的层次结构，这些产品类中的每一类进一步多次细分，直到各产品的 SKU 达到最低级别。

维度建模产生维度表，在维度表中，每个表都包含独立于其它维度的事实特性。例如，客户维度表包含有关客户的数据，产品维度表包含有关产品的信息，而商店维度表包含有关商店的信息。查询使用维度中的特性来指定对事实信息的查看。例如，查询可能使用产品、商店和时间维度来询问 "What was the cost of nonconsumable goods sold in the northeast region in 1999?"（1999 年东北地区销售的非消耗品的成本是多少？）。后面的查询可能在一个或多个维度上深化以检查更详细的数据，如 "What was the cost of kitchen products in New York City in the third quarter of 1999?"（1999 年第三季度纽约的厨房用品的成本是多少？）。在这些示例中，维度表用于指定如何汇总事实数据表中的度量值（成本）。

维度表中的列可用于将信息分为不同的层次结构级。例如，FoodMart 2000 示例数据库中的商店维度表包括下面指定层次结构级别的列。

列 | 描述
store_country | 指定商店所在的国家。这是层次结构的国家级。
store_state | 指定商店所在的省。这是层次结构的省级。
store_city | 指定商店所在的城市。这是层次结构的城市级。
store_id | 指定个别的商店。这是层次结构的最低级别。该字段包含商店维度表的主键，并用于联接该维度表与事实数据表。
store_name | 指定商店的名称。该列中的值用于以可读的形式向用户标识商店。

上面未列出的其它列提供附加的特性信息。有关如何在由 Microsoft® SQL Server™ 2000 Analysis Services 生成的 OLAP 多维数据集中使用维度表的信息，请参见维度。

各种维度表

前面的示例说明了包含被分成常规级别的均衡层次结构的维度表。其它类型的维度表包含不太均衡的信息，如局部划分的结构或组织图表，这类结构中的层次结构由父子关系而不是级别数组表示。

代理键

维度表的主键保持稳定很重要。强烈建议为所有维度表的主键创建代理键并使用它们。代理键是在数据仓库内部维护的键，而不是从源数据系统中获得的键。使用代理键有几个原因：

  • 不同源系统中的数据表可能对同一实体使用不同的键。

    提供历史数据的传统系统可能使用了与当前的联机事务处理系统不同的编号系统。代理键唯一标识维度表中的每个实体，与源键无关。可以使用单独的字段包含源系统中使用的键。

    公司各分部独立开发的系统可能使用不同的键，或使用与其它分部系统中的数据冲突的键。当每个分部独立地创建汇总数据报表时，这种情况不会产生问题，但在合并数据的数据仓库中不允许这种情况。

  • 键可以更改或在源数据系统中重新使用。

    与其它情况相比，这种情况通常不大可能发生，但已知有些系统可以重新使用属于过时数据的键。然而，键仍可以在数据仓库的历史数据中使用，而且同一个键不能标识不同的实体。

  • 组织结构的更改可能移动层次结构中的键。

    这可能是常见情况。例如，如果销售员从一个地区调到另一个地区，公司可能愿意跟踪两个事件：销售员在调动日期前所在的原地区的销售数据，和销售员在调用日期后所在的新地区的销售数据。若要表示这种数据结构，销售员的记录必须存在于销售队伍维度表中的这两个位置，而这在销售员的公司职员标识号用作维度表的主键时是不可能的。代理键使同一销售员得以参与维度层次结构中的不同位置。

    在这种情况下，销售员将在维度表中用两个不同的代理键表示两次。这些代理键用于将销售员的记录联接到与销售员在层次结构中所占用的不同位置相对应的事实数据集。

    表中应包含一个单独的用于职员标识号的列，这样，不论职员的记录在维度表中出现多少次，都可以复查或汇总有关职员的信息。

    显示这类更改的维度称为更改慢的维度。

    导致这类更改的另一个示例是创建产品的新版本，如食品类的减肥产品版。该产品将获得新的 SKU 或统一产品代码 (UPC)，但可以保留仍在制造和销售的原产品的大多数相同特性。适当使用代理键可使产品的两个版本一起汇总或单独汇总。

数据仓库负责实现和管理代理键。OLTP 系统几乎不受这些情况的影响，而这些键的目的是准确跟踪数据仓库中的历史数据。代理键是在数据转换过程中在数据准备区内进行维护。

引用完整性

必须在所有维度表和事实数据表之间维护引用完整性。每个事实记录都包含与维度表中的主键相关的外键。每个事实记录都必须在与事实数据表一起使用的每个维度表中有相关记录。当维度表联接到事实数据表以响应查询或用于填充 OLAP 多维数据集时，维度表中丢失的记录可以导致忽略事实。如果在一个或多个维度表中丢失了记录，则查询可能返回不一致的结果。查询若将有缺陷的维度表联接到事实数据表，则将排除事实，反之，若不联接有缺陷的维度表则将包括那些事实。

共享维度

数据仓库必须为相似的查询提供一致的信息。保持一致性的一种方法是创建由数据仓库中的所有组件和数据集市共享和使用的维度表。可以作为共享维度的对象包括客户、时间、产品和地理等维度，如本主题前面介绍的示例中的商店维度。例如，若要求所有 OLAP 多维数据集和数据集市使用相同的共享时间维度，则将使按时间汇总的结果保持一致。


索引

与在任何关系数据库中一样，索引对数据仓库的性能具有重要作用。每个维度表都必须在主键上建立索引。在其它列（如标识层次结构级别的列）上，索引对某些专用查询的性能也很有用。

事实数据表必须在由维度表外键构成的组合主键上建立索引。

由于星型架构和雪花型架构很简单，大多数数据仓库应用程序所需的索引主要就是这些。对于特殊查询和创建报表，则可能需要其它索引。

请参见

创建和维护数据库概述


创建数据准备区

为支持数据析取、清理和转换操作以便准备数据装入数据仓库，需要创建表和其它数据库对象。可以为数据准备区创建单独的数据库，或者可以在数据仓库数据库中创建这些项目。

数据准备区应包括包含传入数据的表、帮助实现代理键的表以及容纳转换数据的表。可能需要其它表协调来自不同数据源的数据；这些表可能包含标识常用实体（如来自使用不同键的系统的客户记录）的交叉引用信息。可能还需要各种临时表执行中间转换。

数据准备区的特定设计取决于数据源的多样性、组织数据以装入数据仓库时所需的转换程度以及传入数据的一致性。

准备装入数据仓库的数据所在的表与数据仓库中的目标表应具有相同的架构。如果不是这样，则准备装入数据仓库表中的数据需经过转换，该转换在装载数据时可以单步完成。

数据准备区还应包含用于从数据源中析取数据的过程、转换和清理数据的过程以及将数据装入数据仓库的过程。这些过程可以是 SQL 查询的形式、存储过程、数据转换服务 (DTS) 包，或者是手册说明书文档。与开发任何数据库系统一样，其目的都是使尽可能多的过程自动执行，并管理和维护开发的自动工具。通过在数据准备区中存储和维护转换过程，可以利用标准的数据库备份和还原机制保护这些转换。

无论是否使用单独的数据库，创建数据准备区都包含创建表、视图、索引、DTS 包以及关系数据库中常用的其它元素。

请参见

数据准备区

创建和维护数据库概述


创建数据仓库数据库

可以在设计数据仓库架构之后创建数据仓库数据库。需要创建事实数据表和维度表，并在所有表中的主要字段上建立索引。

与 OLTP 数据库或数据准备区相比，数据仓库数据库的架构通常是很简单的。星型架构由单个事实数据表和一些维度表组成。雪花型架构增加了次要维度表。更复杂的数据仓库可能包含多个事实数据表和许多维度表，其中有些维度表由所有事实数据表共享，有些维度表则专用于单个事实数据表。

例如，数据仓库可能包含销售信息和库存信息。由于销售数据和库存数据在本质上不同，它们应存储在不同的事实数据表中。有些维度表（如产品维度表）可能由销售和库存表共享，而有些维度表（如销售队伍或仓库位置）则可能专用于个别的事实数据表。

在随 Microsoft® SQL Server™ 2000 Analysis Services 提供的 FoodMart 2000 示例数据库中，说明了包含库存和销售数据的数据仓库。有关更多信息，请参见Analysis Services 概述。

请参见

设计数据仓库

创建和维护数据库概述


从可操作系统中析取数据

将要用于数据仓库的数据必须从包含数据源的可操作系统中析取出来。数据最初在数据仓库创建过程中析取，并且在更新数据仓库的过程中不断地定期析取。如果源数据驻留在单个关系数据库中，则数据析取是简单的操作，但如果源数据驻留在多个异类可操作系统中，则数据析取是非常复杂的操作。数据析取过程的目的是使所有的源数据都具有通用的、一致的格式，以便准备装入数据仓库。

如果源可操作系统的数据不包含验证错误，则更好。例如，如果购买记录没有相应的客户记录标识购买者，这在源数据中是明显的错误，应在析取数据以便装入数据仓库之前在源可操作系统中改正它们。可以在源可操作系统中执行错误检查，这样，在析取用于数据仓库的数据之前就可以检测到错误。如果上述错误经常发生，则需要检查可操作系统并对其进行修改以减少上述错误，因为上述错误会影响单位的业务及其数据仓库。

从可操作系统中析取数据之前可能无法识别验证错误。从多个数据源中析取数据时会发生这种情况。例如，从不同的销售跟踪、发货和计费系统中析取的协调数据可能会显露某些差异，必须在一个或多个源系统中加以解决。

析取数据后，除了可以识别数据中的错误外，还可以识别不一致。例如，不同的数据源对于同类数据可能使用不同的编码系统。可以经常使用转换表在析取操作中或在稍后的转换操作中协调这些差异。例如，一个传统系统中可能使用三字节代码对州或省名进行编码，而另一个系统可能使用两字节代码。在将数据装入数据仓库前，必须将来自其中一个系统或两个系统的数据转换成一个代码集。

在其它情况下，如果源系统允许自由格式的文本信息项，则会发现不一致。这样的数据在内部经常不一致，因为不同的数据输入人员可能以不同的方式输入相同的数据。如果这样的数据要用于分析，则必须对相同数据的不一致表示法进行协调。例如，在允许以自由格式文本输入地址的州或省部分的数据源中，佛罗里达州可被输入为 FL、Fla、Florida 甚至 Flor。修改传统源系统以使用标准的代码验证可能很困难。如果不能修改起作用的源系统，则有必要对转换进行手工调整以协调这种差异。

在协调很多格式、数据编码和其它不一致的析取过程中，可以使用 Microsoft® SQL Server™ 2000 数据转换服务 (DTS) 的强大转换功能。其它转换必须在数据从源系统中析取出来后完成。

SQL Server 2000 中可用于析取数据的一些工具有：

  • Transact-SQL

  • 分布式查询

  • DTS

  • 命令行应用程序

  • bcp 实用工具

  • 用于从文本文件装载的 BULK INSERT 语句

  • ActiveX 脚本

在某些数据仓库实施中，还会发现可以使用复制将数据从源系统复制到数据准备区。

请参见

访问和更改关系数据概述

导入和导出数据

DTS 概述

复制概述


清理和转换数据

在从源系统析取数据的过程中可以完成很多数据转换。但是，在将数据装入数据仓库前，经常还有其它任务需要完成。例如，必须在析取后协调来自异类数据源的不一致的数据，并完成其它格式化和清理任务。还应该一直等到析取过程合并代理键后。某些在析取过程中可通过技术手段完成的转换可能会影响联机源系统的性能或操作；应将这些任务推迟到析取完成后执行。

从源系统析取后，数据应驻留在数据准备区，在这里可以在数据装入数据仓库前完成清理和转换。数据准备区可以是数据仓库数据库中单独的数据库或单独的表。在清理和转换阶段，可以执行过程以验证数据的一致性，将数据转换成常用格式以及合并代理键。

可能需要执行手工操作协调数据的不一致或解决二义性文本字段输入项。每次需要手工操作时，都应试着确定一种方法来消除在以后的数据转换操作中的手工步骤。在某些情况下，也许能够修改源数据系统以消除源上的起因。在某些情况下，也许能够建立自动化进程将未解决的数据留待以后手工异常处理，这样，大批的数据就可以装入数据仓库而不会因手工干预而耽搁。

某些典型的数据转换包括：

  • 将多个名称字段组合成一个字段。

  • 将日期字段划分成单独的年、月、日字段。

  • 将数据从一个表示法映射到另一个，如从 TRUE 到 1 和 FALSE 到 0 或者邮编从数字到文本。

  • 将数据从多个表示法映射到单个表示法，如电话号码的常用格式，或不同的信用等级代码到常用的"好、一般、不好"表示法。

  • 创建并应用维度表记录的代理键。

Microsoft® SQL Server™ 2000 中可用于转换数据的一些工具有：

  • Transact-SQL 查询

  • DTS 包

  • 命令行应用程序

  • ActiveX 脚本

请参见

访问和更改关系数据概述

DTS 概述

自动化管理任务


将数据装入数据仓库数据库

清理数据并将其转换成与数据仓库要求一致的结构后，数据即准备装入数据仓库。在装载操作中可以进行一些最后的转换，但应在最后的装载操作前完成所有可能标识不一致的转换。

初始装载数据仓库时要填充数据仓库架构中的表，然后验证数据是否准备用于装载。可以用不同的方法装载数据仓库表，如：

  • Transact-SQL

  • DTS

  • bcp 实用工具

将数据装入数据仓库时，就是在填充将由显示应用程序使用的表，该应用程序使数据可由用户使用。装载数据通常涉及从源可操作系统、数据准备区数据库或数据仓库数据库中的准备区表传输大量的数据。这样的操作会显著增加所涉及的数据库的处理负荷，因此应该在系统相对不忙时完成。

数据装入数据仓库数据库后，验证维度和事实数据表之间的引用完整性，确保所有的记录都与其它表中的适当记录相关。应验证事实数据表中的每个记录都与每个将与该事实数据表一起使用的维度表中的记录相关。例如，如果产品销售事实数据表将与维度表一起用于客户、产品、时间和存储，那么，对于事实数据表中的每个销售记录，每个维度表中必须有记录通过相应的主键与销售记录相关。该验证确保对于每笔销售，进行购买的客户、卖出的产品及销售的时间和地点都确定。

不需要相反顺序的数据完整性。即，维度表中的每个记录不必与事实数据表中的记录相关。例如，销售数据仓库中的维度通常是共享维度，这些维度包含完整的客户、产品、存储集等。事实数据表可能包含特定时期的销售记录，在该期间内客户没有进行任何购买且没卖出任何产品。

大多数从数据仓库中检索数据的查询在事实数据表和维度表之间使用内联接。这类查询忽略在至少一个联接维度表中没有匹配记录的事实，从而导致检索的数据不准确且可能在不同的查询之间不一致。例如，如果客户记录中缺少某个销售事实记录，则任何包括客户维度表的查询都将忽略该销售事实记录，但是任何不包括客户维度表的查询将包含该销售事实记录。按客户计算销售总量的查询所生成的总计不同于按产品计算销售总量的查询，因为第一个查询忽略没有客户的销售，而第二个则包括这类销售。

如果使用维度表所包含的数据不适用于所有事实，则必须在维度表中包括一个可用于和其余事实相关的记录。例如，在促销记录表中，可以包括一个普通记录，通过它可与任何没有适用促销的销售事实相关。如果没有这个普通促销记录，任何联接促销表与销售事实数据表的查询都不包括没有相应促销的销售。

若要验证星型架构中的引用完整性，可以使用一个简单的 SQL 查询，计算使用内联接将所有适当的维度表联接到事实数据表时返回的行。该查询返回的行数应与事实数据表中的行数相匹配。如果使用的是雪花型架构，还应验证维度表和它们联接的从属表之间的引用完整性，以验证到从属表的内联接没有将任何表中的记录消除。应这样执行该验证：从雪花维度的最低级上的表开始，将它们联接到下一个较高级上的表，一直继续到验证完主维度表。这一步非常重要，因为可能存在这样的情况：维度在当前事实数据表上验证正确，即使缺少某些维度记录；而添加新事实时将需要这些记录。

请参见

访问和更改关系数据概述


准备显示信息

因为通常通过客户端应用程序提供对数据仓库数据的访问，所以经常必须在数据仓库中完成某些任务以便为最终用户准备显示信息。数据仓库设计的一部分是识别这些应用程序所需的任何特殊数据配置要求，并通常是按照应用程序文档中的描述配置应用程序本身。有关更多信息，请参见使用数据仓库。


将数据分发到数据集市

数据仓库设计可能包括用于特定业务方面（如销售、仓库和财务部门）的数据集市。每个上述数据集市都包含一个数据仓库数据的子集，但应使用公用共享维度以避免分析和生成报表时出现不一致。例如，Products 维度表可用于所有的数据集市，而财务业务计划维度表可能只适合财务数据集市。其它数据集市可能包含区域特有的数据以增大区域特有的操作数据库系统。

从数据仓库中初始装载数据集市时，复制所有适用的共享维度表和适合于数据集市的事实数据表。如果将某个数据集市特有的特殊维度表只用于该数据集市所服务的部门或组，则可以在本地创建这些维度表；用于创建报表从而与来自其它数据集市的报表进行比较的维度应是共享维度，共享维度在数据仓库中集中进行管理并从数据仓库表中装载。可以使用很多或所有用于装载数据仓库数据库的工具来装载数据集市。

请参见

更新数据集市


使用数据仓库

数据仓库的传统任务是收集并组织历史业务数据，以便对其进行分析并帮助管理业务决策。直到最近，还只有数据库专家才能访问数据仓库，这些专家可以创建检索、汇总和格式化信息所需的复杂查询，供分析人员和高级决策者使用。随着数据仓库变得越来越普通且业务在决策管理过程中涉及的级别较低，只具备浅显的数据库专门技术的人直接对数据仓库进行最终用户访问的需要日益增加。

数据仓库必须满足各种应用程序不断增长的访问数据仓库数据的要求。大多数应用程序必须经过设置和初始配置后才能有效地使用数据仓库，这项工作通常由数据仓库管理员执行和管理。在某些情况下，为了满足新应用程序的要求，数据仓库必须并入修改。

除了用于数据访问的最终用户应用程序外，其它在数据仓库环境内执行的应用程序还在继续开发之中，以便采用新的、强大的方法配置和分析数据。上述应用程序要求由数据仓库管理员管理和维护。

数据仓库技术的新用途在不断发展之中。某些单位现在收集、分析和封装数据销售给客户。实时数据仓库（过去是没有意义的术语）现在正在形成，用于联机商务中。

本部分中的主题描述可用于数据仓库的各种技术。

主题 | 描述
SQL 查询 | 描述在数据仓库中使用 SQL 查询。
OLAP 和数据挖掘 | 描述用于数据仓库的联机分析处理 (OLAP) 和数据挖掘技术。
English Query | 描述 Microsoft® SQL Server™ 2000 的组件，该组件支持使用英语单词和短语查询数据仓库。
Microsoft Office 2000 | 描述 Microsoft Office 2000 组件如何使用数据仓库中的数据。
Web 访问和创建报表 | 描述在 Web 上访问数据仓库数据和报表。
脱机 OLAP 多维数据集 | 描述用户没有连接到 SQL Server 2000 Analysis Service 时如何使用脱机多维数据集分析数据。
第三方应用程序 | 描述如何在数据仓库中使用第三方应用程序。
自定义应用程序 | 描述应用程序接口 (API) 的可用性，该接口可用于创建管理或使用数据仓库的自定义应用程序。


SQL 查询

最终用户很少使用结构化查询语言 (SQL) 查询直接访问数据仓库数据。分析 SQL 查询很复杂，必须具有数据库专业知识才能正确创建。数据仓库中的数据量经常很大，以至于需要完善的 SQL 技术获得有用的性能。如果一个 SQL 查询将三个或四个维度表联接到包含数百万行的事实数据表，并且使用聚合函数（如 SUM）汇总和分组结果，会显著增加任何关系数据库的负荷，而且通常会产生联机分析无法接受的性能。

SQL 查询通常由数据库专家创建，与在较低活动期间定期执行的预定义报表一起使用。可以创建辅助汇总表优化这些查询的性能；必须在装载数据仓库时初始设计和填充这些表，然后在每次更新数据仓库时更新它们。

使用 SQL 查询访问数据仓库数据是最早的方法之一。有很多参考书和培训课程提供非常完善的技术，用于配置数据仓库信息和设计解决复杂分析任务的有效 SQL 查询。

Microsoft® SQL Server™ 2000 提供完善的查询处理和优化技术，还提供强大的语言 Transact-SQL 解决数据仓库的实现需要。有关更多信息，请参见访问和更改关系数据概述。


OLAP 和数据挖掘

联机分析处理 (OLAP) 是使用多维数据表达式（称为多维数据集）提供对数据仓库数据进行快速访问的技术。多维数据集为维度表中的数据和数据仓库中的事实数据表建立模型，并为客户端应用程序提供完善的查询和分析功能。

数据挖掘使用复杂算法分析数据并创建模型来表示有关数据的信息。数据挖掘模型可用于预测新数据的特点或识别具有相似特点的数据实体组。

Microsoft® SQL Server™ 2000 Analysis Services 提供强大的服务器和管理工具创建和管理 OLAP 数据并为联机客户端应用程序服务。Analysis Services 还包含数据挖掘算法，可以分析数据仓库数据库中的关系数据和多维数据集中的多维数据。

多维数据集和数据挖掘模型必须经过设计、配置和处理后才能由客户端应用程序使用，并且经常要求在数据仓库数据更新时更新。有关更多信息，请参见 Analysis Services 概述。


English Query

English Query 提供用于开发客户端应用程序的系统，以使最终用户能够使用英语单词和短语访问数据。English Query 可用于访问由 Microsoft® SQL Server™ 2000 Analysis Services 创建的数据仓库数据库或多维数据集中的数据。

若要开发 English Query 应用程序，首先必须创建一个模型将数据库表、字段、多维数据集和数据与英语单词和短语相关。然后，可以生成 English Query 应用程序并将其合并到自定义 Web 或客户端应用程序由最终用户使用。有关更多信息，请参见 English Query 概述。


Microsoft Office 2000

Microsoft® SQL Server™ 2000 数据库中的数据仓库数据可由 Microsoft Office 组件访问，如 Microsoft Excel 或 Microsoft Access。但是，大多数数据仓库中的数据量通常表明，需要创建并维护特殊的查询或数据表以支持最终用户使用这些组件。必须创建这类特殊的查询和表并作为数据仓库的一部分进行维护。

一个例外是 Excel PivotTables® 和 SQL Server 2000 Analysis Services 的集成。Analysis Services 用于创建和管理 OLAP 数据时，最终用户很容易通过分析服务器连接到多维数据集联机分析数据，或在他们的本地计算机上创建多维数据集脱机使用。有关更多信息，请参见 Microsoft Office 2000 文档。


Web 访问和创建报表

向最终用户提供数据仓库数据访问能力的 Web 应用程序很受欢迎，因为客户端可以使用标准的 Web 浏览器，而不必非得安装、配置和维护特殊的应用程序。最初只能查看静态 Web 页上显示的数据，现在，最新技术支持创建高级交互式应用程序，使客户端得以查询和更新数据仓库和多维数据集中的数据。

Microsoft® SQL Server™ 2000 及其组件（如 Analysis Services 和 English Query）与 Microsoft Internet 信息服务 (IIS) 一起使用时，提供很多方法在 Web 上查询和更新数据。SQL Server 2000 引入了对 XML 功能的支持，可以通过 HTTP 连接，使用 XML、简化 XML-Data (XDR) 架构和 Xpath 查询存储、检索和更新信息。Analysis Services 的 PivotTable® 服务组件可以与 IIS 一起使用，通过使用多维表达式 (MDX) 的查询语法提供对多维数据集的 Web 访问。English Query 应用程序可以嵌入基于 Active Server Pages (ASP) 或 COM 的应用程序，以支持英语 Web 查询。

Web 数据访问应用程序是使用由 SQL Server 2000 及其组件提供的 API 开发的。Web 应用程序可以如显示预定义报表或在数据仓库数据库或 OLAP 多维数据集上执行预定义查询一样简单，也可以如任何直接连接的客户端／服务器应用程序一样复杂。Web 应用程序对数据仓库设计或维护的影响由应用程序本身决定。

请参见

XML 和 Internet 支持概述

PivotTable 服务

开发和部署 English Query 应用程序


脱机 OLAP 多维数据集

联机分析处理 (OLAP) 中使用的多维数据集提供数据仓库数据的多维视图，最终用户发现在他们搜索业务问题的答案时很容易使用和浏览该视图。Microsoft® SQL Server™ 2000 Analysis Services 通过其用于客户端应用程序的 PivotTable® 服务组件，提供创建数据仓库多维数据集的子集并在本地保存它们以便脱机分析的功能。最终用户应用程序还可以在脱机模式下使用 PivotTable 服务，直接从关系数据库创建脱机多维数据集。

第三方应用程序和自定义应用程序可以使用 PivotTable 服务创建并管理脱机多维数据集。一个提供脱机多维数据集支持的最终用户应用程序是 Microsoft Excel 2000。有关更多信息，请参见 Excel 文档。

脱机多维数据集由最终用户应用程序创建和管理，通常对数据仓库或多维数据集的设计几乎没有影响。维护脱机多维数据集数据由最终用户负责，他们可以刷新联机多维数据集中的数据，或在必要时更新从本地数据库创建的脱机多维数据集。脱机多维数据集不妨碍正常的数据仓库和多维数据集管理及维护。

请参见

PivotTable 服务


第三方应用程序

开发了许多商业应用程序与数据仓库及 OLAP 多维数据集一起使用。每个应用程序都有独特的要求，为了使这些应用程序有效地运行，可能（也可能不）需要对数据仓库的设计进行修改。有些应用程序在数据仓库上运行以提供额外的分析、管理或维护功能。有些则是为最终用户提供分析功能的客户端应用程序。商业应用程序通常需要经过设置和配置后才能有效地使用数据仓库数据。为了适应数据仓库的更改和数据更新，可能还需要对应用程序的配置进行调整。


自定义应用程序

Microsoft® SQL Server™ 2000 及其组件提供了一套丰富的应用程序接口 (API)，可用于开发自定义应用程序以增强和自动化数据仓库管理，或创建适合业务需要的客户端应用程序。有关更多信息，请参见生成 SQL Server 应用程序概述。


维护数据仓库

数据仓库收集并组织历史业务数据，以便对其进行分析并帮助业务决策管理。为此，创建数据仓库并用现有的历史业务数据初始装载它。然后，定期用可操作数据系统的新数据更新。数据仓库维护中的很多工作与更新数据仓库中的数据、调整数据显示应用程序以包含新数据和更新数据集市有关。

本部分中的主题描述维护数据仓库所执行的常见任务。

主题 | 描述
更新数据仓库数据 | 描述更新数据仓库所涉及的进程和任务。
管理数据仓库 | 描述常见的数据仓库管理任务。
优化数据仓库性能 | 描述提高数据仓库性能的方法。


更新数据仓库数据

更新数据仓库数据包括定期从可操作系统中析取数据，清除和转换数据和将新数据装入数据仓库。每次数据更新还包括：在 Microsoft® SQL Server™ 2000 Analysis Services 用于联机分析处理 (OLAP) 的情况下必须完成同步多维数据集的任务；还必须更新所有作为数据仓库一部分的数据集市。

用于定期更新的析取、清理和转换数据的过程，在本质上与初始装载数据仓库所使用的过程相同，但更新过程通常比初始装载过程简单且自动化程度更高。在初始装载过程中制定的过程和自动化任务可以减少更新过程中所需的手工工作量。初始装载过程中识别和执行的对源可操作系统的改正也减少了必须在更新过程中解决的不一致和错误的数目。但是，经常有这种情况，在更新过程中需要手工干预以确保数据准备装入数据仓库。

初始数据装载和数据更新之间的一个不同之处在于，在将数据装入数据仓库可由用户使用之前，应在更新数据上不断地验证引用完整性。更新通常包括添加和更改维度表以及向事实数据表添加行。在将新更改的数据装入数据仓库之前，应检查其内部一致性并在数据仓库中的当前数据上验证。

在更新数据已准备装入数据仓库后，可以使用 Transact-SQL、数据转换服务 (DTS) 或 bcp 实用工具更新数据仓库表。根据为最终用户提供数据仓库数据访问能力的显示应用程序的设计和实现，可能需要在更新过程中使数据仓库脱机以免查询结果不一致。

请参见

从可操作系统中析取数据

清理和转换数据

将数据装入数据仓库数据库

调度数据更新

同步 OLAP 多维数据集

更新数据集市


调度数据更新

用于分析历史业务数据的数据仓库最好由定期更新而非联机数据更新提供服务。经常更改数据会影响分析过程，因为这要求时间和反复查询来优化和验证结果。数据仓库的更新频率取决于单位的需要和数据仓库的用途。典型的更新周期可以是每月、每周或每天。调度数据仓库更新时需要考虑一些事项。

虽然数据仓库更新所涉及的数据量通常比初始装载数据量少得多，但是析取、清理和转换的过程及装载数据仍会对所涉及的可操作系统造成负面影响。将数据装入数据仓库时，就是在填充将由显示应用程序使用的表，该应用程序使数据可由用户使用。装载数据通常涉及从源可操作系统、数据准备区数据库或数据仓库数据库中的准备区表传输大量的数据。这样的操作会显著增加所涉及的数据库的处理负荷，因此应在系统相对不忙时完成。

还必须协调数据仓库的更新操作和向用于提供数据的显示服务操作。如果要装载大量的数据，可能需要在不使用事务或日志记录的情况下执行大容量装载。在这种情况下，在装载操作过程中可能需要使数据仓库脱机以防止用户访问数据，因为数据在被装入不同的表时可能会不一致。

可能需要调整向最终用户提供数据仓库访问能力的显示应用程序以容纳新数据。例如，Microsoft® SQL Server™ 2000 Analysis Services 多维数据集通常要求更新或重新处理以包含数据仓库中的新数据。有关更多信息，请参见同步 OLAP 多维数据集。


同步 OLAP 多维数据集

如果要将 Microsoft® SQL Server™ 2000 Analysis Services 和数据仓库一起使用以分析和准备显示给用户的 OLAP 数据，那么在更新数据仓库中的数据之前，必须熟悉数据更改对 Analysis Services 多维数据集的影响。在某些情况下，用户可能会在数据仓库数据更改之后收到不一致的结果，除非更新汇总信息以包含新的详细数据。

更改基础数据对多维数据集的影响因使用的多维数据集类型而异。例如，多维 OLAP (MOLAP) 多维数据集不受基础数据更改的影响，除非重新处理多维数据集。根据定义的方式，关系 OLAP (ROLAP) 多维数据集和混合 OLAP (HOLAP) 多维数据集可能会立即受到影响，并要求更新或重新处理以恢复一致性。实时多维数据集是为立即包含新数据仓库数据而设计的。有关更多信息，请参见 Analysis Services 概述和维护 OLAP 数据。


更新数据集市

在有些数据仓库实施中，数据集市从主数据仓库接收它们的数据。在有些实施中，数据集市则在本地更新并向数据仓库数据库提供数据。如果数据集市设计为与主数据仓库一致，则将更新的数据移入数据集市或从数据集市移出更新的数据很简单。使用标准化架构、共享维度和常用事实数据表格式都可以显著减轻数据集市的维护工作。

如果数据集市从主数据仓库接收数据更新，则可以设计自动化任务，在数据仓库数据库更新的过程中筛选数据仓库更新数据并将适当的数据子集发布到每个数据集市。可能需要调整数据集市所使用的显示应用程序以容纳新数据。

如果数据集市在本地收集数据并向主数据仓库提供数据，则可能需要将数据集市看成是操作数据源来处理，并在发布数据到数据仓库之前，将数据放入准备区进行清理并在数据仓库上验证。如果数据集市是作为数据仓库的一个完整部分设计和管理的，则可能不需要验证过程，且可以将数据直接从数据集市装入数据仓库数据库。在每种情况下，都需要调整显示应用程序以容纳新数据。

可以使用 Transact-SQL、数据转换服务 (DTS)、bcp 实用工具或自定义应用程序更新数据集市或数据仓库表。或许还能使用复制执行数据集市更新。有关更多信息，请参见复制概述。


管理数据仓库

管理数据仓库与管理联机事务处理 (OLTP) 系统既相似又不同。相似之处在于：在关系数据库中存储和维护数据仓库数据，所以用于管理关系数据库的工具也可以用于数据仓库。不同之处在于：OLTP 系统通常具有大量不稳定数据的事务更新的特点，而数据仓库通常具有大量稳定的历史数据的特点。这些差异要求对数据仓库管理任务使用不同的方法，如备份数据和自动执行反复出现的任务。

请参见

SQL Server 管理概述

管理 Analysis Services

备份数据仓库数据

自动化数据仓库任务


备份数据仓库数据

联机事务处理 (OLTP 系统捕获外来数据并更新数据库。为确保不丢失数据，系统在事务执行时记录事务，管理员则制定包括定期的完整和增量数据库备份的备份策略。这些策略旨在防止数据丢失，最大程度地减少对可操作事务处理的影响，以及从系统故障中快速恢复。

相反，数据仓库存储大量稳定的历史数据，按照被管理的定期调度进行更新。对于数据仓库，在设计备份策略时应尽量减少完整备份并对数据更新使用增量备份。

在恢复时间约束上，数据仓库故障比 OLTP 故障通常更灵活且限制更少。与 OLTP 系统相比，更宽松的恢复时间约束通常使得很少需要进行完整数据仓库备份。例如，销售事实表可能包含数百万行反映十年历史的销售。在业务执行到年终结束时，几乎不太可能更改销售数据。

重复备份没更改的数据是不必要的，备份策略中应考虑这一点。根据恢复时间约束和数据量，可以创建一个策略，使用增量备份备份在数据仓库更新过程中新增的数据，然后创建只包含在年终结束后的当前年度内新增的数据的备份。从彻底的数据仓库数据库故障中恢复要求装载多个备份，当前年度之前的每一年各有一个备份，然后是当前年度更新的增量备份。

Microsoft® SQL Server™ 2000 Analysis Services 在专用分析服务器数据库中维护 OLAP 数据，该数据库可与数据仓库数据库备份分开存档和还原。

请参见

备份和还原数据库

存档和还原数据库


自动化数据仓库任务

管理和维护数据仓库涉及大量的任务。这些任务中的很多可通过 Microsoft® SQL Server™ 2000 中的各种工具自动执行。可以调度定期完成适当的任务。

必须定期更新数据仓库以包含来自正在进行的业务操作中的新数据。可以组合各种 SQL Server 2000 处理功能和方法来定义执行数据析取作业。可以调度定期执行这种作业并提供有关作业完成和状态的自动提示。

除了内置工具外，SQL Server 2000 还提供很多编程对象模型和接口，可用于创建执行管理任务的自定义应用程序。可以使用编程语言（如 C/C++、Microsoft Visual Basic®）或脚本创建这些应用程序。有关更多信息，请参见生成 SQL Server应用程序概述和联机丛书中"生成 SQL Server 应用程序"小节内的其它主题。

请参见

自动化管理任务

SQL Server工具概述

更新数据仓库数据


优化数据仓库性能

对于分析并汇总多个联接表中的大量行的查询，数据仓库必须提供对这类查询的快速评估。Microsoft® SQL Server™ 2000 提供可用于优化包含数据仓库数据的关系数据库性能的信息。数据库的性能会受您所做的很多选择的影响，比如在数据库的逻辑设计、它的物理实现、索引优化、查询优化等方面的选择。有关更多信息，请参见数据库性能优化概述。

虽然 SQL Server 2000 Analysis Services 的性能在很大程度上取决于数据仓库数据库的性能，它的性能也受数据仓库数据库设计和 Analysis Services 多维数据集的影响。还可以通过使用工具优化 Analysis Services 的性能，这些工具在处理多维数据集时通过调整预先计算好的聚合量分析使用模式，从而优化多维数据集架构以避免不必要的联接，等等。计算机硬件配置也影响分析服务器的性能。有关更多信息，请参见分析和优化性能。