第一范式、第二范式、第三范式参考了3359 www.zhi Hu.com/question/24696366
33559 www.cn blogs.com/LCA 1826/p/6601395.html
知识实体：客观存在于现实世界中，可以区分的东西。 例如“一个学生”、“一本书”、“一门课”等。 应该强调的是，这里所说的“东西”，不仅仅是看得见的“东西”，也可以是“老师和学校的关系”等虚拟的东西。
属性：教科书解释为“实体所具有的特性”。 由此可见，属性最初是一个逻辑概念，例如，“性别”是“人”的属性。 在关系数据库中，属性也是一个物理概念，属性可以被认为是表列。
元组：表中的一行是元组。
分量：元组的属性值。 在关系数据库中，这是操作原子。 也就是说，关系数据库在做任何事情时属性都是“不可分离的”。 否则就不是关系数据库了。
代码：可以唯一确定表中具有一个元组的属性(或属性组)。 如果有多个这样的代码，大家都叫候补代码。 从候补代码中选择一个做老板。 那个叫做主代码。
完整代码：如果一个代码包含所有属性，则此代码为完整代码。
主属性：只要一个属性出现在任意候补代码中，该属性就是主属性。
非主属性：与上述相反，它不出现在任何候选代码中。 此属性是非主属性。
外号(属性)或属性组)，它不是符号，但另一个表的符号，它是外号。
第一范式第一范式列不能再划分。
第二范式第二范式基于第一范式，非主属性完全依赖于代码。
简单地说，消除部分依赖。
什么是代码？ )表允许您唯一确定元组所在的属性(或属性组)。 如果有多个这样的代码，大家都叫候补代码。 从候补代码中选择一个做老板。 那个被称为主代码。主码可以包含多个属性。
理解第二第三范式需要理解完全函数依赖、部分函数依赖、传递函数依赖。
完全函数依赖定义：假设x，y是关系r的两个属性的集合，x’是x的真子集，存在XY，但每个x’都有x’！ Y表示y的完全函数依赖于x。
例如学号-名字
部分函数依赖的定义： x、y为关系r的两个属性集合，XY存在，x’为x的真子集，如果x’y存在，y部分函数称为依赖x。
虽然有必要借用文静的柚子教师的例子来使用，但是自己也理解了很久。
场地用(学号课程)，为什么要添加课程？ 因为不同课程的成绩用学校号码查不到。
但是，用作代码是不是有点问题？
学校号码课程-名字，但学校号码-名字
(学号课程) -系名，但系名
(学号课程) -系主任，但学号-系主任
这是部分依赖。 老实说，我对定义很无知。
如果上表符合第二范式。 必须将表分成两个表。
一张是学校号码、课程、分数表
另一张是学号、姓名、系名、系主任表
传递函数以x、y、z为关系r中相互不同属性的集合，存在xy(y )！ X )、YZ时，据说z传递函数依赖于x。
3359 blog.csdn.net/rl 529014/article/details/48391465
采用这个大人物的例子
在关系r (学号、宿舍、费用)中，(学号(-)宿舍)、宿舍！ (学号，)宿舍(-)费用，费用！=宿舍，所以满足传递函数的要求
在第三范式满足第二范式的条件下不存在传递函数依赖。
要满足第三范式，分成两张表时第二张表有问题吗？
学号-系名、系名-系部长传达依存。
有必要在系主任之外制定新的表格。
总结：第一范式：简而言之，队伍不能再分了
第二范式：简而言之，建立在第一范式的基础上，消除部分依赖
第三范式：简而言之，建立在第二范式的基础上，消除传递依赖。
代码：可以唯一确定表中具有一个元组的属性(或属性组)。 如果有多个这样的代码，大家都叫候补代码。 从候补代码中选择一个做老板。 那个叫做主代码。
主属性：只要一个属性出现在任意候补代码中，该属性就是主属性。
非主属性：与上述相反，它不出现在任何候选代码中。 此属性是非主属性。
BCNF范例https://www.2c to.com/database/201404/290140.html
BCNF是3NF的改良形式
满足BCNF关系模式的条件：
1 .所有非主属性都完全依赖于每个代码的函数。
2 .所有主属性对每个不包含它的代码也是完全的函数依赖。
3 .没有属性完全函数依赖于一组非代码属性。
上表
(仓库名称、管理员)-(物品名称、数量) )。
(管理员、物品名称)-(仓库名称、数量) )。
但是(仓库名称) -管理员)不符合第二条
所以需要换成两种表格：
第一张：仓库名称，管理员
第二张：仓库名称、物品名称、数量