Mysql数据库 关系和范式

关系
将实体与实体的关系，反应到最终数据库表的设计上来，将关系分成三种，一对一，一对多
（多对一）和多对多
所有的关系都是指的表与表之间的关系

一对一
一对一：一张表的一条记录一定只能与另一张表的一条记录进行对应，反之亦然
学生表：姓名，性别，身高，体重，婚姻状况，籍贯，家庭住址，紧急联系人
 ID(P)  姓名  性别  年龄  体重  身高  婚姻  籍贯  住址  联系人
 |         |        |       |        |       |        |        |       |        |       |


表设计成以上这种形式：符合要求，其中姓名，性别，年龄，身高体重属于常用数据，但是婚姻，
籍贯，住址和联系人属于不常用数据，如果每次查询都是查询所有数据，不常用的数据就会影响
效率，实际又不用
解决方案：将常用的和不常用的信息分离存储，分成两张表
常用信息表
 ID(P)  姓名  性别  年龄  体重  身高
 |        |        |        |        |       |   


不常用信息表：保证不常用信息与常用信息一定能够对应上，找一个具有唯一性（确定记录）
的字段来共同连接两张表
ID(P) 婚姻  籍贯  住址  联系人
|       |        |        |        | 

一个常用表中的一条记录，永远只能在一张不常用表中匹配一条记录，反过来，一个不常用表中
的一条记录在常用表中也只能匹配一条记录，一对一的关系

一对多
一对多：一张表中有一条记录可以对应另一张表中的多条记录，但是返回过另外一张表
的一条记录只能对应第一张表的一条记录，这种关系就是一对多或者多对一
母亲与孩子的关系，母亲，孩子两个实体
妈妈表
ID(P)     名字       年龄        性别
|            |            |             |

孩子表
ID(P)     名字       年龄        性别
|           |             |              |

以上关系：一个妈妈可以在孩子中找到多条记录（也有可能是一条），但是一个孩子只能找
到一个妈妈，是一种典型的一对多的关系
但是以上设计，解决了实体的设计表问题，但是没有解决关系问题，孩子找不出妈妈，妈妈也
找不到孩子
解决方案，在某一张表中增加一个字段，能够找到另外一张表中的记录，应该在孩子表中增加
一个字段指向妈妈表，因为孩子表的记录只能匹配到一条妈妈表的记录

妈妈表
ID(P)     名字       年龄        性别
|         |          |           |

孩子表
ID(P)     名字       年龄        性别     妈妈ID
|           |             |              |          | 妈妈表主键

多对多
多对多：一张表中（A)的一条记录能够对应另一张表（B）中的多条记录，同时B表中的一条
记录也能对应A表中的多条记录，多对多的关系
老师教学，老师和学生
老师表
T_ID(P)        姓名          性别
|1               | A             |男
|2               | B             |女

学生表
S_ID(P)        姓名          性别
|1               |张三          |男
|2               |小芳          |女

以上设计方案：实现了实体的设计，但是没有维护实体的关系
一个老师教过多个学生，一个学生也被多个老师教过
解决方案：在学生表中增加老师字段，不管在哪张表中增加字段，都会出现一个问题，该字段
要保存多个数据，而且是与其他表有关系的字段，不符合表设计规范，增加一张新表，
专门维护两张表之间的关系
老师表
T_ID(P)        姓名          性别
|1               | A             |男
|2               | B             |女

学生表
S_ID(P)        姓名          性别
|1                |张三          |男
|2                |小芳          |女

中间关系表：老师与学生之间的关系
ID            T_ID(老师)      S_ID
| 1            | 1               | 1
| 2            | 1               | 2
| 3            | 2               | 1
| 4            | 2               | 2

增加中间表之后：中间表与老师表形成了一对多的关系，而中间表的多表，维护了能够唯一
找到一表的关系，同样学生表与中间表也是一对多的关系，一对多的关系可以匹配到
关联表之间的数据
学生找老师：找出学生ID-- 中间表寻找匹配记录（多条）--老师表匹配（一条）
老师找学生：找出老师ID-- 中间表寻找匹配记录（多条）--学生表匹配（一条）

范式
范式：Nomal Format,是一种离散数学中的知识，是为了解决数据的存储与优化的问题，
保存数据的存储之后，凡是能够通过关系寻找出来的数据，坚决不在重复存储，终极目标是
为了减少数据的冗余

范式：是一种分层结构的规范，分为6层，每一层都比上一层更加严格，若要满足下一层范式
前提是满足上一层范式

6层范式：1NF 2NF 3NF...6NF，1NF是最底层，要求最低 6NF最高最严格

MYSQL属于关系型数据库，有空间浪费，也是致力于节省存储空间，于范式所有解决的问题
不谋而合，在设计数据库的时候，会利用到范式来指导设计
但是数据库不单是要解决空间问题，要保证效率问题，范式只为解决空间问题，所有数据库
的设计又不能完全按照范式的要求实现，一般情况下只要前三种范式需要满足
范式在数据库的设计当中是由直到意义，但是不是强制规范

1NF
第一范式：在设计表存储存储数据的时候，如果表中设计的字段存储的数据，在取出来使用之前
还需要额外的处理（拆分），那么说表的设计不满足第一范式，第一范式要求字段的数据具有
原子性，不可拆分
讲师代课表
讲师      性别   班级        教室      代课时间    代课时间（开始，结束）
朱元璋  Male   php0226 D302    30天         2017-02-12,2017-03-12
朱元璋  Male   php0320 D206    20天         2017-03-31,2017-04-20
李世民  Male   php0320 D206    15天         2017-06-01,2017-06-16 

上表设计不存在问题，但是如果需求是将数据查出来之后，要求显示一个老师从什么时候开始
上课到什么时候结束，需要将代课时间进行拆分，不符合1NF，数据不具有原子性，可以再拆分
解决方案;将代课时间拆分两个字段就可以解决问题
讲师     性别     班级       教室      代课时间   开始              结束
朱元璋  Male   php0226 D302    30天         2017-02-12   2017-03-12
朱元璋  Male   php0320 D206    20天         2017-03-31   2017-04-20
李世民  Male   php0320 D206    15天         2017-06-01   2017-06-16

2NF
第二范式：在数据表设计的过程中，如果有复合主键（多字段主键），且表中有字段并不是由整个
主键来确定，而是依赖主键中的某个字段（主键的部分），存在字段依赖主键的部分的问题，
程之为部分依赖，第二范式就是要解决表设计不允许出现部分依赖
讲师代课表
讲师P   性别     班级P     教室      代课时间   开始             结束
朱元璋  Male   php0226 D302    30天         2017-02-12   2017-03-12
朱元璋  Male   php0320 D206    20天         2017-03-31   2017-04-20
李世民  Male   php0320 D206    15天         2017-06-01   2017-06-16

以上表中：因为讲师没有办法作为独立主键，需要结合班级才能作为主键（复合主键，一个老师在
一个班级永远只带一个阶段的课），代课时间，开始和结束字段都与当前的代课主键（讲师和班级），
但是性别并不依赖班级，教室不依赖讲师，性别只依赖讲师，教室只 依赖班级，出现了性别和
教室依赖主键的中的一部分，部分依赖不符合第二范式

解决方案1：可以将性别与讲师单独成表，班级和教室也单独成表
解决方案2：取消复合主键，使用逻辑主键
ID(P)  讲师    性别     班级        教室      代课时间   开始             结束
 1      朱元璋  Male   php0226 D302    30天         2017-02-12   2017-03-12
 2      朱元璋  Male   php0320 D206    20天         2017-03-31   2017-04-20
 3      李世民  Male   php0320 D206    15天         2017-06-01   2017-06-16
ID = 讲师 + 班级

3NF
要满足第三范式，必须满足第二范式
第三范式：理论上讲应该一张表中的所有字段都应该依赖主键（逻辑主键，代表的是
业务主键），如果表设计中存在一个字段，并不直接依赖主角键，而是通过某个非主键字
段依赖，最终实现依赖主键，把这种不直接依赖主键，而是依赖非主键字段的依赖关系称
之为传递依赖，第三范式就是解决传递依赖的问题
讲师代课表
ID(P)  讲师    性别      班级       教室     代课时间   开始              结束
 1      朱元璋  Male   php0226 D302    30天         2017-02-12   2017-03-12
 2      朱元璋  Male   php0320 D206    20天         2017-03-31   2017-04-20
 3      李世民  Male   php0320 D206    15天         2017-06-01   2017-06-16

以上设计方案中，性别依赖讲师存在，讲师依赖主键，教室依赖班级，班级依赖主键，性别和
教室都存在传递依赖
解决方案：将存在传递依赖的字段，以及依赖的字段的字段本身单独取出，形成一个单独的表，
然后在需要对应的信息的时候，使用对应的实体表的主键
讲师代课表
ID(P)   讲师ID   班级ID   代课时间   开始             结束
1        1           10          30天        2017-02-12   2017-03-12
2        1           12          20天        2017-03-31   2017-04-20
3        2           12          15天        2017-06-01   2017-06-16
讲师表   ID = 讲师
ID       讲师      性别       
1        朱元璋    Male
2        李世民    Male
讲师表   ID = 讲师
ID       讲师      性别       
1        朱元璋    Male
2        李世民    Male

逆规范化
有时候，在设计表的时候，如果一张表中由几个字段是需要从另外的表中获取信息，理论
上讲，的确可以获取到想要的数据，但是就是效率低一点，会刻意的在某些表中，不去保存
另外表达主键（逻辑主键），而直接保存想要的数据信息，这样一来在查询数据的时候，
一张表可以直接提供数据，而不需要多表查询（效率低），但是会导致数据冗余增加

如讲师代课信息表
ID(P)   讲师ID   班级ID       代课时间    开始              结束
1       朱元璋     php0226   30天          2017-02-12   2017-03-12
2       朱元璋     php0320   20天          2017-03-31   2017-04-20
3       李世民     php0320   15天          2017-06-01   2017-06-16
讲师表   ID = 讲师
ID       讲师      性别       
1        朱元璋    Male
2        李世民    Male
讲师表   ID = 讲师
ID       讲师      性别       
1        朱元璋    Male
2        李世民    Male

逆规范化：磁盘利用率与效率的对抗