灵活有效的数据仓库解决方案: 第 2 部分：仓库设计和数据建模

2005 年 7 月 14 日 该系列文章包含 3 个部分，主要介绍灵活且有效的方法来计划、设计并实现基本的数据仓库解决方案。作为该系列的第 2 部分，本文将关注仓库数据的建模。 简介 业务环境是在快速变化的，而业务数据的类型也是如此。一个成功的数据仓库解决方案的基础就是灵活的设计，这种设计可以适应不断变化的业务数据。数据 仓库的架构和仓库数据的建模是仓库设计中的核心过程。 回页首 数据仓库的架构 当使用数据模型捕获业务需求时，您就已经完成了数据仓库设计中的部分工作。然而，正式的数据仓库设计应该从数据仓库的架构开始。 仓库架构是基于一些因素所做的关键决策，这些因素包括当前基础设施、业务环境、期望的管理和控制结构、实现工作的承诺和范围、企业所采用的技术环境 的功能以及可用的资源等。 回页首 架构选择 仓库架构将决定数据仓库和数据集市本身的位置，以及控制所驻留的位置，或者反之。例如，数据可以驻留在集中进行管理的中心位置中。或者，数据可以驻 留在集中或独立管理的分布式的本地和/或远程位置中。 有以下一些架构选择： 业务范围（Business-wide）的数据仓库 独立的数据集市 互连的数据集市 这些架构选择也可以组合使用。例如，数据仓库架构可以在物理上分布或集中管理。 回页首 业务范围的数据仓库架构 业务范围的数据仓库就是将支持整个或一大部分业务的数据仓库，该业务需要更加完全集成的数据仓库，跨部门和业务线（line of business）具有较高的数据访问和使用率。即基于整个业务需求设计和构造仓库。可以将之视作可跨整个企业使用的决策支持数据的公共存储库，或其中的 一个大型子集。这里所使用的术语“业务范围（business-wide）”反映的是数据访问和使用的范围，而非物理结构。在整个企业中，业务范围的数据 仓库在物理上可以是集中式的，也可以是分布式的。 回页首 独立的数据集市架构 独立的数据集市架构暗指单独的数据集市，这些数据集市是由特定的工作组、部门或业务线进行控制的，完全是为满足其需求而构建的。实际上，它们甚至与 其他工作组、部门或业务线中的数据集市没有任何连通性。 图 1. 数据仓库架构选择 回页首 互连的数据集市架构 互连的数据集市架构基本上是分布式的实现。虽然不同的数据集市是在特定的工作组、部门或生产线中实现的，但它们可以是集成、互连的，以提供更加全局 的业务范围的数据视图。实际上，在最高的集成层次上，它们可以成为业务范围的数据仓库。这意味着一个部门中的终端用户可以访问和使用另一部门中数据集市中 的数据。 回页首 您应选择哪种架构？ 如果您客户的业务和数据源是相对集中的，那业务范围的集中式数据仓库架构就是最明智的选择。这实际上对于中间市场的公司而言是很普遍的情况。否则， 对于在地理上广泛分布的业务而言，互连的数据集市和业务范围的分布式数据仓库就是更加实用的选择。 独立的数据集市架构不是一种好方法，因为它违背了数据仓库的关键概念：数据集成。 回页首 数据仓库的实现方法 实现方法的选择受这些因素的影响：当前的 IT 基础设施、可用的资源、所选择的架构、实现的范围、对于跨企业进行的更大业务范围的数据访问的需求、投资回报率（return-on- investment）需求以及实现的速度。实现方法的选择是数据仓库设计中的重要部分；该决策需要在数据仓库项目的早期阶段做出。 回页首 自顶向下的实现 自顶向下的方法就是在单个项目阶段中实现数据仓库。自顶向下的实现需要在项目开始时完成更多计划和设计工作。这就需要涉及参与数据仓库实现的每个工 作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的有关决策一般需要在真正的实现开始之前就完成。 回页首 自底向上的实现 自底向上的实现包含数据仓库的计划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意味着不会开发更大业务范围的数据仓库设计；随着初始 数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范 围实现的证明。 回页首 您应该选择哪种实现？ 每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程 度，因为数据仓库是用自底向上的方法进行构建。 在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成 设计良好的业务数据仓库。这样的方法可以极好地适用于业务。每个数据集市都可以处理可识别的业务问题或主题领域，从而可以计算 ROI。构建团队可以测试并调整产品，而该方法也为构建团队提供了宝贵的学习曲线。 对于中间市场的公司，有一些额外的理由要采用自底向上的方法： 在中间市场的业务及其业务数据结构中，存在比企业业务数据中更多的易变性。 较小的公司通常存在有限的项目预算。 中间市场的公司需要快速解决方案以减轻其业务难度。 该类项目所需要的人员必须具有对业务的广泛理解以及特定业务领域的详细知识。找到这样的人是很困难的，但即使可以，使用他们的时间来进行数据 建模也比让他们尽普通业务职责更加困难。 回页首 数据仓库基础设施 既然已经具有关于高级数据仓库架构的一些决策，您就可以开始考虑数据仓库应该具有什么组件了。 图 2. 商业智能基础设施组件的高级视图 数据仓库应具有上图中所描述的商业智能基础设施中的所有组件。本文将关注数据仓库的构造，其中涉及到了除信息分析之外的所有这些组件。 这些商业智能组件可以定义为： 数据源：当前可用的业务数据源和外部数据源以及将来可能存在的数据源的清晰定义。 数据获取：用于获得、清洗、转换和集成数据的 ETL（提取、转换和装入）过程。 业务数据仓库：仓库数据存储库的数据库。 数据传播：用于为数据集市聚集和增强数据的 ETL 过程。 数据集市：更加用户友好的数据结构中的数据仓库的子集。 信息分析（本解决方案中未涉及）。 元数据管理：业务需求、数据模型、ETL 过程设计、用户手册，等等。 系统管理：数据管理、数据仓库安全性、系统和数据库的备份和恢复，等等。 回页首 数据仓库的建模 数据只是所有业务活动、资源以及企业结果的记录。数据模型是对那些数据的组织良好的抽象，因此数据模型成为理解和管理企业业务的最佳方法是极其自然 的。数据模型起到了指导或计划数据仓库的实现的作用。在真正的实现开始之前，联合每个业务领域的数据模型可以帮助确保其结果是有效的数据仓库，并且可以帮 助减少实现的成本。 目标仓库数据的建模是将需求转换成图画以及支持表示那些需求的元数据的过程。出于易读性目的，本文将关于需求和建模的讨论相分离，但实际上这些步骤 通常是重叠的。一旦在文档中记录一些初始需求，初始模型就开始成型。随着需求变得更加完整，模型也会如此。 最重要的是向终端用户提供良好集成并易于解释的数据仓库的逻辑模型。这些逻辑模型是数据仓库元数据的核心之一。为终端用户提供的简单性以及历史数据 的集成和联合是建模方法应该帮助提供的关键原则。 回页首 仓库数据的建模与操作数据库的建模 在建模的过程中，请记住下列问题： 数据仓库应该是面向终端用户的。在数据库操作中，用户不直接与数据库进行交互。他们使用应用程序，这些应用程序具有预先定义的或固定的查 询。数据仓库的数据库——特别是数据集市——与终端用户非常接近，它通常不具有固定的查询。因此，它必须更易于理解。 数据仓库应该是为数据分析而设计的。终端用户几乎直接处理数据，而且没有固定的工作流（除了这里和那里的少数例外）。终端用户对在仓库中记 录数据不感兴趣，但他们需要从中获得信息。他们向仓库提出问题，通过所提取的信息测试并验证假设，重新构造事件链，分析那些事件以检测可能的模式或季节性 的趋势，以及为将来做出推断和设计。 终端用户的需求可能是模糊或不完整的。这些不完整的需求需要灵活的建模过程和适合于进化开发的技术。灵活的进化软件开发的风险是不连贯和不 一致的终端结果。在开发数据模型时，肯定需要注意这些问题。 数据仓库是集成的数据库集合，而非单个数据库。应将它构想为单个信息源，用于整个企业中所有的决策支持处理和所有的信息应用程序。数据仓库 是一个“有机”物，如果在开始时还不够大，就还会趋于变大。 数据仓库包含属于不同信息主题领域的数据。这些主题领域可以是将数据仓库逻辑划分成几个不同（概念的，甚至或者是物理的）数据库的基础。数 据仓库还可以包含不同类别的数据。 数据仓库通常包含历史数据，而不是日常操作数据的快照（snapshot）。必要的遗留数据库可能不可用，或者可能无法在足够细的层次上捕 获，除非花费金钱并付出努力来改变遗留输入环境。因此，数据仓库启用项目通常涉及业务过程和源应用程序的重组（reengineering）。 回页首 两层数据仓库设计 如何进行数据仓库的建模可能是商业智能领域中最有争议的问题之一，而本文不会进行这方面的讨论。本小节将介绍两层的仓库建模方法，该方法最适合于自 底向上的实现。 图 3. 两层仓库建模 数据存储库层，或后端层包含了所有的人工模型组件和完整的模型结构，它们处理所有必要数据源中的集成业务数据。数据存储库层具有两个数据模块：数据 登台（staging）和数据存储库。数据分级模块存储所有数据源的初始数据和临时数据，以用于 ETL 处理。数据存储库存储所有的集成业务数据，它是数据获取 ETL 过程的最终目标。 数据集市层包含所有的数据集市，这些数据集市是数据存储库模块的子集，以便特定的终端用户组在其数据分析活动中使用起来足够简单。 因为数据仓库和数据集市在许多情形中是可以交换的概念，所以有必要基于两层的仓库模型指定它们的定义。在该模型中，业务数据仓库是数据存储库数据库 （模块）的集合，而数据集市则是数据集市层中的数据库。数据集市中的业务数据只能来自业务数据仓库。 两层数据仓库设计的好处包括： 灵活且易于维护。可以随时根据用户的报表需求修改数据集市的数据结构。但是，它不影响数据存储库中数据库的数据结构。 易于伸缩和集成。关系类型的业务数据存储库数据库比数据集市中非正规（denormalized）和汇总性（summarized）的数据 库更易于伸缩和集成。 用户友好。将数据集市和数据存储库分离使得数据集市的设计更加是终端用户所驱动的，因为数据建模师不需要过多考虑数据集成和模式可伸缩性问 题。 更好的安全设计。两层的方法将数据存储和数据访问管理相分离。终端用户只能访问授权给他们的数据集市，而非所有的数据仓库数据。 更好的数据管理设计。数据仓库是为存储集成的业务范围的历史数据而设计的。但是，数据仓库中的许多数据集市都不一定需要那么多的历史数据。 两层设计是存储历史数据的好地方。 请记住，上面两层的仓库设计是概念仓库布局。例如，在数据存储库层，登台数据库和存储库数据库可以在不同的服务器上、在同一服务器上或者甚至在不同 模式下的同一数据库中。 回页首 仓库数据建模层 数据建模有三层：概念、逻辑和物理。在数据仓库的设计中，数据建模的每一层都有自己的目的。 概念 高级数据模型是所有业务主题领域以及业务的公共数据元素的一致性定义，从高级的业务视图到通用的逻辑数据设计。您可以从中派生出通用的范围，并获得 对业务需求的理解。这个概念数据模型是当前和将来数据仓库开发阶段的基础。 逻辑 逻辑数据模型包含关于业务主题领域的更多详细信息。它捕获目标业务主题领域中的详细业务需求。逻辑数据模型是当前项目的物理数据建模的基础。 从这一阶段开始，该解决方案就适用自底向上的方法了，这意味着这个逻辑数据模型中仅仅将最重要和紧迫的业务主题领域锁定为目标。 逻辑数据模型的功能包括： 对于所有实体及其之间的关系的规范。 对于每个实体的属性的规范。 对于所有主键和外键的规范。 规范化（Normalization）和聚集。 对于多维数据结构的规范。 物理 物理数据建模应用物理约束，如空间、性能以及数据的物理分布。物理数据模型是与数据库系统以及您将使用的数据仓库工具紧密相关的。该阶段的目的是设 计真正的物理实现。 将逻辑建模与物理建模清晰分离是特别重要的。良好的逻辑建模实践关注问题域的本质。逻辑建模解决“什么”之类的问题。物理建模为模型解决“如何”之 类的问题，这表示给定的计算环境中实现的真实性。因为业务计算环境随时间变化，所以逻辑和物理数据建模的分离将帮助稳定一个阶段到另一阶段的逻辑模型。 一旦实现了数据仓库，且客户开始使用它，他们就常常会生成新的请求和需求。这将启动另一开发周期，继续数据仓库构建的迭代和进化过程。正如您可以看 到的，逻辑数据模型是数据仓库的活动部分，在数据仓库的整个生命周期中使用和维护。数据仓库的建模过程确实是无止境的。 图 4. 数据仓库逻辑数据模型的生命周期 回页首 存储库数据库建模 仓库数据存储库数据库存储来自所有业务数据源的所有清洁的（cleaned）集成业务数据，它是数据仓库中数据集成和转换的终点。虽然概念数据模型 是根据业务需求设计的，但是数据存储库逻辑数据模型是基于业务需求和可用业务数据源的分析而设计的。它是用于验证现有业务数据是否支持数据仓库项目中业务 需求的自然检查点。 存储库数据库基本上仍然是正规的（normalized）关系数据库。因为它们是源驱动的，所以源数据模型可以用于协助仓库数据存储库模型的完全开 发过程。您可能需要通过使用逆向工程（reverse engineering）技术构造源数据模型，从而从现有的源数据库中开发实体和关系（Entity and Relation，ER）模型。您可能需要首先将几个这样的模型集成到一个全局模型中，以逻辑集成的方式表示源。 在数据转换过程中，清洗并清理了数据仓库中的数据。它至少应该与源操作系统中的数据一样好。在 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 维度）中的基本聚集路径通常意味着调查维度中的许多典型关系。 构造或结构化关系：信息分析员使用这些关系来探索产品及其组件之间的构造性关系。例如，通过与产品组件相关的成本和产品构造相关的成本，它 们可以用于计算产品成本。 变化（Variation）关系：变化用于就产品模型、版本、实现、组件混合、调配等而言区分产品。 变化还可用于指定产品替换。信息分析员使用变化关系来组合相关产品和聚集相关测度，因为较低级类别的产品可能只存在于一段有限的时期内，或者因 为它们频繁用于在某一过程中相互替换（例如，当“初始”产品缺货，而将某一版本的产品卖给客户时）。 分类关系：分类是将相似的产品分成组。关系分类显然是产品之间出现最频繁的关系，信息分析员用于上卷详细的测度。请注意，通常需要多个不同 类型的分类。例如，可以根据面向销售、面向制造、面向储备或面向供应的特点来对产品进行分类。信息分析员将分类用于统计组中的聚集测度，统计组有总数、平 均数、最小值和最大值等。 事实 事实表只包含用于引用维度表的 ID，以及用于测量所有维度成员变化或性能的测度。下一步就是将维度和测度组织成事实。这是以可以解决指定需求的方式将维度和测度进行分组的过程。 事实表的设计中要解决几个重要问题： 粒度（记录事实的细节级）：如果要有效地分析数据，就必须都在同一粒度级别上。一般说来，您应该将数据放在最详细的粒度级别上。这是因为您 无法将数据修改到您所决定设置的细节级上。但是，您总是可以上卷（汇总）数据以创建一个略粗的粒度级别的表。 相加性（要总结的测度的能力）：测度分成三个类别：全相加的（fully additive）、非相加的（nonadditive）和半相加的（semiadditive）。一个非相加测度的例子就是百分率。您无法简单地将两个 事实的百分率相加到一起，并产生有意义的结果。一个半相加测度的例子就是余额。虽然您可以将两个帐户的余额相加获得总的余额，但无法将同一帐户在两个不同 时间点的两个余额相加。因为余额只是跨一些维度进行相加的，所以我们称之为半相加测度。将可以跨所有维度相加的值视作全相加的。当您考虑将在事实表上发生 的可能汇总时，相加性就变得很重要。通常，全相加的测度是最理想的。当测度不是全相加的时，应考虑将它们分成其原子元素。 键选择：多维数据建模中的键选择是一个难题。它包含性能和易于管理之间的权衡（trade-off）。键选择主要适用于维度。您为维度所选 择的键必须是事实的外键。维度键有两种选择：您可以分配一个任意键，或者使用操作系统中的标识符。任意键通常只是一个序列号，当需要一个新键时，就分配下 一个可用的号码。 为了使用操作系统中的标识符惟一地表示维度，您有时需要使用一个复合键。复合键就是由多个列组成的键。任意键是一列，通常比操作派生的键要小。 因此，任意键通常可以更快地执行连接。 键选择中的最后一个因素就是它对事实表的影响。在创建事实时，必须将每个维度的键分配给它。如果维度将带有时间戳的操作派生的键用于历史数据， 那么在创建事实时，就没有附加工作。连接将自动发生。对于任意键或任意历史标识符，在创建事实时，就必须将一个键分配给事实。 分配键的方式有两种。一种就是维护操作和数据仓库的键的转换表。另一种就是存储操作键，并且在必要时，存储时间戳作为维度上的属性数据。 那么，选择就在任意键的更好性能和操作键的更易维护之间进行。性能提高多少和维护增加多少的问题就必须在您自己的组织中进行评估了。 无论做出什么选择，都必须在元数据中用文档记录生成它们的过程。该信息对于管理和维护数据仓库的技术人员来说是必要的。如果您所使用的工具没有 隐藏连接处理，那么用户可能也需要理解这一点。 既然您理解了维度和事实表的处理，就让我们看一看真实世界的例子，以探索如何从业务需求中识别维度和测度。该例子只是对于一系列业务问题的基本分 析。这些业务问题被定义为示例需求： 按照银行支行，本月客户的平均余额和交易数是多少？ 按照支行、产品和地区汇总，要付给每位客户的年净利润和利息是多少？ 百分之几的客户是盈利的？将他们按照支行、地区和年分类。 本年一位客户的总交易量是多少？ 按照地区，最盈利的前 5 位产品是什么？ 在最近 5 年里，最盈利的前 5 个支行是什么？ 最盈利的客户的人口和地理特点是什么？ 通过分析这些问题，我们就定义了需要满足需求的维度和测度（见表 1）。 表 1. 维度和测度表 维度和测度 Q1 Q2 Q3 Q4 Q5 Q6 Q7 维度 支行 X X X X X 地区 X X X X 客户 X X X X X 产品 X X X 时间 X X X X X 测度 余额 X 交易量 X 交易数 X 净利润 X X X X X 所付利 息 X 此时，您要检查维度以确保： 您具有需要用于回答问题的数据。 在最细的级别定义了所有的测度。 使用这些简化的分析问题来决定最终的星型模型中包含什么以及排除什么： 余额和交易数基于交易量的聚集，所以它们是派生的测度。 所付利息的计算是将帐户利率乘以余额。这是基于帐户和基于月份的计算。因为利率是 Account 表的一个属性，所以需要添加 Account 维度表。正如您可以看到的，所付利息也是派生的测度。 假定净利润基于（投资收益）- （所付利息）的计算。因为投资收益是银行级的测度，而所付利息是派生的测度，所以净利润也是派 生的测度。 从以上分析得出的结论有： 交易量是惟一需要的测度。 需要帐户维度来产生利率和投资收益信息。 回页首 模型元数据 在传统的开发周期中，完成一个模型之后，只有需要进行修改或其他项目需要数据时，才使用它。但是在该仓库中，要连续使用模型。仓库的用户不断访问该 模型以决定他们需要用于分析组织的数据。仓库中数据结构的修改速度比操作性数据结构要快得多。因此，仓库的技术用户（管理员、建模师、设计师等等）也将定 期使用您的模型。 这就是元数据所承担的任务。远远不只是一副漂亮的图画，该模型必须是所存储数据的完整表示，否则，它对于任何人都毫无用处。 为了正确理解模型，以及可以确认它满足了需求，用户必须访问按照容易理解的业务术语描述仓库的元数据。因此，您应在此时记录非技术的元数据。在设计 阶段，您将向它添加技术元数据。 在仓库级上，您应提供仓库中可用东西的列表。该列表包含可用的模型、维度、事实和测度，因为当用户开始分析数据时，这些都将用作初始的进入点。 对于每个模型，提供名称、定义和目的。名称仅仅给用户提供一些搜索时关注的东西。它通常与事实相同。定义指定建模的内容，而目的描述模型用于什么。 模型的元数据也应包含与之相关的维度、事实和测度列表，以及联系人员的姓名，以便用户在有关于模型的问题时，能够获得附加的信息。 模型验证 在投入大量时间和精力实现仓库数据库之前，与用户一起验证模型是一个很好的想法，特别是数据集市模型。进行该检查的目的是双重的。首先，它确认模型 可以真正满足用户的需求。第二，检查应确认用户可以理解该模型。请记住，一旦实现了仓库，用户就会定期依靠模型访问仓库中的数据。无论模型多么好地满足了 用户的需求，如果用户无法理解模型以访问数据，您的仓库都是失败的。 此时，验证是在高级别上完成的。与用户一起检查该模型以确认它是可以理解的。与用户一起，通过解决您将如何回答需求中指定的部分问题来测试模型。 模型不必满足用户的所有需求，这一点是好的。这不意味着您应停止并返回到开始。期望您模型的第一次切入满足约 50% 的需求。接受模型的这 50%（或者不管验证了多少），并开始进行物理设计。应将剩余的送回给需求的收集阶段。要么需要更好地理解需求，要么通常需要修改并重新定义它们。这常常 会导致对已创建的模型进行添加和修改。同时，模型的有效部分将通过设计阶段，并开始向用户提供好处。 开发的重复和部分完整模型的继续创建是提供快速开发数据仓库能力的关键元素。 图 7. 仓库数据模型评估过程 在需求的验证过程中，您将： 对照给定的用户需求，检查初始维度模型的连贯性和完整性以及有效性。与终端用户一起分析初始模型。这将允许需求分析员执行更多调查，并在将其传递给 需求建模阶段之前调整这些初始模型（尝试按照模型中所表达的修改需求）。 指定候选的数据源。建立必要和可用数据源的库存。 将初始维度模型、可能配有的信息化终端用户需求映射到指定的数据源。这通常是一项冗长乏味的工作。源数据映射必须调查下列映射问题： 哪些源数据项可用，哪些不可用？对于不可用的那些，是否应扩展源应用程序？是否可以使用外部数据源找到它们？或者是否应向终端用户通知它们的不可用 性，并且因此，是否应减小维度模型的范围？ 数据源中是否有其他可用但没有请求的有趣数据项呢？指定可用但没有请求的数据项可能暴露信息分析活动的其他有趣方面，并且可能因此极大地影响所构造 的维度模型的内容和结构。 验证数据集市设计没有违背任何业务安全性设置。因为数据集市是为特定的终端用户组设计的，所以确认它只包含该组必要的信息是很好的想法。 执行模型的初始大小调整。如果完全可能，初始的大小调整还应调查与填充数据仓库相关的容量和性能方面的情况。 需求验证的结果将帮助您评估数据仓库开发项目的范围和复杂性，并（重新）评估业务的调整，包括技术、金融和资源的评估。需求验证必须与终端用户协同 执行，以暴露和改正不完整或不正确初始模型的所有问题。需求验证可能涉及构建维度模型的原型。 需求验证过程将确认或重新建立终端用户需求和期望。作为需求验证的结果，您还可能指定和评估源数据重组（reengineering）建议。在需求 验证的最后，您将获得用于数据仓库建模项目的（新的）“签字”。 回页首 后续 继续本系列中的下一篇文章，其中将继续探索仓库 ETL 过程的设计和实现、仓库性能、安全性等。 参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文。 关于商业智能和其他解决方案领域的更多详细信息，请参阅 IBM 软件易捷解决方案快速起点计划。 关于更新产品的特定信息，请在 IBM DB2 Business Intelligence 网站查找详细信息。 关于商业智能的更多技术参考资料，请参阅 developerWorks 中国网站上的 DB2 Business Intelligence 专区。 关于 DB2 数据挖掘、编程、系统管理、内容管理等的技术和业务级特性，请阅读 DB2 Magazine。 International DB2 Users Group 提供了许多有帮助的参考资料。 关于大量技术主题的深入介绍，请在线浏览 IBM 红皮书。 作者简介 Leon Gong 是在 IBM Solution Builder Express Portfolio 工作的一位软件工程师。在过去的四年中，他已经为 IBM Mid-Market Business Partners 开发了许多集成解决方案。他主要集中在商业智能（Business Intelligence）和电子贸易（e-commerce）领域。他拥有 DB2 应用程序开发和管理的认证。您可以通过 [e-mail] 与他联系。 Mike Olivas 是在 IBM Solution Builder Express Portfolio 团队工作的一位架构师。最近，他的工作是帮助业务合作伙伴创建不同行业和解决方案领域中的解决方案，包括但不仅限于商业智能（Business Intelligence）、基础设施和工作场所（workplace）服务。您可以通过 [e-mail] 与他联系。 Christine Posluszny 是 IBM Solution Builder Express Portfolio 的一位解决方案开发人员。她具有 6 年开发利用 DB2 的 Java 和 SQL 应用程序的经验。最近，她为 IBM Mid-Market Business Partners 开发集成解决方案。她是一位 Sun 认证的 Java 程序员。您可以通过 [e-mail] 与她联系。 Donna Venditti 是 Solution Builder Express 的项目经理。在过去的 6 年中，她为 IBM Mid-Market Business Partners 交付了行业以及跨行业的起始解决方案。她主要集中在零售业的电子贸易（e-commerce）以及商业智能（Business Intelligence）解决方案领域。您可以通过 [e-mail] 与她联系。 George McMillan 是在 IBM Solutions Builder Express 团队中工作的架构师。最近，他与业务合作伙伴以及 SBE 架构师们一起工作，开发咨询工具（tooling），并作为方法专家为合作伙伴渠道开发方法策略。他的工作包括为不同行业和解决方案领域的业务合作伙伴创 建解决方案。他在协作和内容管理领域担任技术指导，并参与团队开发商业智能（Business Intelligence）和基础设施解决方案。您可以通过 [e-mail] 与他联系。