建设部网站官网 下载规范,手机特殊网站,瑞郎网络,免费职业技能培训网站文章目录 一、基本概念1、属性2、元组3、关系4、超键5、候选键6、主键7、主属性8、外键9、函数依赖完全依赖 二、数据库范式1、第一范式#xff08;1NF#xff09;2、第二范式#xff08;2NF#xff09;3、第三范式#xff08;3NF#xff09;4、巴斯-科德范式#xff08… 文章目录 一、基本概念1、属性2、元组3、关系4、超键5、候选键6、主键7、主属性8、外键9、函数依赖完全依赖 二、数据库范式1、第一范式1NF2、第二范式2NF3、第三范式3NF4、巴斯-科德范式BCNF5、第四范式4NF6、第五范式5NF 三、反范式四、总结 一、基本概念
我们通过下面这个学生表来深入理解下假设姓名没有重名的 学生表姓名性别年龄是否成年身份证号码手机号码学号班级学生所在班级中的座位号班主任 1、属性
属性就是字段我们表中的每一列
2、元组
元组就是表中的每行数据即数据库表中的每条记录在二维表里元组也称为行。
3、关系
关系Relation是指一个表Table它由行Rows和列Columns组成。
4、超键
超键又叫超码是能够唯一标识关系中的每个元组的一个或多个属性的集合也就是在关系中能唯一标识记录的属性集。 超键可以包含多个属性但不一定是最小的超键任何属性超键 超键的分类
单属性表中的某个属性组合由多个属性组成唯一性约束超键通过在属性上添加唯一性约束使其成为超键
例如有一个学生表学号姓名性别年龄身份证班级那么{学号}、{身份证}、{学号, 姓名}、{学号, 性别}等都是超键{姓名}{姓名性别}不是超键。
5、候选键
候选键又叫候选码是最小的超键不含有多余属性的超键也就是一个属性可以表示超键的话就没必要使用多个属性。 在一个关系中可能存在多个候选键 特点
唯一性候选键的值在关系中是唯一的没有重复的记录。最小性候选键是最小的属性集合即不能再删除任何一个属性而保持唯一性。
例如还是以学生表学号姓名性别年龄身份证班级来说{学号}、{身份证}都是候选键因为它唯一标识每个学生{学号, 性别}不是候选键因为它包含了多余属性。
6、主键
主键又叫主码是从候选键中选择的一个键用于唯一标识关系中的每个元组。 主键必须是唯一且非空的。在关系中只能有一个主键。 例如在学生表中{学号}、{身份证}都可以作为主键。 注还是要根据场景来定主键比如身份证一般在实际生产中我们不用它当主键。
7、主属性
主属性是指在主键中的属性它们是用来唯一标识每个元组的关键属性。 如果主键包含多个属性那么这多个属性都是主属性。 例如在学生表中{学号}是主键因此它也是主属性。
8、外键
外键又叫外码是指其它表的主键。
例如在学生表中{班级}是外键因为它是班级表的主键
9、函数依赖
一个属性的值或属性集合的值对于另一个属性的值或属性集合的值具有决定性影响即给定一个属性或属性集合的值可以唯一确定另一个属性或属性集合的值
例如如果属性A的值决定了属性B的值可以表示为 A - B。这意味着在给定A的值的情况下可以唯一确定B的值。
完全依赖
如果一个属性或属性集合对于另一个属性或属性集合的值具有完全依赖那么没有任何冗余的属性可以从该依赖中删除否则将无法唯一确定被依赖的属性或属性集合的值。
例如假设有一个关系模式R(A, B, C)其中属性A和属性B的组合决定了属性C的值。如果删除属性A或属性B中的任何一个都无法唯一确定属性C的值那么我们可以说属性C对于属性A和属性B具有完全依赖。
二、数据库范式
主要有第一范式、第二范式、第三范式、巴斯-科德范式第四范式和第五范式前面是后续范式的基础级别越高数据库越标准。
1、第一范式1NF
1NFFirst Normal Form 强调属性都是原子的不可再拆分 例如学生表学号姓名班级学生所在班级中的座位号班主任性别年龄是否成年身份证号码这个表设计符不符合第一范式 这种得看业务场景了如果需要展示xx姓同学比如黄同学李同学欧阳同学这种是不是就不符合因为姓可能有多个字比如欧阳索隆欧阳修你怎么知道姓欧还是欧阳这种根本无法拆分所以需要把姓和名拆开存不然不好展示代码逻辑也比较复杂所以这里的姓名还可以再拆分就不符合第一范式了。
2、第二范式2NF
非主键属性完全依赖于主键消除部分依赖。
假设(AB)是主键完全依赖指的是(AB) -C部分依赖指的是A-C。
还是以学生表学号姓名班级学生所在班级中的座位号班主任性别年龄是否成年身份证号码为例这个表设计符不符合第二范式 {班级学生所在班级中的座位号}是主键但{班主任}由班级决定没有完全依赖于主键不符合第二范式而且会有性能影响这里数据冗余了可能导致数据不一致如果班主任有变更很多学生记录都要同步修改不然就出现了数据不一致。 解决方案拆表班主任字段拆出去 学生表学号姓名班级学生所在班级中的座位号性别年龄是否成年身份证号码 班级表班级班主任
3、第三范式3NF
非主键属性不传递依赖于主键直接依赖于主键消除传递依赖
假设A是主键存在A-B-C那么说C传递依赖于A。
例如前面满足第二范式的表结构如下这个表设计符不符合第三范式 学生表学号姓名班级学生所在班级中的座位号性别年龄是否成年身份证号码 班级表班级班主任 年龄是否成年身份证号码性别都是非主键列“年龄”和“性别”都可以由“身份证号码”推出“是否成年”可以由“年龄”推出所以不符合第三范式 解决方案拆表把年龄是否成年身份证号码拆出去 学生表学号姓名班级学生所在班级中的座位号身份证号码 班级表班级班主任 身份证号码关系表身份证号码年龄性别 年龄关系表年龄是否成年
上面这种场景在实际环境中需要维护多一些表或者Java代码进行判断都有性能消耗代码的话每次查询的时候代码都要计算1次那么我们可以采取物化视图插入年龄的时候直接计算好提升性能具体实现可以参考数据库对象介绍与实践视图、函数、存储过程、触发器和物化视图
4、巴斯-科德范式BCNF
对第三范式的优化在它基础上消除对主键子集的依赖而得到的即非主键属性完全依赖于候选键。
学生表学号姓名班级学生所在班级中的座位号身份证号码 班级表班级班主任 身份证号码关系表身份证号码年龄性别 年龄关系表年龄是否成年
这个设计符不符合巴斯-科德范式 学生所在班级中的座位号完全依赖于{学号班级}而不依赖于学号所以符合 5、第四范式4NF
要求消除非平凡多值依赖。
假设有一个关系表格包含以下列学生ID、课程ID、学生成绩1、学生成绩2。如果每个学生ID和课程ID的组合可以决定多个学生成绩的值而不是只有一个固定的学生成绩值那么就存在一个非平凡多值依赖。
6、第五范式5NF
要求消除非平凡函数依赖。
假设有一个关系表格包含以下列学生ID、学生姓名、学生年龄。如果每个学生ID都唯一确定一个学生姓名那么学生ID对学生姓名存在一个非平凡函数依赖。因为在现实生活中学生ID并不直接决定学生姓名而是通过其他信息或逻辑来确定。
三、反范式
反范式Denormalization是一种数据库设计技术旨在提高数据库的性能和查询效率但可能会牺牲一部分数据的一致性和完整性。
在范式化的数据库设计中数据被分解为多个表以减少数据冗余和提高数据的一致性。然而范式化的数据库结构可能导致在进行复杂查询时需要进行多个表的连接操作从而影响查询性能。
反范式化通过将分解的表重新合并或添加冗余数据以减少表之间的连接操作从而提高查询性能。这样可以简化查询的复杂性减少查询的执行时间。
导致的问题
增加存储空间数据冗余字段增大更新风险更新时需要确保所有相关的冗余数据都得到正确的更新以保持数据的一致性
四、总结
在实际工作中一般遵守1NF、2NF、3NF即可但一般用反范式可以显著提高性能优势我们需要自己权衡下根据具体的应用场景和性能需求来决定使用啥范式。
经验之谈
设计的时候脑子里要有范式用于指导设计遵守范式然后根据业务再做反范式
