数据仓库是一个面向主题的、集成的、稳定的、反映时间变化的,用于支持管理决策的数据集合， 需要具备可读性，保证数据一致。数据仓库有两位大师 William H.Inmon 和 Ralph Kimball。
- Inmon 是正统的学术派，比较强调自上而下的建模，强调从源系统的业务与数据出发，在企业全局高度进行业务对象抽象，建立企业级数据仓库系统。
- Kimball 是强调从数据仓库应用角度出发，自下而上的建模。强调以空间换时间、采用星形数据模型、适当雪花化的处理手段建立数据仓库应用模型；强调采用一致的维度来保证各个模型数据统计的一致性。
两个学派各有应用场景：
- Inmon 对业务模式稳定的行业，应用较多，比如电信、银行、保险
- Kimball 在业务高速发展，变化迅速的行业（比如互联网、在线游戏）应用较多。
数据仓库的特点
面向主题
主题是一个抽象的概念,是在较高层次上将企业信息系统的数据综合、 归类并进行分析利用的抽象，可在较高的层次上对分析对象的数据给出完整，一致的描述。以零售业为例,“销售”、“库存”、“供应商”、“客户”等就是一些可以进行分析研究的主题。面向主题性表示数据仓库中数据组织的基本原则，数据仓库中数据都是围绕某一主题组织、展开的。
面向主题组织数据的特点
- 各个主题有完整、一致的内容以便在此基础上作分析处理
- 主题之间有重迭的内容,反映主题间的联系。重迭是逻辑上的,不是物理上的
- 主题域应该具有独立性、完备性:
- 独立性:有明确界限,数据是否属于该主题；
- 完备性:对该主题进行分析所涉及的内容均要在主题域内；
集成性
数据仓库中的数据是从原有分散的数据源中中提取出来的,其每一个主题所对应的源数据在原有的数据库中有许多冗余和不一致,且与不同的应用逻辑相关，在数据仓库体系结构中一般由ods层来完成数据整合。 为了创建一个有效的主题域,必须将这些来自不同数据源的数据集成起来,使之遵循统一的编码规则。数据要保证一致性、完整性、有效性、 精确性。
稳定性
- 数据仓库在某个时间段来看是保持不变的。
- 数据仓库中的数据极少更新：
- 一般只追加不删除数据, 不用的数据从DW移出
- 一般只被用作查询作用
反映时间变化
- 数据仓库大多关注的是历史数据
- 数据仓库中的表大多含有时间属性
- 数据仓库需要能反映数据的随时间的变化，并保留数据的历史记录
维度建模
数据模型
数据模型是抽象描述现实世界的一种工具和方法，以抽象实体及实体之间关系的形式，描述现实世界中事物之间关系的一种映射。
整个数据仓库得建模过程中，我们需要经历一般四个过程：
- 业务建模，生成业务模型，主要解决业务层面的分解和程序化。
- 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念
模型。 - 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关
系进行数据库层次的逻辑化。 - 物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物
理化以及性能等一些具体的技术问题。
术语描述
维度建模是一种将数据结构化的逻辑设计方法,将客观的世界划分为分度量和上下文,让业务用户很直观,很容易的理解数据库。 相对于关系-实体模型，尽管维度模型在物理实现上还是表和关系，但在模型概念上有了一定的抽象，将表分为维度表和事实表两种，事实表中以数字型为主，包含度量信息；而维度表常以文本类型为主，作为事实表的上下文,为度量值添加业务意义。
维度表和事实表是维度建模的两个关键要素：
事实表
事实表通常包含了处理所关心业务和操作的一系列度量值，大部分事实都是数值型的，具备可加性，便于进行诸如sum等聚合运算。对于不可加的数值，比如单均价、设备的面积等，可以考虑抽取到维度表中去。
有维度表的键和度量事实组成；
- 事实表键：事实表的主键一般是维度表外键的子集。有时，事实表的唯一标识某一行的主键可能包含退化维。
-
反映业务和操作的数值型事实数，反映业务事实的数据可以汇总以提供有关业务历史的信息，通过事实表的复合键,将事实表与维表联系起来。
-
事实表粒度：据准确描述事实表的一行代表什么业务意义。粒度确定了事实表的主键；粒度就是锚点：维度设计中必须包含足够的维度上下文来实现粒度，而也必须将那些违背该粒度的维度上下文排除掉。应当包含业务过程中捕捉的最底层，最细节的原子粒度。
维度表
- 两个用途：查询过滤和标记查询结果集
- 属性一般是文本字段或者是作用和文本相同的离散数字
维度表键：本身没有意义，作为维度表和事实表之间的连接字段，强烈建议表的主键为1开始的简单整数序列。
层次关系处理：一般冗余在一个维度表里，如果延伸则雪花组织模式
缓慢变化维
相对于事实表来说，维度表的属性更为稳定和静态，但是有些维度表中的某些属性会慢慢发生变化，这些会缓慢发生变化的维度就被称为缓慢变化维。
百度百科：维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。
如何应对
- 类型1：覆盖维度属性：一旦属性值发生变化就用最新的值覆盖旧值，这样维度属性就反映了最新状态，但是所有的历史值都会丢失，如果不关心历史变化的话可以采用这种方式。
- 类型2：添加一个新的维度行：维度表中将会插入一个新的代理键来反映新的属性值。同时还包含行生效日期、结束日期和当前指示符。是处理缓慢变化维最主要的方法。
缓慢变化维示例行
- 类型3： 添加一个新的维度属性。
- 微型维：添加一个新的维度表，方法2对于跟踪大型维度表(数百万行)中的属性变化是不适用的，解决方法：
将经常变化的客户属性分解到独立的维度表中 - 混合缓慢变化维方法
拉链表:历史拉链表表是针对数据仓库设计中表存储数据的方式而定义的，顾名思义，所谓拉链，就是记录历史。记录一个事物从开始，一直到当前状态的所有变化的信息。历史拉链表的更新策略，注意开始时间，结束时间的变化。
粒度
声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表式什么，在选择维度或者事实前必须声明粒度，因为每个候选维度或事实必须预定义的粒度保持一致。
退化维
退化维度是事实表的一个维度关键字，没有对应的维度表(将属于它维度属性分解到其他的维度表里面去了)，只有一个属性，例如发票号、提货单号等，常常作为事实表主键的一部分。
宽表
所谓宽表就是基于某个实体分析对象而建立的一个逻辑数据体系，由实体的维度、描述信息以及基于这个实体的一系列度量组成。
组织形式
维度表与事实表多以星型模型、雪花模型、星座模型等形式进行组织。
最常见的模型范例是星型模式，其包含：
- 一个大的、包含大批数据、不含冗余的事实表
- 一组小的维度表，每维一个
星型模式
如上图所示：sales有四个维，分别是time,item,branch和location，该模式包含一个中心事实表sales,它包含四个维的关键字和两个度量dollars_sold和units_sold
雪花模式是星型模式的变种，包含一个事实表，若干维度表，但是维度表是规范化的，即进一步把数据分解到附加的表中。冗余度更低
雪花模式
星型模型中会有冗余属性，雪花模型符合3NF，不建议构建雪花型的理由如下：
- 让用户感到复杂
- 导致浏览维度属性的速度较慢
3NF和维度建模
业务系统一般采用3NF而数据仓库多采用星型模型组织数据。
第三范式(3NF)建模和维度建模差异很大，3NF建模是一种想方设法消除数据冗余的设计方法,要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如:存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。这种规范化方式对事务处理来说非常有好处，因为这种方式下事务的加载和更新会比较简单和迅速。
3NF数据被分成很多离散的实体，而维度建模是面向主题的，以简洁，直观让用户易于理解数据库为出发点。
范式和反范式
在范式化的数据库中，每个事实数据会出现并且只出现一次。相反在反范式化的数据库中，信息是冗余的，可能会存储在多个地方。
数据仓库体系结构
总体上，整个数据仓库架构从源系统到应用系统可以分为以下几层:
数据仓库分层模型
- 源数据层：原始数据来自各业务系统的数据库数据和日志数据。业务DB的数据设计主要由业务方自己确定，但需要保证能提供DW需要的数据；日志数据，希望通过统一的规范进行采集和结构化。
- ODS层：原始数据直接同步过来；ODS作为数据缓冲层，保留的是所有的数据，理论上粒度和源系统保持一致，同时不丢数据，业务DB基本上是直接同步过来，LOG主要是做结构化。
- DW层：ODS的数据经过规范化、解析、整合和筛选之后，进入DW(EDW)。DW中的数据是全公司的数据，根据业务做主题梳理建设之后，需要能方便地满足对于全公司数据的分析，同时又能满足各业务部门数据集市的需求，它需要作为各个部门分析数据的来源，保证数据一致性。这里应该放的比较稳定和公司层面比较通用的数据。包含事实表，维度表，各种明细数据，轻型汇总，高度汇总表等。一般以星型模式组织数据。
- DM/BA层：包括部门级别的数据集市和专题分析类的数据集市。各集市根据自己的特定需求对数据进行组织，理论上会和DW数据的组织方式一致。这里应该存放的是集市相对比较稳定和集市内比较通用的数据。
- APP层：应用数据层，从DW或者各个DM获取数据，根据特定业务需求整合，大部分会导入到查询工具的存储环境。原则上这部分数据应该是可以直接用于查询展现的，不需要做复杂的计算或者连接操作，以提高前端查询的性能。另外，一些临时数据也可以放在这里。
仓库设计过程
四步维度设计过程
构建模式
先局部再整体构建模式
先创建部门的数据集市，然后在扩大到企业的数据仓库。
优点：
- 投资少、见效快，局部的业务需求快速得到满足
- 设计上相对灵活
- 快速部署、便于复制
缺点
- 数据需逐步清洗,信息需进一步提炼
- 需要为每个部门做模型和数据重建
- 从部门扩充到企业有一定的困难，没有统一的规范，各个部门统计口径等不一致
- 数据在ETL时有一定的重复工作,还会有一定级别的冗余和不一致性
先整体再局部构建模式
优点
- 数据规范化程度高，最小化的冗余与不一致性，当前数据、历史数据与详细数据整合
- 面向全企业构建了结构稳定和数据质量可靠的数据中心
- 相对快速有效地分离面向部门的应用
缺点
- 建设周期长、见效慢
- 风险程度相对大

数据质量
数据质量的因素包含一致性、完整性、正确性、及时性等。
数据一致性保证数据仓库中数据一致，不会自相矛盾，如果系统采用范式建模，可以很大程度上面减少数据冗余，同时也有利于保持数据一致，但是带来的一个问题，就是可读性差，因此数据集市多采用星型模式。