数据库求助(有关依赖关系)

数据库求助(有关依赖关系),第1张

这个简单

候选关键字:学号(每个学生只有惟一的学号)

最小依赖集:{学号→姓名,学号→出生日期,学号→班号,系名→宿舍区,班号→系名}

存在传递函数依赖:

学号→系名→宿舍区,∴有学号→宿舍区;

班号→系名→宿舍区,∴有班号→宿舍区;

学号→班号→系名,∴有学号→系名;

关系模式:

学生(学号,姓名,出生年月,班号)

班级(班号,专业名,入校年份,人数)

专业(专业名,系号)

系(系名,系号,系办公室地点,人数,学生宿舍区)

学会(学会名,成立年份,地点,人数)

学生学会(学号,学会名,入会年份)

模式的极小函数依赖集:

学生{学号→姓名,学号→出生年月,学号→班号},不存在传递依赖和部分依赖,班号为外码;

班级{班号→专业名,班号→入校年份,班号→人数},不存在传递依赖和部分依赖,专业名为外码;

专业{专业名→系号},不存在传递依赖和部分依赖,系号为外码;

系{系号→系名,系号→系办公室地点,系号→人数,系号→学生宿舍区},不存在传递依赖和部分依赖;

学会{学会名→成立年份,学会名→地点,学会名→人数},不存在传递依赖和部分依赖;

学生学会{(学号,学会名)→入会年份},不存在传递依赖和部分依赖。

候选键是a或b。

a->c,

a->b,

a->bc,

bc->d,

a->d

所以a是key

b->a,所以b也是key

--------------------------------------------

是第一范式,因为满足每一个分量不可再分;

是第二范式,因为非主属性c

、d完全依赖于key;

是第三范式,因为非主属性c

、d对主属性a、b不存在传递函数依赖;

是bc范式,因为每一个决定因素必含有a或b;

是第四范式,因为不存在非平凡且非函数依赖的多值依赖。

(两个多值依赖,都含有主属性)

因此,最高是第四范式。

这六个范式是逐步加强,数据库设计时,满足的范式越高,理论上讲,数据冗余就越少,并且越不容易出问题。。。实际上嘛。。就不说了。。总之,一般设计数据库时要求满足第三范式第一范式的意思就是每列都不可再分,且每个表中的每列都是不重复的,只有满足了第一范式才叫关系型数据库。先满足第一范式才能满足第二范式,第二范式的意思是表中的每行必须唯一,也就是说,要有能唯一标识每行的列(或几个列也行)满足第二范式才能满足第三范式,第三范式是的意思是要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。鲍依斯-科得范式,也就是BC范式,在第三范式的基础上,消除传递依赖(传递依赖。。这个还有个定义问题:比如A->B,B->C,则A与C之间的依赖就是传递依赖)第四范式,(不废话了,反正前提是先满足前一个范式,下面也一样),消除多值依赖(多值依赖就是存在一对多的关系,间接和直接的都可能有)第五范式,这个就比较扯了,细分成第四范式以后表已经很碎了,第五范式还要求更碎。。。第五范式的目标还是消除多值依赖,不过所消除多值依赖的更难以发现,官方的说法是:保证在第四范式中存在的任何可以分解为实体的三元关系都被分解。 晕不?

以上就是关于数据库求助(有关依赖关系)全部的内容,包括:数据库求助(有关依赖关系)、数据库,关系模式的极小函数依赖、数据库有关系模式R(A,B,C,D)有依赖关系F=(A->B, B->C) BC范式问题等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/sjk/10070212.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-04
下一篇 2023-05-04

发表评论

登录后才能评论

评论列表(0条)

保存