三范式

转:

三范式(详解+例子)

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的基础上,任何的非主属性不依赖于其他非主属性 (在第二范式基础上消除传递依赖)

 

注意看第二范式的学生表:存在系主任依赖于系名 (系名—> 系主任),所以不符合第三范式

继续进行拆分

 

这样就符合第三范式…

 

 

posted @   BBS_自律  阅读(17)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 全网最简单!3分钟用满血DeepSeek R1开发一款AI智能客服,零代码轻松接入微信、公众号、小程
· .NET 10 首个预览版发布,跨平台开发与性能全面提升
点击右上角即可分享
微信分享提示