业务驱动因素
数据仓库（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）
Bill Inmon的企业信息工厂（Corporate Information Factory， CIF）是两种主要的数据仓库建设模式之一。 Inmon关于数据仓库的组成是这样描述的： “面向主题的、 整合的、 随时间变化的、 包含汇总和明细的、 稳定的历史数据集合”。
1） 面向主题的。 数据仓库是基于主要业务实体组织的， 而不关注功能或应用。
2） 整合的。 数据仓库中的数据是统一的、 内聚的。 保持相同的关键结构， 结构的编码和解码、 数据定义和命名规范在整个仓库中都是一致的。 因为数据是整合的， 数据仓库不是简单的运营数据的副本。 相反， 数据仓库变成了一个数据记录的系统。
3） 随时间变化的。 数据仓库存储的是某个时间段的数据。 数据仓库中的数据像快照一样， 每一张快照都反映了某个时点的数据状态。 这意味着基于某个时间段的数据查询总是得到相同的结果， 无论什么时候去查询。
4） 稳定的。 在数据仓库中， 数据记录不会像在业务系统里那样频繁更新。 相反， 新数据只会追加到老数据的后面。 一组记录可以代表同一个交易的不同状态。
5） 聚合数据和明细数据。 数据仓库中的数据包括原子的交易明细， 也包括汇总后的数据。 业务系统很少聚合数据。 数据仓库一旦建好， 出于成本和空间的考虑， 都会有把数据汇总的需求。 在当前的数据仓库环境中， 汇总数据可以是持久地存在一个表里， 也可以是非持久的、 以视图的形式展现。 汇总数据是否持久化的决定因素通常是性能上是否需要。
6） 历史的。 业务系统的重心是当前的数据。 数据仓库还包括历史数据， 通常要消耗很大的存储空间。
CIF架构
1） 应用程序。 应用程序处理业务流程。 应用程序产生的明细数据流转到数据仓库和操作型数据存储中， 继而用作分析。
2） 数据暂存区。 介于业务系统源数据库和目标数据仓库之间的一个数据库。 暂存区是用于数据抽取、 转换和加载的地方， 对最终用户透明。 暂存区中的大部分数据是短时留存的， 通常只有相当少的一部分数据是持久性数据。
3） 集成和转换。 在集成层， 来自不同数据源的数据被转换整合为数仓和ODS里的标准企业模型。
4） 操作型数据存储（ODS） 。 操作型数据存储是业务数据的集成数据库。 数据可能直接来源于应用系统， 也可能来自其他数据库。 操作型数据存储中通常包括当前的或近期的（30～90天） 数据， 而数据仓库还包含历史（通常是很多年的） 数据。 操作型数据存储的数据变化较快， 而数据仓库的数据相对稳定。 不是所有的组织都会建设操作型数据存储， 操作型数据存储的存在满足了企业对低延迟数据的需求。 操作型数据存储可以作为数据仓库的主要来源， 还可用于对数据仓库做审计。
5） 数据集市。 数据集市为后续的数据分析提供数据。 这里说的数据通常是数据仓库的子集， 用于支持特定分析或特定种类的消费者。 例如， 数据集市可以聚合数据， 以支持更快的分析。 多维模型（用反范式的技术） 通常针对面向用户类型的数据集市。
6） 操作型数据集市（OpDM） 。 操作型数据集市是专注于运营决策支持的数据集市。 它直接从操作型数据存储而不是从数据仓库获取数据， 具有与操作型数据存储相同的特性： 包含当前或近期的数据， 这些数据是经常变化的。
7） 数据仓库。 数据仓库为企业数据提供了一个统一的整合入口，以支持管理决策、 战略分析和规划。 数据从应用程序系统和操作型数据存储流入数据仓库， 然后流到数据集市， 这种流动通常只是单向的。 需要更正的（不符合要求的） 数据将被拒绝进入， 理想情况是在其源头系统完成更正， 然后通过ETL流程系统重新加载。
8） 运营报告。 运营报告从数据存储中输出。
9） 参考数据、 主数据和外部数据。 除了来自应用程序的交易数据， 企业信息工厂还包括理解交易所需的数据， 如参考数据和主数据。对通用数据的访问简化集成在数据仓库中。 当应用程序使用当前的参考数据和主数据时， 数据仓库还需要它们的历史值及其有效的时间范围
多维数据仓库（ Kimball）
Kimball的数据仓库比Inmon的数据仓库的可扩展性更强。数据仓库包含数据暂存和数据展示区域的所有组件。
1） 业务源系统。 企业中的操作型/交易型应用程序。 这些应用程序产生数据， 数据再被集成到操作型数据存储和数据仓库中。 此组件等同于企业信息工厂图中的应用程序系统。
2） 数据暂存区域。 Kimball的暂存区域包括需要集成的流程和用于展示的转换数据， 可以与企业信息工厂的集成、 转换和数据仓库组件的组合进行类比。 Kimball的重点是分析类数据的高效终端交付， 比Inmon的企业管理数据范围要小。 Kimball的企业数据仓库可以适配数据暂存区域架构。
3） 数据展示区域。 与企业信息工厂中的数据集市类似， 关键的架构差异在于“数据仓库总线”的集成范式， 如应用于若干个数据集市的共享或一致的维度。
4） 数据访问工具。 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路线图中已有或可以维持的业务能力相对应， 这点至关重要。 能力调整中的任何重大偏差或差距， 都可能导致数据仓库/商务智能程序暂停或停止。
使用指标
数据仓库中使用的度量指标通常包括注册用户数、 连接用户数或并发用户数。
