1.1. 理解需求
1.1.1. 构建一个数据仓库与开发一套业务系统不同
1.1.2. 业务系统的开发取决于精确的、具体的业务需求
1.1.3. 数据仓库建设则是把数据汇集在一起，再以各种不同的方式使用这些数据
1.1.4. 要考虑业务目标和业务战略，确定业务领域并框定范围
1.1.5. 确定并对相关的业务人员进行访谈，了解他们想做些什么和这么做的原因，记录他们当下关心的具体问题和想要询问的数据
1.2. 定义和维护数据仓库/商务智能架构
1.2.1. 确定数据仓库/商务智能技术架构
1.2.1.1. 最佳的数据仓库/商务智能架构将提供一种能够以原子化的数据处理方式支撑交易级和运营级报表需求的机制，这种机制可以避免数据仓库存贮每一笔交易细节
1.2.1.2. 概念模型架构是一个起点，要将非功能需求和业务需求很好地结合起来，许多活动是必要的
1.2.2. 确定数据仓库/商务智能管理流程
1.2.2.1. 通过协调和集成维护流程进行生产管理，定期向业务团队发布
1.2.2.2. 建立一个有效的发布流程，确保管理层理解这是一个以数据产品为中心的主动流程，而不是已安装产品的被动式问题解决方式
1.3. 开发数据仓库和数据集市
1.3.1. 数据
1.3.1.1. 支持业务分析所必需的数据。这条轨迹涉及识别数据的最佳来源，设计如何修正、转换、集成、存储以及提供给应用程序使用数据的规则
1.3.2. 技术
1.3.2.1. 支持数据存储和迁移的后端系统及流程。与现有企业系统的集成是必需的，因为数据仓库本身并不是一个孤岛
1.3.3. 商务智能工具
1.3.3.1. 数据消费者从已部署的数据产品中获得有意义的数据洞察所必需的应用套件
1.3.4. 将源映射到目标
1.3.4.1. 源到目标的映射为从各个源系统到目标系统的实体和数据元素建立转换规则
1.3.5. 修正和转换数据
1.3.5.1. 强化数据修正或清理活动的执行标准，并纠正和增强各个数据元素的域值
1.3.5.2. 数据转换重点关注技术系统中实现业务规则的活动，数据转换对数据集成至关重要
1.4. 加载数据仓库
1.4.1. 工作量最大的部分都是数据准备和预处理
1.4.2. 确定加载方法时要考虑的另一个因素是围绕变更数据捕获的过程检测源系统中的数据变更，将这些变更集成在一起，并依时间调整变更
1.4.3. 第一个增量为额外的功能开发和新业务团队的使用铺平了道路
1.5. 实施商务智能产品组合
1.5.1. 实施商务智能组合是为了在业务部门内部或业务部门之间为正确的用户社区选定合适的工具，通过协调常见业务流程、性能分析、管理风格和需求找到相似之处
1.5.2. 根据需要给用户分组
1.5.3. 将工具与用户要求相匹配
1.5.4. 套件是企业架构级别的主要选择，但鉴于大多数组织已经购买了单独的工具或者已经采用了开源工具，关于替换还是共存的问题将会浮出水面
1.5.5. 每个BI工具都需要付出代价，需要系统资源、技术支持、培训和架构集成
1.6. 维护数据产品
1.6.1. 发布管理
1.6.1.1. 发布管理对增量的开发过程至关重要，增加新功能，增强生产部署，并确保为已部署的资产提供定期维护
1.6.2. 管理数据产品开发生命周期
1.6.2.1. 当数据消费者正在使用现有的数据仓库时，数据仓库团队正在为下一次迭代做准备，同时他们理解并非所有项目都会投产
1.6.2.2. 新的数据产品只有通过试点项目，并被业务和IT代表视为已做好生产准备，才可以投入生产
1.6.3. 监控和调优加载过程
1.6.3.1. 监控整个系统的加载处理，并了解性能瓶颈和性能的依赖路径
1.6.3.2. 在需要的地方和时刻使用数据库调优技术，包括分区、备份调优和恢复策略调整
1.6.3.3. 数据归档是数据仓库构建中的一个难题
1.6.4. 监控和调优商务智能活动和性能
1.6.4.1. 商务智能监控和调优的最佳实践是定义和显示一组面向客户满意度的指标，如平均查询响应时间，每天、每周或每月的用户数就是有用的指标
1.6.4.2. 定期审查使用情况的统计数据和使用方法非常重要
1.6.4.3. 提供数据、查询和报表的频率和资源使用情况的报告允许谨慎增强
1.6.4.4. 增加数据质量度量将提高此仪表板的价值，其中的性能不仅是速度和时间
2. 工具2.1. 工具集的选择可能是一个漫长的过程，既要满足近期需求、非功能性规范，还需要考虑尚未产生的后续需求
2.2. 元数据存储库
2.2.1. 大型组织经常会使用来自不同供应商的系统工具，每个工具都可能部署了不同的版本
2.2.2. 数据字典和术语
2.2.2.1. 数据字典是支撑数据仓库使用的必需组件
2.2.2.2. 字典用业务术语来描述数据，包括使用该数据所需的其他信息
2.2.3. 数据和数据模型的血缘关系
2.2.3.1. 许多数据集成工具提供血缘分析，既要考虑开发的总体代码，又要考虑物理数据模型和数据库
2.2.3.2. 用途
2.2.3.2.1. 调查数据问题的根本原因
2.2.3.2.2. 对系统变更或数据问题进行影响分析
2.2.3.2.3. 根据数据来源确定数据的可靠性
2.3. 数据集成工具
2.3.1. 数据集成工具用于加载数据仓库
2.3.2. 过程审计、控制、重启和调度
2.3.3. 在执行时有选择地提取数据元素并将其传递给下游系统进行审计的能力
2.3.4. 控制哪些操作可以执行或不能执行，并重新启动那些失败或中止的进程
2.4. 商务智能工具的类型
2.4.1. 商务智能工具市场很成熟，有各种各样可用的商务智能工具，因而企业很少会构建开发自己的商务智能工具
2.4.2. 运营报表
2.4.2.1. 是商务智能工具的应用，分析短期（月度）和长期（年度）的业务趋势
2.4.2.2. 运营报表指的是业务用户直接从交易系统、应用程序或数据仓库生成报表
2.4.2.3. 数据检索和报表工具，有时称为即席查询工具，允许用户编写自己需要的报表或创建供他人使用的报表
2.4.2.4. 传统的商务智能工具可以很好地展现表格、饼图、折线图、面积图、条形图、直方图、K线图等一些数据可视化方法
2.4.3. 业务绩效管理(BPM)
2.4.3.1. 包括对组织目标一致性的指标的正式评估，此评估通常发生在高管层面
2.4.3.2. 使用战略商务智能工具支持企业的长期目标
2.4.3.3. 绩效管理是一套集成的组织流程和应用程序，旨在优化业务战略的执行
2.4.4. 描述性的自助分析
2.4.4.1. 为前台业务提供的商务智能工具，其分析功能可指导运营决策
2.4.5. 运营分析应用
2.4.5.1. 在线分析处理(OLAP)是一种为多维分析查询提供快速性能的方法
2.4.5.2. OLAP这一术语在某种程度上源于对OLTP（在线交易处理）的明确区别
2.4.5.3. 构建数据立方体以提供所需的功能要求，可能需要将较大的维度拆分为单独的数据立方体，以适应存储、加载或计算要求
2.4.5.4. 在数据立方体中配置基于角色的安全性或多语言文本，可能需要额外的维度、附加功能、计算或创建单独的数据立方体结构
2.4.5.5. 切片(Slice)
2.4.5.5.1. 切片是多维数组的子集，对应不在子集中的维度的一个或多个成员的单个值
2.4.5.6. 切块(Dice)
2.4.5.6.1. 切块操作是数据立方体上两个以上维度的切片，或者是两个以上的连续切片
2.4.5.7. 向下/向上钻取(Drill down/up)
2.4.5.7.1. 向下钻取或向上钻取是一种特定的分析技术，用户可以在不同数据级别之间导航，范围从最概括（向上）到最详细（向下）
2.4.5.8. 向上卷积(Roll-up)
2.4.5.8.1. 卷积涉及计算一个或多个维度的所有数据关系
2.4.5.8.2. 需要先定义计算关系或公式
2.4.5.9. 透视(Pivot)
2.4.5.9.1. 透视图会更改报表或页面的展示维度
2.4.6. 三种经典的OLAP
2.4.6.1. 关系型联机分析处理(ROLAP)
2.4.6.1.1. ROLAP通过在关系数据库(RDBMS)的二维表中使用多维技术来支持OLAP
2.4.6.1.2. 星型架构是ROLAP环境中常用的数据库设计技术
2.4.6.2. 多维矩阵型联机分析处理(MOLAP)
2.4.6.2.1. MOLAP通过使用专门的多维数据库技术支持OLAP
2.4.6.3. 混合型联机分析处理(HOLAP)
2.4.6.3.1. 它是ROLAP和MOLAP的结合
2.4.6.3.2. HOLAP实现允许部分数据以MOLAP形式存储，而另一部分数据存储在ROLAP中
3. 方法3.1. 驱动需求的原型
3.1.1. 对数据进行剖析(Profiling)有助于原型设计，并降低与非预期数据相关的风险
3.2. 自助式商务智能
3.2.1. 自助服务是商务智能产品的基本交付方式
3.2.2. 通常会将用户活动放在受管门户中，根据用户的权限提供各种功能，包括消息传递、警报、查看预定的生产报表、与分析报表交互、开发即席查询报表，当然还有仪表盘和计分卡功能
3.2.3. 可视化和统计分析工具允许快速的数据探索和发现
3.3. 可查询的审计数据
3.3.1. 为了维系数据血缘关系，所有的结构和流程都应该能够创建和存储审计信息，并能够进行细粒度的跟踪和报告
4. 实施指南4.1. 对一个好的数据仓库项目来说，能扩展满足未来需求的稳定架构是很重要的
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.4. 配置管理
4.4.1. 配置管理与发布路线图保持一致，并提供必要的后台调整和脚本，以自动化开发、测试和发布到生产
4.5. 组织与文化变革
4.5.1. 业务倡议
4.5.1.1. 是否有合适的管理层支持？
4.5.2. 业务目标和范围
4.5.2.1. 是否有确切的业务需要、业务目标和工作范围？
4.5.3. 业务资源
4.5.3.1. 业务管理层是否承诺提供或聘用相应的业务专家，专家的参与度如何？
4.5.4. 业务准备情况
4.5.4.1. 业务合作伙伴是否准备好这是一个长期的增量交付项目？
4.5.5. 愿景一致
4.5.5.1. IT战略对业务愿景的支持程度如何？
4.5.5.2. 能力调整中的任何重大偏差或差距，都可能导致数据仓库/商务智能程序暂停或停止
5. 治理5.1. 治理流程应该降低风险，而不是减少任务的执行
5.2. 最关键的功能是那些管理业务运营的发现或改进区域，以及确保数据仓库本身质量稳定的功能
5.3. 将一次性或有限使用的事件视为生命周期的一部分，并且可能在试验区域内或在用户控制的“沙箱”区域内限制它们
5.4. 业务接受度
5.4.1. 一个关键的成功因素是业务对数据的接受程度，包括可以理解的数据、具有可验证的质量，以及具有可证明的数据血缘关系
5.4.2. 概念数据模型
5.4.3. 数据质量反馈循环
5.4.4. 端到端元数据
5.4.5. 端到端可验证数据血缘
5.5. 客户/用户满意度
5.5.1. 对数据质量的认识将提升客户满意度，但满意度也取决于其他因素，如数据消费者对数据的理解以及运营团队对已识别问题的响应能力
5.6. 服务水平协议
5.6.1. 对具体数仓环境的业务和技术期望应在服务水平协议(SLA)中指定
5.6.2. 响应时间、数据保留和可用性要求在不同业务需求类别及其各自的支持系统（如ODS、数据仓库和数据集市）之间存在很大差异
5.7. 报表策略
5.7.1. 安全访问
5.7.1.1. 确保只有获得授权的用户才能访问敏感数据
5.7.2. 描述用户交互、报告、检查或查看其数据的访问机制
5.7.3. 用户社区类型和使用它的适当工具
5.7.4. 报表摘要、详细信息、例外情况以及频率、时间、分布和存储格式的本质
5.7.5. 通过图形化输出发挥可视化功能的潜力
5.7.6. 及时性和性能之间的权衡
5.8. 数据源的治理监控也很重要，确保为授权人员安全地提供适当级别的数据，并且可以根据商定的级别访问订阅数据
6. 度量指标6.1. 使用指标
6.1.1. 数据仓库中使用的度量指标通常包括注册用户数、连接用户数或并发用户数
6.2. 主题域覆盖率
6.2.1. 主题域覆盖百分比衡量每个部门访问仓库的程度（从数据拓扑的角度来看），还强调哪些数据是跨部门共享的，哪些还不是但也可能是共享的
6.3. 响应时间和性能指标
6.3.1. 大多数查询工具会测量响应时间
6.3.2. 通过工具检索响应或性能指标
6.3.3. 此数据指标代表用户的数量和类型
6.3.4. 数据加载过程以原始格式收集每个数据产品的加载时间
6.3.5. 大多数工具将在日志或存储库中为提供给用户的对象保留查询和刷新记录及数据提取时间等
6.3.6. 将数据划分为计划执行的对象和已执行的对象，并将其表示为尝试和已成功访问的原始计数
