1 表的分类

1.1 实体表

定义：一般指一个现实存在的业务对象，比如用户，商品，商家，销售员等等

例：

用户表 用户id姓名生日性别邮箱用户等级创建时间1张三2011-11-11男zs@163.com22018-11-112李四2011-11-11女ls@163.com32018-11-113王五2011-11-11男ww@163.com12018-11-11.....................

 

 

 

 

 

 

 

1.2 维度表

订单状态表 订单状态编号订单状态名称1未支付2支付3发货中4已发货5已完成

 

 

 

 

 

 

 

商品分类表 商品分类编号分类名称1少儿2文艺3生活4科技

 

 

 

 

 

 

1.3 事务型事实表

定义：一般指随着业务发生不断产生的数据，特点是一旦发生，不会再变化，比如交易流水、操作日志、出入库记录等

交易流水表 编号对外业务编号订单编号用户编号支付宝流水编号支付金额交易内容支付类型支付时间186485165987511QEjE-659487256260手机壳alipay2019-02-10 00:50:02232549875624522QEjE-695487521260手机壳wechatpay2019-02-10 00:50:02365847951842333QEjE-154236487260手机壳wechatpay2019-02-10 00:50:02...........................

 

 

 

 

 

 

1.4 周期型事实表

定义：一般指随着业务发生不断变化的数据，比如订单中的订单状态，会发生变化，或者请假、贷款申请等

订单表 订单编号订单金额订单状态用户id支付方式支付流水号创建时间操作时间126021alipayQEjE-6594872562019-02-10 00:50:022019-02-10 00:50:02226022wechatpayQEjE-6954875212019-02-10 00:50:022019-02-10 00:50:02326013wechatpayQEjE-1542364872019-02-10 00:50:022019-02-10 00:50:02........................

 

 

 

 

 

 

2 同步策略

数据同步策略的类型包括全量表、增量表、新增及变化表、拉链表等，全量表存储完整的数据，增量表存储新增加的数据，新增及变化表存储新增加的数据和变化的数据，拉链表对新增及变化表做定期合并。

2.1 实体表同步策略

对于实体表，数据量比较小，通常可以做每日全量，即全量表

2.2 维度表同步策略

维度表数据量较小，也可以做每日全量，即全量表，但是针对不同的维度，可能会有不同的处理方式，比如可能有变化的维度数据，可以存储每日全量，对于没变化的客观世界的维度，比如性别、地区、民族、政治成分、鞋子尺码等，可以只存一分固定值即可，表可以不用分区。

2.3 事务型事实表同步策略

因为数据不会变化，而且数据量巨大，所以每天只同步新增数据即可，即每日创建一个分区进行分区存储，即增量表

2.4 周期型事实表同步策略

这类表，从数据量角度来考虑，存全量表的话，数据量会很大，冗余也会很大，但是如果用每日增量表，又无法反映出数据的变化。那么新增及变化表好像比较符合情景，在某些程度上来说也是可以的，但是存在一个问题，无法解决想要得到某一历史时间点（时间切片）的切片数据。所以为了解决这个问题，要利用每日新增和变化表，制作一张拉链表，以方便的取到某个时间切片的快照数据，即拉链表。

例：

name(姓名)start（新名字创建时间）end（名字更改时间）张三1990-01-012018-12-31张三三2019-01-019999-99-99.........

 

 

 

 

 

要知道某一时刻，这个人的名称，可使用该语句对拉链表进行查询，SELECT * FROM user WHERE start<'2020-01-01' AND end>'2020-01-01'

3 范式理论

3.1 范式概念

关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性，目前业界范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）、第五范式（5NF）。范式的标准定义：符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。通俗地讲，范式可以理解为一张数据表的表结构，所符合的某种设计标准的级别。使用范式的根本目的是，1）减少数据冗余，尽量让每个数据只出现一次。2）保证数据一致性。缺点是获取数据时，需要使用join进行拼接。

3.2 函数依赖

示例用表

学号姓名系名系主任课名分数1022211101李小明经济系王强高等数学951022211101李小明经济系王强大学英语871022211102张莉莉经济系王强计算机基础761022211102张莉莉经济系王强高等数学981022511101高芳芳法律系刘玲法学基础99

 

 

 

 

 

 

 

3.2.1 完全函数依赖

数学定义：设X，Y是关系R的两个属性集合，X'是X的真子集，存在X→Y，但对每一个X'都有X'!→Y，则称Y完全函数依赖于X。记做

解释：通过（学号，课程）可以推出分数，但是如果只有学号，则无法得到分数，那么可以说分数完全依赖于（学号，课程），即通过AB能得到C，但是AB单独都得不到C，那么就说C完全依赖于AB，记做

3.2.2 部分函数依赖

数学定义：假如Y函数依赖于X，但同时Y并不完全函数依赖于X，那么我们就称Y部分函数依赖于X，记做

解释：通过（学号，课程）推出姓名，但是通过学号可以直接推出姓名，所以姓名部分依赖于（学号，课程），即通过AB能得出C，通过A也能得出C，或通过B也能得出C，那么说C部分依赖于AB

3.2.3 传递函数依赖

数学定义：设X，Y，Z是关系R中互不相同的属性集合，存在X→Y(Y!→X)，Y→Z，则称Z传递函数依赖于X。记做

解释：学号推出系名，系名推出系主任，但是，系主任推不出学号，系主任主要依赖于系名，这种情况可以说系主任传递依赖于学号

3.3 三范式

3.3.1 第一范式

第一范式的原则就是属性不可切分，实际上，第一范式是所有关系型数据库的最基本要求，如果在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的，也就是说，只要在RDBMS中建立的数据表，一定是符合1NF的

不符合第一范式表格示例 ID商品商家ID用户ID0015台电脑xxx旗舰店00001

 

 

 

解读：商品列中的数据，不是原子数据项，是可以进行分割的

表修改 ED商品数量商家ID用户ID001电脑5xxx旗舰店00001

 

 

 

3.3.2 第二范式

第二范式的原则是不能存在部分函数依赖，如3.2.2所示，假设3.2示例用表主键为（学号，课名），分数是完全依赖的，但是姓名并不完全依赖于（学号，课名），所以需要对示例用表，进行如下拆分

学号课名分数1022211101高等数学951022211101大学英语871022211102计算机基础761022211102高等数学981022511101法学基础99

 

 

 

 

 

 

学号姓名系名系主任1022211101李小明经济系王强1022211102张莉莉经济系王强1022511101高芳芳法律系刘玲

 

 

 

 

 

3.3.3 第三范式

第三范式的原则是不能存在穿衣函数依赖，例如3.3.2中第二张表所示，学号→系名→系主任，但是无法反推，所以存在传递函数依赖，需要对该表继续进行拆分

学号姓名系名1022211101李小明经济系1022211102张莉莉经济系1022511101高芳芳法律系

 

 

 

 

系名系主任经济系王强法律系刘玲

 

 

 

 

4 关系建模与维度建模

4.1 关系建模

关系模型主要应用于OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的

PS：什么是OLTP？OLTP（On-Line Transaction Processing）联机事务处理过程(OLTP)，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。具体可以查看百度百科，有更加详细的解释，网址：https://baike.baidu.com/item/OLTP/5019563?fr=aladdin。

4.2 维度建模

维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，但是在大规模数据跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率，所以把相关各种表整理成两种，事实表和维度表，所有维度表围绕着事实表进行解释。

PS：什么是OLAP？OLAP（On-Line Transaction Processing）联机分析处理展现在用户面前的是一幅幅多维视图。维（Dimension）：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等），具体可以查看百度百科，网址：https://www.baidu.com/link?url=Eek_GqLlxurNBLIzFrW6V1hGvqOmPbv4EKuL8Z_kDUgIZV5KSUdf_65o3kJvcDLGuTY0F37SlaEhq0QD79cWOFcRI3J5CPN-fsKjLqIQwF9U3c5sfZLAH48Hq-PduaVkzaRGgX6nBnf7KqD4ovKOUff7WL4TGJXtGIo3TbPsavIEzqwokqUIuclV7BCgn2D5&wd=&eqid=e7f57b210001a6c8000000025f006b14

5 维度建模模型

5.1 星型模型

雪花模型与星型模型的区别主要在于维度的层级，标准的星型模型维度只有一层，而雪花模型会涉及很多层

星型模型图示

5.2 雪花模型

雪花模型介于关系模型和星座模型之间，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高。

雪花模型图示

5.3 星座模型

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

5.4 模型的选择

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