说一说关系数据库中的范式建模

面试中可能会被问到，来回顾总结一下，参考《数据库系统第五版》（王珊/萨师煊）

范式(normal form)，我的理解是用来规范关系数据库中实体如何划分以及实体间如何建立联系来保持数据完整性的一种指导思想，目的就是要消除数据冗余，追求单表操作，修改某个实体只需要操作一张表，实体与实体间修改互不影响。目前存在六种范式：1NF/2NF/3NF/BCNF/4NF/5NF，它们之间属于层层递进的关系。日常业务中满足3NF就可以了，因为更高的范式意味着更多层表的拆分，那么在操作时也就会产生更多的表关联，同样会拉低性能。

1NF

1NF用来保证属性的原子性。也就是属性不可再分。什么是原子性，我的理解是没有绝对的原子性，具体需要结合业务来设计。比如对于地址这个属性，如果业务中这个属性只是为了简单的对地址做个记录，我们可以直接设计成类似xx省xx市xx县”，而如果在以后的业务中可能会发生针对于市县的操作，那就需要对地址进行到市县的分解。1NF是关系型数据库的基础，不满足1NF就不是一个关系型数据库。

2NF

2NF的目的是消除部分依赖。指的是表中所有除主键外的属性都能由这个主键唯一确定，不能由这个主键中的部分字段确定。举个例子，有学生成绩表(学号,课程,姓名,成绩)，这个成绩表中主键是(学号,课程)，(学号,课程)作为主键时可以确定成绩。而对于姓名这个属性，只根据学号就可以确定。这里，就存在姓名对主键(学号，课程)的部分依赖。从这个例子可以看出，如果一个表存在部分依赖其实说明了这个表中至少存储了两种实体的数据，在这个例子中存储了成绩实体和学生实体的数据。

3NF

3NF用来消除传递依赖。直白说就是表中所有主键外的属性都得与主键直接相关，而不能是间接相关。比如有学生信息表(学号,姓名,院系,院系主任)，其中主键为学号，根据学号可以确定院系，根据院系可以确定院系主任，这里就说存在院系主任对学号的传递依赖。其实这里还是说明一个表中如果存在传递依赖，也至少存储了两个实体类型的数据。个人觉得二范式和三范式的目的都是为了保证一张表只存储一种实体数据，减少数据冗余，保证数据的完整性。区别在于分表的过程，2NF是以复合主键中的主属性来建立两个实体之间的联系，保证实体完整性。而3NF是通过外键的形式建立两个实体之间的联系，保证参照完整性。

遵守3NF建模的好处

从上面可以看到，如果表的设计不满足2NF或3NF，那么就会存在一个表中包含多个实体属性的问题，造成数据冗余，这种数据冗余一方面导致数据修改复杂，另一方面可能会导致数据插入或删除时引起业务逻辑上的错误。

比如说对于2NF中的那个成绩表(学号,课程,姓名,成绩)，一个学生每选一门课，他的姓名就会被存储一次，如果说某天这个学生改名了，那么所有他选过的课程记录都要被修改，不仅效率低，也容易漏改出错，这表现了修改复杂。再比如说，这个学生还没选课，那么就会因为缺少主键而保存不了学生实体的信息，这里存在插入异常。或者说是，这个学生开始选了2门课，后来因为不喜欢不选了，当这个学生所有的选课记录都被删除后，那么这个学生实体的信息也丢失了，这里就表现出删除异常。

实际业务中怎么遵守3NF建模

这里引用网上看到的一段话，觉得很精炼简洁：

怎么做到第三范式？ 不需要考虑第三范式的定义。按对象划分就好了，学生的属性归学生，系的属性归系，教师的属性归教师，学校的属性归学校。