MySQL篇（数据库范式）(持续更新迭代）
目录
巴斯-科德范式（BCNF，Boyce-Codd Normal Form）
一、什么是范式
范式（数据库设计范式，数据库的设计范式）是符合某一种级别的关系模式的集合。
构造数据库必须遵循一定的规则。
在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。
二、三大范式
第一范式（1NF）
在任何一个关系数据库中，
第一范式（1NF是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，
即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，
新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
第一范式 (1NF) 示例：
订单表 (Orders)：
| OrderID | CustomerName | Products |
| 1 | John | Product1, Product2 |
| 2 | Jane | Product3 |
| 3 | Bob | Product1, Product3 |
在上面的表中，每个单元格包含原子值，没有多值属性，因此符合第一范式（1NF）。
第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，
即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。
这个唯一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，
新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。
简而言之，第二范式就是非主属性完全依赖于主关键字。
第二范式 (2NF) 示例：
如果我们将产品表（Products）引入，它包含了产品信息，包括产品号（ProductID）、产品名称（ProductName）和产品描述
（ProductDescription）。
订单表 (Orders)：
| OrderID | CustomerName |
| 1 | John |
| 2 | Jane |
| 3 | Bob |
产品表 (Products)：
| ProductID | ProductName | ProductDescription |
| 1 | Product1 | Description1 |
| 2 | Product2 | Description2 |
| 3 | Product3 | Description3 |
产品表（Products）和订单表（Orders）之间存在关系，通过“产品号”（ProductID）来连接
这符合第二范式（2NF），因为非主键属性（如“产品描述”）依赖于整个候选键（“产品号”）。
第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。
简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息
表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性。
第三范式 (3NF) 示例：
如果我们在订单表（Orders）中添加一个新的属性，比如“客户地址”（CustomerAddress）：
订单表 (Orders)：
| OrderID | CustomerName | CustomerAddress |
| 1 | John | Address1 |
| 2 | Jane | Address2 |
| 3 | Bob | Address1 |
在这种情况下，客户地址（CustomerAddress）依赖于“客户名称”（CustomerName），而不是订单号
（OrderID）。这违反了第三范式（3NF）。
为了符合3NF，我们应该将“客户地址”移动到一个独立的客户表，其中“客户名称”是主键，然后在订单表中使
用客户名称作为外键来建立关联。
三、其它范式
巴斯-科德范式（BCNF，Boyce-Codd Normal Form）
某些特殊情况下，即使关系模式符合3NF的要求，仍然存在着插入异常，修改异常与删除异常的问题。
BCNF由Boyce与Codd提出，通常被认为是修正的第三范式。
巴斯-科德范式即在满足第三范式（3NF）基础上，任何非主属性不能对主键子集依赖
（即在3NF基础上，消除主属性对候选码的部分函数依赖和传递函数依赖）。
BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。
满足BC范式的关系都必然满足第三范式。
或者还可以换一种说法：
若一个关系达到了第三范式，并且它只有一个候选码，
或者它的每个候选码都是单属性，则该关系自然达到BC范式。
一般来说，一个数据库设计符合3NF或BCNF就可以了。
第四范式（4NF）
多值依赖的概念：
多值依赖即属性之间的一对多关系，记为K→→A。函数依赖事实上是单值依赖，所以不能表达属性值之间的一对
多关系。
平凡的多值依赖：
全集U=K+A，一个K可以对应于多个A，即K→→A。此时整个表就是一组一对多关系。
非平凡的多值依赖：全集U=K+A+B，一个K可以对应于多个A，也可以对应于多个B，A与B互相独立，即
K→→A，K→→B。
整个表有多组一对多关系，且有：“一”部分是相同的属性集合，“多”部分是互相独立的属性集合。
第四范式即在满足巴斯-科德范式（BCNF）的基础上，消除非平凡且非函数依赖的多值依赖（即把同一表内的多对多关系删除）。
第五范式（5NF）
即在满足第四范式（4NF）的基础上，消除不是由候选码所蕴含的连接依赖。
如果关系模式R中的每一个连接依赖均由R的候选码所隐含，则称此关系模式符合第五范式。
函数依赖是多值依赖的一种特殊的情况，而多值依赖实际上是连接依赖的一种特殊情况。
但连接依赖不像函数依赖和多值依赖可以由语义直接导出，而是在关系连接运算时才反映出来。
存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题。
原文地址：https://blog.csdn.net/qq_51226710/article/details/142349810
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！