--------关系
--------范式
一、三种关系
1、一对一关系
关系数据库中,第一个表中的单个行只可以与第二个表中的一个行相关，且第二个表中的一个行也只可以与第一个表中的一个行相关。
2、一对多关系
关系数据库中,第一个表中的单个行可以与第二个表中的一个或多个行相关，但第二个表中的一个行只可以与第一个表中的一个行相关。
一对多并不是一对多列,列不能一对多,只能一对多行。
3、多对多关系
关系数据库中,第一个表中的一个行可以与第二个表中的一个或多个行相关。第二个表中的一个行也可以与第一个表中的一个或多个行相关。
举个栗子:
科目表与学生表,这俩个表存在这种现象:一个科目存在多个对应的学生,一个学生也可以学习多个科目.
这种现象为多对多关系,要表示多对多的关系,必须创建第三张表"链接表",然后将前两张表中的主键存入链接表,通过链接表记录匹配关系.
二、范式
1、1NF(第一范式)
1NF的定义为：符合1NF的关系中的每个属性都不可再分。
第一范式是指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如下表所示,不符合1NF:
简而言之，第一范式就是无重复的列。
例如，
由“职工号”“姓名”“电话号码”组成的表(一个人可能有一部办公电话和一部移动电话)，
这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性，即职工(职工号，姓名，办公电话，移动电话)。
再如下图所示
虽然符合1NF,但是存在冗余过大/插入异常/删除异常/修改异常
①每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
②假如新增系,无法单独添加系名与系主任——插入异常
③假设与某个系相关的学生全部删除,那么该系都会被删除——删除异常
④假设一名同学转系,为了保证数据库数据的统一性,需要修改三条记录中系与系主任的数据。——修改异常。
正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。
2、第二范式
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
例如，
在选课关系表(学号，课程号，成绩，学分)，关键字为组合关键字(学号，课程号)，
但由于非主属性学分仅依赖于课程号，对关键字(学号，课程号)只是部分依赖，而不是完全依赖，
因此此种方式会导致数据冗余以及更新异常等问题，解决办法是将其分为两个关系模式：
学生表(学号，课程号，分数)和课程表(课程号，学分)，
新关系通过学生表中的外关键字课程号联系，在需要时进行连接。
3、第三范式
NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
以学生表(学号，姓名，课程号，成绩)为例，其中学生姓名无重名，
所以该表有两个候选码(学号，课程号)和(姓名，课程号)，故存在函数依赖：
学号——>姓名，(学号，课程号)——>成绩，
唯一的非主属性成绩对码不存在部分依赖，也不存在传递依赖，所以属性属于第三范式。
4、BC范式
构建在第三范式的基础上，如果关系模型R是第一范式，且每个属性都不传递依赖于R的候选键，那么称R为BCNF的模式。
假设仓库管理关系表(仓库号，存储物品号，管理员号，数量)，满足一个管理员只在一个仓库工作；一个仓库可以存储多种物品，则存在如下关系：
(仓库号，存储物品号)——>(管理员号，数量)
(管理员号，存储物品号)——>(仓库号，数量)
所以，(仓库号，存储物品号)和(管理员号，存储物品号)都是仓库管理关系表的候选码，表中唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库号)——>(管理员号)
(管理员号)——>(仓库号)
即存在关键字段决定关键字段的情况，因此其不符合BCNF。
把仓库管理关系表分解为两个关系表仓库管理表(仓库号，管理员号)和仓库表(仓库号，存储物品号，数量)，
这样这个数据库表是符合BCNF的，并消除了删除异常、插入异常和更新异常。