业务驱动因素
数据仓库（Data Warehouse， DW） 的概念始于20世纪80年代；20世纪90年代出现商务智能
数据仓库的主要驱动因素是：
支持运营职能
合规性需求
和商务智能（BI）活动
目标和原则
建设数据仓库的目标
1） 支持商务智能活动。
2） 赋能商业分析和高效决策。
3） 基于数据洞察寻找创新方法。
数据仓库建设应遵循如下指导原则：
1） 聚焦业务目标。 确保数据仓库用于组织最优先级的业务并解决业务问题。
2） 以终为始。 让业务优先级和最终交付的数据范围驱动数据仓库内容的创建。
3） 全局性的思考和设计， 局部性的行动和建设。 让最终的愿景指导体系架构， 通过集中项目快速迭代构建增量交付， 从而实现更直接的投资回报。
4） 总结并持续优化， 而不是一开始就这样做。 以原始数据为基础， 通过汇总和聚合来满足需求并确保性能， 但不替换细节数据。
5） 提升透明度和自助服务。 上下文（各种元数据） 信息越丰富，数据消费者越能从数据中获得更多数据价值。 向利益相关方公开集成的数据及其流程信息。
6） 与数据仓库一起建立元数据。 数据仓库成功的关键是能够准确解释数据。 能回答一些基本问题， 如“这个数字为什么是X”“这个怎么计算出来的”“这个数据哪里来的”。 元数据的获取应该作为软件开发周期的一部分， 元数据的管理也应该作为数据仓库持续运营的一部分。
7） 协同。 与其他数据活动协作， 尤其是数据治理、 数据质量和元数据管理活动。
8） 不要千篇一律。 为每种数据消费者提供正确的工具和产品
数据仓库
数据仓库有两个重要组成部分： 一个集成的决策支持数据库和与之相关的用于收集、 清理、 转换和存储来自各种操作和外部源数据的软件程序。
企业级数据仓库（EDW） 是集中化的数据仓库， 为整个组织的商务智能需求服务。
数据仓库建设的方法
Inmon把数据仓库定义为“面向主题的、 整合的、 随时间变化的、 相对稳定的支持管理决策的数据集合”[2]， 用规范化的关系模型来存储和管理数据。 而Kimball则把数据仓库定义为“为查询和分析定制的交易数据的副本”， 他的方法通常称作多维模型。
循的核心理念:
1） 数据仓库存储的数据来自其他系统。
2） 存储行为包括以提升数据价值的方式整合数据。
3） 数据仓库便于数据被访问和分析使用。
4） 组织建设数据仓库， 因为他们需要让授权的利益相关方访问到可靠的、 集成的数据。
5） 数据仓库数据建设有很多目的， 涵盖工作流支持、 运营管理和预测分析。
企业信息工厂（Inmon）
多维数据仓库（ Kimball）
数据仓库架构组件
源系统:源系统包括要流入数据仓库/商务智能环境的业务系统和外部数据。
数据集成:数据集成包括抽取、 转换和加载（此三者英文首字母缩写为E、T、 L， 通常直接这把三者称为ETL） 、 数据虚拟化以及将数据转换为通用格式和位置的其他技术。
数据存储区域:
数据仓库包含多个不同用途的存储区域：
暂存区。 暂存区是介于原始数据源和集中式数据存储库之间的中间数据存储区域。
参考数据和主数据一致性维度。 参考数据和主数据可以存储在单独的存储库中。
中央数据仓库。 完成转换和准备流程后， 数据仓库中的数据通常会保留在中央或原子层中。
数据结构的设计元素包括：
①基于性能考虑而设计的业务主键和代理主键之间的关系。
②创建索引和外键以支持维度表。
③用于检测、 维护和存储历史记录的变更数据捕获（Change DataCapture， CDC） 技术
操作型数据存储（ODS）
操作型数据存储是中央持久存储的一个解决方案， 它能支持较低的延迟， 因此可以支持业务应用。 由于操作型数据存储包含一个时间窗口的数据而不是全部历史记录， 因此可以比数据仓库有更快地刷新频率。
数据集市
数据集市是一种数据存储， 通常用于支持数据仓库环境的展示层， 还用于呈现数据仓库的部门级或功能级子集， 以便对历史信息进行集成报表、 查询和分析。 数据集市面向特定主题域、 单个部门或单个业务流程。
数据立方体（Cubes）
存在三种经典的支持在线分析处理系统（OLAP） 实现方法： 基于关系数据库的、 基于多维数据库的及混合型存储结构的， 它们的名称与底层数据库类型有关。
加载处理的方式
数据仓库建设涉及两种主要的数据集成处理类型： 历史数据加载和持续不断的数据更新。
历史数据
Data Vault， 作为数据暂存处理的一部分， 同样进行数据清洗和标准化。 历史数据以规范化的原子结构存储， 每个维度定义了代理键（Surrogate key） 、 主键（Primary key） 、 备用键（Alternate key） 。
批量变更数据捕获
准实时和实时数据加载
有涓流式加载、 消息传送和流式传送三种主要的替代方案
1） 涓流式加载（源端累积） 。 与夜间窗口批量加载不同， 涓流式加载是以更频繁的节奏（如每小时甚至每5分钟） 或者以阈值的方式（如每300个事务， 每1 G数据） 进行批量加载。
2） 消息传送（总线累积） 。 当极小的数据报（消息、 事件或事务） 发布到消息总线时， 实时或接近实时的消息交互就非常有用。 目标系统订阅消息总线， 并按需增量加载数据报到仓库中。
3） 流式传送（目标端累积） 。 与在源端定时或按阀值加载不同，目标端系统用缓冲区或队列方式收集数据， 并按顺序处理。
活动
开发数据仓库和数据集市
据仓库/商务智能建设项目有三条并存的构建轨迹：
1） 数据。 支持业务分析所必需的数据。 这条轨迹涉及识别数据的最佳来源， 设计如何修正、 转换、 集成、 存储以及提供给应用程序使用数据的规则。
2） 技术。 支持数据存储和迁移的后端系统及流程。 与现有企业系统的集成是必需的， 因为数据仓库本身并不是一个孤岛。
3） 商务智能工具。 数据消费者从已部署的数据产品中获得有意义的数据洞察所必需的应用套件。
将源映射到目标
源到目标的映射为从各个源系统到目标系统的实体和数据元素建立转换规则。
修正和转换数据
强化数据修正或清理活动的执行标准， 并纠正和增强各个数据元素的域值。
工具
元数据存储库
数据字典和术语
数据字典是支撑数据仓库使用的必需组件。 字典用业务术语来描述数据， 包括使用该数据所需的其他信息（如数据类型、 结构细节、 安全限制） 。
数据和数据模型的血缘关系许多数据集成工具提供血缘分析， 既要考虑开发的总体代码， 又要考虑物理数据模型和数据库。 有些工具通过提供Web界面监视、 更新模型定义及其他元数据信息。 记录的数据血缘关系有很多用途：、
1） 调查数据问题的根本原因。
2） 对系统变更或数据问题进行影响分析。
3） 根据数据来源确定数据的可靠性。
数据集成工具
数据集成工具用于加载数据仓库。 除了完成数据集成工作之外， 它们还可以将来自多个数据源的复杂数据交付以作业的方式进行调度。 在选择工具时， 还要考虑系统管理的如下功能：
1） 过程审计、 控制、 重启和调度。
2） 在执行时有选择地提取数据元素并将其传递给下游系统进行审计的能力。
3） 控制哪些操作可以执行或不能执行， 并重新启动那些失败或中止的进程
商务智能工具的类型
商务智能工具市场很成熟， 有各种各样可用的商务智能工具， 因而企业很少会构建开发自己的商务智能工具。
在线分析处理（OLAP） 是一种为多维分析查询提供快速性能的方法。 OLAP这一术语在某种程度上源于对OLTP（在线交易处理） 的明确区别。 OLAP查询的典型输出采用矩阵格式， 维度构成矩阵的行和列，因子或度量是矩阵内的值。
常见的OLAP操作包括切片和切块、 向下钻取、 向上钻取、 向上卷积和透视。
1） 切片（Slice） 。 切片是多维数组的子集， 对应不在子集中的维度的一个或多个成员的单个值。
2） 切块（Dice） 。 切块操作是数据立方体上两个以上维度的切片， 或者是两个以上的连续切片。
3） 向下/向上钻取（Drill down/up） 。 向下钻取或向上钻取是一种特定的分析技术， 用户可以在不同数据级别之间导航， 范围从最概括（向上） 到最详细（向下） 。
4） 向上卷积（Roll-up） 。 卷积涉及计算一个或多个维度的所有数据关系。 为此， 需要先定义计算关系或公式。
5） 透视（Pivot） 。 透视图会更改报表或页面的展示维度
三种经典的OLAP实现方法如下：
1） 关系型联机分析处理（ROLAP） 。 ROLAP通过在关系数据库（RDBMS） 的二维表中使用多维技术来支持OLAP。 星型架构是ROLAP环境中常用的数据库设计技术。
2） 多维矩阵型联机分析处理（MOLAP） 。 MOLAP通过使用专门的多维数据库技术支持OLAP。
3） 混合型联机分析处理（HOLAP） 。 它是ROLAP和MOLAP的结合。 HOLAP实现允许部分数据以MOLAP形式存储， 而另一部分数据存储在ROLAP中。 控件的实现方式各不相同， 设计师对分区的组合也各有不同。
方法
驱动需求的原型
自助式商务智能
可查询的审计数据
工具
绪评估/风险评估
数据仓库应该能够实现以下几点：
1） 明确数据敏感性和安全性约束。
2） 选择工具。
3） 保障资源安全。
4） 创建抽取过程以评估和接收源数据。
版本路线图
配置管理
组织与文化变革
在整个数据仓库/商务智能生命周期中， 始终保持一致的业务重点是项目成功的关键。
将项目与实际业务需求保持一致并评估必要的业务支持：
1） 业务倡议。 是否有合适的管理层支持？ 例如， 是否有一个确定参与的指导委员会和对应的资金支持？ 数据仓库/商务智能项目需要强有力的管理层支持。
2） 业务目标和范围。 是否有确切的业务需要、 业务目标和工作范围？
3） 业务资源。 业务管理层是否承诺提供或聘用相应的业务专家，专家的参与度如何？ 缺乏承诺是一个常见的失败点， 反过来说也是一个充足的理由， 可以在确认承诺前停止DW/BI项目。
4） 业务准备情况。 业务合作伙伴是否准备好这是一个长期的增量交付项目？ 他们是否承诺建立卓越中心， 并在未来持续维护产品的版本？ 目标组织内的平均知识水平或技能差距有多大， 可以在一个增量版本中拉平这种差距吗？
5） 愿景一致。 IT战略对业务愿景的支持程度如何？ 确保所需的功能要求与当前IT路线图中已有或可以维持的业务能力相对应， 这点至关重要。 能力调整中的任何重大偏差或差距， 都可能导致数据仓库/商务智能程序暂停或停止。
使用指标
数据仓库中使用的度量指标通常包括注册用户数、 连接用户数或并发用户数。
