数据库-----范式判断

简介: 数据库-----范式判断

以一道例题来看:


3.已知关系模式R<ABCDEG>

F={BC-->E,DC-->B,D-->A,B-->G,D-->E,E-->G,B-->C} 求:

①F的最小函数依赖集        ②R的候选码        ③R最高属于哪级范式


(1)求最小函数依赖集

首先,看F={BC-->E,DC-->B,D-->A,B-->G,D-->E,E-->G,B-->C},将每一个推导依次去掉,看其他推导能否推出这一推导,如果可以就把这一推导去掉,例如将BC-->E去掉,看在其他推导中BC能否推出E


F={BC-->E,DC-->B,D-->A,B-->G,D-->E,E-->G,B-->C},即F - {BC-->E}


BC--->G,推不出E,不是多余的,不能将其删去


F={BC-->E,DC-->B,D-->A,B-->G,D-->E,E-->G,B-->C},即F - {DC-->B}


DC-->AEG,推不出B,不是多余的,不能将其删去


F={BC-->E,DC-->B,D-->A,B-->G,D-->E,E-->G,B-->C},即F - {D-->A}


D-->EG,推不出A,不是多余的,不能将其删去


F={BC-->E,DC-->B,D-->A,B-->G,D-->E,E-->G,B-->C},即F-{B-->G}


B-->CEG,可以从其他推导中推出G,所以这是多余的,需要删除


同理其他依次判断,得到F:


F={BC-->E,DC-->B,D-->A,D-->E,E-->G,B-->C}


现在看左边不是单个的推导式:BC-->E,DC-->B,


对于BC-->E,若B-->E或C-->E,则也可以简化


例如B-->C,BC-->E,所以B+=BCE,包含E,所以可以简化,另一个同理,D-->B或D-->C都不满足,所以还是DC-->B


所以最终简化得最小函数依赖集


F={B-->E,DC-->B,D-->A,D-->E,E-->G,B-->C}


(2)求候选码

只在左边的元素:L:{D}


只在右边的元素:R:{A,G}


两边都有的:LR:{B,C,E}


只在左边出现的,一定是候选码,所以D一定是候选码,只在右边出现的,一定不是候选码,而两边都在的则不确定是不是候选码


首先,看D--->u(全集),若D能推出全集则一定是唯一候选码


D-->AEG,不能推出全集,所以D不是唯一的候选码

接着,我们将D与LR组合,先组成2个为1组的,再3个为一组的,看是否能以尽量少的元素推出全集

DB--->AEGC,能够推出全集,所以BD是候选码

DC--->AEGB,能够推出全集,所以DC是候选码

DE--->AG,不能推出全集,所以DE不是候选码

这里DCB不是候选码,因为比他更少元素的DB,DC已经能推出全集了,所以{DB,DC是候选码}

若DB,DC,DE,都不能推出全集,就应该往3个为一组推了,即DBC,DBE,DCE

(3)求R最高属于哪级范式

如果你看懂如下图,就都明白了:

现在通过例子来细说一下:

F={B-->E,DC-->B,D-->A,D-->E,E-->G,B-->C}

上面例子已经求出,候选码为{DB,DC}

主属性为:D,B,C

非主属性:A,E,G

判断是否为2NF,即候选码的真子集(D或B或C)是否能推出A或E或G

由于D-->A,又因为D (真包含)于{D,B},非主属性A部分依赖于候选键DB,所以存在部分依赖,其是1NF,不是2NF,即最高属于1NF

上面说明了1NF,现在说说其余范式:

对于2NF,若非主属性传递依赖于候选键,则为2NF,例如

B-->A,A-->C

①若B是候选键,C是非主属性

②并且A不能推出B,只有B能推出A

只有这两个步都满足时,才能说C传递依赖于B

再举一例:


对于R(A,B,C,D),F={B-->D,D-->B,AB-->C}


按照上面的(1)可知,最小函数依赖集就为F={B-->D,D-->B,AB-->C}


由(2)的步骤得到候选键为AB,AD


主属性为:A,B,D


非主属性为:C


由于F={B-->D,D-->B,AB-->C},非主属性C不部分依赖于候选键AB,只有AB能推出C,单独的A不行,单独的B也不行,所以其不是1NF


由于F={B-->D,D-->B,AB-->C},也不存在非主属性传递依赖于候选键,所以也不是2NF


由于依赖项的左边为B,D,AB,B和D都不是候选键,所以不满足左边全部为候选键,所以其不是BCNF,最高为3NF


再举一例:


R(A,B,C),F={A-->B,B-->A,A-->C}


由(1)(2)可得,候选键为A,B

可以很直观地看到不是部分依赖,其不是1NF,再看是不是2NF,2NF需要满足

① B-->A,A-->C,非主属性C传递依赖于候选键B

②但其不满足第二个条件,第二个条件是A不能推出B,但是这里A能推出B

所以不满足第2个条件,这里也不是2NF,需要非常注意,这里至少为3NF

由于依赖项的左边都是候选键,所以其最高为BCNF范式

总结:

从1NF--->2NF-->3NF-->BCNF条件是越来越严苛的

若存在非主属性部分依赖于候选键,为1NF

在非主属性全部依赖于候选键的基础上,若满足传递依赖的两个条件,则为2NF

不满足传递依赖的任意条件的基础上,若依赖项左边不全为候选键,则为3NF

不满足传递依赖的任意条件的基础上,若依赖项左边全为候选键,则为BCNF

目录
相关文章
|
5月前
|
存储 关系型数据库 MySQL
轻松入门MySQL:数据库设计之范式规范,优化企业管理系统效率(21)
轻松入门MySQL:数据库设计之范式规范,优化企业管理系统效率(21)
129 0
|
2月前
|
存储 数据库
数据库设计三范式
三范式设计的最终目的都是为了减少我们的工作量,所以说,尽管三范式是一种很好的指导规范,但在实际应用中,我们也不需要太局限在三范式中,更多的是应该从项目中出发,设计出合理的表结构。
|
2月前
|
存储 算法 Java
数据库范式与设计原则
数据库范式与设计原则
49 0
|
3月前
|
存储 关系型数据库 数据库
关系型数据库设计范式:深入理解与实践
【7月更文挑战第20天】关系型数据库设计范式是数据库设计中的重要指导原则,它通过一系列规范来减少数据冗余、提高数据一致性和优化查询性能。在实际应用中,我们应该根据具体需求和数据特点,灵活选择和应用不同的范式级别,以构建高效、可靠和可扩展的数据库系统。同时,也需要注意范式设计带来的挑战和限制,根据实际情况进行权衡和调整。
|
3月前
|
存储 Java 数据库连接
数据库三范式详解及应用
数据库三范式详解及应用
|
3月前
|
存储 Java 数据管理
数据库三范式设计与规范化过程详解
数据库三范式设计与规范化过程详解
|
3月前
|
存储 SQL 关系型数据库
MySQL设计规约问题之在数据库设计中,为什么要适当考虑反范式的表设计
MySQL设计规约问题之在数据库设计中,为什么要适当考虑反范式的表设计
|
5月前
|
存储 关系型数据库 数据库
关系型数据库设计规范第一范式(1NF)
【5月更文挑战第14天】关系型数据库设计规范第一范式(1NF
108 8
|
5月前
|
关系型数据库 数据库
关系型数据库设计规范第二范式(2NF)
【5月更文挑战第14天】关系型数据库设计规范第二范式(2NF)
133 7