属性：实体所具有的某一特性，例如学生的姓名，学号等

码/键：能唯一标识实体的属性或属性集，即其闭包包含R的所有属性，其包括主码，候选码，超码

域：某一属性的取值范围为域，如性别的男女，在关系二维表中，列为域

元组：关系二维表中的一行，即学生关系中一个学生记录为一个元组

候选码/候选键：能唯一标识元组的一个属性或属性集，且该属性的组合中不包含多余属性，一个关系可能有多个候选码

      求解注意事项：

                  候选码不能包括候选码，即一个关系R模式（A,B,C,D）中，若A为候选码,则A不可出现在其它候选码中                          

若BC，BD为候选码,则BCD不可能为候选码，其为超码

主码：从候选码中任取其一

超码：一个或多个属性的集合，这些属性的组合可以使我们在一个实体集中唯一的标识一个实体，候选码是最小的超码

全码：候选码包括关系模式中的所有属性

外码：R2中的属性或属性组是关系模式R1的主码，则该属性或属性组为R2的外码

最小函数依赖集求解：

1. 先将F中每个函数依赖的右边部分均变为单属性，例如D→BC转换为D→B，D→C
2. 去掉F左边的多余属性，例如BD→A，（B+）包含A，则D为多余属性，去掉
3. 去掉F中冗余的函数依赖，例如BD→，（BD+）包含C，则去掉
4. 最终得出结果

主属性：包含在任一候选码中的属性，即候选码所有属性的并集

非主属性：不包含在任一候选码之中的属性

第一范式：关系模式中属性均为原子属性，每个属性均不可再分

第二范式：R属于第一范式，且每个非主属性完全依赖于R的主码

          当主码为单属性或R的全体属性均为主属性，R必为第二范式

第三范式：R属于第二范式，且每个非主属性都不传递函数依赖于R的主码

BC范式：R属于第一范式，且所有的函数依赖X→Y（Y不属于X），决定因素X都包含了R的一个候选码

   简单判定方式：函数依赖集F的左边均一定包含一个候选码

相关概念：
非主属性：不包含在任何一个候选码中的属性。
第一范式（1NF）：无重复的列。第一范式是关系模式的基本要求。
第二范式（2NF）：在满足第一范式的前提下，非主属性非部分依赖于主关键字。要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
第三范式（3NF）：在满足第二范式的基础上，要求一个数据库表中不包含已在其它表中已包含的非主关键字信息，即：属性不依赖于其它非主属性。 不存在非关键字的传递关系。

例如1：假定选课关系表为SelectCourse(学号，姓名，年龄，课程名称，成绩，学分)，关键字为组合关键字(学号，课程名称)，因为存在如下决定关系：
(学号，课程名称) → (姓名，年龄，成绩，学分)
这个数据库表不满足第二范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名，年龄)
即存在组合关键字中的字段决定非关键字的情况。

例如2：假定学生关系表为Student(学号，姓名，年龄，所在学院，学院地点，学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名，年龄，所在学院，学院地点，学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点，学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

附：主键和外键
1.主键是能确定一条记录的唯一标识，比如，一条记录包括身份正号，姓名，年龄。

身份证号是唯一能确定你这个人的，其他都可能有重复，所以，身份证号是主键。
2.外键用于与另一张表的关联。是能确定另一张表记录的字段，用于保持数据的一致性。

比如，A表中的一个字段，是B表的主键，那他就可以是A表的外键。

候选码（Candidate Key）或候选键
如果在一个关系中，存在多个属性（或属性组合）都能用来惟一标识该关系的元组，这些属性
（或属性组合）都称为该关系的候选码或候选键。
例如，在学生登记表关系中，如果姓名不允许重名时，学号和姓名都是候选码。
主码（Primary Key）或主键
在一个关系的若干个候选码中指定一个用来惟一标识该关系的候选码称为该关系的主码或主
键。
例如，在学生登记表关系中，学号一般都是惟一的，如果姓名不允许重名时，存在两个候选
码：学号和姓名，若选中学号作为惟一标识，那么，学号就是学生登记表关系的主码或主键。