1.数据仓库的基本概念
英文名称为Data Warehouse，可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。它出于分析性报告和决策支持目的而创建。
数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
2.数据仓库的主要特征
数据仓库是
面向主题的（Subject-Oriented）、
集成的（Integrated）、
非易失的（Non-Volatile）和
时变的（Time-Variant ）数据集合，用以支持管理决策。
3. 数据仓库与数据库区别
数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。
操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。
分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing）,一般针对某些主题的历史数据进行分析，支持管理决策。
首先要明白，数据仓库的出现，并不是要取代数据库。
- 数据库是面向事务的设计，数据仓库是面向主题设计的。
- 数据库一般存储业务数据，数据仓库存储的一般是历史数据。
- 数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析。数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
- 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
以银行业务为例。
数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记账。
数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。
4.数据仓库分层架构
按照数据流入流出的过程，数据仓库架构可分为三层——源数据、数据仓库、数据应用。
数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。
- 源数据层（ODS）：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。
- 数据仓库层（DW）：也称为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。
- 数据应用层（DA或APP）：前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。
为什么要对数据仓库分层？
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
5. 表的分类
5.1 实体表
一般是指一个现实存在的业务对象，比如用户，商品，商家，销售员等等。
用户表：
用户id 姓名 生日 性别 邮箱 用户等级 创建时间
1 张三 2011-11-11 男 zs@163.com 2 2018-11-11
2 李四 2011-11-11 女 ls@163.com 3 2018-11-11
3 王五 2011-11-11 中性 ww@163.com 1 2018-11-11
5.2 维度表：
一般是指对应一些业务状态，编号的解释表。也可以称之为码表。
比如地区表，订单状态，支付方式，审批状态，商品分类等等。
订单状态表：
订单状态编号 订单状态名称
1 未支付
2 支付
3 发货中
4 已发货
5 已完成
5.3 事务型事实表
事务型事实表，一般指随着业务发生不断产生的数据。特点是一旦发生不会再变化。
一般比如，交易流水，操作日志，出库入库记录等等。
交易流水表： ]
编号 对外业务编号 订单编号 用户编号 支付宝交易流水编号 支付金额 交易内容 支付类型 支付时间
1 7577697945 1 111 QEyF-63000323 223.00 海狗人参丸1 alipay 2019-02-1000:50:02
2 0170099522 2 222 qdwV-25111279 589.00 海狗人参丸2 wechatpay 2019-02-10
5.4 周期型事实表
周期型事实表，一般指随着业务发生不断产生的数据。
与事务型不同的是，数据会随着业务周期性的推进而变化。
比如订单，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。
订单表：
订单编号 订单金额 订单状态 用户id 支付方式 支付流水号 创建时间 操作时间
1 223.00 2 111 alipay QEyF-63000323 2019-02-10 00:01:29 2019-02-10 00:01:29
2 589.00 2 222 wechatpay qdwV-25111279 2019-02-10
00:05:02 2019-02-10 00:05:02
3 485.00 1 666 unionpay hSUS-65716585 2019-02-10 00:50:02 2019-02-10
00:50:02
6. 数据同步策略
数据同步策略的类型包括：全量表、增量表、新增及变化表、拉链表
- 全量表：存储完整的数据。
- 增量表：存储新增加的数据。
- 新增及变化表：存储新增加的数据和变化的数据。
- 拉链表：对新增及变化表做定期合并。
6.1 实体表同步策略
实体表：比如用户，商品，商家，销售员等
实体表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。
6.2 维度表同步策略
维度表：比如订单状态，审批状态，商品分类
维度表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。
说明：
1）针对可能会有变化的状态数据可以存储每日全量。
2）没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以只存一份固定值。
6.3 事务型事实表同步策略
事务型事实表：比如，交易流水，操作日志，出库入库记录等。
因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，所以可以做成每日增量表，即每日创建一个分区存储。
6.4 周期型事实表同步策略
周期型事实表：比如，订单、请假、贷款申请等
这类表从数据量的角度，存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。
每日新增及变化量，包括了当日的新增和修改。一般来说这个表，足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。
所以要用利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。
7. 范式理论
7.1 范式概念
关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性，目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
范式可以理解为设计一张数据表的表结构，符合的标准级别。
使用范式的根本目的是：
- 1）减少数据冗余，尽量让每个数据只出现一次。
- 2）保证数据一致性
缺点是获取数据时，需要通过Join拼接出最后的数据。
7.2 函数依赖
7.3 三范式区分
8 关系建模与维度建模
8.1 关系模型
关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
8.2 维度模型
维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。
所以把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。
8.3 雪花模型、星型模型和星座模型
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
