【数据库系统概论】数据库三类范式和BC范式

前：需要了解掌握函数依赖、传递性函数依赖、闭包、候选键等内容。

第一范式
第一范式也叫原子性，是针对数据列名的规定。在数据库中，数据列是不可再分的，并且每一条记录都是唯一的。如果列名可以再分（比如将name分为姓和名），比如Star(name, address(street, city))，那么就不满足第一范式。多值属性指的是，记录中的某一个属性存在多个值，比如（‘001912’，‘李明’，‘计算机系’），（‘001912’，‘李明’，‘自动化系’）

怎么处理？
1、将非1NF转化为1NF
Star(name, address)或者Star(name, street, city)
2、引入新的数据模型
加入面向对象模型（Object-Oriented Data Model）

第二范式
在满足第一范式的条件下，非主属性完全依赖于候选键。

必须理解：候选键、非主属性、完全函数依赖。

具有关系R（U）
候选键（X）：能够完全决定的属性（组）
非主属性：不在候选键的属性，称为非主属性。
完全函数依赖：X决定Y，X中任意真子集（X‘）都不能决定Y

【例子】R(S#, SN, SD, CN, G)，S#：学号，SN：姓名，SD：班级，CN：课程，G：成绩，判断其是否满足第二范式。
1、确定函数依赖
函数依赖：S#->SN，S#->SD，「S#，CN」->G
候选键：「S#，CN」，非主属性：「SN，SD，G」
2、是否为完全函数依赖
「S#，CN」部分决定「SN，SD」
也就是说：只有S#就可以决定SN和SD，那么是部分函数依赖，所以不满足第二范式。

问题：如何将不满足第二范式的关系进行更改，使其满足第二范式？
解决方法：对该关系模式进行分解成多个关系模式
将R(S#, SN, SD, CN, G)转化为： R1(S#, SN, SD)，R2(S#, CN, G)

【练习】学生（学号，姓名，班级，课号，课程名，成绩，教师，教师职务）是否满足第二范式？
满足第一范式。
1、确定函数依赖
「学号」->「姓名，班级」
「课号」->「课程名，教师，教师职务」
「学号，课号」->「成绩」
候选键：「学号，课号」
2、判断是否为完全函数依赖
「学号」可以决定「姓名」，… ，所以是部分函数依赖

第三范式
满足第二范式的条件下，没有传递函数依赖。
【例子】商店（商店号，商品号，经营部，经理）
1、函数依赖
「经营部」-> 「经理」
「商店号，商品号」 -> 「经营部」
「商店号，经营部」 -> 「经理」
候选键：「商店号，商品号，经营部」，非主属性：「经理」
2、是否为完全函数依赖？
不是完全函数依赖
3、是否存在传递函数依赖？
不属于第三范式
（具有传递函数依赖关系。「商点号，商品号」决定「经营部」；「经营部」决定「经理」，「商点号，商品号」决定「经理」）

第三范式
消除非主属性对（候选键\非主属性之间）的传递依赖

【练习】员工（员工码，姓名，部门，部门经理）是否满足第三范式？
1、满足第一范式
2、满足第二范式
（1）函数依赖
「员工码」->「姓名，部门，部门经理」
「部门」->「部门经理」
候选键「员工码」，非主属性：「姓名，部门，经理」
满足第二范式
3、不满足第三范式
员工码决定部门，部门决定部门经理。不满足第三范式

BC范式。函数依赖的「决定因子」->「决定属性」，中的“所有的”「决定因子」都在候选键中则为BC范式。
【例】邮编（城市，街道，邮政编码）
1、函数依赖
「城市，街道」->「邮政编码」
「邮政编码」->「城市」
2、范式
（1）满足1NF。
（2）满足2NF。「邮政编码」完全函数依赖于「城市，街道」。即，「城市」不能单独决定「邮政编码」，「街道」也不能单独决定「邮政编码」。
（3）没有传递函数依赖，满足3NF。
（4）是否满足BCNF？
由于「邮政编码」->「城市」中的「邮政编码」是决定因子，但是不包含在候选键内，所以不满足BCNF。

【例】选课（学号，课程号，教师编号）
1、函数依赖
「学号，课程号」->「教师编号」
「教师编号」->「课程号」
2、满足的范式
（1）满足1NF。
（2）是完全函数依赖，满足2NF。
（3）没有传递函数依赖，满足3NF。
（4）「教师编号」不属于候选键，所以不满足BCNF
满足BCNF，那么一定是3NF

写在最后：新成立了一个AI分享社区，欢迎大家踊跃加入。
https://t.zsxq.com/15OvRxMr5