数仓分层

计算逻辑、计算结果复用。提取公共逻辑解耦，方便表的管理降低sql复杂度，比如bds中的宽表，减少join

度量、事实、维度

1. 事实、度量

对业务过程的度量称为事实

2. 维度

1）维度定义 在维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的多样环境

2）维度属性 维度所包含的表示维度的列，称为维度属性 如开门方式是维度，具体11种方式是维度属性

3）维度作用 维度属性是查询约束条件、分组和的基本来源，是数据报表标签生成易用性的关键。

4）维度应用 维度的作用一般是查询约束、分类汇总以及排序、生成报表标签等。

5）标识维度 维度使用主键标识其唯一性

事实表、维度表

事实表：记录事实的表；比如，订单表，注册表，购物车，退货表，浏览日志表 维度表：对维度的详细描述信息；比如，地域维表，产品维表，品类维表，栏目维表，时间维表；

事实表

访客浏览记录表 uid,session,page,lanmu,pinlei,pid,datetime,areacode u1,s1,/abc/dd,lm1,cat1,p01,2019-10-21 16:18:21,11010 u1,s1,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010 u2,s2,/aty/rt,lm3,cat5,p05,2019-10-21 16:17:21,01010 u2,s2,/bbb/cd,lm2,cat3,p08,2019-10-21 16:19:30,01010

上面的表就是一个 事实表，对事实表，假如要计算pv数（指标 | 度量） 我们可以按如下口径来统计：

总pv数每个栏目的pv数每个省份的pv数每个商品品类的pv数每个省份下每个栏目的pv数 从这些需求中可以看出，同一个指标，可以通过多种角度（口径）去统计！ 这些角度，或口径，就叫“维度！”

维度组合中的维度越多，统计出来的事实指标粒度越细

维度表

栏目维度表： 栏目id，栏目名称 lm1,生鲜水产 lm2,冲调饮品 lm3,智能设备

地域码维表：

地域码 省 市 11010 湖北省,武汉市 01010 山西省,临汾市

时间维表：

日期 季度 周数 周几 销售季 活动期间 2019-10-21 4 38 monday 2019-10-21 4 38 monday

维表的作用： 可以对统计维度进行人性化的诠释！可以丰富维度内容！

维度表也有更新的需求

缓慢变化维 一些维表中的纬度值，会随时间缓慢变化，会对数据分析产生困扰==》解决办法就是把这种状态记录下来。拉链表 某维度列在不同时间范围内值不一样，有更新，这样可以记录维度表的更新。

3. 退化维度 维度冗余

维度退化：将一些常用的维度属性直接写到事实表中的维度操作称为维度退化 维度冗余：数据冗余是指同一条数据存储在不同的数据文件中都进行存储，从而产生冗余数据的现象

4.

{1} 规范化

按照三范式形成设计是事实和纬度表的方式管理数据称为规范化 规范化常用于OLTP系统的设计

{2} 反规范化

将维度的属性层次合并到单个维度中的操作称为反规范化 反规范化会产生包含全部信息的宽表，形成数据冗余；实现用维表的空间换取简明性和查询性能的效果，常用于OLAP系统的设计

模型和建模

模型，在数仓中就是表结构 建模：建表和表之间关系

1. 三范式模型

数仓用的很少，但业务系统关系型数据库中用的多。OLTP 业务最终都会体现到数据库中， 特点是高并发的随机CRUD，一次一般只会操作一条

数仓不会有高并发的随机CRUD，特点是大数据量、低并发、批量、大多数是查询。OLAP。 因为2者特点不同，建表时的方法论也不同，OLAP因为频繁的插入、修改，所以每条数据尽量的小，尽量避免数据冗余，所以要把维度尽量的提取出来，规范化。比如订单表，如果用三范式理论，那么某手机订单中的商品名称就要用外键，而不能直接用名称，否则，商品名称修改时，订单表中每条都要改。订单表改了，退货表中的也要改，否则会有一致性的问题。

而OLAP中，会带有商品名称，这样计算的时候方便。

第一范式（列不可分）：每一列都是不可分割的原子数据项，如果列可分割，用sql查某一列时，会返回很多冗余数据。

（像下面的表格就能分割，所以它连第一范式都算不上） 分割后的样子（本表就符合了第一范式）

第二范式（消除部分依赖）：在1NF基础上，非码属性必须完全依赖于主码，

（在1NF基础上消除非主属性对主码的部分函数依赖） 在上面那张表中主码为：学号+课程名称，但是姓名、系名、系主任都部分依赖于主码，比如系主任，不仅仅由学号+课程名称决定，也由系名决定。这不符合第二范式，所以进行拆分如下 第一张表主码为：学号、课程名称 第二张表主码为：学号 它们都是完全依赖的，因此符合第二范式。

第三范式（消除传递依赖）：在2NF的基础上，任何的非主属性不依赖于其他非主属性

（在第二范式基础上消除传递依赖） 注意看第二范式的学生表：存在系主任依赖于系名 （系名—> 系主任），系主任并不是由学号直接决定，而是学号 决定 系名，系名 决定 系主任。此时如果要添加一个新系和系主任，根本添加不了，因为没有主键。所以不符合第三范式，继续进行拆分

2. 星型

不完全星型模型

事实表中，不是所有维度都按维度主键信息存储（维度退化）

地域维度信息：年月日周等时间维度信息，这些维度信息，基本不会发生任何改变，并且在大部分主题分析场景中，都需要使用，直接在事实表中存储维度值页面信息：页面类别信息，频道信息，业务活动信息，会员等级信息等，可能发生缓慢变化的维度信息，事实表中遵循经典理论存储维度主键，具体维度值则在主题分析计算时临时关联

3. 雪花型

4. 星座型

基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。 所以星座模型并不和前两个模型冲突。

5. 模型的选择：

首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。 星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。 目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是hadoop体系，减少join就是减少shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）

数据结构上，雪花型更符合逻辑ETL性能