数据库原理:了解范式(1NF、2NF、3NF、BCNF),做例题快速弄懂

该博客主要介绍数据库范式相关知识。先阐述第一、二、三范式及BC范式的定义和关系,指出高一级范式包含低一级范式。接着通过三道例题,判断关系模式的范式级别并给出解析。最后总结强调理解定义和多做题对掌握范式判断的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

如果你基本定义都理解了,建议直接跳到例题部分

本篇讲的是范式及例题,如果函数依赖还不知道,请移步至另外一篇讲函数依赖的博客:

数据库原理:通过例题弄懂函数依赖,并附带题目_Allow-er的博客-优快云博客

一、定义

1、第一范式(1NF)

定义:有关系模式满足以下条件:“每一个分量必须是不可分的数据项”的即为第一范式(1NF)。

ps:基本上所有的关系模式都属于第一范式(1NF),因为第一范式的级别比较低。

2、第二范式(2NF) 

定义:若 R\in 1NF,且每一个 非主属性 完全函数依赖 于 任何 一个候选码,则R\in 2NF

PS:如果题目中我们得到某个关系模式不含有非主属性,那么这个关系模式必定属于2NF

3、第三范式(3NF)

定义:设关系模式  R<U,F>\in 1NF ,若R中不存在这样的码X,属性组Y及非主属性Z(Z\nsubseteq Y)使得 X\rightarrow Y , Y\rightarrow Z 成立,且Y-/->X,则称 R<U,F>\in 3NF

定义看不懂,那就看下面的就明白了:

(1)由定义可以证明:若 R\in 3NF ,则每一个非主属性不传递依赖于码,也不部分依赖于码。

(2)如果R属于3NF,则必有R属于2NF。反之则不一定成立。

(3)PS:如果题目中我们得到某个关系模式不含有非主属性,那么这个关系模式必定属于3NF

4、BC范式(BCNF)

一般认为BCNF是修正的第三范式,有时也称为扩展的第三范式。

定义:

关系模式 R<U,F>\in 1NF ,若X\rightarrow Y 且 Y\nsubseteq XX必含有码,则R<U,F>\in BCNF

由定义还可以得到:

结论:

  1. 所有非主属性对每一个码都是完全函数依赖。
  2. 所有主属性对每一个不包含它的码也是完全函数依赖。
  3. 没有任何属性完全函数依赖于非码的任何一组属性。

看不懂可以这样理解: 

要属于BCNF,则每一个函数依赖关系的决定性因素(也就是箭头-->左边的集合)必须含有码。

还不理解通过一个例题来明白:

例:关系模式SJP(S,J,P),其中S代表学生,J代表课程,P代表名次,此关系模式是不是属于BC范式?

解:

候选码:(S,J),(J,P)

函数依赖:(S,J)\rightarrow P,(J,P)\rightarrow S 

因为每一个学生选的每一门课程决定他在这门课的名次;每一门课的每一个名次都对应着一个学生(假设没有并列)。

结果:这两个码的属性是相交的,这个关系模式中没有非主属性,在这个题目中(S,J)、(J,P)都是候选码,所以不存在非主属性,所以属于3NF;并且所有的“X\rightarrow Y 且 Y\nsubseteq X时,X中都含有码”,也就是因为所有函数依赖箭头左边的集合X中都含有码。在这个题目中(S,J)、(J,P)都是候选码,都在箭头左边,所以属于BCNF

5、范式之间的关系

包含关系:5NF\subset 4NF\subset BCNF\subset 3NF\subset 2NF\subset 1NF 

如图:

 规范化:一个低一级范式的关系模式通过分解可以转换为若干个高一级范式的关系模式的集合的过程

结论:属于高一级范式一定属于低一级的范式,反之则不一定。

二、例题

1、判断下列关系模式的范式级别

第一题:

学生(Sno、Sname、Date、Sdept、Class,Area)  

其中:Sno代表学号,Sname代表姓名,Date代表出生日期,Sdept代表所在系,Class代表班号,Area代表宿舍区

第二题:

教学(Sno、Cno、Grade、Teacher、Tsdept)

其中:Grade代表成绩,Teacher代表老师,Tsdept代表老师所在系

第三题:

员工(PID、Ename、Salary)

PIDEnameSalary
100A胡一民2400
100A张小华2100
100B张小华2100
200A胡一民2400
200B胡一民2400
200C李红卫1500
200C张小华2100
200D李红卫1500

2、解析:

第一题:

候选码:Sno

函数依赖:Sno\rightarrow Sname,Date,Sdept,Class

Sdept\rightarrow Area

Class\rightarrow Area

Sno--传递-->Area

结果:属于2NF   ,因为非主属性Area传递依赖于Sno,所以不满足3NF。而所有非主属性都完全函数依赖于候选码Sno,所以属于2NF。

第二题:

候选码:(Sno,Cno)

函数依赖:Sno,Cno\rightarrow Grade,Teacher

Teacher\rightarrow Tsdept

Cno\rightarrow Tsdept

学号和课程号共同决定某一个学生在某一门课上的成绩,以及他的任课老师是谁。

某一个任课老师只属于某一个系。

某一门课程属于某一个系开设的。

结果:属于1NF,因为非主属性Tsdept可以由候选码(Sno,Cno)决定,也可以由Cno单独决定,也就是说Tsdept对Cno是部分函数依赖,而属于第二范式的要求是所有非主属性要完全函数依赖于候选码。所以不属于2NF。

第三题:

候选码:(PID,Ename)、(PID,Salary)

函数依赖:PID,Ename\rightarrow Salary

PID,Salary\rightarrow Ename

Ename\rightarrow Salary

结果:属于3NF。因为没有非主属性,就不存在第三范式定义要求的非主属性既不传递依赖于码,又不部分依赖于码,所以属于3NF。而因为 Ename\rightarrow Salary,并且Ename并不是码也不包含码,不满足BC范式要求的任何X\rightarrow YY\nsubseteq XX必含有码,所以不属于BCNF。

三、总结

另外一些易错复杂一点的判断范式进阶题:

数据库原理:易错的函数依赖与求解范式的例题,进一步巩固。_小许要加油啊~的博客-优快云博客

总的来说,只要理解了范式的定义,做题就简单了,当然初学的时候看定义都是云里雾里不知所云,因为定义是有学术严谨性的,自然不会那么直观,而这就需要我们理解并转化为自己的理解了。例题可以加深我们对于定义的理解,建议多去做题,看了上面三个例题应该能够大概知道怎么做了。

由于本人的自身局限性,如果有错误或者不足之处,欢迎指正!也可以在评论区把自己的疑问打出来讨论,如果觉得有帮助,还请多点个赞、收藏一下,给我一点鼓励和动力,我会有继续更新下去的动力的,谢谢!希望对你有帮助!

### BCNF 分解与 3NF 分解 #### BCNF 分解示例题目解答方法 考虑关系模式 `R(A,B,C,D)` 及其上的函数依赖集 `F={AB→C, C→D}`。 对于给定的关系模式及其函数依赖集合,如果存在非平凡的函数依赖 X → A 并且 A 不完全包含于 X 的闭包,则该关系不满足BCNF。因此,`R` 中有如下违反BCNF的情况: - 对于 AB → C,由于 {A, B} 是候选键的一部分,所以这个依赖并不破坏BCNF。 - 而对于 C → D 来说,{C} 并不是超码,这表明当前模式不符合BCNF的要求[^1]。 为了使上述关系模式转换成BCNF形式,需要对其进行适当分解。具体操作如下所示: 1. 将原始关系 R 拆分为两个新的子关系 S1(C,D) 和 S2(A,B,C),其中前者仅保留了由 C 到 D 的决定因素;后者则包含了原表中的其他列以及作为公共部分存在的 C 属性。 这样的目的是确保每一个新创建出来的表格都只含有单一类型的实体间关联,并且这些关联都是基于各自完整的主关键字来建立起来的。 最终得到的结果就是一组既能够保持原有数据完整性又符合更高层次规范化要求的新表格结构——S1(Schema_1) 和 S2(Schema_2)。 ```sql CREATE TABLE Schema_1 ( C VARCHAR, D VARCHAR, PRIMARY KEY (C) ); CREATE TABLE Schema_2 ( A VARCHAR, B VARCHAR, C VARCHAR, PRIMARY KEY (A, B), FOREIGN KEY (C) REFERENCES Schema_1(C) ); ``` #### 3NF 分解示例题目解答方法 假设有一个学生选课系统的关系模式 `SC(S#, C#, G)` 表示学号、课程编号和成绩之间的联系,已知 F = {(S#, C#) → G}, 即学生的特定课程的成绩是由这两个字段共同确定的。此时 SC 已经处于第二范式2NF),因为所有的非主属性都不传递依赖于任何候选键的部分分量[^2]。 然而,考虑到可能存在某些情况下不同教师教授同一门课程而产生不同的评分标准等问题,我们希望进一步消除这种潜在的数据冗余风险并提高系统的可维护性和一致性水平。为此,可以采用以下方式进行3NF分解: 通过引入一个新的中间件 T(TeacherID, CourseID), 它记录着每位老师所负责的具体科目信息,从而使得原有的成绩表不再直接存储关于授课人员的信息而是改为间接引用的方式实现相同的功能效果。这样不仅简化了整体架构还增强了灵活性与扩展能力[^3]。 ```sql CREATE TABLE TeacherCourse ( TeacherID INT NOT NULL, CourseID CHAR(8) NOT NULL, PRIMARY KEY (TeacherID, CourseID) ); ALTER TABLE Scores ADD COLUMN TeacherID INT; UPDATE Scores SET TeacherID = /* some logic to determine teacher */; ALTER TABLE Scores DROP COLUMN CID; -- Ensure referential integrity between tables. ALTER TABLE Scores ADD CONSTRAINT fk_teacher_course FOREIGN KEY (TeacherID, CourseID) REFERENCES TeacherCourse(TeacherID, CourseID); ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小许要加油啊~

是对我最大的鼓励以及肯定,谢谢

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值