基本概念
实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，比如说“老师与学校的关系”。
属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。
元组：表中的一行就是一个元组。
分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。
码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。
全码：如果一个码包含了所有的属性，这个码就是全码。
主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。
外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。
范式的主要目的：减少数据冗余，但并非越严格约好，也并非一定要完全遵守，视需求以及性能而定，可适当冗余；
第一范式（1NF）：属性不可分
场景举例：
用户表（姓名，联系方式，年龄）
假设联系方式字段存放微信号、手机、QQ、邮箱等，并且从业务需求来看，这些属性表述的含义和用途并不相同，则该属性的记录的数据不是原子的，因而不符合1NF；（注意此处一定是从业务的实际需求来看，并非一定要把字段拆分到最细不可）
应该将字段拆分，以满足1NF：
用户表（姓名，微信号，手机，QQ，邮箱，年龄）
第二范式（2NF）：符合1NF，并且，非主属性完全依赖于码。（注意是完全依赖不能是部分依赖，设有函数依赖W→A，若存在（X，W），有X→A成立，那么称W→A是局部依赖，否则就称W→A是完全函数依赖）
场景举例：
课程表（姓名，课程，教师，教师职称，教材，教室，上课时间）
存在如下函数依赖：
一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师；
一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－>教室；
一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－>老师职称；
一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－>教材
一个学生上一门课，一定在特定时间。所以有（学生，课程）－>上课时间
因此（学生，课程）是一个码。
然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有课程－>教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖，或者说部分依赖。因而不满足第二范式；
由此引入的问题：
插入异常：假如新增课程，此时学生还没有选课，（学生，课程）为码，则学生字段不能为空，此时无法插入记录；
删除异常：下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教材啊？……郁闷了吧?
更新异常：校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这门课，改动好大啊！改累死了……郁闷了吧？
拆分课程表，变为2张表：课程表、教材表
课程表（姓名，课程，教师，教师职称，教室，上课时间）
教材表（课程，教材）
第三范式（3NF）：符合2NF，并且，消除传递依赖（也就是每个非主属性都不传递依赖于候选键，判断传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。）
场景举例：
课程表（姓名，课程，教师，教师职称，教室，上课时间）
教材表（课程，教材）
上面的“课程表，教材表”符合2NF，但不符合3NF，一个老师一定能确定一个老师职称，则存在传递依赖：
（学生，课程）->老师->职称
由此引入的问题：
修改异常：老师升级了，变教授了，要改数据库，表中有N条，改了N次……
删除异常：没人选这个老师的课了，老师的职称也没了记录……
插入异常：新来一个老师，还没分配教什么课，他的职称记到哪？……
继续拆分课程表，分为2张表：课程表、教师表
课程表（姓名，课程，教师，教室，上课时间）
教师表（教师，职称）
教材表（课程，教材）
BC范式（BCNF）：符合3NF，并且，主属性不依赖于主属性(也就是不存在任何属性对任一候选码的传递函数依赖)
BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。
若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。
场景举例：
仓库管理表 (仓库ID, 存储物品ID, 管理员ID, 数量)
假设一个管理员只在一个仓库工作；一个仓库可以存储多种物品，则存在如下依赖关系：
（仓库ID, 存储物品ID） →（管理员ID, 数量）
（管理员ID, 存储物品ID） → （仓库ID, 数量）
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选码，表中的唯一非主属性为数量，它是符合第三范式的。但是，由于存在如下决定关系，即存在主属性之间的函数依赖，不符合BCNF范式：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
引入问题：
删除异常：当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。
更新异常：如果仓库换了管理员，则表中所有行的管理员ID都要修改。
拆分仓库管理表为2张表：仓库表、管理员表；
仓库表（仓库ID，存储物品ID）
管理员表（仓库ID，管理员ID）
数据库范式之间存在递进关系，更高一级的范式需要满足前面的所有范式，数据库设计通常符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五范式。
