一.基础概念
要理解范式，首先要知道什么是关系数据库。 如果你不知道的话，我就不容易再轻易说了。 关系数据库是用二维表保存数据。 表与表之间……(省略10w字)。
然后，应该理解以下概念。
实体：客观存在于现实世界中，可以区分的东西。 例如“一个学生”、“一本书”、“一门课”等。 应该强调的是，这里所说的“事物”，不仅是看得见的“事物”，也可以是虚拟的，倒不如说是“老师和学校的关系”。
属性：教科书中解释为“实体具有的某种特性”。 由此可见，属性最初是一个逻辑概念，例如，“性别”是“人”的属性。 在关系数据库中，属性还是一个物理概念，可以将属性视为“表列”。
元组：表中的一行是元组。
分量：元组属性值。 在关系数据库中，这是操作原子。 这意味着关系数据库在做某事时属性是“不可分离的”。 否则就不是关系数据库了。
代码：可以唯一确定表中具有一个元组的属性(或属性组)。 如果有多个那样的代码，大家都称为候补代码。 从候补代码中选择一个做老板。 那个称为主要代码。
完整代码：如果一个代码包含所有属性，则此代码为完整代码。
主属性：只要一个属性出现在某个候选代码中，该属性就是主属性。
非主要属性：与上述相反，未出现在任何候选代码中。 此属性是非主要属性。
外部码(属性)或属性组)，它不是编码，但是是另一个表的编码，它是外部码。
二、六种范式
那么，到此为止，我介绍了掌握范式所需的所有基础概念，这里说明范式。 首先，必须理解范式的包含关系。 如果一个数据库设计符合第二范式，也一定符合第一范式。 只要符合第三范式，就一定也符合第二范式…
第一范式(1NF )属性不可分离。
我之前介绍了属性值的概念，我们说它是“不可分割的”。 第一范式的要求属性也是不可分离的。 那么，什么不能与属性值区分开来呢？ 举个例子：
名字
电话
age
大宝
13612345678
22
小明
13988776655
010-1234567
21
Ps :在此表中，属性值为“分钟”。
名字
电话
age
手机
座机
大宝
13612345678
021-9876543
22
小明
13988776655
010-1234567
21
Ps :在此表中，属性为“分钟”。
两种情况都不满足第一范式。 不满足第一范式的数据库不是关系数据库！ 所以，我们不能用任何关系数据库管理系统来制定这样的“表”。 (也就是说，只要是关系数据库就是第一模式)
第二范式(2NF ) :符合1NF，且非主属性完全依赖于代码。
听起来很神秘，但其实没什么。
一个候选代码中的主属性也可能有一些。 如果主要属性不能单独用作候选代码，则也无法确定主要属性以外的属性。 举个反例吧。 考虑一下小学的教务管理系统吧。 学生在课堂上指定老师、教材、教室和时间。 大家去上课吧。 没有问题。 那么，数据库怎么设计？ (学生的课表)。
学生
路线
教师
老师的职称
文本
教室
上课时间
小明
一年级的国语(上) ) ) ) ) )。
大宝
副教授
《小学语文1》
101
14点30分
一个学生上课，一定在特定的教室里。 所以(学生，上课) -教室
一个学生上课，一定会有特定的老师教。 所以(学生，上课) -老师
一个学生上课，他的老师的作用就可以确定。 所以(学生，课程) -老师的作用
一个学生上课，一定是特定的教材。 所以(学生，课程) -教材
一个学生上课，一定要在特定的时间。 所以(学生，上课) -上课时间
所以，(学生，课程)是代码。
但是，因为一节课，一定要指定某教材，一年级的国语一定要用《小学语文1》，所以有课-教材。 (学生，课程)是代码，但课程决定教材。 这称为不完全依赖或部分依赖。 一旦发生这种情况，就不满足第二范式！
有什么不好的吗？ 想想看：
1、校长新增“微积分”这门课。 教材是《大学数学》。 我该怎么办？ 学生还没有选课，学生是主要属性。 主属性不能为空。 上课怎么记录？ 教材能记住多少？ ……郁闷了吧？ (插入异常)
2、下学期学一年级语文(上)的学生不在了，学了一年级语文(下)的话，表中一年级语文(上)就不存在了，010 ) 30 ) 10 )也就没有了。 这时，校长问：“一年级语文(上)使用的教材是什么？ ……郁闷了吧？ (删除例外)
3、校长说：“一年级的国语(上)要改教材，改成《小学语文1》。 有一个
10000个学生选了这么课，改动好大啊！改累死了……郁闷了吧？(修改异常)那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表
学生
课程
老师
老师职称
教室
上课时间
小明
一年级语文(上)
大宝
副教授
101
14：30
学生上课表新
课程
教材
一年级语文(上)
《小学语文1》
课程的表
第三范式(3NF)：符合2NF，并且，消除传递依赖
上面的“学生上课表新”符合2NF，可以这样验证：两个主属性单独使用，不用确定其它四个非主属性的任何一个。但是它有传递依赖！
在哪呢？问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。有什么问题吗？想想：
1、老师升级了，变教授了，要改数据库，表中有N条，改了N次……(修改异常)
2、没人选这个老师的课了，老师的职称也没了记录……(删除异常)
3、新来一个老师，还没分配教什么课，他的职称记到哪？……(插入异常)
那应该怎么解决呢？和上面一样，投影分解：
学生
课程
老师
教室
上课时间
小明
一年级语文(上)
大宝
101
14：30
老师
老师职称
大宝
副教授
BC范式(BCNF)：符合3NF，并且，主属性不依赖于主属性
若关系模式属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。
通常BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。还可以这么说：若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。
一般，一个数据库设计符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五范式。
第四范式：要求把同一表内的多对多关系删除。
第五范式：从最终结构重新建立原始结构。