面试常见问题（2）——数据库

本文整理的网上比较符合本人理解的关于范式的解释，参考链接如下：

https://blog.csdn.net/u013164931/article/details/79692402， https://www.cnblogs.com/lca1826/p/6601395.html 以及https://www.2cto.com/database/201404/290140.html

第一范式：简单说 列不能再分

第二范式：简单说 建立在第一范式基础上，消除部分依赖

第三范式：简单说 建立在第二范式基础上，消除非主属性对候选码的传递依赖。

BCNF：在第三范式的基础上，消除主属性对其他主属性的传递函数依赖。

一个满足BCNF的关系模式的条件:

　　1.所有非主属性对每一个码都是完全函数依赖。

　　2.所有的主属性对每一个不包含它的码,也是完全函数依赖。

　　3.没有任何属性完全函数依赖于非码的任何一组属性。

进一步举例子解释BCNF：（来自链接，写的非常生动易懂）

BCNF：中文叫巴斯范式，是由Boyce和Codd提出的,比3NF又进了一步,通常认为是修正的第三范式。

例如：设关系模式R<U，F>∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有超码，那么R∈BCNF。

 

假设仓库管理关系表 (仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。

这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。

3NF和BCNF的区别：一句话就是3NF是要满足不存在非主属性对候选码的传递函数依赖，BCNF是要满足不存在任一属性（包含非主属性和主属性）对候选码的传递函数依赖。

 

相关知识点：

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

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

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

 

完全函数依赖
定义：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

比如，一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师

这就是完全依赖。

部分函数依赖
定义：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

码用(学号+课程),为什么要加课程呢？因为不同课程成绩是通过学号查不出来的。

不过用(学号+课程)当作码是不是有些问题？

(学号+课程)->姓名，但是学号->姓名

(学号+课程)->系名，但是学号->系名

(学号+课程)->系主任，但是学号->系主任

这个就是部分依赖

要是上面那张表符合第二范式。需要将表拆分为两张表。

一张是 学号、课程、分数表

另外一张是 学号、姓名、系名、系主任表

传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

https://blog.csdn.net/rl529014/article/details/48391465

采用这位大佬的例子
在关系R(学号 ,宿舍, 费用)中，(学号)->(宿舍),宿舍！=学号，(宿舍)->(费用),费用!=宿舍，所以符合传递函数的要求