第1章 电商业务与数据结构简介
1.1 电商业务流程
电商业务流程
1.2 电商常识（SKU、SPU）
- SKU=Stock Keeping Unit（库存量基本单位）。现在已经被引申为产品统一编号的简称，每种产品均对应有唯一的SKU号。
- SPU(Standard Product Unit)：是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息集合。
比如，咱们购买一台iPhoneX手机，iPhoneX手机就是一个SPU，但是你购买的时候，不可能是以iPhoneX手机为单位买的，商家也不可能以iPhoneX为单位记录库存SKU。必须要以什么颜色什么版本的iPhoneX为单位。比如，你购买的是一台银色、128G内存的、支持联通网络的iPhoneX，商家也会以这个单位来记录库存数。那这个更细致的单位就叫库存单元（SKU）。
那SPU又是干什么的呢？
SPU
SPU表示一类商品。好处就是：可以共用商品图片，海报、销售属性等。
1.3 电商表结构
电商表结构
1.3.1 订单表（order_info）
订单表
1.3.2 订单详情表（order_detail）
订单详情表
1.3.3 商品表
商品表
1.3.4 用户表
用户表
1.3.5 商品一级分类表
商品一级分类表
1.3.6 商品二级分类表
商品二级分类表
1.3.7 商品三级分类表
商品三级分类表
1.3.8 支付流水表
支付流水表
第2章 数仓理论（面试重点）
2.1 表的分类
2.1.1 实体表
实体表，一般是指一个现实存在的业务对象，比如用户，商品，商家，销售员等等。
用户表：
实体表
2.1.2 维度表
维度表，一般是指对应一些业务状态，编号的解释表。也可以称之为码表。
比如地区表，订单状态，支付方式，审批状态，商品分类等等。
维度表
2.1.3 事务型事实表
事务型事实表，一般指随着业务发生不断产生数据。特点是一旦发生不会再变化。
一般比如，交易流水，操作日志，出库入库记录等等。
事务型事实表
2.1.4 周期型事实表
周期型事实表，一般指随着业务发生不断产生变化(更新, 新增)的数据。
与事务型不同的是，数据会随着业务周期性的推进而变化。
比如订单，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。
订单表：
周期型事实表
2.2 同步策略
数据同步策略的类型包括：全量表、增量表、新增及变化表、拉链表
- 全量表：存储完整的数据。
- 增量表：存储新增加的数据。
- 新增及变化表：存储新增加的数据和变化的数据。
- 拉链表：对新增及变化表做定期合并。
2.2.1 实体表同步策略
实体表：比如用户，商品，商家，销售员等
实体表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。
2.2.2 维度表同步策略
维度表：比如订单状态，审批状态，商品分类
维度表数据量比较小：通常可以做每日全量，就是每天存一份完整数据。即每日全量。
说明：
1）针对可能会有变化的状态数据可以存储每日全量。
2）没变化的客观世界的维度（比如性别，地区，民族，政治成分，鞋子尺码）可以只存一份固定值。
2.2.3 事务型事实表同步策略
事务型事实表：比如，交易流水，操作日志，出库入库记录等。
因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，所以可以做成每日增量表，即每日创建一个分区存储。
2.2.4 周期型事实表同步策略
周期型事实表：比如，订单、请假、贷款申请等
这类表从数据量的角度，存每日全量的话，数据量太大，冗余也太大。如果用每日增量的话无法反应数据变化。
每日新增及变化量，包括了当日的新增和修改。一般来说这个表，足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点（时间切片）的切片数据。
所以要用利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。
拉链表
2.3 范式理论
2.3.1 范式概念
关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性，目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
范式可以理解为设计一张数据表的表结构，符合的标准级别。
使用范式的根本目的是：
1）减少数据冗余，尽量让每个数据只出现一次。
2）保证数据一致性
缺点是获取数据时，需要通过Join拼接出最后的数据。
2.3.2 函数依赖
函数依赖
2.3.3 三范式区分
三范式区分
二范式区分
三范式区分
未完待续