数据仓库学习（一）——数据仓库、商业智能及维度建模的初步
1.DW
数据仓库（Data Warehouse 简称DW）是一个面向主题的（SubjectOriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（TimeVariant）的数据集合，用于支持管理决策。
数据仓库是实现商务智能的基础平台。
2.BI
商业智能（Business Intelligence），是指通过对数据的收集、管理、分析以及转化，使数据成为可用的信息，从而获得必要的洞察力和理解力，更好地辅助决策和指导行动
3.OLTP与OLAP的介绍
数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。
OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
--------------------------------------------------------------------------------------------------
1.DW/BI 的业务驱动目标
首先要了解，信息几乎总是用作2个目的：操作型记录的保存、分析型决策的制定。
1.1 DW/BI 系统要能方便地存取信息。
1.2 DW/BI 系统必须以一致的形式展现信息。（同名同义，异名异义）
1.3 DW/BI 系统必须能够适应变化。
1.4 BW/BI 系统必须能够及时展现信息。
1.5 DW/BI 系统必须成为保护信息财富的安全堡垒。（能有效控制对组织中的机密信息的访问，即通过权限能有效限制）
1.6 DW/BI 系统必须成为提高决策制定能力的权威和可信基础。（早起用于表示DW/BI 系统的称谓是决策支持系统）
1.7 DW/BI 系统成功的标志是业务群体接受 DW/BI 系统。
2.维度建模的核心概念及涉及的主要词汇，包括事实表与维度表
2.1 维度建模 并不是一种新技术，早期主要用于简化数据库。简单性至关重要，因为它能够确保用户方便地理解数据，异己确保软件能够快速、有效的发现及发布结果。爱因斯坦曾经说过，“凡事应该简单，知道不能再简单为止。”。
维度是展现分析数据的首选技术，主要基于以下两个需要同时满足的需求：
以商业用户可理解的方式发布数据
提供高效的查询性能。
2.2 3范式（3NF）——有称为 实体-关系模型（实体-关系图 即ER图或ERD），但 ER模型不全是 3NF 模型，所以 3NF 模型又称为规范化模型加以区分
数据库中强调 3NF 主要是为消除冗余。规范的 3NF 将数据划分为多个不同实体，每个实体构成一个关系表。
3NF 和 维度模型都可以用ERD表示。
规范化的 3NF 模型主要应用于操作型过程中，难以满足 DW/BI 对系统高性能的需求，维度建模解决了模式过分复杂的问题。即维度建模与规范化模型包含的信息相同，但是又对其进行了包装。
2.3 星型模式与OLAP多维数据库
在关系数据库管理系统中实现的维度模型称为星型模式。
在多维数据库环境中实现的维度模型通常称为联机分析处理（OLAP）多维数据库。
通常建议将详细的、院子的信息加载到星型模式中，然后将OLAP多维数据库移植到星型模式中。
OLAP部署注意事项：
1.构建于关系数据库智商的星型模式是建立OLAP多维数据库的良好物理基础。通常也被任务是备份与恢复的良好的、稳定的基础。
2.传统上，一般认为OLAP多维数据库比RDBMS具有更好的性能，但这优越性随着计算机硬件（例如设备和内存数据库）和软件（例如纵列数据库）的发展变得不那么重要。
3.由于供应商多，OLAP多维数据库数据结构比关系数据库管理系统变化更大，因此，最终的补数据细节通常和供应商有关。通常在不同的OLAP工具之间建立BI应用比在不同关系数据库之间建立BI更困难。
4.OLAP多维数据库通常比RDBMS提供更多的复杂安全选项。例如，限制访问细节数据。
5.OLAP多维数据库显然能够提供比RDBMS更加吩咐的分析能力，后者受SQL制约。
6.OLAP多维数据库方便地支持缓慢变化维度类型2变化，但当需要使用其他缓慢变化维度技术重写数据时，通常需要被全部或部分的重新处理。
7.OLAP多维数据库方便地支持事物和周期性的快照事实表，但是由于上一点（6）而无法处理累计快照事实表。
8.OLAP多维数据库通常支持具有层次不确定的复杂的不规则层次结构，例如组织结构图或物料表等。使用自身查询语法比RDBMS的方法更优越。
9、OLAP多维数据库与关系数据库比较，能对实现下钻层次的维度关键字结构提供更详细的约束。
10.一些OLAP产品无法确保实现维度角色和别名，因此需要定义不同的物理维度。
2.4 用于度量的事实表
“事实”表示某个业务度量。从市场角度观察，记录销售的产品的数量单位，以及每种产品在每个销售事务中设计的销售额。（产品、销售额、时间为维度的事实表）
事实表中的每行对应一个度量单位。事实表每行中的数据是一个特定级别的细节数据，称为粒度。（维度建模的核心原则之一是同一事实表中所有度量行必须具有相同的粒度，常见粒度划分：事务，周期性快照，累计快照）
最实用的事实是数值类型和可加类型事实。可加性至关重要，因为BI应用往往一次需要加载上千甚至百万。半可加事实（例如，账户节余）和不可加事实（例如，单位价格）不可直接相加，不得不进行技术或者区平均值操作，对于海量数据进行操作并不现实。
事实通常以连续值描述，这样有助于区分到底是事实还是维度属性的问题。
一般事实表具有2个或更多的外键与维度表的主键关联。事实表通常有包含外键集合的主键。
2.5 用于描述环境的维度表
维度表包含与业务过程度量时间有关的文本环境。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。
维度属性对构建DW/BI系统的可用性和可理解下起着非常重要的作用。应该对那些操作型代码进行解码。（通常两者都有）
维度表通常不用满足第3范式。（可能多对一）
雪花模式：例如，在产品维度表中仅存储品牌代码，建立品牌分类查询表的方式，使数据规范化。（即：给维度表建维度表）。
2.6 Kimball的 DW/BI 结构的组件和原则
1.操作型源系统
用于获取业务事务。可以认为源系统处于数据仓库之外，因为几乎不能控制这些操作型系统中数据的格式和内容。
2.获取-转换-加载（ETL）系统
DW/BI 环境中的 ETL 系统包括一个工作区间、实例化的数据结构以及一个过程的集合。
1）清洗数据（消除拼写错误、解决领域冲突、处理错误的元素、解析为标准格式）
2）合并来自不同数据源的数据
3)复制数据
3.用于支持商业智能决策的展现区
确认采用维度模型：星型模式 or OLAP多维数据库。
展现区的数据可以围绕业务过程度量事件来构建。采用这一方法可以自然的裁剪操作型源数据获取系统。
必须使用公共的、一致性的维度建立维度结构。如果没有一种可共享的、一致性的维度，维度模型将成为一个孤立的应用，而DW/BI 环境应该是一个健壮的、集成的环境。
处于 DW/BI 系统可查询展现区中的数据必须是维度化的、院子（辅以增强性能的聚集）的、以业务过程为中心的，坚持使用总线结构的企业数据仓库，数据不应该按照个别部门来构建。
4.商业智能应用
所有的BI应用的查询针对的是 DW/BI 展现区。
2.6其他 DW/BI 架构
1.独立数据集市架构
以部门为基础部署，不需要考虑企业级别的信息共享和集成。（短期看成本低，能够快速开发）
2.辐射状企业信息工厂Inmon架构
3.混合辐射状架构与Kimball架构