MySQL -- 范式

一、需要明确数据库中相关的概念

• 实体：现实世界中客观存在并可以被区别的事物，比如“一个学生”、“一本书”、“一门课”等等。
  值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，比如说“老师与学校的关系”。

• 属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。

• 元组：表中的一行就是一个元组。

• 分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系型数据库了。

• 码（键）：表中可以唯一确定一个元组的某个属性（或者属性组），
    如果这样的码有不止一个，那么它们都被称作候选码（候选键），
    我们从候选码中挑选一个出来，它就叫主码（主键）。

• 全码：如果一个码包含了所有的属性，这个码就是全码。

• 主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。

• 非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

• 外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。

二、依赖

• 依赖：在数据表中，属性（属性组）X确定的情况下，可以完全确定属性Y，就可以说属性Y是依赖于属性（属性组）X的，记作X→Y；
• 完全依赖：完全依赖是针对属性组来说的，当一组属性X能确定Y的时候就可以说Y完全依赖于X；
• 部份依赖：一组属性X中的其中一个或几个属性能确定Y就说Y部份依赖于X；
• 函数传递依赖：设X，Y是关系R中互不相同的属性集合，存在X→Y(Y!→X)，Y→Z，则称Z传递函数依赖于X；

三、范式

1. 第一范式（1NF）

特点：每一列要保持原子特征
  列是基本数据项，不能进行拆分，否则设计成一对多的关系；
 因为不满足第一范式，就不能称之为关系型数据库；

例1：
学生表（学号、姓名、性别、年龄、地址）
地址1：陕西省西安市****大学
地址2：陕西省显示 ** 区 ** 路 ****大学

地址信息包含省市区可以拆分
拆分改造后：
学生表（学号、姓名、性别、年龄、地址ID）
地址表（地址ID、省、市、区）

例2：
  下表就是不符合第一范式所规定的原子性的，不符合关系型数据库的基本要求的话，在关系型数据库中这个表的操作就不成功；

将上面的数据表重新设计成下表：

2. 第二范式（2NF）

特点：属性必须依赖于主键（针对联合主键 来消除部分依赖）（当一个第一范式的候选键只有一个属性的时候，它就是第二范式）

  在1NF的基础上，非主属性完全依赖于主键，如果不是依赖主键，应该拆分成新的主体，拆分成一对多的关系；

举例：
学生选课表（学生ID、学生姓名、学生性别、可而成名称、课程成绩）
主键（学生ID、课程名称）

有这样的依赖关系：
学生姓名 → 学生ID → 部分依赖
学生性别 → 学生ID → 部分依赖
课程成绩 → (学生ID、课程名称) →完全依赖

拆分改造后：
学生表（学生ID、学生姓名、学生性别） 主键：学生ID
成绩表（课程ID、课程名、学生ID、成绩） 主键：课程ID
键（课程ID、学生ID）

3. 第三范式（3NF）

特点：在2NF的基础上，属性不依赖于其他非主属性（消除依赖传递）

举例：
学生表（学生ID、学生姓名、学生性别、学院名称、学院电话）
主键：学生ID
依赖关系：

• 学生姓名 → 学生ID
• 学生ID → 学生ID
• 学院名称 → 学生ID
• 学院电话 → 学生ID → 查询学院→ 查询学院电话

拆分改造后：

• 学生表（学生ID、学生姓名、学生性别、学院ID）
  主键：学生ID
• 学院表（学院ID、学院名称、学院电话）
  主键：学院ID

4. BC范式（BCNF）

特点：主属性不能对候选键存在部分函数依赖或者传递函数依赖

  这张表不存在部分函数依赖于传递函数依赖，属于第三范式。

主属性：仓库名、管理员、物品名
非主属性：数量

表中的依赖关系：

• 仓库名→管理员
• 管理员→仓库名
• 物品名→数量

存在的问题：

• 先新增加一个仓库，但尚未存放任何物品，不可以为该仓库指派管理员，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
• 某仓库被清空后，该仓库的信息也被清空。
• 当需要更换仓库管理员，该仓库存放了多少物品，就要修改多少条信息。

  在这个问题中就是存在了主属性对于候选码的部分依赖，也就是仓库名对于管理员和物品名的部分依赖。

修改为
仓库（仓库名，管理员）
库存（仓库名、物品数、数量）

5. 第四范式（4NF）

消除表中的多值依赖

  设R是一个关系模型，D是R上的多值依赖集合。如果D中存在凡多值依赖X→Y时，X必是R的超键，那么称R是第四范式的模式。

  例如，职工表(职工编号，职工孩子姓名，职工选修课程)
  在这个表中，同一个职工可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，不符合第四范式。如果要符合第四范式，只需要将上表分为两个表，使它们只有一个多值事实，例如
  职工表一(职工编号，职工孩子姓名)
  职工表二(职工编号，职工选修课程)
两个表都只有一个多值事实，所以符合第四范式。

总结：

1. 范式之间的关系：
   
2. 通过范式学习：应用范式越高，表越多、会带来的问题

• 查询时需要连接多个表，增加了查询的复杂性；
• 查询时需要连接多个表，降低了数据库查询的性能（效率）；

所以范式并不是越高越好，一般满足3NF即可

四、范式的作用和优点

作用：

  数据库范式是进数据库设计时字段、库表划分的依据；

优点：

• 减少数据冗余（最主要的好处、其他好处因此而附带）；
• 消除异常（插入异常、更新异常、删除异常）；
• 让数据组织的更加和谐。