本文详细解释了数据库设计中的各种范式，如1NF、2NF、3NF、BCNF等，强调了主键、候选键、外键和不同范式之间的关系，以及如何通过实例分析确保数据的一致性和完整性。
范式：在关系型数据库中，关于数据库设计的基本原则
数据库的范式设计的越高阶，冗余度就越低。同时高阶的范式一定符合低范式的要求。
从低到高分为：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯范式（BCNF）、第四范式和第五范式
范式的定义离不开主键和候选键，数据库中的键由一个或者多个属性组成。
以下图为例我们来认识一下各种键
| 球员编号 | 姓名 | 身份证 | 年龄 | 球队编号 |
| 球队编号 | 主教练 | 球队所在地 |
主键（主码）：用户从候选键中选择一个当主键 、能唯一定位（球员编号或者身份证） 主键只能有一个
超键：能唯一标识元组的属性集叫做超键 。就是主键加任意的属性（球员编号加姓名加年龄）
候选键（码）：如果超键不包含多余属性，那么这个超键就是候选键，最小的超键。（球员编号或者身份证号 ） 候选键可以有多个
外键：在一个表里不是主键但在另一个表里是主键。那个这个属性集就是第一个表的外键
（球队编号）
主属性：包含在任一候选键中的属性称为主属性。（球员编号、身份证）
非主属性：就是不是主属性的属性
键是一个或者多个属性组成。针对单个属性，我们可以用主属性和非主属性来进行区别
第一范式
第一范式主要是确保数据表中每个字段的值必须具有原子性。也就是说数据表中每个字段的值不可拆分的最小数据单元
第二范式
第二范式要求，在满足第一范式的基础上，还要满足数据表里每条数据记录，都是可唯一标识的，而且所有非主键字段都必须完全依赖主键（候选键），不能部分依赖主键。如果知道主键的所有属性的值，就可以检索到任何元组的任何属性的任何值
例子
| 学号 | 课程号 | 成绩 |
（学号，课程号）可以决定成绩，但是学号不能决定成绩，课程号也不能决定成绩，所以（学号，课程号）对成绩就是完全依赖关系
| 球员编号 | 比赛编号 | 姓名 | 年龄 | 比赛事件 | 比赛场地 | 得分 |
主键是（球员编号，比赛编号） 姓名和年龄部分依赖主键中球员编号 比赛事件和比赛场地部分依赖主键中的比赛编号。 得分完全依赖于主键
（球员编号)---->(姓名，年龄)
（比赛编号）--->（比赛时间，比赛场地）
第三范式（第二范式不能有部分函数依赖，第三范式不能有传递函数依赖）
第三范式在第二范式的基础上，确保数据表中每个非主属性字段都和主关键字直接相关，要求数据表中的所有非主键字段不能依赖于其他非主键字段
| 商品主键ID（主键） | 商品类别ID | 商品类别名称 | 商品名称 | 商品价格 |
商品类别名称依赖于商品类别编号ID，不符合第三范式
| 商品类别ID |
| 商品类别名称 |
| 球员编号 | 姓名 | 球队名称 | 球队教练 |
球队教练依赖球队名称
巴斯范式
若一个关系达到了第三范式，并且它只有一个候选键，或者它的每个候选键都是单属性，则该关系达到巴斯范式
| 仓库名 | 管理员 | 物品名 | 数量 |
| 北京仓 | 张三 | 宝马 | 10 |
| 北京仓 | 张三 | 奔驰 | 20 |
| 上海仓 | 李四 | 捷豹 | 30 |
| 上海仓 | 李四 | 布加迪 | 40 |
仓库名觉得管理员，管理员觉得仓库名
候选键：（管理员，物品名）和（仓库名，物品名）。从二者选一个做主键
主属性：包含任一候选键中的属性，也就是仓库名，管理员和物品名
非主属性：数量这个属性
假设将（仓库名，物品名）做主键
主属性的仓库名对于候选键中（管理员，物品名）是部分依赖的关系。因为仓库名和管理员是一一对应的关系
解决办法：
拆分成两个表：仓库表：（仓库名，管理员）、库存表（仓库名，物品名，数量）
第四范式
多值依赖的概念：
多值依赖：即属性间一队多关系
函数依赖：就是单值依赖，所以不能表达属性值之间的一对多的关系
| 职工编号 | 职工孩子姓名 | 职工选修课程 |
职工可能会有多个职工孩子的名字。同一个职工也可能有多个职工选修课程。不符合第四范式
解决：
拆成（职工编号，职工孩子姓名）和（职工编号，职工选修课程）
第五范式
如果关系模式R中每一个连接依赖由R的候选键所隐含，则称此关系模式符合第五范式
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
