[分享]微软BI专题-构建成功的商业智能系统

尽管创建和管理一个成功的DW/BI系统是相当具有挑战性的，但是业界也有一些权威人士和机构总结的方法论，可以辅助BI项目管理规避风险、增加成功的可能性。

如果你去问一位资深的程序员：“我的程序用Java语言开发能成功还是C#语言开发能成功？”答案很可能是：“语言本身并不重要，重要的是如何设计、如何搭建合理的程序架构……”
同样的，如果你去问一位商业智能专家：“我的商业智能项目应该采购什么产品？”他会告诉你，产品不是最重要的，商业智能工具的使用方法也不是最重要的，成 功的关键在于如何分析需求，如何设计模型，如何在方法论的层面解决问题。今天，就让我们来谈谈，与方法论相关的几个重要问题。

数据仓库和商业智能（DW/BI）究竟意味着什么？
数据仓库和商业智能的作用在于，为业务人员提供制定操作性和战略性业务决策所需要的信息和工具。
BI是企业战略型的规划：在这里，客户一般是指公司的业务人员。但是对BI系统的开发者来说，并非所有的业务用户都具有同等的重要性——我们应该重点关注 那些制定战略型业务决策的人。为什么？因为这就是真正产生利润的地方。一个非常好的业务决定可能意味着为公司带来数百万美元的利润。BI系统的主要客户是 主管人员、经理以及公司的分析师。因此，数据仓库和商业智能（DW/BI）系统影响深远、意义重大。
BI意味着高风险：战略性也就意味着重要性。这些是可以决定公司成败的决策。当制订了某个重要决定之后，有的将会带来成功，而有的将会导致失败。因此，构建DW/BI系统也就成为了一个高风险的事务。
BI要求复杂的数据收集和管理：从技术角度看，不管制定的决策是战略性的还是操作性的，都需要提供必要的信息来制定这些决策。任何给定的决策都需要一个独 特的信息子集。我们可能需要跨公司或者从公司外部提取数据来构建一个信息基础数据库，然后清理、排列和重构这些数据来使得它们更灵活和更可用。尽管大部分 事务系统模块只和与之相关的数据打交道，例如：账单、订单或账目，但是，DW/BI系统最终必须将它们集成在一起。因此，DW/BI系统要求技术上很复杂 的数据收集和管理。
BI是多种工具的集成解决方案：最后，需要给业务决策制定者提供使用这些数据的工具。在这样的情形下，工具并不 仅仅意味着软件，它意味着业务用户需要了解的所有事情，哪些信息是可用的，查找需要的子集以及将数据结构化来阐明潜在的业务动态。因此，工具意味着培训、 文档、支持，以及即时查询工具、报告和分析型应用程序。
那么，数据仓库和商业智能（DW/BI）究竟意味着什么呢？让我们一起回顾DW/BI系统：

BI是高配置的和高影响的；
BI是高风险的；
BI是高度战略性的；
BI要求技术上很复杂的数据收集和管理；
BI要求强化的用户访问、培训和支持。

BI项目的生命周期是什么？
在深入一个BI项目之后，我们往往会感到恐慌，因为摆在我们面前的困难、需要我们投入的精力远比之前想象的多得多。许多DW/BI系统都从这样的概念开 始：移动一些数据到新机器中，清理数据然后开发一些报表。这听起来很不错，但经过6周后或最多两个月的努力，我们会发现身边已经危机重重。
避免这种恐慌的最好方式是：选择一种过程管理的方法，通过里程碑式的标识物，阶段性地展开项目，并且在每个阶段的开始，最大程度地明确阶段过程中的风险和相应的解决方案。DW/BI系统是一个复杂的实体，构建这种系统的方法必须能够降低其复杂性。
图1展现了业务维度的生命周期。它为我们的方法论提供了典型的阶段划分。13个方框显示了关于构建一个成功的数据仓库和这些任务之间的主要依赖性的主要任务区域。



图1：业务维度生命周期

我们接下来对业务维度生命周期进行简单的描述。
首先，注意到业务维度生命周期的“定义业务需求”。业务需求是紧随其后的三个轨迹的基础，同时，它也影响着“项目规划”。因此，它和“项目规划”的方框之间的箭头是双向的。业务维度生命周期的某一个迭代经常会以定义一个新的业务需求结束。
其次，我们来看看生命周期中间的三个轨迹。

顶部的轨迹是关于技术的。这些任务主要是要确定计划使用哪些技术、产品以及如何安装和配置它们。
中间的轨迹是关于数据的。在数据轨迹中，我们将设计和实例化维度模型，然后开发ETL系统来填充它。可以将数据轨迹视作“构建数据仓库数据库”，尽管数据仓库直到生命周期的其它任务结束时才意味着成功。
底部的轨迹是关于商业智能应用的。在这些任务中将为业务用户设计和开发BI应用程序。

当我们开始部署系统时，上述三个轨迹将合并，这是一个非常微妙的时刻，因为只有在这里，我们才有机会让整个系统获得好的印象。同时，维护DW/BI系统并不是在部署之后才开始，之前，我们需要投入一定的能力来设计系统及工具来维护它。

最后，项目增长阶段链接到的箭头隐含着这样的含义：生命周期的增量迭代方法是发布BI系统业务价值的基本要素。
在整个生命周期的下面是项目管理方框，这里要记住的最重要的事情就是：我们需要一个领导者，他一定要能够和高级管理层有效沟通。其实，理想的团队领导者很难找到，因为他们要做到同技术人员、业务人员、包括公司最高级的执行者进行有效的沟通。

澄清关键术语，让我们走在同一条路上！
商业智能领域有很多没有被正确使用或者被用错的术语。业界的一些主要争论源自于其他人对于术语的误解，就像哲学与真实的差异一样。虽然我们不能解决所有的历史争论，但是，我们应该尝试着保持清晰和一致。因此，我们在这里强调一些关键的术语。
同时，当我们定义每个术语时，也对应性的强调了微软技术，以便将该术语的实现具体化，其中大部分是SQL Server 2005的成员。

数据仓库是 用于商业智能的平台。在Kimball Method中，数据仓库包含了从原始数据提取出用户需要的、与软件和应用相关的所有内容。我们不认同某些作者，他们坚持认为数据仓库仅仅用来集中储备高 度规范化的数据，这种解释实际上远离了最终用户的需求。为了减少分歧，我们使用短语“数据仓库/商业智能系统（DW/BI系统）”来表示整个端到端系统。 当我们特别原子级的用户可查询数据存储时，我们称之为数据仓库数据库；
业务过程维度模型是建模数据的特定准则，也是规范 化建模的一个选择。一个维度模型包含了和规范化模型一样的信息，但是以对称的方式包装数据。这样设计的目的是为了实现用户的可理解性、商业智能查询性能和 对于变化的适应性；规范化模型，有时也被称为第三范式模型，主要用于支持高数量的、单行插入和更新来定义事务系统，但一般会在可理解性、快速和适应变化方 面不尽人意。
关系型数据库是用于存储、管理和查询数据的一般用途的技术。SQL Server 2005数据库引擎是微软的关系数据库引擎。业务过程维度模型可以存储在一个关系数据库中，支持事务处理的规范化的数据模型也可以存储在一个关系数据库中。
联机分析处理（OLAP）数据库是用于存储、管理和查询专门用于支持商业智能使用的技术。SQL Server2005 Analysis Services是微软的OLAP数据库引擎。业务过程维度模型可以存储在一个OLAP数据库中，但不能存储在一个事务型数据库中，除非先将它变换成明确的维形式。
一个ETL系统是 一个过程的集合，可以用来清理、转换、合并、删除重复记录、存档一致化以及结构化数据，应用于数据仓库。早期的ETL系统使用SQL脚本和其它脚本来构 建。尽管许多小型ETL系统仍然这么做，但是大型的或者更重要的ETL系统使用专门的ETL工具。更进一步，几乎每个DW/BI系统都使用了像SQL Server 2005 Integration Services这样的工具。
商业智能（BI）应用是 一些预定义的应用，它们可以查询、分析和展现信息来支持业务需要。实际上，存在一系列的BI应用，从复杂的、预定义的报告到直接影响事务系统和公司每天操 作的分析型应用。比如，我们可以使用SQL Server Reporting Service来构建一个制表应用，或者使用微软和第三方技术来构建复杂的分析型应用。
数据挖掘模型是一个静态模型，经常被用于根据数据过去的行为预测未来的行为。数据挖掘是一个术语，指的是服务于不同目的的统计技术，或算法的不固定的（经常改变的）集合。主要包括聚类、决策树、神经网络和预测。Analysis Services数据挖掘是数据挖掘工具的一个实例。

项目团队成员的分工和职责有哪些？
在DW/BI系统在生命周期中，需要一定数量的人分别掌握不同的技能、承担不同的工作角色，这些技术和技能不仅仅来自于技术领域，还可能来自于业务领域。 在这里，我们来回顾一下与创建DW/BI系统有关的主要角色。其实，在角色和人之间，一般没有一个一对一的关系。我们和不同的团队合作过，这些团队可以小 到只有1个人，也可以大到有40个人（听说有更大的），大部分DW/BI团队在3～7个全职成员之间，但是根据需要可以增加成员数量。
由同一个团队承担DW/BI系统的开发和维护这两种不同类型的责任是很常见的，这不同于大部分技术项目团队。在DW/BI项目开发中，团队的建设和周期的高度迭代是相关联的。图2列出了设计和开发活动相关联的常见角色。



图2：BI开发团队角色划分

DW/BI项目经理：负责项目的总体领导和方向。DW/BI项目经理必须能够和高级业务层、IT管理层进行有效的沟通，同时，必须能够和团队一起工作来阐明DW/BI系统的总体架构。
项目经理：负责系统开发过程中的项目任务和活动的日常管理。
业务项目领导者：是业务领域的成员，需要和项目经理一起工作。
业务系统分析师：或称业务分析师，负责领导业务需求定义活动，并且经常参与业务过程维度模型的开发。业务系统分析师需要能够在业务和技术之间进行沟通。
数据建模人员：负责执行包括数据配置和开发详细维度模型的详细数据分析。
系统架构师：设计DW/BI系统的不同构件。这些构件包括ETL系统、安全系统、审核系统和维护系统。
数据库管理员（DBA）：创建关系型数据仓库数据库并且负责总体的物理设计，包括磁盘排列、划分和初始的索引计划。
OLAP数据库设计人员：创建OLAP数据库。
ETL系统开发人员：创建Integration Services包、脚本、及其它可以从源数据库移动数据到数据仓库的程序。
DW/BI管理工具开发人员：负责编写对于管理DW/BI系统的任何必要的定制工具。这些工具的简单例子包括输入源数据、脚本或执行系统备份和恢复的Integration Services包的简单UI（用户界面），以及维护维体系结构的简单UI。
BI应用开发人员：负责构建BI应用，包括标准报告和业务需要的高级分析型应用，他们也负责开发BI门户的任何定制的组件以及集成数据挖掘模型到业务操作中。

循着前人的路标前进！
尽管创建和管理一个成功的DW/BI系统是相当具有挑战性的，但是业界也有一些权威人士和机构总结的方法论，可以辅助BI项目管理规避风险、增加成功的可 能性，例如：Kimball Group。Kimball Group的成员已经在DW/BI领域工作了20多年，一直都从事着数据仓库和商业智能系统的工作。在过去20年中，在构建数据仓库的同时，他们不断在寻 找简化和划分设计过程的方法。当他们看到相同的设计过程重复地出现时，就会给予这种技术一个名称，然后尝试以一种清晰的方式来解释它。这些设计技术的集合 称为Kimball Method。
在Kimball Group的主要成员于2006年编写并出版的《The Microsoft Data Warehouse Toolkit With SQL Server 2005 and the Microsoft Business Intelligence Toolset》一书中，将Kimball Method和Microsoft SQL Server 2005工具有机地集合起来，堪称“Microsoft SQL Server DW/BI”系统项目建设的指路标。
该书与绝大多数其它技术书籍的不同点在于，它试图阐述商业智能方法论层面的知识，或者说“该做什么”，而不是“如何做”。
2007年底，清华大学出版社出版了该书的中文版本《数据仓库工具箱——面向SQL Server 2005和Microsoft商业智能工具集》，相信会给广大准备投身于商业智能领域、或者正在其中奋战的实践者们，带来很大的指导价值。