品牌和网站建设,如何自己做网站的优化推广,旅游电子商务网站开发,旅游类网站策划建设_文章目录 简介什么是范式最常用的范式 第一范式 - 1NF第二范式 - 2NF第三范式 - 3NF第四范式 - 4NF第五范式 - 5NF巴斯-科德范式 - BCNF总结 简介
什么是范式
范式#xff08;Normal Form#xff0c;简称NF#xff09;是数据库设计时遵循的一种规范#xff0c;不同的规范… 文章目录 简介什么是范式最常用的范式 第一范式 - 1NF第二范式 - 2NF第三范式 - 3NF第四范式 - 4NF第五范式 - 5NF巴斯-科德范式 - BCNF总结 简介
什么是范式
范式Normal Form简称NF是数据库设计时遵循的一种规范不同的规范要求遵循不同的范式。 数据库范式是数据库设计表结构所遵循的规范和指导方法目的是为了减少冗余建立结构合理的数据库从而提高数据存储和使用的性能。
最常用的范式
最常用的范式是三大范式即第一范式、第二范式、第三范式。这三大范式之间是具有依赖关系的。每个范式都是用来规定某种结构或数据要求后一范式都是在前一范式已经满足的情况用来“加强要求”。比如第二范式是在第一范式的基础上建设的第三范式是在第二范式的基础上建设的。
第一范式 - 1NF
符合1NF的关系中的每个属性都不可再分。即表中字段的数据均不可再拆分遵循原子性。具体来说第一范式要求数据库表的每一列都是不可分割的原子数据项而不能是集合、数组、记录等非原子数据项。 举例员工表信息如下
编号姓名性别001技术部张三男002技术部李四男003行政部王五女
上表中姓名字段中的数据是可以继续拆分的因此它不符合第一范式。那么怎么优化才符合第一范式呢将姓名字段拆分即可优化结果如下
编号部门姓名性别001技术部张三男002技术部李四男003行政部王五女
那么是否遵循第一范式就更好呢
编号姓名家庭地址001张三江西省南昌市东湖区002李四广东省佛山市禅城区003王五湖北省武汉市新洲区
观察该表我们发现家庭地址可以继续拆分拆分结果如下
编号姓名省市区001张三江西省南昌市东湖区002李四广东省佛山市禅城区003王五湖北省武汉市新洲区
看上去拆分以后更符合第一范式。但如果项目中只需要使用一个完整的家庭地址呢明显不拆分更简单好用。 所以范式只是给我们一个参考更多的需要根据项目实际情况来进行设计。
第二范式 - 2NF
在满足第一范式的基础上要求表中的非主键列必须安全依赖于主键而不是依赖于主键的一部分。这有助于减少数据冗余并确保数据的一致性。即一张表只描述一件事情遵循唯一性。 举例学生成绩表如下
学号姓名年龄课程名称成绩学分001小张28语文903001小张28数学1002002小黄25语文953002小黄25数学902003小高22数学952
姓名和年龄依赖于学号学分依赖于课程名称成绩依赖于学号和课程名称如果学号和课程名称是联合主键那么它们可以确定联合主键以外的所有非主键值。但姓名、年龄、学分部分依赖于主键的一部分所以该表只符合第一范式不符合第二范式。 那么如何调整上述表才能符合第二范式呢基于上述三种主键可能将表拆分成三个。
学生表
学号姓名年龄001小张28002小黄25003小高22
课程表
课程名称学分语文3数学2
成绩表
学号课程名称成绩001语文90001数学100002语文95002数学90003数学95
那么为什么要遵循第二范式呢如果不遵循第二范式会有什么问题呢
数据冗余过大 如上表学生表和课程表分别有3条数据、2条数据。如果数据都放在一张表中姓名、年龄、课程名称、学分数据就在表中大量冗余。插入异常 假如学号和课程名称是主键现在计划新开设一门科学课暂时还没有学生由于缺少学号主键信息就无法正常插入数据。更新不方便 假如数学课程的学分发生变化则需要把表中关于该课程的学分全部更新。如果拆分出课程表只需要更新一条记录。删除异常 假如把所有学生的数学成绩删除那么所有与数学课程相关的数据也随之消失了。学生的数学成绩没了并不表示这门数学课也没了。
第三范式 - 3NF
在满足第二范式的基础上要求任何非主键列不能传递依赖于主键。也就是说非主键列必须直接依赖于主键而不是通过其他非主键列间接依赖于主键遵循独立性。这有助于进一步消除数据冗余和更新异常。
编号部门姓名性别部门经理001技术部张三男王经理002技术部李四男王经理003行政部王五女李经理
上表符合第二范式但是在非主键字段中部门经理依赖于部门所以不符合第三范式。那怎么调整才符合第三范式呢答案是拆成两张表消除依赖传递。
员工表
编号部门姓名性别001技术部张三男002技术部李四男003行政部王五女
部门表
部门部门经理技术部王经理行政部李经理
第四范式 - 4NF
在第三范式的基础上要求表中的列不能再有重复的元组。也就是说表中的每一列都应该包含唯一值没有重复的组合。它是在第三范式的基础上进一步消除多值依赖的范式。 多值依赖是指一个非主键字段依赖于另一个非主键字段的多个值。在第四范式中这种多值依赖关系被要求被拆分为独立的关系表以消除数据冗余和更新异常。 具体来说如果在一个关系模式中存在多个独立的多值依赖关系那么这些多值依赖关系应该被分解成单独的关系模式。每个模式都只包含一组相关的数据从而避免数据的冗余和不一致性。这样的拆分使得数据库结构更加清晰数据更加简洁同时也提高了数据的一致性和完整性。
第五范式 - 5NF
它要求表中的每一列都是不可再分的最小单元并且所有的函数依赖关系都已经被明确地定义。这意味着表中不会有隐含的数据依赖关系所有的依赖关系都应该清晰地表达出来。这有助于消除所有可能的数据冗余和更新异常。
巴斯-科德范式 - BCNF
BCNF范式并不是传统意义上的第六范式但实验室同样是数据库设计中重要的一个概念。BCNF要求所有决定因素即能唯一确定一个元组的属性或属性组都必须包含候选键。这有助于消除由传递函数依赖导致的冗余和更新异常。
总结
这六大范式在数据库设计中是层层递进的满足更高层次的范式通常意味着数据库的设计更加合理、数据冗余更少、维护更加方便。但在实际应用中并不是一定要满足所有范式而是要根据具体的应用场景和需求进行权衡和选择。
