三范式
3.6.2数据库系统-范式判断:范式分类、第一范式、第二范式、第三范式、BC范式
1.三范式的重要性:
- 节省数据的存储空间
- 能够保证数据的完整性
- 方便进行数据库应用系统的开发
关系型数据库中,关于数据表设计的基本原则,规则就称为范式
2.键和相关属性的概念
比如有如下数据:
超键
在关系中能唯一标识元组的属性集称为关系模式的超键。
于是我们从例子中可以发现 学号是标识学生实体的唯一标识。那么该元组的超键就为学号。
除此之外我们还可以把它跟其他属性组合起来,比如:
(学号,性别)
(学号,年龄)
这样也是超键.
候选键
不含多余属性的超键为候选键。
根据例子可知,学号是一个可以唯一标识元组的唯一标识,因此学号是一个候选键,实际上,候选键是超键的子集,比如 (学号,年龄)是超键,但是它不是候选键。因为它还有了额外的属性。
主键
用户选择的候选键作为该元组的唯一标识,那么它就为主键。
简单的说,例子中的元组的候选键为学号,但是我们选定他作为该元组的唯一标识,那么学号就为主键。
外键
外键是相对于主键的,比如在学生记录里,主键为学号,在成绩单表中也有学号字段,因此学号为成绩单表的外键,为学生表的主键。
主键为候选键的子集,候选键为超键的子集,而外键的确定是相对于主键的。
3.第一范式(1NF)
- 第一范式主要是保证数据表中的每一个字段的值必须具有原子性,也就是数据表中的每个字段的值是不可再拆分的最小数据单元
-
- 属性的原子性是主观的,我们要根据实际项目的需求来设计,比如说地址,如果项目没有说要细分为省,市,县,镇这么具体的话,我们一般就可以不拆分。
几个重要的概念:
1.函数依赖:A–>B,如果通过A属性(属性组)的值,可以确定唯一的B属性的值,则称B依赖于A
例如:学号---->姓名 (学号、课程名称 的属性组)–> 分数
2.完全函数依赖:A–>B 如果A是一个属性组,则B属性值的确定需要依赖A属性组的中所有的属性值
例如:(学号、课程名称)–> 分数
3. 部分函数依赖: A–>B 如果A是一个属性组,则B属性值的确定只需要依赖A属性组的中某一些的属性值(第二范式就是消除这个)
例如:(学号 、课程名称)–> 姓名
4.传递函数依赖:A – >B , B – >C 如果通过A属性(属性组)的值,可以确定唯一的B属性的值,再通过B属性(属性组)的值,可以唯一确定C属性的值,那么称C传递依赖于A
例如: 学号 --> 系名 ,系名 --> 系主任
5.码 :如果在一张表中,一个属性或属性组,被其他所有的属性(非主属性)所函数依赖,则称这个属性(属性组)为该表的码。(上面的表,学号和课程名称所构成的属性组就是码)
例如: 该表中码为 (学号、课程名称)
主属性: 码中所有属性
非主属性: 除码之外的所有属性
在上面那张表中我们可知码为(学号、课程名称),但是姓名、系名、系主任都部分依赖于码(主属性),这不符合第二范式,
所以进行拆分如下
第一张表码为(学号、课程名称),第二张表为(学号),它们都是完全依赖的,因此符合第二范式。
4.第二范式:在1NF基础上,非码属性必须完全依赖于候选码(在1NF基础上消除非主属性对主码(主属性)的部分函数依赖)
第一张表码为(学号、课程名称),第二张表为(学号),它们都是完全依赖的,因此符合第二范式。
第三范式(3NF):在2NF的基础上,任何的非主属性不依赖于其他非主属性 (在第二范式基础上消除传递依赖)
注意看第二范式的学生表:存在系主任依赖于系名 (系名—> 系主任),所以不符合第三范式
继续进行拆分
这样就符合第三范式…
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 全网最简单!3分钟用满血DeepSeek R1开发一款AI智能客服,零代码轻松接入微信、公众号、小程
· .NET 10 首个预览版发布,跨平台开发与性能全面提升