本书描述了如何使用Microsoft SQL Server 2005产品集构建一个成功的商业智能系统以及数据仓库数据库，这里的关键字是“成功的”。 0.1 数据仓库和商业智能系统 数据仓库和商业智能的作用在于，为业务人员提供制定操作性和战略性业务决策所需的信息和工具。我们将详细剖析这方面的问题，以便您能真实了解将要采纳的决策的性质和规模。 首先，客户一般是指公司的业务人员。但是对您来说，并非所有的业务用户都具有同等的重要性——您对于那些制定战略性业务决策的人可能更感兴趣。为什么？因为这就是真正产生利润的地方。一个非常好的业务决定可能意味着许多公司的数百万美元。您主要的客户是主管人员、经理以及公司的分析师，因此，数据仓库和商业智能(DW/BI)系统影响深远、意义重大。 战略性也意味着重要性。这些是可以决定公司成败的决策。因此，DW/BI系统是一个高风险的努力。当制定了某个重要决定时，有些人将会成功而有些人将会失败，因此DW/BI系统也是高度战略性的努力。 DW/BI系统正日益支持着操作性决策，特别是在决策制定者需要从多个数据源中查询历史数据或集成数据的地方。许多“分析型应用程序”都支持这一操作。从技术角度看，不管制定的决策是战略性的还是操作性的，您都需要提供必要的信息来制定这些决策。任何给定的决策都需要一个独特的信息子集。您需要跨公司并且可能从公司外部提取数据来构建一个信息基础结构，然后清理、排列和重构这些数据来使得它们更灵活和更可用。尽管大部分事务系统模块和某种类型的数据，例如收到的账单、订单或账目一起工作，DW/BI系统最终必须将它们集成在一起。因此，DW/BI系统要求技术上很复杂的数据收集和管理。 最后需要给业务决策制定者提供使用这些数据的工具。在这样的情形下，工具并不仅仅意味着软件，这意味着业务用户需要了解的所有事情，哪些信息是可用的，查找需要的子集以及将数据结构化来阐明潜在的业务动态。因此，工具意味着培训、文档、支持，以及即席查询查询工具、报告和分析型应用程序。 让我们一起回顾DW/BI系统： ● 是高配置的和高影响的； ● 是高风险的； ● 是高度战略性的； ● 要求技术上很复杂的数据收集和管理； ● 要求强化的用户访问、培训和支持。 创建和管理DW/BI系统是一项具有挑战性的任务，我们希望以您所了解的全部知识来接受这一任务。以我们的经验来看，如果您事先被预警，将很容易应对这些挑战。 我们并不想使您气馁，而是要在您跳进深水之前警告您，以我们的经验来看，所有使得数据仓库具有挑战性的原因也就是使得它成为一个很有趣且令人兴奋的项目。 0.1.1 Kimball Group 尽管构建和管理一个成功的DW/BI系统是具有挑战性的，但也有一些增加成功可能性的方法，那就是使用Kimball Group所提供的方法。我们已经在DW/BI领域工作了20多年，本书的作者也是Kimball Group的成员，整个职业生涯作为销售商、顾问、实现者和用户，一直都从事着数据仓库和商业智能系统的工作。我们的格言是“Practical techniques—proven results(实践的技术证明了结果)”，我们共同的动力是指明构建和管理一个成功的DW/BI系统的最好方式。我们也是热心的老师，衷心希望您通过学习本书获得成功并且避免我们和其他人犯过的错误。 0.1.2 本书目标 数据仓库和商业智能至少自1970年就具有相似的形式，并且持续享受着无限的技术生命周期。在1995年，我们的主要作者构建了第一个顾问公司，其中的作者之一认为数据仓库已经结束了，这个浪潮已经开始回落。幸运的是，我们在找到工作之前获得了更多的项目。12年后，数据仓库和商业智能依然很强大，事实上，仅仅在过去几年我们才看到它们在工业上的成熟。 成熟市场的一个标志就是单源提供者的出现——对不愿冒风险的公司来说这是一种安全的选择。数据仓库技术涵盖了从深奥源系统知识到用户接口设计以及具有最好实践的BI应用。尽管许多销售商在最近几年都争着把自己放在端到端的提供者位置上，但对于我们来说，很显然，数据仓库销售商确实是那些可以提供端到端解决方案的人。在2001年，当我们首次讨论这本书时，我们已经感觉到Microsoft要以一个诱人的价格强行将一个可行的、单源数据仓库系统提供者的概念加入到现实世界中。 我们相信向单源提供者的转变意味着必须将Kimball Method技术扩展到特定的产品级，使其可以直接投放单源提供者市场。我们选择Microsoft工具集作为测试样例有两个原因，首先，SQL Server 2005是一个强大的BI平台，Microsoft自20世纪90年代中期投资Analysis Services引擎以来，就一直在扩展和增强商业智能方面投资巨大。投资的级别也因此巨大地翻升。随着SQL Server 2005开发的开始，SQL Server 2005开发团队增长到200人，Microsoft对于将商业智能引入主流市场很认真。其次，两位作者都从1997到2002或2004在Microsoft工作，特别地，Joy曾是SQL Server Business Intelligence 开发团队中SQL Server BI Best Practices组的经理，这可以给予我们一系列很强的工作关系以及访问关键的支持资源。 0.1.3 本书读者对象 本书覆盖了整个数据仓库生命周期，因而可以给数据仓库团队的每个成员提供有用的指导，从项目经理到业务分析师、数据建模者、ETL开发者、DBA，分析型应用开发人员甚至业务用户都可以从本书中受益。我们相信本书对从事Microsoft SQL Server 2005数据仓库项目的任何人都非常有价值。 本书的主要读者是在Microsoft SQL Server平台上启动项目的新的DW/BI团队，我们假定您并没有构建DW/BI系统的经验，但假定您对Microsoft世界有一个基本的认识：操作系统、基础设施组件以及资源。我们也假定您对关系数据库(表、列和简单SQL)有一个基本认识，并且对SQL Server 2000关系数据库有一定认识，尽管这并不是一个必备条件。贯穿全书，我们提供了许多其他书和资源的参考。 第二个读者群是有Kimball Method DW/BI使用经验但首次接触Microsoft SQL Server 2005工具集的读者，这些读者可能需要阅读一些资料以便了解基础结构，特别是如果您从来没有使用过Windows Server更需如此。我们将指出对于那些曾经阅读过我们的Toolkit书籍以及实践过我们的方法的读者需要复习哪些部分和章节，不过再次阅读这些材料并没有坏处。 不管您的背景如何，如果您从一个新项目开始将从本书受益匪浅。尽管我们确实提供了运转现有的数据仓库的建议，但在理想情况下，您不会对任何已有的数据仓库或数据集市满意，至少在新系统部署后对仍然留在原处的系统不会满意。 0.2 业务维度生命周期 在深入一个项目后，我们都会感到内心恐慌，因为我们面前努力的范围和规模将会比我们在外围的想象花费更多的精力。许多BI/DW系统都从这样的概念开始：移动一些数据到新机器中，清理数据然后开发一些报告。这听起来很不错，但经过六周后或最多两个月的努力，在您意识到需要建立一座桥之前您已经身陷河中。 避免这种恐慌的最好方式是在您跳入水中之前告诉您应该去哪里，通过提供一些路标和方向可以将您安全地领过不熟悉的区域，这些路标和方向将告诉您哪些地方是安全的以及前途中会有哪些危险区域。本书就是Microsoft SQL Server BI/DW系统项目的路标。它遵循了The Data Warehouse Lifecycle Toolkit(Wiley，1998)首先描述的业务维度生命周期中的基本流程。本书汇集了根据我们的经验，很好地描述了生命周期的这些步骤、任务和依赖关系。生命周期是一个基于四个主要原则的迭代的方法： ● 专注于业务：集中识别业务需求和它们的关联。努力开发牢靠的业务关系并且让您的业务感和咨询技能更敏锐； ● 构建一个信息基础设施：设计一个单一的、集成的容易使用的高性能的信息基础设施，旨在满足您在跨企业中识别的、更加广泛的业务需求； ● 进行有意义的增量发布：以增量方式构建数据仓库，可以以6~12个月的时间来发布。使用可以清晰识别的业务值来决定增量的执行次序； ● 发布整个解决方案：提供所有必要的元素来传递值给业务用户。这意味着一个稳固的、设计很好的、高质量的可用数据仓库正在开始中。您也必须发布即席查询工具、报告的应用以及高级的分析、训练、支持、Web站点和文档。 本书通过使用业务维度生命周期帮助您遵循构建DW/BI系统的四个原则，这四个原则已经加入到生命周期中。理解业务维度生命周期的秘密就清晰地隐藏于它的名字中：它是基于业务的，采用维度方法用于设计展现给最终用户的数据模型，而且它是一个真实的生命周期。 0.2.1 生命周期跟踪和任务区域 BI/DW系统是一个复杂的实体，并且构建这种系统的方法必须能够简化此复杂性。图0-1展现了生命周期。13个方框显示了关于构建一个成功的数据仓库和这些任务之间的主要依赖性的主要任务区域。 说明：迟做总比什么都不做要好 发布整个解决方案是我们的根本原则之一，我们甚至不会考虑在没有发布现在所谓的商业智能层之前构建一个数据仓库。在经历过仅仅专注于创建数据仓库数据库的失败项目后，在1990年后期其他工业才逐步认识到这一点。 图0-1 业务维度生命周期 在生命周期这一级可以进行多方观察，首先，注意到业务维度生命周期的业务需求定义方框的中心角色。业务需求提供了紧随其后的三个轨迹的基础，它们也影响着项目计划，因此箭头指向了后面的项目规划方框。经常会以修改一个基于业务需求和优先权的更详细的理解结束。其次，生命周期中间的三个轨迹集中了三个不同的领域。 ● 顶部的轨迹是关于技术的。这些任务主要是关于计划使用哪部分Microsoft技术以及如何安装和配置它们。 ● 中间的轨迹是关于数据的。在数据轨迹中，将设计和实例化维度模型，然后开发ETL(提取、转换和加载)系统来填充它。可以将数据轨迹视作“构建数据仓库数据库”，尽管数据仓库直到将生命周期任务的其余部分包围上时才会成功。 ● 底部的轨迹是关于商业智能应用的。在这些任务中将为业务用户设计和开发BI应用程序。 当开始部署系统时这些轨迹将合并，这是一个非常微妙的时刻，因为仅有一次机会可以获得第一好印象。维护DW/BI系统并不在部署之后开始，需要有一定的能力来设计系统并要有工具来维护它。项目增长阶段链接到的箭头有一些主要的隐含之意，生命周期的增量方法是发布业务值的基本元素。见图0-1。 在整个生命周期的下面是项目管理方框，这里要记住的最重要的事情就是您需要一个领导者，并且他能够访问高级管理。团队领导者是那些很难找到的理想的人选之一，他们是可以同技术人员和业务人员，包括公司最高级的执行者进行有效沟通的人员。 0.2.2 关键术语和Microsoft工具集 商业智能领域充斥着没有正确使用的或者用错的术语。工业上的一些主要的争论主要源自于其他人对于术语的误解，就像哲学上真实的差异一样。记住这一点，我们尝试着保持清晰和一致，即使我们不能解决所有的历史争论。我们将在这里强调一些关键的术语。 当我们定义每个术语时，也强调了关联的Microsoft技术，其中大部分是SQL Server 2005的成员。 ● 数据仓库是用于商业智能的平台。在Kimball Method中，数据仓库包含了从原始数据提取到用户见到的软件和应用的所有内容。我们不同意其他作者，他们坚持认为数据仓库仅仅是后备房间的集中式的高度规范化的数据存储，这远离了最终用户。 为了减少分歧，在本书中我们一贯使用短语“数据仓库/商业智能系统(DW/BI系统)”来表示整个端到端系统。当我们特别讨论和专门讨论原子级的用户可查询数据存储时，我们称之为数据仓库数据库。 ● 业务过程维度模型是建模数据的特定准则，也是规范化建模的一个选择。一个维度模型包含了和规范化模型一样的信息，但以对称的方式包装数据，这样设计的目的是用户可理解性，商业智能查询性能和对于变化的适应性。规范化模型，有时也被称为第三范式模型，用于支持高数量的、单行插入和更新来定义事务系统，但一般会在可理解性、快速和适应变化方面失败。 我们使用术语“业务过程维度模型”具有两层含义，既指支持业务过程的逻辑维度模型，又指数据库中相应的物理表。换句话说，维度模型既是逻辑的又是物理的。 ● 关系型数据库是用于存储、管理和查询数据的一般用途的技术。SQL Server 2005数据库引擎是Microsoft的关系数据库引擎。业务过程维度模型可以存储在一个关系数据库中。支持事务处理的规范化的数据模型也可以存储在一个关系数据库中。 ● 联机分析处理(OLAP)数据库是用于存储、管理和查询专门用于支持商业智能使用的技术。SQL Server 2005 Analysis Services是Microsoft的OLAP数据库引擎。业务过程维度模型可以存储在一个OLAP数据库中，但不能存储在一个事务数据库中，除非首先将它变换成明确的维形式。 ● 一个ETL系统是一个过程的集合，可以清理、转换、合并、重复数据删除、存档，一致化以及结构化数据来用于数据仓库。这些术语在本书中都有描述。早期的ETL系统使用SQL脚本和其他脚本来构建。尽管许多小型ETL系统仍然这么做，但是大型的或者更重要的ETL系统是用专门的ETL工具。更进一步，几乎每个DW/BI系统都使用了像SQL Server 2005 Integration Services这样的工具，因为收益很大而增加的代价很低或者代价为零。 ● 商业智能(BI)应用是一些预定义的应用，它们可以查询、分析和展现信息来支持业务需要。有一系列的BI应用，从复杂的一系列预定义的报告到直接影响事务系统和公司每天操作的分析型应用。可以使用SQL Server Reporting Services来构建一个制表应用，以及一个大范围的Microsoft和第三方技术来构建复杂的分析型应用。 ● 数据挖掘模型是一个静态模型，经常用于根据数据过去的行为预测未来的行为。数据挖掘是一个术语，意指服务于不同目的的统计技术或算法的不固定的(经常改变的)集合。主要包括聚类、决策树、神经网络和预测。Analysis Services数据挖掘是数据挖掘工具的一个例子。 ● 即席查询由用户即时创建，维度模型方法被认为是支持即席查询的最好技术，因为简单的数据库结构易于理解。Microsoft Office，特别是Excel Pivot表是市场上最流行的即席查询工具，可以使用Reporting Services Report Builder来执行即席查询和简单的报表定义。然而，许多系统为它们的超级用户增加了第三方的即席查询工具来作为对Excel和Report Builder的补充。 ● 此外，数据仓库/商业智能(DW/BI)系统包括：源系统摘要，ETL，既是关系型又是OLAP的维数据库，BI应用以及即席查询工具。DW/BI系统也包括了管理工具和实践，面向用户的文档和培训，一个安全系统以及其他我们将在本书中讨论的成员。 0.2.3 角色和职责 DW/BI系统在生命周期中需要一定数目的不同的角色和技能，这些技术和技能可能来自业务和技术领域。在本部分中，我们将回顾和创建DW/BI系统有关的主要角色，在角色和人之间一般没有一个一对一的关系。我们和不同团队合作过，这些团队小到只有1个人，大到有40个人(听说有更大的)，大部分DW/BI团队在3~7个全职成员之间，并且根据需要可以增加其他人。 单个DW/BI团队承担开发和操作的责任是很常见的，这不同于大部分技术项目团队，而且和DW/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项目开发周期的后期阶段起一定的作用，当团队进入部署和操作系统的阶段时，一部分这些角色属于严格操作型的。 ● 数据干事负责保证数据仓库中的数据是精确的。 ● 安全经理规定业务用户需要的新的用户访问角色。以及增加用户到现有的角色中，安全经理也决定了DW/BI系统的ETL后备室中的安全过程。 ● BI门户目录经理管理BI门户。他决定了门户中的目录以及这些目录如何安排，如何保持最新。 ● DW/BI培训者创建和发布BI/DW系统的培训材料。 ● 关系数据库管理员(DBA)负责管理关系数据仓库数据库的性能和操作。 ● OLAP DBA负责管理OLAP数据仓库数据库的性能和操作。 ● 协调经理负责保证DW/BI的政策和操作遵循企业和常规的法令，如隐私权、HIPAA和Sarbanes-Oxley。协调经理和安全经理和Internet审核紧密联系。 ● 元数据经理决定了收集哪些元数据、放置在哪里以及如何将它们发布到业务领域。正如我们在第13章讨论的，元数据一般不用于管理，除非有专门的人负责。 ● 数据挖掘分析师对于业务很熟悉而且常常在统计学有一定的背景、数据挖掘分析师开发数据挖掘模型并和BI应用开发人员一起工作，设计使用数据挖掘模型的操作型应用。 ● DW/BI团队的用户支持人员必须能够帮助业务用户，特别是即席查询访问。企业范围的帮助似乎并没有特别必要的技术，只需要帮助解决连接问题。 0.3 本书内容 我们已经将本书分为五个部分： I. 需求、实施和体系结构； II. 开发和填充数据库； III. 商业智能应用程序的开发； IV. DW/BI系统的部署和管理； V. DW/BI系统的扩充。 第I部分：需求、实施和体系结构 第I部分为本书的其余部分奠定基础。大部分人渴望了解Microsoft工具集。虽然这对于试验和了解这个技术是很好的，但对于项目来说却是死神之吻。停下来，离开键盘，思考您将要做的事。 第1章：定义业务需求 本书从业务维度生命周期的简要概述开始，对每个重要的步骤进行了深入讨论，收集业务需求，然后简要地为贯穿本书使用的Adventure Works Cycles案例研究呈现业务需求。第1章引用了图0-1中的业务需求定义方框。 非常熟悉Kimball Method的读者可以跳过第I部分的内容，但必须学习案例研究。 第2章：业务过程维度模型设计 本章提供了如何开发维度模型的简要介绍，还提供了贯穿本书使用的一些术语和概念，理解这些材料将是很重要的。本章引用了图0-1中的维度建模方框。 对于熟悉Kimball Method的读者可以略过大部分材料，然后在本章的最后回顾Adventure Works案例研究。 第3章：工具集 体系结构和产品选择的任务对于一个Microsoft DW/BI系统是很直接的。在这个简短的章节中，我们将详细讨论如何使用以及在何处使用SQL Server 2005的不同组件与其他Microsoft产品，以及在何处使用系统中的第三方软件。本章提供了图0-1中的技术体系结构设计和产品选择和安装方框。 即使对于SQL Server 2000非常熟悉的读者也应该复习本章，因为它包含了有关SQL Server 2005新特征的信息，其中一些是非常独特的。 第Ⅱ部分：开发和填充数据库 本书的第Ⅱ部分提供了有效地构建和填充数据仓库数据库的必要步骤。大部分Microsoft DW/BI系统既以关系数据库实现维数据仓库又以Analysis Services数据库实现维数据仓库。 第4章：设置和物理设计 第4章描述了如何安装和配置SQL Server 2005的不同产品、我们讨论了系统规模和配置，以及如何操作和为什么操作，要选择在多个服务器间分发DW/BI系统。 关系数据库中的物理数据模型应该和第2章我们讨论过的维度模型几乎相同，有一些物理设计的问题要考虑，特别是是否要划分事实表。您也要为关系数据库开发最初的索引计划。 第4章专注于图0-1中的产品选择和安装方框，和物理设计方框，但不会结束讨论。Analysis Services的物理设计问题将延迟到第7章讨论。 第5章：设计ETL系统 DW/BI系统的ETL部分常常是一个设计的难点。本章首先引入了SQL Server 2005的新的ETL技术：Integration Services。然后讨论了如何编写ETL系统的设计规范。第5章和第6章覆盖了图0-1中的ETL设计和开发方框的大部分任务，尽管在本书中我们将多次回顾这些问题。 第6章：开发ETL系统 最后可以开始移动数据了。本章讨论了Integration Services中ETL系统的基本设计，我们将详细讨论加载维表，从加载一个简单表的详细示例开始。本章并不是一个指南，然而，我们很快就可以加快速度，讨论关键的维管理问题，例如代理键分配和属性变化管理。 其次，我们解释了如何加载事实表。举例说明了代理键管道并讨论了一些高级的主题，如维护快照事实表和处理迟到数据。 第7章：设计Analysis Services OLAP数据库 我们建议Microsoft DW/BI系统使用Analysis Services作为主要的数据库来让用户查询。关系数据库和ETL过程设计得越满足您的业务需求，设计Analysis Services数据库也就越简单。Analysis Services包括许多构建一个在构造很差的数据库之上的OLAP数据库，但结果将会更好，如果您遵循我们的指令，并且有一个整洁的和一致的关系数据仓库作为OLAP数据库的起点。 Analysis Services向导在一个小型系统中很容易使用，您不必担心高级设置。然而，如果您有大量的数据或者许多用户，就需要对OLAP引擎有一个深入的了解。本章的许多部分主要帮助您了解更多跨企业实现Analysis Services的内容。 Analysis Services章节采用了图0-1中的物理设计方框和ETL设计和开发方框，但这次是从OLAP数据库引擎的角度。 第Ⅲ部分：商业智能应用程序的开发 本书的第Ⅲ部分呈现了提供数据给业务用户的必要步骤。我们从清晰地定义BI应用程序开始，然后讨论如何使用Reporting Services来发布预定义报告的初始集合。 数据挖掘通过寻找数据中的隐藏关系和趋势可以将大量值发布到您的业务中。第10章讨论了如何使用 Analysis Services来构建数据挖掘模型。 第8章：商业智能应用程序 一些人似乎认为开发数据仓库起始于和结束于第Ⅱ部分“开发和填充数据库”，但请记住数据仓库的定义：它是通向用户屏幕的完全系统。您是在构建DW/BI系统而不仅仅是数据库。我们强烈反对您略过生命周期的第Ⅰ部分的早期阶段，您开发的数据库将不会很有用，相似地，您应该在第Ⅲ部分发布一些应用程序，否则业务用户不能使用系统。 大部分DW/BI系统的用户简单地接受预定义的报告。他们不会创建新的报告，更不会执行系统中的复杂分析。作为替代，他们将运行和复习报告，这些报告可能是使用picklist的带参数的报告。您需要提供一个当系统运行时一个相对完整的报告集合，更经常地，这些报告在BI门户处发送。 另一种BI应用程序是分析型应用程序。一个分析型应用程序以一个特定的业务过程为中心，并封装了一定数量的关于如何分析和解释业务过程的领域知识。甚至可以包括复杂的、基于代码的算法或者帮助识别潜在问题或机会的数据挖掘模型。第8章讲述了图0-1中BI应用程序规范方框的任务。 第9章：在Reporting Services中构建BI应用程序 在本章中，我们从描述用于开发和发布系统报告的标准开始，然后讨论SQL Server Reporting Services如何满足这些标准。在线文档在为您显示如何创建简单报告方面做得很好，所以我们将注意力集中在更困难的问题上。我们将带您从关系数据库中创建相对复杂报告的实例，并展示如何从Analysis Services中获得一个相似的报告。 第9章和第10章描述了图0-1中BI 应用程序开发方框的任务。 第10章：数据挖掘的加入 数据挖掘可以说是BI工具箱中最强大也是最容易理解的工具。本章定义了数据挖掘，然后提供了如何使用它的示例。我们讨论的是Microsoft的数据挖掘技术，也包括包含在SQL Server Analysis Services中的算法。我们提供了实践性的指导如何构造数据挖掘模型以及如何将挖掘结果合并到您的系统中。为了使理论上的讨论更加具体，我们将浏览两个案例研究。 第Ⅳ部分： DW/BI系统的部署和管理 本书的第Ⅳ部分包含了如何部署和操作DW/BI系统的信息。 第11章：使用现有的数据仓库进行工作 尽管本书的主要读者是开发新系统的DW/BI项目团队，但也并非总是如此。本章描述了如何使用现有的系统，首先将评估当前系统哪些可以运行哪些不能运行。 我们讨论了如何将SQL Server 2000 DW/BI系统升级到SQL Server 2005，并且强烈建议大部分成员需要有选择性地重写而不是升级SQL Server技术。这样设计在异构环境中运行得很好，强调了那些在异构环境中不如在整个SQL Server实现环境下运行得好的相对较新的特征。 第11章并没有和图0-1中的任何一个方框完全匹配，尽管和顶部的技术轨迹很接近。 第12章：安全 我们通过鼓励您开发一个信息的公开访问策略来开始我们对DW/BI系统安全的讨论。敏感数据当然需要保护，但我们认为大部分经验证过的用户都应该可以访问数据仓库的大部分内容。 验证是一个重要的概念，只有验证过的用户可以访问系统，这点很重要。访问控制从物理服务器开始，如果任何人可以进入服务器房间并能直接访问机器，设定一个复杂的安全系统就没有什么意义。 意识到并不是每个人都可以实现一个公开的安全策略，我们描述了如何控制对SQL Server不同成员，也就是Reporting Services、关系数据库和Analysis Services的访问，也讨论了数据仓库后备开发中独立的安全问题。 安全的讨论和图0-1中部署方框和维护方框关联最紧密。 第13章：元数据 许多人都讨论过元数据，我们也看到了它被彻底实现和成功实现的示例。我们当然希望在Microsoft SQL Server 2005 中看到集成的元数据服务，我们可以为您简单描述集成的元数据服务，但那并不是问题所在。本章花了大量篇幅详细讨论了元数据，因为我们认为这是最重要的，接着我们描述了维护和发布元数据信息的步骤。 元数据和图0-1中的部署方框和维护方框关联。 第14章：部署 部署DW/BI系统包含两个主要的任务集。首先需要部署整个系统。这个任务主要包括测试数据、过程、性能以及部署脚本本身。部署脚本应该包括一个小册子，一步一步地指导您如何部署系统变化。 另一个主要的开发行为专注于业务用户而不是技术。您需要开发和发布培训和文档材料，需要将第8章和第9章描述的BI门户放在一起，然后需要开发一个业务用户支持计划，因为这些业务用户不可避免地会存在一些问题。 第15章：操作和维护 当业务用户开始使用数据仓库来回答常见问题时，他们开始依赖它。如果用户认为数据仓库不可靠，他们将回到原来的获取信息的方式。这种依赖性是一种信任，您必须尽您所能保持这种信任。您需要监控数据加载和用户查询的使用率和性能，追踪系统资源并确保不会用光磁盘空间。简而言之，若要像产品系统一样维护数据仓库，您必须时刻注意加载到数据仓库的数据质量。一旦业务用户对数据的精确性失去了信任，那种信任几乎是不可能恢复的。我们需要特别注意在第14章讨论的培训、文档、BI门户、报告和系统支持。 第Ⅴ部分：扩展DW/BI系统 Kimball Method的一个关键特征就是DW/BI系统开发是迭代的。从最有价值的业务过程开始，然后一直循环引入数据来支持额外的业务过程。 第16章：管理增长 维护是一个重要的任务而不只是临时的任务。增长数据仓库的本质是向业务中增加值。数据仓库中的业务信息越多，它就变得越有价值。 在业务和信息系统管理之间有一个常见的误解：开发一个数据仓库和大部分系统项目一样需要完成大量前端的开发任务，还要完成一些临时的小型维护任务。这是不正确的，因为数据仓库生命周期是一个迭代的过程，一旦完成了最高优先级的业务过程主题域，您就要开始下一个最重要的主题域，重新经历整个生命周期。一般地，数据仓库团队并不会离开。事实上，在最初时先后有更多的维护和增长数据仓库的工作要做。我们在第16章将谈论长期的维护和增长问题。 第17章：实时商业智能 第17章的主题是实时商业智能，讨论如何将实时数据——一般定义为比每天刷新更频繁的数据，引入DW/BI系统中。SQL Server 2005包含了许多特征来支持实时商业智能，我们将更多地讨论如何使用这些特征以及在实现实时BI时面临的不可避免的代价。 第18章：提出规则和未来展望 第18章回顾了DW/BI项目的主要阶段并强调了最大的风险也就是项目的成功所在。本章最后还介绍了Microsoft BI工具集即将具有的特征和功能。 0.4 补充信息 本书包含了使用SQL Server 2005成功构建和部署一个基本的DW/BI系统所需要的大部分信息，为了保持本书足够小得可以放进背包中，我们并没有复制可以在SQL Server 2005联机丛书中可以很容易找到的工具的指令。在合适的地方我们提供了帮助寻找相关材料的搜索主题。在许多地方，我们建议您在期望完全理解某些技术材料之前阅读SQL Server自带的指南。 本书并没有试图讲授数据仓库的基础知识。我们总结了许多概念和技术而不是将所有细节包含进来，这些概念和技术的细节可以在Kimball Data Warehouse Toolkit 系列的其他书籍中找到。我们也在需要的地方提供了那些书籍关键部分的参考。表0-1显示了Toolkit系列的关键书籍，它们主要关注的内容以及主要面向的读者。 这些书封装了Kimball Group 关于数据仓库和商业智能的集体智慧，我们建议您将这些书增加到团队的库中。 我们已经将本书和一些技巧、关键概念、其他选项和章节指针联系在一起来使得它更有用，更便于参考。我们将关注其中一些具有如下格式的部分。 参考： 将可以使用的其他材料的参考点来补充到您的DW/BI库中。这包括SQL Server联机丛书、Kimball Group Toolkit书籍、其他书籍和文章以及参考材料的引用。 注意： 该部分提供了正在讨论的主题的一些额外信息以及澄清材料的解释或细节，参见表0-1。 表0-1 核心Kimball 数据仓库工具集标题 标 题 主 题 主 要 读 者 The Data Warehouse Lifecycle Toolkit 实现指导 所有项目参与者的很好概述；项目经理、业务分析师和数据建模人员的关键工具 The Data Warehouse Toolkit, Second Edition 维数据建模 数据建模人员、业务分析师、DBA、ETL开发人员 The Data Warehouse ETL Toolkit ETL系统架构 ETL架构师和开发人员 提示： 该部分提供了可以使您的工作更有效的捷径或线索。 警告： 该部分帮助您避免花费时间、数据或脑力的潜在危险。 0.5 Web站点 在本书的Web站点：我们提供了收集到的大部分列表和示例，Web站点的内容在中也可以找到。