在数仓体系中，最重要的部分就是要建表，这篇来说一下关于数仓中表的那些事。
实体表
- 一般是指一个现实存在的业务对象，比如用户，商家，商品等等
维度表
- 维度表，一般是指对应一些业务状态，编码的解析表。也可以称为码表。
- 比如地区表，订单状态，支付方式，审批状态，商品分类等等。
事务型事实表
事务型事实表，一般指随着业务发生不断产生的数据。特点是
一旦发生不会再变化。一般比如，
交易流水，操作日志，出库入库记录等等。
交易流水表：
| 编号 | 对外业务编号 | 订单编号 | 用户编号 | 支付宝交易流水编号 | 支付金额 | 交易内容 | 支付类型 | 支付时间 |
|---|---|---|---|---|---|---|---|---|
| 1 | 7577697945 | 1 | 111 | QEyF-63000323 | 223.00 | 海狗人参丸1 | alipay | 2019-02-10 00:50:02 |
| 2 | 0170099522 | 2 | 222 | qdwV-25111279 | 589.00 | 海狗人参丸2 | wechatpay | 2019-02-10 00:50:02 |
| 3 | 1840931679 | 3 | 666 | hSUS-65716585 | 485.00 | 海狗人参丸3 | unionpay | 2019-02-10 00:50:02 |
周期型事实表
- 周期型事实表，一般指随着
业务发生不断产生的数据。与事务型不同的是，数据会随着业务周期性的推进而变化。 - 比如
订单，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。
订单表：
| 订单编号 | 订单金额 | 订单状态 | 用户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 |
同步策略
数据同步策略的类型包括：全量表、增量表、新增及变化表、拉链表
- 全量表：存储完整的数据。
- 增量表：存储新增加的数据。
- 新增及变化表：存储新增加的数据和变化的数据
- 拉链表：对新增及变化表做定期合并。
实体表同步策略
- 实体表:如用户(1100w)，商品，商家，销售员等
- 实体表数据量比较小:通常可以做每日全量，就是每天存一份完整数据，即
每日全量
维度表同步策略
- 维度表：比如订单状态，审批状态，商品分类
- 维度表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即
每日全量。
事务型事实表同步策略
- 事务型事实表：比如，交易流水，操作日志，出库入库记录等。
- 因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，
所以可以做成每日增量表，即每日创建一个分区存储。
周期型事实表同步策略
周期型事实表：比如，订单、请假、贷款申请等
这类表从数据量的角度，
存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。每日新增及变化量，包括了当日的新增和修改。一般来说这个表，足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。
所以要用利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。拉链表：
| name姓名 | start新名字创建时间 | end名字更改时间 |
| ——– | ——————- | ————— |
| 张三 | 1990/1/1 | 2018/12/31 |
| 张小三 | 2019/1/1 | 2019/4/30 |
| 张大三 | 2019/5/1 | 9999-99-99 |
| 。。。 | 。。。 | 。。。 |1
select * from user where start =<’2019-1-2’ and end>=’2019-1-2’
范式理论
范式概念
关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性，目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
范式可以理解为一张数据表的表结构，符合的设计标准的级别。
使用范式的根本目的是：
1）减少数据冗余，尽量让每个数据只出现一次。
2）保证数据一致性
缺点是获取数据时，需要通过Join拼接出最后的数据。
1NF
- 核心原则就是:属性不可切割。
- 例如：5个电脑，可以切分为数量和商品名称。那么这个属性就不符合1NF
- 1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的
设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。
2NF
- 不能存在”部分函数依赖”
- 例如:学号,课程能推出分数，但是学号单独也能推出分数，那么它就是不符合2NF的。
3NF
- 不存在传递函数依赖
- 例如:根据学号和系名能够获得系主任，根据学号或者系名都可以单独获得系主任，这就不符合3NF。
函数依赖
完全函数依赖
- 比如可以通过(学号,课程)推出分数，但是不能单独使用学号或者课程来推出分数，那么分区完全依赖于(学号，课程)。即，通过AB能得出C，但是AB单独不能得到C，因此C完全依赖于AB。
部分函数依赖
- 比如通过，(学号，课程) 推出姓名，因为其实直接可以通过，学号推出姓名，所以：姓名 部分依赖于 (学号，课程)
- 即：通过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB。
传递函数依赖
- 比如：学号 推出 系名 ， 系名 推出 系主任， 但是，系主任推不出学号，系主任主要依赖于系名。这种情况可以说：系主任传递依赖于学号
- 通过A得到B，通过B得到C，但是C得不到A，那么说C传递依赖于A。
关系(范式)建模与维度建模
关系(范式)建模
- 关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
维度建模
- 维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。
- 所以把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。
雪花模型与星型模型
- 在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
拉链表
拉链表概述
- 拉链表，
记录每条信息的生命周期，一旦一条记录的生命周期结果，就重新开始一条新的记录，并把当前日期放入生效开始日期。 - 如果当前信息至今有效，在生效结束日期中填入一个极大值(如9999-99-99)
- 拉链表适合于:
数据会发生变化，但是大部分是不变的。 - 比如:订单信息从未支付、已支付、未发货、已完成等状态经历了一周，大部分时间是不变化的。如果数据量有一定规模，无法按照每日全量的方式保存。比如:1亿用户*365天，每天一份用户信息。就可以使用拉链表来解决该问题。
接下来会使用一篇文章对拉链表进行单独的介绍。