| 商家名称 | 信用等级 | 购买信息 | 订购本书 |
 |
 |
Microsoft数据仓库工具箱(第2版):使用SQL Server 2008 R2和Microsoft BI工具集 [平装] |  |
 |
|
Microsoft数据仓库工具箱(第2版):使用SQL Server 2008 R2和Microsoft BI工具集 [平装] | |
![Microsoft数据仓库工具箱(第2版):使用SQL Server 2008 R2和Microsoft BI工具集 [平装]](http://img.reader8.com/uploadfile/2014/0222/20140222024438956.jpg)
《Microsoft数据仓库工具箱(第2版):使用SQL Server 2008 R2和Microsoft BI工具集》描述如何使用Microsoft SQL Server产品集设计并构建一个成功的商业智能系统及其底层的数据仓库数据库。
作者：（美国）蒙迪（Joy Mundy） （美国）桑思韦特（Warren Thornthwaite） （美国）金博尔（Ralph Kimball） 译者：包战 孔祥亮
蒙迪（Joy Mundy），在斯坦福大学、WebTV和Microsoft SQL Server产品研发小组中一直关注DW／BI系统。Joy在塔夫茨大学获得经济学学士学位，然后在斯坦福大学获得工程经济系统硕士学位。
桑思韦特（Warren Thornthwaite），自1980年起就开始了DW／BI生涯。在离开Metaphor咨询公司后，他为斯坦福大学和WebTV工作。Warren从密西根州立大学获得传媒学的学士学位，从宾夕法尼亚州的沃顿商学院获得决策学的MBA学位。
金博尔（Ralph Kimball），Kimball Group的创立者，自从20世纪80年代中期开始，他就是DW／BI行业中维度方法的思想领袖，培训了10000多名IT专业人员。他曾在Metaphor工作过，创立了Red Brick Systems，之后在Xerox的Palo Alto Research Center（PARC）工作时还与其他人一起创立了星型工作站。Ralph获得了斯坦福大学的电气工程博士学位。
第Ⅰ部分 需求、现实情况和体系结构
第1章 定义业务需求
1.1 长期成功的最重要的决定因素
1.2 Adventure Works Cycles简介
1.3 揭示业务价值
1.3.1 获得赞助商关系
1.3.2 定义企业级业务需求
1.4 设定业务需求的优先级
1.5 项目规划
1.6 收集项目需求
1.7 小结
第2章 业务过程维度模型设计
2.1 维度建模概念和术语
2.1.1 事实表
2.1.2 维度
2.1.3 整合事实和维度
2.1.4 总线矩阵、一致性维度和交叉探查
2.2 其他设计概念和技术
2.2.1 代理键
2.2.2 渐变维度
2.2.3 日期
2.2.4 退化维度
2.2.5 雪 花模型
2.2.6 多对多维度或多值维度
2.2.7 层次结构
2.2.8 聚合维度
2.2.9 无意义维度
2.2.103种事实表类型
2.2.11 聚合
2.3 维度建模过程
2.3.1 准备工作
2.3.2 数据剖析和研究
2.3.3 构建维度模型
2.3.4 开发详细维度模型
2.3.5 模型测试和细化
2.3.6 评审和验证模型
2.4 案例研究：Adventure Works cvcles订单维度模型
2.4.1 订单事实表
2.4.2 维度
2.4.3 确定订单业务过程的维度属性和事实
2.4.4 初始订单模型的最终草图
2.4.5 详细订单维度模型开发
2.4.6 最终的维度模型
2.5 小结
第3章 工具集
3.1 Microsoft DW／BI工具集
3.2 使用Microsoft工具集的原因
3.3 Microsoft DW／BI系统的体系结构
3.3.1 包含Analysis Services的原因
3.3.2存储在关系数据库中的原因
3.3.3 ETL不是可选的
3.3.4 Master DataServices的作用
3.3.5 交付BI应用程序
3.4 Microsoft工具概述
3.4.1 需要的产品
3.4.2 SQL Server开发和管理工具
3.5 小结
第4章 系统设置
4.1 系统规模的考虑事项
4.1.1 计算数据卷
4.1.2 确定应用复杂度
4.1.3 估计并发用户数
4.1.4 评估系统可用性需求
4.1.5 系统的规模
4.2 系统配置考虑事项
4.2.1 内存
4.2.2 一体化还是分布式
4.2.3 存储系统考虑事项
4.2.4 处理器
4.2.5 高可用性设置
4.3 软件安装和配置
4.3.1 开发环境的软件需求
4.3.2 测试和产品系统的软件需求
4.3.3 操作系统
4.3.4 SQL Server关系数据库设置
4.3.5 Analysis Services设置
4.3.6 Integration Services设置
4.3.7 Reporting Services设置
4.4 小结
第Ⅱ部分建立和填充数据库
第5章 创建关系数据仓库
5.1 开始
5.2 完成物理设计
5.2.1 代理键
5.2.2 字符串列
5.2.3 空或非空
5.2.4 常规事务列
5.2.5 数据表和列的扩展属性
5.3 定义存储器并创建约束和支持对象
5.3.1 创建文件和文件组
5.3.2 数据压缩
5.3.3 实体和引用完整性约束
5.3.4 初始索引和数据库统计
5.3.5 聚合表
5.3.6 创建数据表视图
5.3.7 插入未知成员行
5.3.8 CREATE TABLE语句示例
5.4 分区表
5.4.1 分区表的工作方式
5.4.2 管理分区表
5.5 收尾
5.5.1 中间表
5.5.2 元数据设置
5.6 小结
第6章 主数据的管理
6.1 管理主引用数据
6.1.1 属性不完整
6.1.2 数据集成
6.1.3 系统集成
6.1.4 主数据管理系统和数据仓库
6.2 SQL Server主数据服务
6.2.1 模型定义功能
6.2.2 数据管理功能
6.3 创建简单的应用程序
6.3.1 业务场景
6.3.2 尽可能简单
6.3.3 创建。MDS模型
6.3.4 加载子类别成员
6.3.5 改进模型
6.3.6 导出到数据仓库
6.4 小结
第7章 设计和开发ETL系统
7.1 确定需求
7.2 制定ETL计划
7.3 SQL Server Integration Services概述
7.3.1 控制流和数据流
7.3.2 SSIS程序包的体系结构
7.4 ETL的主要子系统
7.5 提取数据
7.5.1 子系统1：数据剖析
7.5.2 子系统2：更改数据捕获系统
7.5.3 子系统3：提取系统
7.6 清理和一致化数据
7.6.1 子系统4：数据清理系统
7.6.2 子系统5：错误事件模式
7.6.3 子系统6：审核维度汇编器
7.6.4 子系统7：重复数据删除系统
7.6.5 子系统8：一致化系统
7.7 传递数据以用于展示
7.7.1 子系统9：渐变维度管理器
7.7.2 子系统10：代理键生成器
7.7.3 子系统11：层次结构管理器
7.7.4 子系统12：特殊维度管理器
7.7.5 子系统13：事实表构建器
7.7.6 子系统14：代理键管道
7.7.7 子系统15：多值维度桥接表构建器
7.7.8 子系统16：迟到数据的处理程序
7.7.9 子系统17：维度管理器
7.7.10 子系统18：事实提供程序系统
7.7.11 子系统19：聚合构建器
7.7.12 子系统20：OLAP多维数据集构建器
7.7.13 子系统21：数据传播管理器
7.8 管理ETL环境
7.9 小结
第8章 核心Analysis Services OLAP数据库
8.1 Analvsis Services OLAP概述
8.1.1 使用.Analysis Services的原因
8.1.2 不使用Analysis Services的原因
8.2 设计OLAP结构
8.2.1 规划
8.2.2 起始工作
8.2.3 创建项目和数据源视图
8.2.4 维度设计
8.2.5 创建和编辑维度
8.2.6 创建和编辑多维数据集
8.3 物理设计的考虑因素
8.3.1 理解存储模式
8.3.2 分区计划
8.3.3 设计性能聚合
8.3.4 部署计划
8.3.5 处理整个多维数据集
8.3.6 开发增量处理计划
8.4 小结
第9章 实时商业智能的设计需求
9.1 实时分类
9.1.1 实时的含义
9.1.2 需要实时的人员
9.1.3 对实时的权衡
9.2 场景和解决方案
9.2.1 实时地执行报表
9.2.2 通过缓存向报表提供服务
9.2.3 用镜像和快照创建ODS
9.2.4 用复制功能创建ODS
9.2.5 建立BizTalk应用程序
9.2.6 建立实时关系分区
9.3 小结
第Ⅲ部分 商业智能应用程序的开发
第10章 在Reporting Services中构建BI应用程序
10.1 BI应用程序概述
10.2 商业智能应用程序的价值
10.3 报表设计高层次的体系结构
10.3.1 回顾报表设计的业务需求
10.3.2 Reporting Services的体系结构
10.3.3 使用Reporting Services作为标准的报表设计工具
10.3.4 Reporting Services的评价
10.4 报表设计系统的设计和开发过程
10.4.1 报表设计系统的设计
10.4.2 报表设计系统的开发
10.5 报表的构建和传送
10.5.1 规划和准备
10.5.2 创建报表
10.5.3 报表设计的运行
10.6 即席报表设计选项
10.6.1 报表模型
10.6.2 共享数据集
10.6.3 报表部件
10.7 小结
第11章 PowerPivot和Excel
11.1 使用Excel进行分析和报表设计
11.2 PowerPivot体系结构
11.3 创建和使用PowerPivot数据库
11.3.1 开始使用PowerPivot
11.3.2 PowerPivot表的设计
11.3.3 使用PowerPivot创建分析表
11.3.4 PowerPivot for Excel的观察和指导原则
11.4 PowerPivot for SharePoint
11.4.1 PowerPivot SharePoint用户体验
11.4.2 服务器级别的资源
11.4.3 PowerPivot的监控和管理
11.5 PowerPivot在托管DW／BI环境下的作用
11.6 小结
第12章 BI门户和SharePoint
12.1 BI门户
12.1.1 BI门户的规划
12.1.2 对设计的影响
12.1.3 业务过程的类别
12.1.4 额外的功能
12.1.5 建立BI门户
12.2 把SharePoint用作BI门户
12.2.1 体系结构和概念
12.2.2 安装SharePoint
12.2.3 安装测试系统
12.2.4 完成BI门户
12.2.5 BIPortal站点模板的其他功能
12.2.6 研究SharePoint
12.3 小结
第13章 数据挖掘的加入
13.1 数据挖掘的定义
13.1.1 基本的数据挖掘术语
13.1.2 数据挖掘的业务应用
13.1.3 角色和责任
13.2 SQL Server数据挖掘体系结构概述
13.2.1 数据挖掘设计环境
13.2.2 构建、部署和处理
13.2.3 挖掘模型的访问
13.2.4 Integration Services和数据挖掘
13.2.5 其他功能
13.2.6 体系结构的总结
13.3 Microsoft数据挖掘的算法
13.3.1 决策树
13.3.2 Naive Bayes算法
13.3.3 群集
13.3.4 顺序群集
13.3.5 时间序列
13.3.6 关联
13.3.7 神经网络
13.4 数据挖掘的过程
13.4.1 业务阶段
13.4.2 数据挖掘阶段
13.4.3 操作阶段
13.4.4 元数据
13.5 数据挖掘的示例
13.5.1 案例研究：给城市分类
13.5.2 案例研究：产品推荐
13.6 小结
……
第Ⅳ部分 DW/BI系统的部署和管理
版权页： 
插图： 
Albert Einstein指出了使用维度模型的主要原因：能使任何事情尽可能简单，但绝不是简化。结果证明，简单是相对的。人们普遍认为，在数据仓储和商业智能中，维度模型是给用户显示信息的首选结构。维度模型比典型的源系统规范化模型更便于用户理解，即使维度模型所包含的内容与规范化模型完全一致也是如此。维度模型中的表更少，信息分组为对用户有意义的、一致的业务类别。这些类别称为维度，有助于用户浏览模型，因为可以忽略与特定分析无关的全部类别。
但是，尽可能简洁并不意味着模型一定简单。模型必须反映业务，而业务通常都比较复杂。如果简化得过多，一般来说只表示了聚合数据，模型就会丢失对理解业务非常重要的信息。无论如何进行数据建模，数据内容内在的复杂性都使大多数人最终愿意通过结构化报表和分析应用程序来访问DW／BI系统。
要达到第二个目标，即良好的性能，可能更需要依赖平台。在关系环境下，维度模型能提供更好的查询性能，这是因为在创建维度时采用了反规范化的方法。通过预先连接各种层次结构和查询表，优化程序考虑的连接路径较少，创建的中间临时表也更少。通过采用维度结构而不是完全规范化的结构，SQL Server关系数据库的分析查询性能会更好——通常会好得多。从更基本的层面上看，优化程序可以识别出维度模型，并利用其结构大幅度减少返回的行数。这称为“星型连接优化”，当然这也是企业版的功能。
在Analysis Service OLAP环境下，专门把引擎设计成支持维度模型，主要通过在维度之内和之间进行预聚合来提高性能。
达到第三个目标需要采用各种设计模式，以创建出精确捕获和跟踪业务的模型。下面从最基本的模式开始。维度模型由一个或者多个中心事实表和与其相关的维度构成。事实表位于中心，而维度环绕在其周围，类似于星型结构，因此又把维度模型称为星型模式。为避免混淆，本书始终使用维度模型这一术语。
从关系数据建模的角度来看，维度模型是由一个规范化的事实表和反规范化的一些维度表组成的。本节将定义维度模型、事实表和维度等基本组成部分，以及在处理随时间而发生的改动时涉及的一些重要概念。
2.1.1 事实表
每个事实表都包含与特定业务过程相关的度量，例如下一个订单，显示一个网页，接待一位患者或者处理一个顾客的服务请求。事实表中的一条记录是一个度量事件，这些事件通常有数字值，用来量化大量的事件，如订购的数量、销量或呼叫持续时间等。这些数字称为事实（或在Analysis Services中称为度量）。
事实表的键通常是多部分的键，由业务事件涉及的每个维度表的外键子集构成。
1.事实
大多数事实都是数字型的，且可以累加（如总销量或单位销量），这意味着可以对所有维度求和。可加性很重要，因为DW／BI应用程序很少检索单个事实表记录。用户查询一般一次选择数百或数千条记录并合计。查询去年每个月的销售量仅返回12行结果，但它合计了成千上万行（或者更多）。一些事实具有半可加性（如市场份额或账目结算），一些事实则具有非可加性（如单价等）。
并非所有的数字型数据都是事实，包括离散的描述信息，例如用来描述产品的包装尺寸或重量，以及用来描述商店面积的平方英尺。通常这些不大变化的数字值是维度表中的描述性属性。这种描述信息自然也用来约束查询，而不是在计算中求和。决定将一个数据元素作为维度或事实的一部分时，这一区别是非常有用的。
一些业务过程跟踪没有任何实际度量的事件。如果发生这种事件，源系统就添加一项，反之源系统就没有任何记录。这类事件的常见示例有雇佣活动，例如聘用或者解雇某个雇员；参与事件的人数，例如学生何时加入某个班级等。跟踪这类事件的事实表没有任何实际度量值，因此也称为没有事实的事实表。通常的做法是向表中添加一列，该列称为EventCount，并且包含数字1。这就为用户提供了一种统计事件数量的简便方法，即通过累加EventCount事实来实现。
有些事实是从其他事实派生或计算得到的，如纯收入是从销售总额减去营业税后得到的。一些半可加性的事实可以使用基于查询上下文的派生列来处理，例如月底结算是累加多个账户，而不是对日期进行累加。对于非可加性的单价，可以把它定义为平均单价，即Total Amount（总额）除以Total Quantity（总数量）。有几种方法可以处理这种派生或计算得到的事实。可以把它们作为ETL过程的一部分计算，并在事实表中存储：也可以把它们存储在事实表的视图定义里；还可以把它们包含在Analysis Services数据库的定义中。唯一不能接受的方式是把这一过程留给用户处理。
喜欢Microsoft数据仓库工具箱(第2版):使用SQL Server 2008 R2和Microsoft BI工具集 [平装]请与您的朋友分享,由于版权原因，读书人网不提供图书下载服务
