一. 生命周期初始活动
1.1 程序／项目规划与管理
毫无疑问，DW/BI 始于一系列的程序和项目规划活动 。
1.1.1 评估准备
在开始 DW/Bl工作前 ，有必要花点时间评估组织的准备工作 。基于与上百家客户约谈所积累的经验 ，我们认为有三种因素可用于区分项目能够顺利开展还是需要付出艰辛的努力。这些因素将成为决定 DW/BI 是否成功的先行指标 。我们将按照重要性讨论这些特征 。
最关键的准备因素是有一个强有力的执行业务主管 。业务主管应该对 DW/BI 系统对组织的潜在影响具有清晰的认识 。最佳情况是，业务主管具有成功完成其他内部活动的经历 。 他们应该是能够说服其他领导支持该项目的政策上精明的领导 。如果首席信息官（CIO）是指定赞助商 ，则项目将会冒更大的风险 。我们更喜欢现实的承诺而不是业务同事 。
准备期间第 2 个主要的因素是有一个强大的 、解决 DW/BI 活动的引人注目的动机 。这一因素往往与发起工作齐头并进。DW/BI 项目需要解决关键的业务问题 ，这一工作需要为获得成功的开始和健康的生命期而获取资源 。引人注目的动机通常会建立一种紧迫感 ，无 论这一动机是来自于外部资源 ，例如 ，竞争因素 ，还是内部资源 ，例如 ，完成收购后无法 对跨组织的指标进行分析等 。
第 3 个因素是评估准备的可行性 。可行性包含几个方面的内容 ，尽管也涉及技术和资 源的可行性 ，但数据可行性最为重要 。从实际的操作型源系统中收集的数据能够支持业务 需求吗 ？数据可行性是最重要的关注点 ，因为如果无法以正确的粒度收集需要的源数据 ， 项目将无法在短期内完成 。
1.1.2 范围及论证
在熟悉了组织的准备工作后 ，需要确定项目的边界范围 。确定范围需要 IT 组织和业务 管理的联合输入 。DW/BI 项目的范围对业务组织来说要有意义 ，对 IT 组织来说要可 管理。 应该先考虑关注单一业务过程的数据 ，这样可以减少很 多困难，然后处理多过程项目 。记 住在确定范围时要避免 “ 太” 规则一一项目时间表 “ 太” 短暂，涉及 “太” 多的系统 ，包 含 “ 太” 多的位于 “ 太” 多不同位置的具有 “ 太” 多不同分析需求的用户 。
项目论证需要评估与 DW/BI 初启工作有关的利 益和成本。理想的结果是 ，预期收益远 远大于成本 。信息技术通常是成本的主要来源 。DW/BI 系统趋向于快速扩展 ，因此评估一 定要考虑短期增长的空间 。与操作型系统开发不同 ，操作型系统在投产后对资源的需求会 变得越来越小 ，而对 DW/BI 支持的需求不会随着时间的推移而显著下降 。
业务团体主要负责确定预期财务收益 。DW/BI 环境的验证通常基于增加收益或利润的可 能性而不是仅仅关注降低费用 。仅仅提供 “唯一的真实版本” 或 “对信息的灵活存取” 显然 还不能构成充分的财务论证 。需要层层深入地确定这些 方面对获得高质量的决策制定的影 响。如果您正在开展论证工作 ，就会发现项目初启 关注的可能是错误的业务发起或问题 。
1.1.3 人员配备
DW/BI 项目需要集成不同的功能小组以及来自业务和 IT 领域的不同资源 。同一个人 在小组中往往需要扮演不同的角色 。将命名的资源分配给角色需要考虑项目的大小及范围 ， 以及每个人的可用性 、能力和经验 。
从业务层面考虑 ，我们需要扮演下列角色的人员 ：
业务发起人 ：发起人是 DW/BI 系统的最终客户 ，同时他们也是系统最强大的支持 者。发起人有时采用执行董事委员会的方式存在，特别是当发起人涉及多个企业时。
业务驱动者 ：在大型企业中 ，项目发起人可能地位较高或不能直接与项目组打交 道。在此情况下 ，发起人有时会将 DW/BI 系统中那些不具备战略性的责任指派给 组织中的中层管理人员 。此时，业务驱动者与业务发起人具有同样的特征 。
业务领导者 ：商业项目领 导者应该是一位受大家尊敬的人 ，他应该将主要精力投 入到项目中 ，每天都与项目经理交流 。有时可 以由业务驱动者扮演这一角色。
业务用户 ：理想的情况是 ，商业用户是 DW/BI 的狂热粉丝 。他们需要尽早且经常 性地参与确定项目范围和业务需求 。从此，您必须找到创造性的方法在项目推进 过程中不断地维持他们对系统的兴趣和参与热情 。记住 ，业务用户的参与是DW/BI 能够被接受的关键因素 。没有商业用户的参与和支持 ，DW/BI 系统就变成徒劳的 技术训练 。
几个位置的人员配置来自业务或 IT 组织。这些人员可以作为了解业务的技术资源或了 解技术的业务资源 。业务分析师 ：业分析师主要负责确定业务需要并将需求转 化为结构 、数据和商业 应用需求 。
数据管理师 ：作为主题专家 ，数据管理师通常是当前处理特设分析的 “ 关键” 人 力资源 。他们理解数据的含义 ，如何使用这些数据 ，何处可能存在数据不一致情 况 。考虑实现围绕核心多维数据在组织中的共同理解问题 ，这是一个具有挑战性 的角色，正如我们在第 4 章 “库存” 中所描述的那样。
Bl 应用设计人员／开发人 员：BI 应用资源负责设计并开发分析模板的最初集合 ，并 提供持续的 BI应用支持 。
以下角色通常来自 IT 组织：
项目经理 ：项目经理是 一个关键的角色 ，应该由高管们和技术团队满意的并受尊 敬的人来担任 。项目经理必须具备交际和项目管理技能 。
技术架构师 ：架构师负责总体技术架构 。需要制定计划将需要的技术功能粘合到 一起并能够从总体技术架构的角度评估各种制品。
数据架构师／建模者 ：这一角色通常由强调规范 化的具有事务型数据背景 的人来担 任 。他们支持维度建模概念并了解业务需求 ，而不是仅仅关注节省空间或减少 ETL 工作负载。
数据库管理员 ：类似数据建模者 ，数据库管理员应该放下一些传统的数据库管理 的看法 ，例如 ，在一个关系表中只应该建立 一个索引等。
元数据协调人 ：该角色帮助建立元数据库策略并确保能够收集 、管理 、发布适当 的元数据。
ETL 架构师／设计人 员：该角色负责设计 ETL 环境和过程。
ETL 开发人员：在 ETL 架构师／设计人 员的指导下，开发人员建立并自动 化过程， 可能会要求使用 ETL 工具。
找们再次指出上述列表罗列的是角色 ，而不是具体的人。特别是在一些小型企业中 ， 具有多种技能的个人可以同时担任多个角色 。
1.1.4 规划的开发及维护
DW/BI 规划要区分所有必要的生命周期任务 。详细的任务列表可参考 Kimball 工作组 的网站 www.kimballgroup.com 。单击书名为 The Data Warehouse Lifecycle Toolkit, Second Edition 下面的 Tools & Utilities 标签进入 。
任何了解小组成员的优秀项目经理应该制定不同任务需要的开发工作 量估计 ，项目经 理无法保证允许与期望的时间总能保持 一致。在每个主要 的里程碑和发布物产生后 ，项目 规划应该确定由业务代表参加的验收检查点 ，以保证项目按计划推进。
DW/BI 项目需要广泛的交流 。尽管项目经理通常擅长小组内交流 ，但仍然需要建立交 流策略以便为其他参与者描述频度 、讨论会和重要消息 。其他参与者主要包括业务发起人 、 业务团体和其他 IT 同行。
最后 ，因为非常需要满足商业用户的需求 ，因此 DW/BI 项目的范围极易发生变化 。在 面对变化时 ，应该具有多种选择：增加范围（通过增加时间 、资源或预算），执行零和（zero-sum ) 游戏（以放弃某些要求为交换条件而保持原有范围不变） ，或说 “ 不” （并非直接否定，而是 通过将变化当成增强的需求来处理） 。关于范围的决策 ，最重要的事情是不应该只考虑 IT 的问题。正确的回答是依赖环境 。现在是利用业务伙伴 关系给出所有参与者都能够接受的 答案的时候了 。
1.2 业务需求定义
要构建一个成功的 DW/BI 系统，最重要的工作是与商业用户紧密合作 ，了解他们的需 求并确保他们的投入是有价值的 。
1.2.1 需求预规划
在开始与业务代表坐下来收集业务需求前 ，为保证会议的效果，我们提出以下建议 。
选择讨论话题
业务用户需求讨论会通常也涉及源系统专家的数据发现 。这种双管齐下的方法能够洞 悉业务需要及数据现实 。然而，不要问业务代表关于他们的关键数据的粒度和维度的问题 。 应该问他们希望做什么 ，为什么要做 ，他们是如何制定决策的 ，他们希望未来能制定什么样的决策 。与对组织的治疗类似 ，他们试图发现问题和机会 。
获取需求主要可以采用两种技术 ：用户访谈或用户联席会 。这两种技术各有优缺点 。 用户访谈鼓励个人参与并且比较容易调度 。联席会可以减少收集需求的时间 ，但对每个参 与者来说 ，需要花费更多的时间 。
基于我们的经验 ，调查表并非是获取需求的合理工具 ，因为它们是平面的 、二维的。 其自选项仅包含那些我 们提前考虑好的答案 ，无法获得更深入的情况 。此外 ，调查表方式 不利于我们努力要获得的业务用户与 DW/BI 发起人之间的联系 。
我们通常采用混合访谈方式获得细节并通过联席会议达成小组共识 。尽管我们会更详 细地讨论这一混合方法 ，多数讨论可应用于联席会议 。需求获取论坛选择依赖小组的技能 、 组织的文化以及业务用户已有的业务 。一种方法并不能适用于所有的环 境。确定及筹备需求小组
无论采用哪种方式 ，都需要确定并筹备相关 的项目组成员 。如果您正在开展用户访谈 工作，需要确定访谈负责人 ，其主要责任是 问一些开放式的问题 。同时，需要访谈抄录员 记录大量 的笔记。尽管使用录音设备可以提供更完整的访谈内容 ，但我们不使用它 ，因为 使用它会改变访谈的动态性 。我们宁愿其他人员参加访谈也不依赖相关技术 。我们通常邀 请一个或两个额外的项目成员 （要根据受访者的数 量来定）作为观察员 ，这样他们能够直接 获取用户的需求 。
在与商业用户交谈前 ，需要确认自己以正确的心态来看待讨论会 。不要认为自己已经 什么都清楚了 ，您一定会通过交谈更进一步地了解业务 。另一方面 ，应该提前做点功课 ， 研究可用的资源 ，例如 ，年报 、网站和组织内部的图表 。
得到正确答案的关键是正确 地提出问题 ，我们推荐起草 一个问卷调查 。不应该将问卷 调查视为 一种剧本 ，它是一种用于组织您思想的工具 ，作为在讨论会期间 ，一旦您的想法 出现空白时可用的后备装置 。在访谈过程中 ，当小组对业务主题事直更加了解的情况下 ， 调查问卷将被 更新。选择、调度和准备业务代表
如果您是初次接触 DW/BI ，或者是开发 一种处理现存数据的孤立状态的衔接策略 ，您 应当与合理代表组织各方面业务的 人员交谈 。合理 的范围对制定企业数据仓库总线矩阵蓝 图至关重要 。您需要理解涵盖核心业务功能的公共数据词汇 ，以便能够建立一个可扩展的 环境 。
在 目标用户团体内部，应当垂直地覆盖组织 。DW/BI 项目小组自然地趋向于构建企业 强大的分析能力。尽管他们的见识是有价值的 ，但不能忽略企业高级和中层管理人员 。否 则就会过度关注 战术，而把握不住小组的战略方向 。
调度业务代表是最艰巨 的需求任务 ，特别是要得到部门行政助理的帮助 。我们愿意单 独约见执行经理 。当约见处于组织机构中较低级别的人员时 ，将类别相同的两 三个人分为 一组同时会谈是 比较合适的。一般单独访谈的时间控制在 1 小时左右 ，小组访谈的时间控 制在 1.5 小时左右 。调度者需要 在会议之间安排 半小时时间用于处理汇报和其他事直 。出 于对新要求 的关注 ，访谈过程涉及的工作将极其繁 重 。因此，在一天中尽量只安排三四次 会议 。
在约见受访者前 ，业务发起人应该与受访者进行沟通 ，强调他们对该工作的承诺和每 个参与者 的重要性 。可以要求受访者将其关键报表和分析的复件带入会场 。这样的沟通方 式传播了一种一致的消息 ，并表达 出对业务用户重要性的肯定 。有些时候 ，业务用户不太 愿意将关键 的报表带米参加会议 。然而 ，我们发现在访谈结束后 ，这些人几乎总是回到其 办公率将这些报表带问。
1.2.2 收集业务需求
现在是开始面对面 收集业务需求的时候了 。过程通常按照结构化问询到最后的文档形 成这一流程 。
初启
在会议室收集需求前 ，首先要指定介绍会议的责任人 。该责任人应当用最初的几分钟 根据拟定的访谈会基调描述访谈要点 。这一介绍应该传达简单明晰的以业务为中心的信息 ， 不要漫无边际地介绍硬件 、软件和其他技术术语 。访谈流程
访谈的目标是让业务用户说清楚他们做什么和为什么要做 。简单温和的开启话题的方 式是询问受访者的工作职责和在组织中所处的位置 。这一话题是每个受访者都容易回 答的 问题。此后 ，通常会询问 一些受访者的关键指标度 量。确定他们是如何跟踪进展并成功地 将这些指标直接放入到维度模型中 ，不需要您直接提问 ，他们就会将其关键业务过程和 事 实告诉您。
如果访谈对象有较高的应用数据经验 ，应该考虑如何更好地通过访谈者理解业务的多 维性。类似 “您如何区分不同的产品（或代理商 、供应商或设施） ？” 或 “ 如何自然地分类 产品 ？” 等问题有助于识别关键维度属性和层次 。
如果受访者更侧重分析工作 ，则询问当前建立的分析类型 。理解这些分析工作的特性 ， 无论它们是自组织的还是标准的 ，将它们作为 BI 工具需求以及 BI应用设计过程的输入 。 理想情况下 ，受访者会带来关键图表和报表的拷贝 。与其将它们放入文件夹中 ，不如立即 了解一下受访者是如何进行分析的 ，可以作为进一步改进的机会 。某些行业专家建议 ，您 不能将可扩展的分析环境设计成 一个仅仅能够满足用 户最主要的 5 个报表的环境 。用户的 问题必然会发生变化 ，因此决不能将设计关注点仅仅放在最 重要的 5 个问题上 。
假如与管理人员会面 ，不要落入这样的战术性细节中 。相反 ，应该询问他们对于更好
地在整个组织中利用信息的构想 。也许项目小组设想构建 一个自组织环境 ，而业务管理层 对发布标准化的分析更感兴趣 。您需要确保 DW/BI 发布物匹配业务需求和期望 。
询问每个受访者有关改进信息访问的 影响问题。您可能 已经接收了初期项目资金 ，但 获取更多潜在的 、可量化的利益 是有益无害的。形成最终文档
在访谈进入最后总结阶段时 ，请每个受访者提出有关项 目成功的关键评判标准 。当然，关 键评判标准应该是可 度量的。“ 易于使用” 和 “快捷” 对每个人来说都有不同的考虑 ，因此， 受访者需要提出清晰的细节 ，例如 ，他们为运行预定义的 BI报表所需要花费的训练次数 。
在这一情况下 ，始终要制定一个宽泛的免 责声明。让受访者理解尽管在会议中讨论了 能力问题 ，但不能保证讨论的能力能够在项目的 第 l阶段就予以实施。感谢受访者才华横、溢的洞察力 ，让他们知道下 一步将会做什么，以及需要他们参与哪些工作 。
指导以数据为中心的访谈
在关注理解业务 需求的过程中 ，让源数据专家或主题业务专 家参加访谈会以评估支持业务需求的可行性是非常有益的 。开展这些以数据为中 心的访谈与前面讨论的那些访谈是不同的 。目标是查明在建立需求的动力前 ，需要的核心数据是否已经存在 。在以数据为中心的访谈中 ，您可以深入了解 一些初期的随后需要提供的数据分析结果 ，例如，一些关键 数据字段的领域值和计数 ，这样可以确保您不至于站在流沙之上 。在维度建模过程中 ，将进行更加全面的数据审计 。在该点上努力学习 ，就可以恰当地管理组织的期望 。文档化需求
访谈后紧接着需要做的事情是 ，访谈小组应完成详细的访谈报告 。确认每个 小组成员 所记录的内容 。如果每个人都能在会议后 ，趁对访谈内容尚具有清 晰记忆时 ，快速总结自 己的笔记是非常有用的，这样做可以填补空白 。笔记中的缩略词和记录不全的句子在几天 后会变得难 以理解。同样，需要检验收集的报告以赢得对更多数据仓库必须支持的多维性 的见解。
此后 ，可以将所听到的内容变成文字材料 。尽管形成文档是大家都不太喜欢做的工作 ， 但文档无论是对用户验证 ，还是作为项目组参考材料来说都是非常重要的 。在需求过程中 将形成两个可能的文档类别 。第 1 个文档是记录下每个访谈 ，该活动需要花费大 量时间， 因为记录不能仅仅是对意识流的抄写 ，重要的是能够使那些未参会的人 也能够理解 。合并 结果的文档是最为关键的文档 。该文档将围绕业务过程来组织 。因为DW/Bl 项 目的处理是 以逐个的过程为基础的 ，因此将业 务需求放入不同 的领域中是非常适当的，这样可以按照 不同领域开展实施工作 。
在完成合并文档时 ，应该撰写执行综合文档 ，紧接着撰写项目概述 ，包括用到的过程 和有关的参与者 。总体上说 ，文档要 以业务过程为中心 。对每个过程 ，要描述为什么业务 用户期望分析过程的指标度量 ，他们需要得到何种能力 ，当前他们所受到的限制 ，可能存 在的好处或影响是什么 。处理每个过程的可行性评论 也是非常重要的 内容 。-
需求优先级
综合结果文档将成为后面为高管层和其他需求参与人员展示的基础 。难以避免的是 ， 您不可能通过一次迭代就涵盖所有需要处理的需求，因此需要考虑优先顺序 。正如在讨论项目范围时所提到的那样，不要凭空制定优先顺序，需要与业务团队的合作者 一起来建立 合适的优先顺序。
在结果评审和优先顺序考虑会议上要汇报需求总结 报告。参与者包括高级业务代表（参 与过访谈会 的优先），以及 DW/Bl 管理者和其他高级 IT 管理人员。会议 以概述每个确定的 业务过程开始 。应当使每个参与者对机会有共 同的理解。也可以评审机会／利益相关方矩阵 ， 以及简化的总线矩阵 。
最终成果提交后 ，开始考虑优化使用如下 所示的优先级网格 。网格的纵制｜ 表示业 务潜在的影响或价值 。横制l表达可行性 。每个最终成果的业务过程 主题按照业务代表 们所 确认的有关影响和可行性的综合情况米放置 。它图形化地表示 出您应该从哪里着手 。需要 优先关注的项目位于右上角，因为它们代表的是影响大、可行性高的项目 。而位于 左下角 的项目要尽力避免 ，它们对业务没有 多少价值 。同样，位 于右下角的项目也没有短期启动的意义，尽管项目组有时会被它们吸引，囚为这些项目是可行的，但并非关键的。最后，左上角项目表示那些有意义的机会。这些项目具有较大的业务投资价值 ，但当前可行性不强。当 DW/BI 项目小组关注右上角阴影部分的项目时，其他 IT 小组应该解决那些位于 左上角的当前可行性受到限制的项目 。
image.png
1.3 生命周期技术路径
1.3.1 技术架构设计
与新家的蓝图类似，技术架构是描绘 DW/BI 环境的技术服务和基础设施的蓝图。类似装修房屋的蓝图 ，技术架构包含 一系列揭示每个主要部件细节的模型 。无论哪种情况 ，架构确保能够抓住纸面上的问题 （例如 ，洗碗机离水槽太远），并减少项目中期的诧 异。支持并行工作 ，通过重用模块化的组件加快开发进度 。架构可 以确定哪些是马上就需 要的组件 ，哪些是可 以稍后完成的（例如 ，地面和玻璃门廊） 。最重要 的是，架构可作为 交 流工具 。家庭建筑蓝图可使建筑师 、总承包商 、分包商和房屋主人通过 一个公共文档进行 交流。同样，DW/BI 技术架构支持在组内 、上层的管理者和外部的承包商间建立 一个对技 术需求具有一致性的集合 。
DW/BI 小组通常从架构设计过程范围的两端着手 。一些小组根本无法理解架构的益处， 感觉主题和任务太过模糊 。他们非常关注交付物 ，认为架构像是 一种阻碍并干扰其工作进 展的东西，因此他们选择绕过架构设计 。实际上 ，他们将完成第1次迭代所需要的组件使用口香糖和电线捏合起来 ，换来的是集成和接口需要花费更大的代价来增加更多的数据 、更多的用户和更多的功能 。最终，这些小组需要重新构建 ，因为没有架构的结构无法承受压力 。另外一种极端情况是 ，某些小组期望花费两年的时间设计架构，忘记了 DW/BI 环境 的主要目的是解决商业问题，而不是解决任何貌似有理 （实际上并无道理）的技术挑战。
从设计范围的两端开始都是不健康 的。最适当的响应应该是从中间开始 。我们将支持 以下的 8 步过程来帮助大家开展结 构化设计工作 。每个 DW/BI 系统都包含一个技术架构 ， 问题在于其规划是清楚还是模糊 。
建立架构工作组
建立一个仅包含两三个人的重点关注架 构的工作组是非常有用的。通常，他们由技术架构师组成，包括ETL架构师／设计师和BI应用架构师／设计师，这些人能够代表后端和前端环境 。收集与架构有关的需求
建立架构主要是为了支持业务需求 。不能将它当成购买最新的 、最好的产品的借口 。实际上，设计过程的关键输入来自业务需求定义 。然而 ，对待业务需求 ，需要有选择地获取，主要获得那些能 够驱动架构设计的需求 。主要关注点在于揭示出那些能够对架 构产生影响的业务需求 。重 点关注涉及时间、可用性和性能方面的需求 。
您还应该召开 IT 组织内部的访谈会 。这些会议重点关注技术，以理解当前的标准，规 划技术方向 以及确定边界。此外，需要揭示那些从先前开展的信息交互产物中学习到的经 验和教 训 ，以及组织的有关用 DW/BI 项目适应操作变化的意愿 ，例如 ，确定源系统中更新 的事务。架构需求 文档化
在利用业务需求过程以及召开辅助性的访谈后 ，需要对产生的结果文档化 。我们建 议使用简单的图表形式 ，仅需要列出影响架构的业务需求 ，以及受影响的架构的详细列表 。 例如 ，如果需要每晚发布总体销售性能数据 ，那么对技术方面的影响可能是 全局范围内的 24月的可用性问题 ，为加载需要进行的数据镜像 ，支持全局访 问的元数据的健壮性 ，适当 的网络带宽，足够的用于处理操作型数据集成的 ETL 能力等。
建立架构模型
文档化架构需求后 ，将为发现的需求构建模型 。此时，架构小组通常要集中到会议 且 ， 与外界隔绝地仔细考虑一段时间 。将架构需求划分为主要的组件 ，包括 ETL 、BI 、元数据 和基础设施 。从此，小组开始勾画并逐步求精地建立高级的架构模型 。产生的结果与前文讨论的建房的蓝图类似。它将描述从街面上看 ，建筑看起来像什么 ，但它还非常简单，因为相关的细节尚未加以考虑。确定架构实现阶段
就像房屋拥有者梦想中的房屋 一样 ，您不可能一次就将技术架构的方方面面都予以实现。有些方面是必须强制实施的 ，其他方面可能是最好具备 。再一次返回到业务需求来建立架构优先顺序 ，因为在项目初期必须提供包含最少元素的架构 。设计并定义子系统
所需的大部分功能可能通过主要的工具提供商的标准产品都能够获得 ，但是总会有 一些子系统无法在现成产品中找到 。必须对这些子系统详尽地加以定义 ，这样要么有人能 够 为您构建这些产品 ，要么可以根据您的需求来评价产品 。建立架构规划
技术架构需要被文档化 ，包括规划的各个实现阶段 ，可供那些未参加会议的人员使用 。技术架构规划文档应该包括十分详尽的细节 ，这样有经验的职业人士可以处理框架的构建 ， 就像木匠基于蓝图构建房屋一样 。然而 ，除非己经开始使用 ，否则一般不要指明特定的 产品。评审及确定技术架构
最后 ，让我们结束关于架构设计过程的讨论 。架构任务 工作团队需要将架构规划以各 种不同细节层次与项目小组 、IT 伙伴和业务领导者交流 。评审后，应该对文档按照评审结 果进行更新并立即用于 产品选择过程。
1.3.2 产品选择与安装
架构规划在许多方面类似选择满足规划框架的 产品的购物清单。以下6 种与 DW/BI 产 品选择有关的任务与所有技术选择类似 。
了解公司的采购流程
选择新产品的第 1个步骤是了解公司内部的硬件和软件采购流程 。建立产品评价矩 阵
以架构规划为起始点 ，开发出基于电 子图表的用于确定评价准则的评价矩阵以及指 示 重要性的权衡因素 。评价准则越具体越好 。如果评价准则太模糊或太 一般化 ，则所有供应 商都能够满足您的需要 。进行市场调研
在选择产品时，要成为明智的买家 ，就应该开展市场调研以更好地了解提供商及其提 供的产品。请求建议(Request For Proposal ，盯P）是一个经典的产品评价工具 。尽管有些组 织别无选择 ，但您应该尽力避免采用这 一技术 。构建 盯P 和评价响应需要耗费小组大量的 时间。同时，提供商会从最积极的角度主动响应问题 。最终 ，支付的价值可能与付出的努力不成比例 。评价的选项列表不要太多
尽管市场上存在大量的可用产品，但通常仅有 一小部分供应商能够同时满足功能和技 术需求 。通过比较评价矩阵的 基本得分 ，可以将目标集中到小部分供应商 而将其他大部分 排除在外。在确定供应商后 ，可以开展详细的评估工作 。如果是评估 BI 工具 ，则应该将业 务代表包含进来 。作为评估人员 ，您应该驾驭评估过程 ，而不是被供应商驱动 ，共享相关 的来自架构规划的信息 ，这样会议才会关注您的需求 而不是产品 的表面浮华的特性 。一定 要讨论供应商的 参考资料 ，这些资料包括从正规渠道获得 的，以及从非正规的网络 上获 得的。必要情况下构建原型系统
详细评估完成后 ，有时明确 的优胜者会浮出水面 ，通常是基于小组先前的经验或关系 。 另外也可能出现一些其他情况 ，胜出方式是由于现有 的企业承诺 ，例如 ，站点协议或历史 上存在的硬件购买。无论哪种情况 ，当出现唯一的候选者时 ，您可以绕过构建原型这 一步 骤（这关系到时间和金钱的投入 ） 。如果没有 明显的胜者 ，您应该考虑构建不超过两个产品 的原型。再次说明 ，需要控制原型开发过程 ，开发有限的但非常现实的业务案例 。选择产品 、安装试验以及谈判
现在可以选择产品了。不要立即就签字成交 ，通过给单个供应商私下的 、非公开的承诺 ，保留您继续谈判的能力 。不要立即通知供应商您决定购买其产品 ，而是进入试用期 ， 您有机会将相关产 品应用到实际环境中。安装产品、进行培训和开始使用 ，这些需要花费 大量的精力，因此应当与中意的提供商 一起走过这一阶段 ，不应该将测试作为另外一种消 耗精力的游戏 。试验结束后 ，可以开展对各参与方都有利的购买谈判工作 。
1.4 生命周期数据路径
1.4.1 维度建模
参考之前的维度建模篇章。
1.4.2 物理设计
通过基本的源到目标映射而开发和文档化的维度模型需要转换成物理数据库 。采用维度模型，逻辑和物理设计具有相似性，您肯定不希望数据库管理员在物理设计过程中将您可爱的维度模型转换为规范化的结构 。
物理数据库实现细节随平台和项目的不同而存在较大的差异 。此外，硬件、软件和工 具发展迅速 ，因此后续的物理设计活动和考虑仅仅能提供简单的参考 。
开发命名及数据库标准
表和列名是用户体验的关键因素 ，用于数据模型和 BI 应用的导航 ，因此它们对业 务来 说应该是有意义的 。您还需要围绕键的定义来建立标准以及确定是否允许存在空值 。开发物理数据库模型
物理数据库模型应该尽早建立在开发服 务器中 ，以便能够被 ETL 开发小组使用 。几个 附加的表集合应该作为 DW/BI 系统的组成部分而 被设计和部署 ，这些表集合包括支持ETL 过程的临时表 ，ETL 过程和质量的审计表 ，支持安全访问 数据仓库子集的结构等。开发初始索引规划
除了要理解关系数据库的查询优化器和索引工作原理外 ，数据库管理员还应当敏锐地 意识到 DW/BI 需求与联机事务处理（OLTP）需求存在显著的差别。因为维度表具有单列主键 ，所以可以建立唯 一索引。如果可以用位图索引的话 ，通常可以在维度属性中增加 一个 位图索引列 ，用于过滤和分组 ，特别是当需要属性联合约束时 •。否则，可以考虑针对这 些 属性使用 B 树索引。同样，第 1 个事实表索引通常是针对 主键的 B 树索引或聚集索引，确 定日期外键在索引的主导地位可以加快数据加载和 查询操作 ，因为日期通常会被频繁使用 。 如果数据库管理系统（DBMS）支持高粒度的位图索引 ，则对事实表中独立的外键使用位图索 引是较好的选择 ，因为当用户以未知方式约束维度时 ，它们比聚集索引更具有未知性 。其 他事实表索引的确定依赖于可用的索引及平台的优化策略 。尽管联机分析处理（OLAP）数据 库引擎也使用索引并且有 查询优化器 ，但与关系世界不同的是 ，数据库管理员对这些环境 的控制能力有限。设计聚合 ，包括 OLAP 数据库
与流行的观念不同 ，增加更多的硬件不 一定是性能调整武器库中最好的武器 ，利用聚集表是使成本更有效的可选方法 。无论使用 OLAP 技术还是使用关系聚集表 ，聚集都是 DW/BI 环境中必要的设计。当性能度量被聚集后，您要么删减维度 ，要么将度量与遵守原子基本维度的缩减上卷维度关联 。由于不可能建立、仓储 、管理所有理论上可能存在的聚集 ，因此需要考虑两个主要 的评价因素 。首先 ， 考虑从需求文档中获取的业务用户的访问模式 ，以及通过监控实际使用模式所获得的输入 。 其次 ，通过评价数据的统计分布以提供划算的聚集点 。确定物理存储细节
这包括块、文件、磁盘 、分区和表空间以及数据库的具体存储结构细节 。大型事实表通常是按照活动日期划分的 ，数据按月进行分段后放入不同的分区中，但仍然以 单一表的形式呈现给用户 。按照日期分区能够 为数据加载 、维护和查询性能带来好处 。 聚集、索引及其他性能调整策略将随着对实际使用模式更好的理解而不断改进 ，因此要对不可避免 的持续更新有思想准备 。然而，您必须为最初的上卷发布适当的索引和聚集 数据，以确保 DW/BI 环境从开始就能具备合理的查询性能 。
1.4.3 ETL 设计与开发
生命周期的数据路径结束于 ETL 系统设计和开发 。
1.5 生命周期 Bl 应用路径
尽管某些人可能认为数据仓库应该是完全随时的、自服务的查询环境，发布参数驱动 的 BI 应用将满足大部分业务团队的需求 。对多数商业用户来说 ，“随时的” 意味着改变报 表的参数来建立他们个人的版本的能力 。没有必要让所有用户都从头开始 。构建一系列 的 BI 应用为组织建立了一个一致的分析框架，而不会让每个报表都存在差异 。BI 应用还服务 于获取组织的分析知识，从监控性能到识别例外 ，确定因果因素 ，建模可替代的响应，这 种封装提供 了更少的分析性趋向的跳跃 。
1.5.1 Bl 应用规范
业务需求定义完 成后，需要评审形成的产物并收集示 例报表以确定初始集合中包含的 大约 10-15 个 BI 报表和分析应用 。将着眼点收缩到关注最 为关键的能力，对期望进行管 理并及时发布 。对这一优先过程来说 ，业务团队的输入是非常关键的 。尽管 15 个应用昕起 来不算多 ，但仅仅改变简单模板的变 量就可能会产生大量的分析。
开始设计初始应用时 ，建立标准（例如 ，常见的下拉菜单和一致性的输出的外观和感觉 ） 是非常有益的 。利用这些标准 ，定义每个应用模板并获得足够 的有关布局 、输入变量 、计算 、拆分的信息 ，这样应用开发人员和业务代表都能够获得共同的理解 。
在BI 应用规范活动过程中 ，还应当考虑应用的组织。需要确定用于访问应用的结构化的导航路径 ，要反映用户考虑其业务的方式 。利用可定制的信息门户或仪表盘是传播路径 的主要策略 。
1.5.2 Bl 应用开发
此您进入BI应用开发阶段时，需要再次关注标准 、命名规则 、计算 、库和编码标准的建立工作以最小化未来的修改工作 。数据库开发工作结束后，Bl 工具和元数据安装完成，部分历史数据也己经加载完成，此时可以开展应用开发活动 。尽管模板定义已经完成 ，仍然应该重新考虑 BI 应用模板定义 ，以应对不可避免的模型修改 。
每个BI 工具都有特定的产品技能 ，因此可能需要重新加以考虑 。我们建议，与其通过反复试验获取经验 ，不如为开发小组投资特定工具的教育培训或补充资源的工作 。
开发BI应用时，一些辅助工作将有利于获得良好的结果 。BI 应用开发人员采用健壮的访问工具，将能够在数据的草堆中快速发现针尖小的问题 ，尽管 ETL 应用已经对数据质量进行了验证工作 。这也是我们为什么推荐在 BI 应用开发活动开展前 ，ETL系统已经完成的原因 。开发者还将首先开展对查询响应时间的实际测试工作 。现在是评审主要的性能 调整策略的时候了 。
BI应用质量保证活动在数据稳定前是不会停止的 。您必须确保足够的调度时间，超过最后的ETL截止时间 ，以允许顺序完成 BI 应用开发任务 。
1.6 生命周期总结活动
后续部分提供确保项目达到有序结论的建议，同时确保您能够为未来的扩展做好准备 。
1.6.1 部署
技术、数据和BI 应用路径收敛于部署 。遗憾的是 ，这一收敛并不能自然发生 ，需要预先进行大量的规划 。也许更为重要的是 ，成功的部署需要胆略和毅力以诚实地评价项目的部署准备 。部署与在假日里为亲朋好友制作 一份大餐类似 。要准确地预测烹调主菜所需要 的时间是非常困难的事情 。当然，如果主菜尚未完成 ，厨师不得不在叫所有人上桌之前， 放慢配菜速度以补偿延迟 。
就 DW/BI 部署来说 ，数据就是主菜 。在 ETL 厨房中 “ 烹调” 数据是最难以预测的任务。遗憾的是 ，即使数据没有完全准备好 ，您通常仍然会继续 执行部署工作 ，因为您告诉 数据仓库的使用者 ，他们将会在特定的日期和时间得到服 务 。由于您并未放慢部署的步伐 ， 所以带着尚未 “ 烹调好” 的数据进入客户的办公室 。难怪用户有时不再回来而去寻找其他 的帮助。
尽管在 DW/BI 开发任务期间 ，毫无疑问会进行测试，但您需要执行端到端的系统测试 ， 包括数据质量保证 、操作处理 、性能和可用性测试 。除了批判性地评价 DW/BI 发布物的准 备情况外 ，还需要通过教育对其进行包装且支持部署 。因为用户团体必须接受注定会取得 成功的 DW/BI 系统，因此教育是至关重要的 。DW/BI 支持策略依赖管理层的期望和现实 的发布物的结合 。支持通常是按照层次结构组织的 。第 1 层是网站和自助服务支持 ；第 2 层由业务区域中的强力用户支持 ；来自 DW/BI 小组的集中式支持提供最后 一道防线。
1.6.2 维护和发展
部署工作完成 ，您已经准备放松休息了 。别太着急 ！尽管部署结束 ，但工作远未完成 。 您需要通过投资下列各类资源不断地管理己有的环境 ：
支持 ：部署后，为确保业务团队能够喜欢使用它们 ，用户支持立即成为关键 。您 不能坐在房间中并认为没有来自业务团队的消息就是好消息 。如果没有来自他们的消息，只可能是没有人使用 DW/BI 系统。关注（至少临时地）业务团体 ，使用户能够非常方便地使用支持资源 。如果数据或 BI 应用有错误被发现了 ，要诚实地告知，这样才能建立相互的信任关系，同时立刻采取行动以改正存在的问题 。如果 DW/BI 发布物质量不高，难以想象的对数据调整和应用返工予以支持的请求将会占到问题的大多数。
教育 ：必须持续不断为 DW/BI 系统提供教育程序 。课程应该包括正规的进修和 高 级课程，以及不断重复的入门课程 。可以为开发者和强力用户提供更多的非正规 教育以鼓励思想交流 。
技术支持 ：应当将 DW/BI 系统视为 具有服务级别许可的生产环境 。当然，技术支 持应当主动地监控性能和系统容量趋势。您当然不希望由业务团体来告诉您性能 下降的情况。
程序支持 ：DW/BI 程序不是一个阶段就能够完成的 。您必须密切监视 ，然后推销 您的成功经验 。必须持续不断地与不同的 DW/BI 支持者进行交流 。还必须确保己 有的实现能够不断地解决业务的需要 。不间断的检查点评审是评价和确定改进机 会的关键工具 。
如果您正确地开展工作 ，不可避免地会存在发展的需求 ，可能源于新用户 、新数据、 新的 BI 应用 ，或对己有 的发布物进行重大的改进 。与传统的开发计划不同 ，DW/BI 变化 应该被视为是成功的 ，而不是失败的信号 。正如我们在前面讨论项目范围时提出的建议那 样 ，DW/BI 小组不要凭空臆想发展选项而做出决定 。业务需要按照优先过程来 处理 。如果您还没有开展 这一工作 ，应该建立执行董事会来 设置 DW/BI 优先级以剪裁组织的总体目标 。在新 的优先级确定后 ，返回到生命周期起始点， 重新开展所有的工作 ，利用己经存在的技术 、数据 、BI 应用基础 ，并重新建立它 们 ，当 然注意力要转到满足新的需求上 。
1.7 应当避免的常见错误
尽管我们能够提供有关数据仓库和BI 方面 的积极的建议 ，一些读者最好关心一下常见 错误清单 。下面是我们提出 的在建立 DW1BI 系统时需要避免的 10 个常见错误：
错误 10：过于迷恋技术和数据 ，而没有将重点放在业务需求和目标上 。
错误9：没有或无法找到一个有影响的 、平易近人的 、明白事理的高级管理人员作为 DW/Bl 工作的发起人 。
错误8：将项目处理为一个巨大的持续多年 的项目，而不是追求更容易管理的、虽 然仍然具有挑战性的迭代开发工作 。
错误7：分配大量的精力去构建规范化数据结构 ，在基于维度模型建立可行的展现 区前，用尽所有的预算 。
错误6：将主要精力投入到后端操作型性能和易开发性 ，而没有重点考虑前端查询 的性能和易用性 。
错误5：使存在于展现区的所谓的可查询数据极端复杂 。喜欢提供复杂展现的数据 库设计者花费大量时间支持业务用户 ，他们的确应该通过简化解决方案开发出更适合需要的产品 。
错误4：将维度模型放入单一基础之上 ，不考虑使用可共享的 、一致性维度通过数据结构将这些模型联系在一起 。
错误3：只将汇总数据加载到展示区的维度结构中 。
错误2：臆想业务、业务需求及分析，其涉及的数据及支持技术都是静态的。
错误 1：忽略承认DW/BI系统的成功直接来源于业务的认可 。如果用户未将 DW/BI系统当成他们制定决策的基础 ，那么您所做的工作就是徒劳无益的 。
参考:
- 《数据仓库工具箱 维度建模权威指南》第三版