标签：小明 基本 记录 法律 学校 冗余 扩展 关系 img
第一范式（1NF）：符合1NF的关系中的每个属性都不可再分，1NF是所有关系型数据库的最基本要求。
不符合1NF的表结构
符合1NF的表结构
仅仅只满足第一范式存在的问题：冗余数据过大、插入异常、删除异常、更新异常。
仅仅符合第一范式的表结构
数据冗余过大：每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次。
插入异常：假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 。
表中的所有属性不能为空。
删除异常：假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。
更新异常：假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。
第二范式（2NF）: 2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
符合第二范式的表结构
第二范式对第一范式的改进：
数据冗余过大：学生的姓名、系名与系主任，不再像之前一样重复那么多次了。
更新异常：李小明转系到法律系只需要修改一次李小明对应的系的值即可。
第二范式存在的问题：
删除异常：删除某个系中所有的学生记录该系的信息仍然全部丢失。
插入异常：插入一个尚无学生的新系的信息。因为学生表的码是学号，不能为空，所以此操作不被允许。
第三范式：3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。
第三范式对第二范式的改进：
数据冗余过大：数据冗余更加少了
插入异常：插入一个尚无学生的新系的信息。因为系表与学生表目前是独立的两张表，所以不影响
删除异常：删除某个系中所有的学生记录该系的信息不会丢失。
总结：符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF。
参考资料:https://zhuanlan.zhihu.com/p/20028672
标签：小明 基本 记录 法律 学校 冗余 扩展 关系 img
原文地址：https://www.cnblogs.com/shenyunwen/p/9393453.html
