交付有效且灵活的数据仓库实现解决方案

業务环境是在快速变化的而业务数据的类型也是如此。一个成功的数据仓库实现解决方案的基础就是灵活的设计这种设计可以适应不斷变化的业务数据。数据仓库实现的架构和仓库数据的建模是仓库设计中的核心过程

当使用数据模型捕获业务需求时，您就已经完成了數据仓库实现设计中的部分工作然而，正式的数据仓库实现设计应该从数据仓库实现的架构开始

仓库架构是基于一些因素所做的关键決策，这些因素包括当前基础设施、业务环境、期望的管理和控制结构、实现工作的承诺和范围、企业所采用的技术环境的功能以及可用嘚资源等

仓库架构将决定数据仓库实现和数据集市本身的位置，以及控制所驻留的位置或者反之。例如数据可以驻留在集中进行管悝的中心位置中。或者数据可以驻留在集中或独立管理的分布式的本地和/或远程位置中。

这些架构选择也可以组合使用例如，数据仓庫实现架构可以在物理上分布或集中管理

业务范围的数据仓库实现架构

业务范围的数据仓库实现就是将支持整个或一大部分业务的数据倉库实现，该业务需要更加完全集成的数据仓库实现跨部门和业务线（line of business）具有较高的数据访问和使用率。即基于整个业务需求设计和构慥仓库可以将之视作可跨整个企业使用的决策支持数据的公共存储库，或其中的一个大型子集这里所使用的术语“业务范围（business-wide）”反映的是数据访问和使用的范围，而非物理结构在整个企业中，业务范围的数据仓库实现在物理上可以是集中式的也可以是分布式的。

獨立的数据集市架构暗指单独的数据集市这些数据集市是由特定的工作组、部门或业务线进行控制的，完全是为满足其需求而构建的實际上，它们甚至与其他工作组、部门或业务线中的数据集市没有任何连通性

图 1. 数据仓库实现架构选择

互连的数据集市架构基本上是分咘式的实现。虽然不同的数据集市是在特定的工作组、部门或生产线中实现的但它们可以是集成、互连的，以提供更加全局的业务范围嘚数据视图实际上，在最高的集成层次上它们可以成为业务范围的数据仓库实现。这意味着一个部门中的终端用户可以访问和使用另┅部门中数据集市中的数据

如果您客户的业务和数据源是相对集中的，那业务范围的集中式数据仓库实现架构就是最明智的选择这实際上对于中间市场的公司而言是很普遍的情况。否则对于在地理上广泛分布的业务而言，互连的数据集市和业务范围的分布式数据仓库實现就是更加实用的选择

独立的数据集市架构不是一种好方法，因为它违背了数据仓库实现的关键概念：数据集成

实现方法的选择受這些因素的影响：当前的 IT 基础设施、可用的资源、所选择的架构、实现的范围、对于跨企业进行的更大业务范围的数据访问的需求、投资囙报率（return-on-investment）需求以及实现的速度。实现方法的选择是数据仓库实现设计中的重要部分；该决策需要在数据仓库实现项目的早期阶段做出

洎顶向下的方法就是在单个项目阶段中实现数据仓库实现。自顶向下的实现需要在项目开始时完成更多计划和设计工作这就需要涉及参與数据仓库实现实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型嘚有关决策一般需要在真正的实现开始之前就完成

自底向上的实现包含数据仓库实现的计划和设计，无需等待安置好更大业务范围的数據仓库实现设计这并不意味着不会开发更大业务范围的数据仓库实现设计；随着初始数据仓库实现实现的扩展，将逐渐增加对它的构建现在，该方法得到了比自顶向下方法更广泛的接受因为数据仓库实现的直接结果可以实现，并可以用作扩展更大业务范围实现的证明

每种实现方法都有利弊。在许多情况下最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集荿的计划和设计的程度因为数据仓库实现是用自底向上的方法进行构建。

在使用自底向上或阶段性数据仓库实现项目模型来构建业务范圍架构中的一系列数据集市时您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库实现这样嘚方法可以极好地适用于业务。每个数据集市都可以处理可识别的业务问题或主题领域从而可以计算 ROI。构建团队可以测试并调整产品洏该方法也为构建团队提供了宝贵的学习曲线。

对于中间市场的公司有一些额外的理由要采用自底向上的方法：

• 在中间市场的业务及其業务数据结构中，存在比企业业务数据中更多的易变性
• 较小的公司通常存在有限的项目预算。
• 中间市场的公司需要快速解决方案以减轻其业务难度
• 该类项目所需要的人员必须具有对业务的广泛理解以及特定业务领域的详细知识。找到这样的人是很困难的但即使可以，使用他们的时间来进行数据建模也比让他们尽普通业务职责更加困难

既然已经具有关于高级数据仓库实现架构的一些决策，您就可以开始考虑数据仓库实现应该具有什么组件了

图 2. 商业智能基础设施组件的高级视图

数据仓库实现应具有上图中所描述的商业智能基础设施中嘚所有组件。本文将关注数据仓库实现的构造其中涉及到了除信息分析之外的所有这些组件。

这些商业智能组件可以定义为：

• 数据源：當前可用的业务数据源和外部数据源以及将来可能存在的数据源的清晰定义
• 数据获取：用于获得、清洗、转换和集成数据的 ETL（提取、转換和装入）过程。
• 业务数据仓库实现：仓库数据存储库的数据库
• 数据传播：用于为数据集市聚集和增强数据的 ETL 过程。
• 数据集市：更加用戶友好的数据结构中的数据仓库实现的子集
• 信息分析（本解决方案中未涉及）。
• 元数据管理：业务需求、数据模型、ETL 过程设计、用户手冊等等。
• 系统管理：数据管理、数据仓库实现安全性、系统和数据库的备份和恢复等等。

数据只是所有业务活动、资源以及企业结果嘚记录数据模型是对那些数据的组织良好的抽象，因此数据模型成为理解和管理企业业务的最佳方法是极其自然的数据模型起到了指導或计划数据仓库实现的实现的作用。在真正的实现开始之前联合每个业务领域的数据模型可以帮助确保其结果是有效的数据仓库实现，并且可以帮助减少实现的成本

目标仓库数据的建模是将需求转换成图画以及支持表示那些需求的元数据的过程。出于易读性目的本攵将关于需求和建模的讨论相分离，但实际上这些步骤通常是重叠的一旦在文档中记录一些初始需求，初始模型就开始成型随着需求變得更加完整，模型也会如此

最重要的是向终端用户提供良好集成并易于解释的数据仓库实现的逻辑模型。这些逻辑模型是数据仓库实現元数据的核心之一为终端用户提供的简单性以及历史数据的集成和联合是建模方法应该帮助提供的关键原则。

仓库数据的建模与操作數据库的建模

在建模的过程中请记住下列问题：

• 数据仓库实现应该是面向终端用户的。在数据库操作中用户不直接与数据库进行交互。他们使用应用程序这些应用程序具有预先定义的或固定的查询。数据仓库实现的数据库——特别是数据集市——与终端用户非常接近它通常不具有固定的查询。因此它必须更易于理解。
• 数据仓库实现应该是为数据分析而设计的终端用户几乎直接处理数据，而且没囿固定的工作流（除了这里和那里的少数例外）终端用户对在仓库中记录数据不感兴趣，但他们需要从中获得信息他们向仓库提出问題，通过所提取的信息测试并验证假设重新构造事件链，分析那些事件以检测可能的模式或季节性的趋势以及为将来做出推断和设计。
• 终端用户的需求可能是模糊或不完整的这些不完整的需求需要灵活的建模过程和适合于进化开发的技术。灵活的进化软件开发的风险昰不连贯和不一致的终端结果在开发数据模型时，肯定需要注意这些问题
• 数据仓库实现是集成的数据库集合，而非单个数据库应将咜构想为单个信息源，用于整个企业中所有的决策支持处理和所有的信息应用程序数据仓库实现是一个“有机”物，如果在开始时还不夠大就还会趋于变大。
• 数据仓库实现包含属于不同信息主题领域的数据这些主题领域可以是将数据仓库实现逻辑划分成几个不同（概念的，甚至或者是物理的）数据库的基础数据仓库实现还可以包含不同类别的数据。
• 数据仓库实现通常包含历史数据而不是日常操作數据的快照（snapshot）。必要的遗留数据库可能不可用或者可能无法在足够细的层次上捕获，除非花费金钱并付出努力来改变遗留输入环境洇此，数据仓库实现启用项目通常涉及业务过程和源应用程序的重组（reengineering）

如何进行数据仓库实现的建模可能是商业智能领域中最有争议嘚问题之一，而本文不会进行这方面的讨论本小节将介绍两层的仓库建模方法，该方法最适合于自底向上的实现

图 3. 两层仓库建模

数据存储库层，或后端层包含了所有的人工模型组件和完整的模型结构它们处理所有必要数据源中的集成业务数据。数据存储库层具有两个數据模块：数据登台（staging）和数据存储库数据分级模块存储所有数据源的初始数据和临时数据，以用于 ETL 处理数据存储库存储所有的集成業务数据，它是数据获取 ETL 过程的最终目标

数据集市层包含所有的数据集市，这些数据集市是数据存储库模块的子集以便特定的终端用戶组在其数据分析活动中使用起来足够简单。

因为数据仓库实现和数据集市在许多情形中是可以交换的概念所以有必要基于两层的仓库模型指定它们的定义。在该模型中业务数据仓库实现是数据存储库数据库（模块）的集合，而数据集市则是数据集市层中的数据库数據集市中的业务数据只能来自业务数据仓库实现。

两层数据仓库实现设计的好处包括：

• 灵活且易于维护可以随时根据用户的报表需求修妀数据集市的数据结构。但是它不影响数据存储库中数据库的数据结构。
• 易于伸缩和集成关系类型的业务数据存储库数据库比数据集市中非正规（denormalized）和汇总性（summarized）的数据库更易于伸缩和集成。
• 用户友好将数据集市和数据存储库分离使得数据集市的设计更加是终端用户所驱动的，因为数据建模师不需要过多考虑数据集成和模式可伸缩性问题
• 更好的安全设计。两层的方法将数据存储和数据访问管理相分離终端用户只能访问授权给他们的数据集市，而非所有的数据仓库实现数据
• 更好的数据管理设计。数据仓库实现是为存储集成的业务范围的历史数据而设计的但是，数据仓库实现中的许多数据集市都不一定需要那么多的历史数据两层设计是存储历史数据的好地方。

請记住上面两层的仓库设计是概念仓库布局。例如在数据存储库层，登台数据库和存储库数据库可以在不同的服务器上、在同一服务器上或者甚至在不同模式下的同一数据库中

数据建模有三层：概念、逻辑和物理。在数据仓库实现的设计中数据建模的每一层都有自巳的目的。

高级数据模型是所有业务主题领域以及业务的公共数据元素的一致性定义从高级的业务视图到通用的逻辑数据设计。您可以從中派生出通用的范围并获得对业务需求的理解。这个概念数据模型是当前和将来数据仓库实现开发阶段的基础

逻辑数据模型包含关於业务主题领域的更多详细信息。它捕获目标业务主题领域中的详细业务需求逻辑数据模型是当前项目的物理数据建模的基础。

从这一階段开始该解决方案就适用自底向上的方法了，这意味着这个逻辑数据模型中仅仅将最重要和紧迫的业务主题领域锁定为目标

逻辑数據模型的功能包括：

• 对于所有实体及其之间的关系的规范。
• 对于每个实体的属性的规范
• 对于所有主键和外键的规范。
• 对于多维数据结构嘚规范

物理数据建模应用物理约束，如空间、性能以及数据的物理分布物理数据模型是与数据库系统以及您将使用的数据仓库实现工具紧密相关的。该阶段的目的是设计真正的物理实现

将逻辑建模与物理建模清晰分离是特别重要的。良好的逻辑建模实践关注问题域的夲质逻辑建模解决“什么”之类的问题。物理建模为模型解决“如何”之类的问题这表示给定的计算环境中实现的真实性。因为业务計算环境随时间变化所以逻辑和物理数据建模的分离将帮助稳定一个阶段到另一阶段的逻辑模型。

一旦实现了数据仓库实现且客户开始使用它，他们就常常会生成新的请求和需求这将启动另一开发周期，继续数据仓库实现构建的迭代和进化过程正如您可以看到的，邏辑数据模型是数据仓库实现的活动部分在数据仓库实现的整个生命周期中使用和维护。数据仓库实现的建模过程确实是无止境的

图 4. 數据仓库实现逻辑数据模型的生命周期

仓库数据存储库数据库存储来自所有业务数据源的所有清洁的（cleaned）集成业务数据，它是数据仓库实現中数据集成和转换的终点虽然概念数据模型是根据业务需求设计的，但是数据存储库逻辑数据模型是基于业务需求和可用业务数据源嘚分析而设计的它是用于验证现有业务数据是否支持数据仓库实现项目中业务需求的自然检查点。

存储库数据库基本上仍然是正规的（normalized）关系数据库因为它们是源驱动的，所以源数据模型可以用于协助仓库数据存储库模型的完全开发过程您可能需要通过使用逆向工程（reverse engineering）技术构造源数据模型，从而从现有的源数据库中开发实体和关系（Entity and RelationER）模型。您可能需要首先将几个这样的模型集成到一个全局模型Φ以逻辑集成的方式表示源。

在数据转换过程中清洗并清理了数据仓库实现中的数据。它至少应该与源操作系统中的数据一样好在 ETL 過程中，即时参照完整性和检查约束极其有助于检测数据问题在最终的数据仓库实现表中实现它们也不会高效。

数据仓库实现的一个重偠特点就是它包含历史数据根据更新频率而言，有两种历史数据：慢更新的和快更新的历史数据对于慢更新的历史数据，更新是使用具有有效状态和时间框架（time-frame）数据的历史子表进行处理的

事务和 Web 遍历数据是快更新数据的典型例子；它们通常具有较大的（旧的和新的）数据量。存储快更新历史数据最重要的设计问题就是性能例如，有从 1999 年开始的大量事务数据但是正如业务需求所显示的，只有最近 3 姩的事务数据才被频繁访问以制作报表图 5 是一个高级的事务表的逻辑和物理分区设计。

图 5. 事务表的逻辑和物理分区

因为仓库终端用户直接与数据集市进行交互所以数据集市的建模是捕获终端用户业务需求的最有效工具之一。数据集市的建模过程取决于许多因素下面描述了三个最重要的：

• 数据集市的建模是终端用户驱动的。终端用户必须参与数据集市的建模过程因为他们显然是要使用该数据集市的人。因为您应期望终端用户完全不熟悉复杂的数据模型所以应该将建模技术和建模过程作为整体进行组织，以便使复杂性对终端用户透明

• 数据集市的建模是由业务需求驱动的。数据集市模型对于捕获业务需求十分有用因为它们通常由终端用户直接使用，且易于理解

• 数據集市的建模极大地受到了数据分析技术的影响。数据分析技术可以影响所选择的数据模型的类型及其内容目前，有几种常用的数据分析技术：查询和报表制作、多维分析以及数据挖掘

  如果仅仅意图提供查询和报表制作功能，那么带有正规（normalized）或非正规（denormalized）数据结构的 ER 模型就是最合适的维度数据模型也可能是较好的选择，因为它是用户友好的并具有更好的性能。如果其目标是执行多维数据分析那麼维度数据模型就是这里的惟一选择。然而数据挖掘通常在可用的最低细节级（level of detail）工作得最好。因此如果数据仓库实现是用于数据挖掘的，就应该在模型中包含较低细节级（level of detail）的数据

因为本文没有包括 ER 建模，所以本小节将讨论维度数据建模这是数据集市设计中最重偠的数据建模方法。

有两种基本的数据模型是可以在维度建模中使用的：

星型模式已经成为一个公共术语用于表示维度模型。数据库设計师长期使用术语“星型模式”来描述维度模型因为结果结构看上去像一个星星。一些业务用户不习惯术语“模式”所以他们接受听起来更加简单的术语“星型模型”。术语“星型模型”和“星型模式”是可以相互交换的

星型模型是维度模型的基本结构。它通常有一個大型的中心表（称作事实表）和一组小型表（称作维度表）维度表以放射模式围绕事实表。

传统的 ER 模型具有均匀且平衡的实体样式和實体之间的复杂关系而星型模型却是完全不对称的。维度模型中的事实表与其他所有维度表之间存在单一连接

维度建模通常在收集了業务需求之后，首先指定事实和维度初始的维度模型在外表上通常像星星一样，一个事实位于中心一个级别上的多个维度则围绕在周圍。雪花型模型是一个或多个维度的分解结果它们自己有时具有层次结构。您可以将一个维度表中成员之间多对一的关系定义为一个单獨的维度表从而形成层次结构。

分解的雪花型结构很好地展示了维度的层次结构雪花型模型易于数据建模师的理解以及数据库设计师鼡于维度的分析。然而雪花型的结构看起来更复杂，并且可能趋于使业务用户用起来感到不如更简单的星型模型舒服开发人员也可以選择雪花型，因为它通常节省了数据存储考虑一个银行应用程序，其中针对一个维度有一个极其大型的帐户表您可以选择通过不存储極其频繁重复的文本字段，而是将其一次性放置在一个子维度表中节省该大小的表中的大量空间。

虽然雪花型模型不节省空间但与事實表相比时，这通常是不重要的大多数数据库设计师都不将节省空间作为选择建模技术的主要决策标准来考虑。

图 6. 星型模式结构示例

用戶通常需要评估或分析企业业务的某些方面所收集的需求必须表示该分析的两个关键元素：所分析的内容以及用于分析内容的评估标准。评估标准称作测度（事实的数字属性）而所分析的内容称作维度（事实的描述属性）。一组维度及其相关的测度共同组成了所谓的事實

维度的基本结构就是层次结构。维度层次结构用于在比维度模型中测度所呈现的基本粒度更小的细节级（level of detail）来聚集业务测度如销售總收入（Total Revenue of Sales）。本例中操作称作上卷（roll-up）处理。上卷处理是对维度模型中的基本事实或测度执行的

如果将测度上卷到更小的细节级（level of detail），那么终端用户就显然可以执行逆操作（下钻）该操作包含查看更详细的测度，或按照维度层次结构探索更低的细节级聚集测度

维度建模最重要的活动之一就是捕获聚集路径或终端用户执行上卷和下钻所依照的聚集层次结构。该过程将产生维度模型您将在稍后执行其怹建模活动时扩展和修改该模型，如慢变化的时间维度的建模、维度中约束的处理以及跨维度的关系和约束的捕获

维度建模与终端用户囷业务过程紧密相关。为了使维度模型持续更长时间并适用于更多用户组特别重要的是从概念的观点建模维度，寻找终端用户社区大致會感兴趣的基本的聚集路径和聚集级别

您通常可以向良好定义的事实添加测度，且根本不对模型造成很大影响然而，对于维度这就肯定不正确了，因为维度层次结构的结构可能变得复杂

当您在广阔的环境中考虑问题域时，将期望一个维度中具有多个不同的聚集路径维度层次结构中的分割可以在不同的级别上出现。已经分割的层次结构可以在稍后再次进行分割该过程可能导致复杂的模式，也许太過于复杂以致终端用户无法处理。请咨询您的终端用户以避免不必要的纠纷

一个通常难以做出的重要决策就是一个聚集层是否真正是（结构化）层次结构的一个元素，或它是否仅仅是维度中一项的属性例如，将产品包装单元、品牌或存储类型作为维度路径的显式元素（即作为维度层次结构中潜在的实体类型）是否是明智或必要的呢？或者是否可以仅仅将它们考虑成产品的属性呢

查找维度（如 Product 维度）中的基本聚集路径通常意味着调查维度中的许多典型关系。

1. 构造或结构化关系：信息分析员使用这些关系来探索产品及其组件之间的构慥性关系例如，通过与产品组件相关的成本和产品构造相关的成本它们可以用于计算产品成本。

2. 变化（Variation）关系：变化用于就产品模型、版本、实现、组件混合、调配等而言区分产品

   变化还可用于指定产品替换。信息分析员使用变化关系来组合相关产品和聚集相关测度因为较低级类别的产品可能只存在于一段有限的时期内，或者因为它们频繁用于在某一过程中相互替换（例如当“初始”产品缺货，洏将某一版本的产品卖给客户时）

3. 分类关系：分类是将相似的产品分成组。关系分类显然是产品之间出现最频繁的关系信息分析员用於上卷详细的测度。请注意通常需要多个不同类型的分类。例如可以根据面向销售、面向制造、面向储备或面向供应的特点来对产品進行分类。信息分析员将分类用于统计组中的聚集测度统计组有总数、平均数、最小值和最大值等。

事实表只包含用于引用维度表的 ID鉯及用于测量所有维度成员变化或性能的测度。下一步就是将维度和测度组织成事实这是以可以解决指定需求的方式将维度和测度进行汾组的过程。

事实表的设计中要解决几个重要问题：

• 粒度（记录事实的细节级）：如果要有效地分析数据就必须都在同一粒度级别上。┅般说来您应该将数据放在最详细的粒度级别上。这是因为您无法将数据修改到您所决定设置的细节级上但是，您总是可以上卷（汇總）数据以创建一个略粗的粒度级别的表

• 相加性（要总结的测度的能力）：测度分成三个类别：全相加的（fully additive）、非相加的（nonadditive）和半相加嘚（semiadditive）。一个非相加测度的例子就是百分率您无法简单地将两个事实的百分率相加到一起，并产生有意义的结果一个半相加测度的例孓就是余额。虽然您可以将两个帐户的余额相加获得总的余额但无法将同一帐户在两个不同时间点的两个余额相加。因为余额只是跨一些维度进行相加的所以我们称之为半相加测度。将可以跨所有维度相加的值视作全相加的当您考虑将在事实表上发生的可能汇总时，楿加性就变得很重要通常，全相加的测度是最理想的当测度不是全相加的时，应考虑将它们分成其原子元素

• 键选择：多维数据建模Φ的键选择是一个难题。它包含性能和易于管理之间的权衡（trade-off）键选择主要适用于维度。您为维度所选择的键必须是事实的外键维度鍵有两种选择：您可以分配一个任意键，或者使用操作系统中的标识符任意键通常只是一个序列号，当需要一个新键时就分配下一个鈳用的号码。

  为了使用操作系统中的标识符惟一地表示维度您有时需要使用一个复合键。复合键就是由多个列组成的键任意键是一列，通常比操作派生的键要小因此，任意键通常可以更快地执行连接

  键选择中的最后一个因素就是它对事实表的影响。在创建事实时必须将每个维度的键分配给它。如果维度将带有时间戳的操作派生的键用于历史数据那么在创建事实时，就没有附加工作连接将自动發生。对于任意键或任意历史标识符在创建事实时，就必须将一个键分配给事实

  分配键的方式有两种。一种就是维护操作和数据仓库實现的键的转换表另一种就是存储操作键，并且在必要时存储时间戳作为维度上的属性数据。

  那么选择就在任意键的更好性能和操莋键的更易维护之间进行。性能提高多少和维护增加多少的问题就必须在您自己的组织中进行评估了

  无论做出什么选择，都必须在元数據中用文档记录生成它们的过程该信息对于管理和维护数据仓库实现的技术人员来说是必要的。如果您所使用的工具没有隐藏连接处理那么用户可能也需要理解这一点。

既然您理解了维度和事实表的处理就让我们看一看真实世界的例子，以探索如何从业务需求中识别維度和测度该例子只是对于一系列业务问题的基本分析。这些业务问题被定义为示例需求：

1. 按照银行支行本月客户的平均余额和交易數是多少？
2. 按照支行、产品和地区汇总要付给每位客户的年净利润和利息是多少？
3. 百分之几的客户是盈利的将他们按照支行、地区和姩分类。
4. 本年一位客户的总交易量是多少
5. 按照地区，最盈利的前 5 位产品是什么
6. 在最近 5 年里，最盈利的前 5 个支行是什么
7. 最盈利的客户嘚人口和地理特点是什么？

通过分析这些问题我们就定义了需要满足需求的维度和测度（见表 1）。

表 1. 维度和测度表

此时您要检查维度鉯确保：

• 您具有需要用于回答问题的数据。
• 在最细的级别定义了所有的测度

使用这些简化的分析问题来决定最终的星型模型中包含什么鉯及排除什么：

• 余额和交易数基于交易量的聚集，所以它们是派生的测度
• 所付利息的计算是将帐户利率乘以余额。这是基于帐户和基于朤份的计算因为利率是 Account 表的一个属性，所以需要添加 Account 维度表正如您可以看到的，所付利息也是派生的测度
• 假定净利润基于（投资收益）- （所付利息）的计算。因为投资收益是银行级的测度而所付利息是派生的测度，所以净利润也是派生的测度

从以上分析得出的结論有：

• 交易量是惟一需要的测度。
• 需要帐户维度来产生利率和投资收益信息

在传统的开发周期中，完成一个模型之后只有需要进行修妀或其他项目需要数据时，才使用它但是在该仓库中，要连续使用模型仓库的用户不断访问该模型以决定他们需要用于分析组织的数據。仓库中数据结构的修改速度比操作性数据结构要快得多因此，仓库的技术用户（管理员、建模师、设计师等等）也将定期使用您的模型

这就是元数据所承担的任务。远远不只是一副漂亮的图画该模型必须是所存储数据的完整表示，否则它对于任何人都毫无用处。

为了正确理解模型以及可以确认它满足了需求，用户必须访问按照容易理解的业务术语描述仓库的元数据因此，您应在此时记录非技术的元数据在设计阶段，您将向它添加技术元数据

在仓库级上，您应提供仓库中可用东西的列表该列表包含可用的模型、维度、倳实和测度，因为当用户开始分析数据时这些都将用作初始的进入点。

对于每个模型提供名称、定义和目的。名称仅仅给用户提供一些搜索时关注的东西它通常与事实相同。定义指定建模的内容而目的描述模型用于什么。模型的元数据也应包含与之相关的维度、事實和测度列表以及联系人员的姓名，以便用户在有关于模型的问题时能够获得附加的信息。

在投入大量时间和精力实现仓库数据库之湔与用户一起验证模型是一个很好的想法，特别是数据集市模型进行该检查的目的是双重的。首先它确认模型可以真正满足用户的需求。第二检查应确认用户可以理解该模型。请记住一旦实现了仓库，用户就会定期依靠模型访问仓库中的数据无论模型多么好地滿足了用户的需求，如果用户无法理解模型以访问数据您的仓库都是失败的。

此时验证是在高级别上完成的。与用户一起检查该模型鉯确认它是可以理解的与用户一起，通过解决您将如何回答需求中指定的部分问题来测试模型

模型不必满足用户的所有需求，这一点昰好的这不意味着您应停止并返回到开始。期望您模型的第一次切入满足约 50% 的需求接受模型的这 50%（或者不管验证了多少），并开始进荇物理设计应将剩余的送回给需求的收集阶段。要么需要更好地理解需求要么通常需要修改并重新定义它们。这常常会导致对已创建嘚模型进行添加和修改同时，模型的有效部分将通过设计阶段并开始向用户提供好处。

开发的重复和部分完整模型的继续创建是提供赽速开发数据仓库实现能力的关键元素

图 7. 仓库数据模型评估过程

在需求的验证过程中，您将：

• 对照给定的用户需求检查初始维度模型嘚连贯性和完整性以及有效性。与终端用户一起分析初始模型这将允许需求分析员执行更多调查，并在将其传递给需求建模阶段之前调整这些初始模型（尝试按照模型中所表达的修改需求）

• 指定候选的数据源。建立必要和可用数据源的库存

• 将初始维度模型、可能配有嘚信息化终端用户需求映射到指定的数据源。这通常是一项冗长乏味的工作源数据映射必须调查下列映射问题：

  • 哪些源数据项可用，哪些不可用对于不可用的那些，是否应扩展源应用程序是否可以使用外部数据源找到它们？或者是否应向终端用户通知它们的不可用性并且因此，是否应减小维度模型的范围

  • 数据源中是否有其他可用但没有请求的有趣数据项呢？指定可用但没有请求的数据项可能暴露信息分析活动的其他有趣方面并且可能因此极大地影响所构造的维度模型的内容和结构。

• 验证数据集市设计没有违背任何业务安全性设置因为数据集市是为特定的终端用户组设计的，所以确认它只包含该组必要的信息是很好的想法

• 执行模型的初始大小调整。如果完全鈳能初始的大小调整还应调查与填充数据仓库实现相关的容量和性能方面的情况。

需求验证的结果将帮助您评估数据仓库实现开发项目嘚范围和复杂性并（重新）评估业务的调整，包括技术、金融和资源的评估需求验证必须与终端用户协同执行，以暴露和改正不完整戓不正确初始模型的所有问题需求验证可能涉及构建维度模型的原型。

需求验证过程将确认或重新建立终端用户需求和期望作为需求驗证的结果，您还可能指定和评估源数据重组（reengineering）建议在需求验证的最后，您将获得用于数据仓库实现建模项目的（新的）“签字”

繼续本系列中的下一篇文章，其中将继续探索仓库 ETL 过程的设计和实现、仓库性能、安全性等

• 关于商业智能和其他解决方案领域的更多详細信息，请参阅
• 关于更新产品的特定信息，请在 网站查找详细信息
• 关于商业智能的更多技术参考资料，请参阅
• 关于 DB2 数据挖掘、编程、系统管理、内容管理等的技术和业务级特性，请阅读
• 提供了许多有帮助的参考资料。
• 关于大量技术主题的深入介绍请在线浏览 。

数据集成是数据仓库实现中的关鍵概念ETL（数据的提取、转换和加载）过程的设计和实现是数据仓库实现解决方案中极其重要的一部分。ETL 过程用于从多个源提取业务数据清理数据，然后集成这些数据并将它们装入数据仓库实现数据库中，为数据分析做好准备

尽管实际的 ETL 设计和实现在很大程度上取决於为数据仓库实现项目选择的 ETL 工具，但是高级的系统化 ETL 设计将有助于构建高效灵活的 ETL 过程

在深入研究数据仓库实现 ETL 过程的设计之前，请記住 ETL 的经验法则：“ETL 过程不应修改数据而应该优化数据。”如果您发现需要对业务数据进行修改但不确定这些修改是否会更改数据本身的含义，那么请在开始 ETL 过程之前咨询您的客户

调制的 ETL 过程设计

由于其过程化特性以及进行数百或数千个操作的可能性，所以以精确方式设计 ETL 过程从而使它们变得高效、可伸缩并且可维护就极为重要。ETL 数据转换操作大致可以分为 6 个组或模块：数据的提取、验证、清理、集成、聚集和装入要安排好这些组，按照使这一过程获得最大简化、具有最佳性能和易于修改的逻辑次序来执行操作下图中展示了执荇的次序。

图 1. ETL 数据转换过程的功能模块设计

在项目的业务需求和数据分析阶段我们创建了数据映射信息。有许多中记录数据映射的方式；ETL 数据映射表是指导 ETL 过程设计的最佳方式您还可以将该表用作与业务客户就数据映射和 ETL 过程问题进行交流的方式。ETL 数据映射表有不同的級别如实体级别和属性级别。每个级别中都具有不同级别的详细数据映射信息下表是一个实体级别的 ETL 数据映射表的简化例子。该表中嘚每个“X”表示到操作细节或较低级数据映射文档的链接

设计和实现仓库 ETL 过程。

下面是创建和启动新的仓库控制数据库的步骤：

确保启動了 DB2 仓库（Warehouse）服务器和相关的服务在仓库控制数据库的管理窗口中，填入控制数据库名、模式名（IWH）、用户 ID 和密码并创建该仓库控制數据库。如果在以前版本的 DB2 DWE 上已经有一个仓库那么还可以使用此过程将仓库控制数据库迁移到当前版本中。

通过新创建的或迁移的控制數据库登录到 DB2 Data Warehouse Center如 图 2 所示。确保使用与步骤 1 相同的用户 ID 和密码如果仓库控制数据库是一个远程数据库，则必须对该节点和控制数据库进荇编目

注意：DB2 Data Warehouse Center 的登录窗口将允许您在多个仓库控制数据库中进行切换。当有许多项目或开发人员在同一 DB2 数据仓库实现（Data Warehouse）服务器上工作時此功能极其有用。

这些代理使用 Open Database Connectivity（ODBC）驱动程序或 DB2 CLI 与不同的数据库进行通信只需要几个代理就可以处理源仓库和目标仓库之间的数据遷移。您所使用的代理数目取决于现有的连接配置以及计划迁移到仓库中的数据量。如果需要同一代理的多个进程同时运行则可以生荿附加的代理实例。

代理站点是安装了代理软件的工作站的逻辑名称代理站点的名称与 TCP/IP 主机名不同。一个工作站可以只有一个 TCP/IP 主机名鈈过，您可以在一个工作站上定义多个代理站点逻辑名称将标识每个代理站点。

在设置数据仓库实现时必须定义仓库将用来访问源数據库和目标数据库的代理站点。Data Warehouse Center 使用本地代理作为所有 Data Warehouse Center 活动的默认代理但是，您可能需要使用来自包含仓库服务器的工作站的另一站点仩的仓库代理您必须在 Data Warehouse Center 中定义该代理站点，从而标识安装了该代理的工作站Data Warehouse Center 使用这一定义来标识启动代理的工作站。

上图说明了仓库玳理、数据源、目标和仓库服务器之间的关系

仓库源指定将为仓库提供数据的表和文件。Data Warehouse Center 使用仓库源中的说明来访问数据DB2 Data Warehouse Center 支持所有主偠平台上的大量关系数据源和非关系数据源，如下图所示

定义仓库主题领域、过程和步骤

仓库步骤是对仓库中单独某一操作的定义仓库步骤萣义如何移动和转换数据。可以在 DB2 Data Warehouse Center 中使用的仓库步骤类型有很多：

SQL（插入、更新和替换）

文件（FTP文件数据的导入和导出）

DB2 程序（数据导絀、装入、表重组和统计数据更新）

仓库转换器（数据清理、键表和时间表的生成，以及翻转和透视数据）

在运行一个步骤时可能发生倉库源和仓库目标之间的数据迁移或转换。其中一个步骤就是 Data Warehouse Center 中的一个逻辑实体该实体定义了以下内容：

对输出表或文件的定义和链接。

用来填充输出表或文件机制（SQL 语句或程序）和定义

填充输出表或文件的处理选项或时间表。

仓库过程包含为特定仓库执行数据转换和迻动的一系列步骤一个过程可以产生一个表或一组总结表（summary table）。过程还可以执行一些特定类型的数据转换

图 7. 定义仓库过程

主题区域指萣并划分与逻辑业务领域相关的过程。例如如果构建一个营销和销售数据的仓库，那么要定义一个销售（Sales）主题领域和一个营销（Marketing）主題领域

Data Warehouse Center 通过使用三种模式（开发、测试或生产）中的一种来划分步骤，从而允许您管理步骤的开发该模式将确定您是否可以修改步骤，以及 Data Warehouse Center 是否将根据其时间表运行步骤升级步骤表示将该步骤移至更高的模式（开发 -> 测试 -> 生产）。

开发模式：在创建一个步骤之后您就巳经处在开发模式中。您可以在该模式中修改任何步骤属性在此模式下，仓库为这一步骤所生成的目标表并不在目标仓库中如果需要運行这一步骤来执行测试，则必须将该步骤升级到测试模式

就会创建目标表。因此当您将一个步骤升级到测试模式之后，就只能进行那些不会损坏目标表的修改例如，当一个目标表的相关步骤处于测试模式时就可以向该目标表添加列，但无法从目标表中删除列在測试模式下，可以单独运行每个步骤Data Warehouse Center 不会根据其自动时间表来运行步骤。

生产模式：为了激活时间表和任务流链接必须将步骤升级到苼产模式。生产模式表明步骤已经处于最终格式在生产模式下，只能修改不影响该步骤所生成的数据的设置您可以修改时间表、处理選项（除了填充类型）或关于该步骤的描述性数据。但您不能修改该步骤的参数

DB2 仓库外部触发器程序

外部触发器程序是调用 Data Warehouse Center 的仓库程序。外部触发器服务器脚本可以用于升级或降级 DB2 仓库步骤以及启动或运行过程和步骤。在 ETL 开发和测试中外部触发器程序对于批量升级和降级仓库过程和步骤特别有用。您还可以使用该脚本来管理 ETL 过程和步骤的执行次序

外部触发器程序包含两个组件：外部触发器服务器（XTServer）和外部触发器客户机（XTClient）。XTServer 与仓库服务器安装在一起XTClient 与仓库代理安装在一起，用于所有的代理类型在从外部触发器程序触发一个步驟之前，必须在该步骤的 Properties 记事本的 Processing Options 页面上指定 Run on demand 选项

下面是 Windows 平台上用于升级 ETL 步骤的外部触发器脚本实例：

从命令窗口启动外部触发器服务器：

其中，<port_number> 是仓库服务器上外部触发器的服务端口号默认端口号是 11004。

创建并运行客户端的脚本命令文件该文件可能包含多行代码。例洳（在执行该文件时在一行中包含了所有的参数）：

<port> 是仓库服务器上的外部触发器服务端口号。默认端口号是 11004

<wait_for_result> 是可选的。该参数表明外部触发器程序是否要返回步骤或过程的处理结果请选择下列值之一：

1：等待步骤或过程完成。如果该步骤或过程成功完成了则返回 0，或者如果该步骤或过程失败则返回一个错误。

0 或空白：不等待步骤或过程完成

数据提取是捕获源数据的过程。有两种捕获数据的主偠方法：

完全刷新顾名思义，只是对移入中间（staging）数据库的数据进行完全复制该复制可能替换数据仓库实现中的内容，及时在新的时間点上添加完整的新副本或者与目标数据进行比较，以便在目标中生成一条修改记录增量更新的关注重点是只捕获源数据中修改的数據。

如何捕获数据修改与数据源本身是密切相关的；它实际上是逐个（case-by-case）实现的问题DB2 Data Warehouse Center 支持许多数据捕获方法，其中包括直接用 SQL 选择来捕獲所有数据或数据子集用 FTP 来捕获源数据源中的数据，数据文件的直接导入或装入以及数据复制。

从仓库数据源提取大量数据是所有数據仓库实现项目中的一个重要问题在 DB2 Warehouse Center 中，您可以采用许多方法：Select and Insert SQL 步骤或仓库负载实用程序

增量提交是一个允许您控制 Data Warehouse Center 所管理数据的提茭范围的选项。增量提交可用于 Select and Insert SQL 步骤中在代理要移动的数据量十分大，以致于在整个步骤的工作完成之前 DB2 日志文件就可能已经填满时戓者在需要保存部分数据时，可以使用增量提交如果所移动的数据量超出了已经分配的 DB2 最大日志文件，SQL 步骤将以失败结束数据库的性能可能会受到损害，因为在使用增量提交时可能出现相当多的提交。在执行提交之前要使用增量提交选项来指定将要处理的行数（大致为最接近的因数 16）。代理将选择并插入数据然后进行增量提交，直到成功完成数据移动为止

DB2 Load 转换器可以将大量数据从定界的（delimited）文件装入 DB2 表，替换或追加数据库现有的数据默认情况下，DB2 Load 仅在日志中记录进度消息而不是真正地输入数据，因此在这里不需要考虑日誌文件的长度。在数据装入结束之后表空间会处于暂挂（pending）状态；您需要备份该表空间，以使目标表可用然而，DB2 Load 转换器为您提供了一個保存输入数据的副本的选项如果使用该选项，则该表在数据装入之后就立即可用

您还可以指定要处理的最大行数，图 9 中展示了其他許多性能相关选项

DB2 Data Warehouse Center 的数据复制服务功能非常强大，并广泛用于为数据仓库实现中的完全刷新和增量更新捕获数据

对于增量更新，数据修改是从日志文件和时间取样（time-sampled）源中捕获的提取日志数据的典型方法就是数据复制。DB2 数据复制服务是与 DB2 Data Warehouse 紧密集成在一起的因此数据複制可以从 DB2 Data Warehouse Center 中进行配置和调度。

您可以使用 DB2 Data Warehouse Center 来定义复制步骤它将复制所有 DB2 Data Warehouse 支持的数据源之间的修改。您所需要的复制环境取决于需要进荇更新的时间以及处理事务的方式数据仓库实现（Data Warehouse）支持 5 种类型的复制：

用户副本（User Copy）：复制源表的完整压缩副本。压缩意味着目标表Φ包含一个主键并且可用它来进行更新。

时间点（Point-in-time）：在某一个时刻上的复制源表的完整的压缩副本目标表有一个主键和一个时间戳列。

基本聚集（Base aggregation）：历史表为每个订阅周期追加新行，在复制源表（基表）上使用 SQL 列函数的计算结果

更改聚集（Change aggregate）：历史表，为每个訂阅周期追加新行对包含了最近更改数据的复制源更改数据表使用 SQL 列函数的计算结果。

中间表（Staging table）：生成包含所提交事务中数据的目标表的表也称作一致的更改数据表。

创建仓库步骤所需要的密码文件

在源数据库的同一系统上启动 Capture 程序。

运行该步骤在运行该步骤时，仓库代理启动 Apply 程序来处理复制订阅

为复制准备 DB2 源数据库

为了使 DB2 源数据库用于复制，必须将数据库配置参数 LOG_RETAIN 设置为 RECOVERY以保留数据库日志攵件。

备份源数据库以解除数据库的 BACKUP PENDING 状态。

检查源数据库的配置参数 LOGPRIMARY、LOGFILSIZ 和 LOGSECOND确保这些值足够大，能够处理数据修改

可以在 DB2 Data Warehouse Center 中设置复制の前，必须在仓库控制数据库和目标数据库中创建复制控制表复制控制服务器上的用于捕获复制数据的控制表。目标数据库中的控制表鼡于应用复制数据

输入合适的大小值。下表中的值是一个实例：

对于一个源表您通常拥有多少目标表？

隔多久将数据应用到目标表

您期望一天捕获多少事务？

选择合适的源表并保留这些表的默认设置。选择 Run now 注册用于复制的源表

在 DB2 Data Warehouse Center 中，检查 Warehouse Sources 下面所列的数据库或表洳果没有列出复制源数据库或表，则将其作为仓库数据源进行导入或添加

在 DB2 Data Warehouse Center 中，检查 Warehouse Targets 下面所列的数据库或表如果没有列出复制源数据庫或表，则将其作为仓库目标导入尽管这些表可能已经列出，但仍需要重新导入它们让 DB2 DWC 知道已经为进行复制注册了这些表。

定义复制步骤与定义其他仓库步骤十分相似您可以在复制仓库步骤中定义 5 种类型的复制步骤：用户副本、时间点、基本聚集、更改聚集和中间表。（这些与 上面 所解释的步骤相同）

默认情况下，设置复制步骤是为了生成目标表如果需要将复制步骤链接到现有的目标表中，那么鈳以双击该目标表来打开 Properties 窗口在第一个选项卡上，启用选项 Data Warehouse Center created this table然后使用数据链接工具来将复制步骤连接到目标步骤上。在进行连接之后返回到目标表的属性，然后取消选项 Data Warehouse Center

在使用现有的用户创建的目标表时请特别小心，它与 DWC 生成的目标表相反正如前面提到的，在将複制步骤降级到开发模式时DWC 将删除 Apply 以及与这些步骤相关的订阅集。在升级步骤时将重新创建它们，而且因为 Applies 在此时是新的所以 Capture 程序將认为它需要向目标表提供完全刷新。如果已经在每个目标表上启用了 Data Warehouse Center created this table 选项那么将在降级时删除这些表，并在升级时重新创建它们（鉯及 Apply 程序、订阅集和表），这些表将为空准备各自接收数据的完全刷新。但是如果从不删除这些表，那么数据都会保留着并且如果執行完全刷新，那么通过外键连接目标表时很可能会发生错误在作为已填充的另一表的外键的目标表上，完全刷新的 Apply 部分将失败因为鈈可以从父表删除它。

图 10 说明仓库 User Copy 复制步骤的属性其中包括数据源和目标表之间的数据映射、复制订阅集名称、事件名、应用限定符（囿关的细节，请参阅下一小节）和用户 ID/密码

图 10. 定义仓库用户副本复制步骤

使用 asnpwd 实用程序创建密码文件

复制密码文件是加密的。Data Warehouse Center 复制步骤假定用于复制步骤的密码文件是：

位于由环境变量 VWS_LOGGING 指定的目录中

然后添加用户 ID 和密码：

除了对所有的应用限定符重复该命令之外，您可鉯只创建一次 pwd 文件然后为每个应用限定符制作该文件副本，将其重新命名为 applyqual.pwd —— 假定复制步骤都使用相同的数据库、用户 ID 和密码

您可鉯从 DB2 Replication Center 启动复制 capture 控制服务器。启动 Capture 程序将启动对复制启用的源表进行的数据库日志记录修改其中包括删除、插入和更新。请确保您所指定嘚日志记录目录有足够大的空间可以处理修改数据量。

您还可以通过将 capture 程序保存到文件中并从命令行运行它或者通过将 capture 程序保存为任務来启动它。

将复制步骤升级到测试或生产模式

在 DB2 Data Warehouse Center 中将复制步骤升级到测试或生产级别。在升级步骤时DB2 将创建订阅集和 Apply 程序，并在降級步骤时删除它们

可以修改测试模式中复制步骤的属性，只要不将复制降级到开发模式修改就会有效。下次将复制步骤降级到开发模式时这些修改将会丢失。

在项目的业务数据分析阶段您产生了一组数据质量假设。这些假设将指定客户和解决方案提供者双方在数据質量问题上的职责解决方案提供者通常关心数据清理和增强问题。客户至少要关注仅仅可以在数据源本身中解决的问题以及与解释数據含义相关的数据质量问题。例如：

业务操作应用程序相关的数据问题 —— 只能从应用程序本身解决的数据质量问题

您应该在项目合同攵档中包含数据质量假设，因为如果没有用正确的方法及时解决业务数据的质量问题它可能严重影响项目时间表。数据质量假设可能是與客户进行时间表协商的一个好基础

即使假设客户将承担其责任，解决他们业务数据源中的数据质量问题将来仍然可能在业务数据源Φ产生质量较差的数据。在那些数据对后面的 ETL 过程产生负面影响之前实现数据验证 ETL 筛选器模块来拒绝它们就显得十分重要。数据验证包含许多检查其中包括：

属性的有效值（域检查）。

属性在剩余行的环境中是有效的

属性在该表或其他表中相关行的环境中是有效的。

關系在该表和其他表中的行间是有效的（外键检查）

这并非是一个详尽的列表。它仅仅强调了数据验证的一些基本概念

错误处理是一個确定如何处理不尽人意的（less-than-perfect）数据的过程。可以暂时拒绝这些数据将数据存储起来以便在固定领域中对它们进行修正，或者将其缺点傳递给数据仓库实现所拒绝的数据将存储在客户可以访问的位置；请确保每次发生数据的拒绝时，都会通知您的客户应该允许稍后将巳修理的遭拒绝的业务数据移至数据仓库实现中。

DB2 Data Warehouse Center 中的 Clean Data 转换器可以用于基本的数据验证目的您还可以构建自己的数据验证 SQL 步骤或特殊的數据验证步骤来进行复杂的数据验证。

数据清理是清理有效数据使之更精确更有意义的过程。数据清理包括下列等任务：

数据类型和格式的转换

用于不同目标表的数据分离（Data splitting）。

数据合并的一个常见例子就是姓名和地址信息客户的姓名和地址信息通常存储在多个位置仩。经过一段时间这些信息可能就不同步了。为客户合并数据通常比较困难因为用于匹配不同客户映像的数据不再匹配。数据增强将偅新同步这些数据

您可以使用 DB2 Warehouse Center 中的 Clean Data 转换器来执行源数据上的基本清理、替换和映射操作。Clean Data 转换器操作源表中步骤所访问的特定数据列嘫后，转换器在您的步骤所写入的目标表中插入新的行根据您所选择的处理选项，将无法清理的数据写入目标错误表中在将数据作为過程中一部分进行装入或导入之后，您还可以使用 Clean Data 转换器来清理和标准化数据值

Clean Data 转换器提供了下列可供指定的清理类型：

Find and replace：在规则表的 Find 列中定位所选择的源列值，然后在目标表中用规则表中相应的替换值替换该值规则表是这种清理类型所必需的。规则表指定 Clean Data 转换在查找囷替换过程中将使用的值

Numeric? clip：缩短超出了指定范围的数字输入值。范围内的输入值将不加修改的写入输出范围之外的输入值将由下界替换值或上界替换值进行替换。规则表是这种清理类型所必需的

Discretize into ranges：基于规则表中的范围执行输入值的离散化（discretization）。规则表是这种清理类型所必需的如果允许该清理类型为空（null），则必须在规则表的 Bound 列中放入 null 值

Carry over with null handling：指定输入表中要复制到输出表中的列。您可以从输入表中選择多个列移至输出表中规则表不是这种清理类型所必需的。这种清理类型允许您用指定的值替换空（null）值您还可以拒绝 null，并将所拒絕的行写入错误表中

Convert case：将源列中的字符从大写转换成小写，或从小写转换成大写并将其插入目标列中。默认情况下将源列中的字符轉换成大写。规则表不是这种清理类型所必需的

Encode invalid values：用指定的值替换没有包含在您所使用的规则表的有效值列中的所有值。您要在 Clean Data 转换器嘚 Properties 记事本中指定替换值并且必须指定与源列数据类型相同的替换值。例如如果源列是数字类型的，则必须指定一个数字型的替换值囿效值在写入目标表时不会发生改变。规则表是这种清理类型所必需的

大多数清理类型都有一个 Matching Options 窗口，用于指定希望用来处理匹配的方式

数据集成是将多个数据源联合成一个统一数据接口来进行数据分析的过程。数据集成是仓库数据转换过程中最重要的步骤也是数据倉库实现设计中的关键概念。

数据集成可能极其复杂在该模块中，可以应用数据集成业务规则以及数据转换逻辑和算法集成过程的源數据可以来自两个或更多数据源；它通常包含不同的连接操作。源数据还可能来自单个数据源；该类型的数据集成通常包含域值的合并和轉换集成结果通常生成新的数据实体或属性，易于终端用户进行访问和理解

数据聚集是收集并以总结形式表达信息的过程。数据聚集通常是数据仓库实现需求的一部分它通常是以业务报表的形式出现的。

在多维模型中数据聚集路径是维度表设计中的重要部分。在数據存储库或数据仓库实现中数据聚集的级别是逐个（case-by-case）确定的。因为数据仓库实现几乎仍然都是关系数据模型类型的所以最好是建议您的客户从数据集市构建业务报表。但是某些客户喜欢直接从数据仓库实现构建报表。本例中将考虑在仓库数据模型中进行数据聚集。请确保数据聚集表与其余的仓库数据模式相对分隔因此，报表的业务需求修改将不影响基本的数据仓库实现数据结构

将数据移至中惢数据仓库实现中的目标表通常是 ETL 过程的最后步骤。装入数据的最佳方法取决于所执行操作的类型以及需要装入多少数据您可以通过两種基本方法在数据库表中插入和修改数据：

大多数应用程序使用 SQL IUD 操作，因为它们进行了日志记录并且是可恢复的但是，成批加载操作易於使用并且在装入大量数据时速度极快。使用哪种数据装入方法取决于业务环境；应在 ETL 设计文档中指定装入方法

ETL 数据拒绝的处理

如何處理拒绝的业务数据是 ETL 设计中的重要问题。当业务数据违背下列条件时将遭到拒绝：

ETL 过程中所实现的业务数据集成规则

您应在数据仓库實现开发人员/管理员和终端用户都同意的地方存储遭拒绝的业务数据。被拒绝的业务数据中的问题的解决是数据仓库实现维护中的一部分；它通常是属于客户的职责因为处理这类问题需要域知识和数据库技能，所以数据库管理员和终端用户都应该参与该工作修复的业务數据最终将重新进入 ETL 周期，从而流入数据仓库实现

ETL 过程和步骤的执行次序

执行次序是另一个重要的 ETL 设计问题。尽管从数据仓库实现服务器执行了越来越多的并行处理但是并非所有的 ETL 过程都可以并发执行。有许多影响执行次序的因素：

实体依赖性：参照完整性的实施决定叻表和对象的依赖性例如，父实体表需要在子数据或关系表之前进行装入

属性依赖性：属性依赖性通常意味着属性值是基于一个或多個属性的一个或多个值进行计算的。

ETL 逻辑模块：ETL 模块设计次序通常决定了 ETL 过程中 ETL 步骤的执行次序在数据集成步骤之前，需要验证并清理數据是很易于理解的

数据集成依赖性：数据集成业务规则通常包含对象和数据依赖性。

在仓库过程中执行次序是在设计阶段使用 图 7 所礻的仓库链接工具进行定义的。您可以定义仓库过程中步骤之间的捷径以控制过程的执行次序。

运行仓库 ETL 步骤

您可以随需应变地运行步驟或者按照下列方法来安排将运行的步骤：

重复地，例如每个星期五

依次在一个步骤结束时，下一个步骤才开始运行

在完成时不管昰成功还是失败，都将开始另一个步骤

如果您安排一个过程该过程中的第一个步骤就会在安排的时运行。

您可以组合这些方法来运行一個过程中的步骤您可以安排第一个步骤在指定的日期和时间运行。当该步骤处于生产模式时这些时间表和级联（cascade）就是活动的。在安排好第一个步骤之后您可以指定另一步骤在第一个步骤运行之后开始，并指定第三个步骤在第二个步骤运行之后开始等等。

您可以安排过程和步骤并指定一个过程在另一个过程运行之后开始。您必须小心地将步骤组合成有意义的过程以便可以正确地调度和指定过程嘚任务流。通过 Scheduler 记事本的 Process Task Flow 页面您可以基于一个过程的完成来启动另一个过程。

元数据管理对于 ETL 的有效开发和操作至关重要ETL 元数据包括 ETL 過程设计、ETL 过程执行历史、被拒绝的数据过程记录、调度信息、数据增长和存储管理记录，以及用户数据访问记录中所涉及的所有东西

您可以导出 Data Warehouse Center 中所存储的元数据，并且还可以从另一元数据源导入元数据

您可以使用 Data Warehouse Center 导出功能来导出主题、过程、源、目标和用户定义的程序定义。在导出对象时所有的隶属对象在默认情况下都将导出到标记语言文件或 XML 文件中。您可以导出下列类型的元数据：

标记语言（XML 格式）

默认情况下导出包括所选择的对象和所有选择对象引用的对象。例如如果您选择导出一个过程，那么就包括了步骤所使用的源囷目标、隶属的步骤和隶属的过程

在将元数据导出到标记语言时，您可以通过取消 Export dependent source properties 选项在导出中排除源定义。如果这样做则必须在導入该标记文件之前在目标系统中定义源，以避免错误

您可以限制导出对象的数目，减小标记文件的大小默认情况下，导出操作包含具有数据依赖性的步骤例如，考虑下列场景：过程 P1 包含用于填充 T1 的步骤 S1而过程 P2 包含步骤 S2，而 S2 包含作为源的 T1因此可以建立下列依赖性：S1 –> T1 –> S2 –> T3。如果您仅导出过程 P2那么 P1 也将导出到标记文件中，因为 S2 依赖于 S1 的数据数据依赖性反向也成立。因此即使您仅导出 P2，P1 也会包含在标记文件中分开导出 P1 和 P2 不会有什么帮助，因此最佳方法就是将其一起导出当将元数据导出到标记文件时，您可以启用选项 Do not export dependent steps from unselected process 来排除楿依赖的步骤

除了数据依赖性，您还必须考虑级联（cascading）可以考虑过程 P5 中的一个步骤，它包含到过程 P6 中某一个步骤的捷径如果导出 P5，那么 P6 也会被导出本例中，导出通过捷径级联向下转到下一步骤默认情况下，导出操作包括级联操作和过程无论在导出到标记文件时昰否提供一个机会，使之不包括级联步骤和过程

在导入元数据时，所有对象都分配给标记语言文件中指定的安全分组如果没有指定安铨分组，那么所有对象都将分配给默认的安全分组

您可以导入下列类型的元数据：

如果您将标记语言文件从一个系统移至另一系统，则必须移动与之相关的所有文件（例如：源文件）它们必须位于在同一目录中。

导出和导入元数据的提示：

因为仓库的导入和导出格式取決于版本所以无法使用来自前面版本的导出文件从一个版本的 Data Warehouse Center 迁移到另一个版本的 Data Warehouse Center。

导出和导入过程都使用大量系统资源当您导出对潒定义时，可能需要限制其他程序的使用当您进行大型导出操作时，可能需要将仓库数据库的 DB2 应用程序堆数大小增加到 8192

与仓库数据源、目标和代理相关的服务器名和用户名都要导出到标签文件中，而且在导入到新系统之后需要对这些信息进行更新。不过不用导出密碼，因此您需要提供密码信息以访问仓库数据源、目标和代理。

一旦实现了数据仓库实现项目业务域领域的第一个分组您就应设置仓庫实现原型，以验证：

当开始与用户一起验证设计时实地体验（hands-on）测试是最好的方法。让用户尝试通过对测试目标的操作来回答问题記录测试目标无法提供所需数据的所有领域。必须与终端用户一起执行建议解决方案的功能性验证这通常导致终端用户暂时使用所构造嘚解决方案，让他们有机会使用本地解决方案中（可能是数据集市中）已经可用的信息此外，本地解决方案然后可能集成到更大业务范圍的数据仓库实现架构中包括所生成的数据模型。

除了测试之外要与用户一起检查在设计阶段产生的模型添加和修改，以确保它们是鈳以理解的与模型的验证步骤一样，要将起作用的东西传递到实现阶段将不起作用的返回给需求阶段，以便澄清和重新进入建模

数據仓库实现是系统、网络配置、应用程序、数据库、报表和人员的集合。数据仓库实现的性能受所有这些因素的影响这一节将关注如何從终端用户的角度寻找数据仓库实现的性能问题，该意味着从查询工作负载和响应时间的角度查看问题

数据仓库实现上的工作负载很少保持不变。新的用户带来了他们自己的需求类型现有的用户修改他们的焦点，并且常常改变其研究深度业务周期呈现其自己的峰值和穀值类型，在大多数情况下数据仓库实现随着它存储数据跨越更长时期而进行扩展。

索引的使用在只读的数据仓库实现中将更加自由洇为索引是为了高效的数据检索而定义的。索引应根据数据仓库实现决策支持环境中的访问模式和查询需求来进行优化

随着数据仓库实現上的需求发生改变，一些索引成为无用的而需要创建其他索引，一些聚集不再被引用而其他的则需要进行评估，必须对并行处理上嘚限制进行评估和调整以满足当前需求。这些任务和其他调优任务都将定期执行以确保查询性能满足业务需求。

查询性能的评估和调優最接近于包含了一系列连续改进的进行过程每次改进都是从对于分组查询的较差响应时间的抱怨或观察开始的。

在执行查询调优任务の前您需要知道有问题的查询的期望响应时间。为了刻画工作负载您必须整理查询，将其组成家族然后确定它们在处理时间、I/O 请求、内存需求、网络数据信息量（如果可适用）等方面的资源需求。期望的查询响应时间是基于对查询工作负载特性的评估而估算的

一旦知道了期望的响应时间，并且测量了查询的当前响应时间就可以按照下列方法定期调优数据仓库实现：

分析监控的响应时间，以确定它們是否满足期望的响应时间

当查询无法满足响应时间目标时，考虑进行调优：

设置系统和数据库的性能监控收集数据和分析监控的响應时间信息以寻找瓶颈。

记录产生最大乃至最小影响的性能决定因素的列表以进行相应的调整。

确定哪些查询仍然无法满足响应时间目標数量应该很少。使用 DB2 Query Performance Monitor 为这些查询开发详细的概要文件和动作计划该动作计划很可能将包含性能权衡（trade-off），这些权衡可能导致其他的資源瓶颈

继续调整系统和数据库，直到所有查询都?满足其性能目标。

数据仓库实现包含秘密的和敏感的业务数据在进入稍后的数据倉库实现设计阶段之前，数据仓库实现的安全性常常被忽略随着其中涉及了更多数据源或业务主题领域，数据仓库实现安全的复杂性也茬增加不同的数据源通常具有不同的安全性需求或用户，因此为集成的仓库数据定义数据访问可能十分困难幸好 DB2 数据库系统和 DB2 Data Warehouse Center 提供了極其广泛的数据访问安全性服务，这使得维护数据仓库实现的安全性变得更容易

您需要在数据仓库实现安全性设计中考虑许多因素：

数據访问：数据仓库实现是为了决策支持的传递而创建的；终端用户只是从中挖掘信息。对于数据仓库实现中数据的访问是只读性的

终端鼡户：知道谁将使用数据仓库实现将指导仓库的设计。如果授权终端用户访问仓库中的所有数据则只需要设置一个系统或数据库组来访問数据仓库实现即可。然而在实际的业务世界中，不是每位终端用户都被允许访问所有的业务数据不同的终端用户被授权访问仓库中鈈同的数据子集。

数据分析方法：有几种从数据集市中生成报表的方法其中包括标准化的业务报表、即席 OLAP 报表和数据挖掘。对于标准化嘚报表在允许终端用户访问一组预先定义的报表时，安全性易于实现对于即席 OLAP 和数据挖掘报表，安全性很可能通过将数据库级别的数據集市或数据集市子集分配给用户组来实现

性能：限制性的安全性计划是按不同的方式以牺牲性能为代价得到的。找到安全性和性能需求之间的平衡十分重要

数据仓库实现设计：数据安全性本身就是数据仓库实现设计中的重要问题。该解决方案中两层的数据仓库实现设計假设终端用户将仅仅访问数据集市中更加用户友好的数据而非数据仓库实现中复杂的数据结构。这极大地简化了数据仓库实现终端用戶的安全性因为数据集市通常是为特定的部门或与用户组定义的。

数据仓库实现工具：DB2 Data Warehouse Center 安全性结构是与数据库和操作系统的安全性相分離的该结构包含仓库组和仓库用户。通过属于某一仓库组用户可以获得对 Data Warehouse Center 对象的权限和访问。仓库组是仓库用户和权限的命名分组咜授权用户执行功能。仓库用户和仓库组不需要与为仓库控制数据库所定义的数据库用户和数据库组相匹配

下图展示了 DB2 仓库用户、仓库組以及仓库数据库的用户 ID 和密码之间的关系。

数据仓库实现解决方案的可交付性

下面是重要的数据仓库实现可交付性列表：

该文章系列向您介绍了商业智能并提供了交付灵活的低成本数据仓库实现解决方案的基本方法。该方法使用 IBM DB2 Data Warehouse Edition Version 8.2.1它以用户可承担的价格提供了端对端的商业智能软件，特别是对于中型市场的客户

商业智能特定领域中所提供的信息让您洞悉在为客户开发数据仓库实现解决方案时将碰到的任务、决策和问题。从与客户的第一次见面到将商业智能解决方案部署到生产中本文包含了许多有用的想法和提示，其中包括 ETL 过程、数據仓库实现的设计与实现以及数据仓库实现的安全性和性能。

IBM 是世界一流的商业智能解决方案提供商而商业智能也是 IBM 的关键计划。商業智能解决方案的范围很广可以从部门级的数据集市，即用于诸如销售或金融分析的特定功能到增加到亿万字节（terabyte）的大规模企业数據仓库实现。本文剖析了咨询师或解决方案提供者为交付 IBM 商业智能策略中的部分解决方案要付出什么代价