数据库1~4NF+ BCNF

基础概念

元组:表中的一行即为一个元组,对应存储文件中的一个记录值。数据表中一行数据。
属性:表中的列称为属性,每一列有一个属性名。属性名相当于记录中的数据项或字段值。

码:具有唯一性的key。
候选码:属性或属性组合,其值能够唯一标识一个元组。若关系中的某一属性组的值能唯一地标识一个元组(一行数据),则称该属性组为候选码;
主码(主键):在一个关系中可能有多个候选码,从中选择一个作为主码。也就是主键。
主属性:候选码的诸属性称为主属性(Primeattribute)。
非码属性:不包含在任何侯选码中的属性称为非码属性(Non-key attribute)。
超码:也叫超键,是指包含所有候选键属性及其他非码属性的集合。

部分函数依赖:如果X->Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖。部分函数依赖就是一个组合里任意真子集能够决定依赖关系,例如(学号,课程号)---->姓名这个组合关系的函数依赖中,单一个学号也能够决定姓名了,所以这就是部分函数依赖。
传递函数依赖:在R(U,F)中,如果X->Y,Y->Z,则称Z对X传递依赖。


在最简单的情况下,候选码只包含一个属性。
在最极端的情况下,关系模式的所有属性组是这个关系模式的候选码,称为全码(AIl-key)。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。

在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

1NF 属性不可再分

所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

2NF 不存在部分依赖

定义:设R是一个关系模式,R属于第二范式当且仅当R是1NF,且每个非主属性都完全函数依赖于候选码。满足第二范式(2NF)必须先满足第一范式(1NF)。

第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。

第二范式(2NF)要求实体的属性完全依赖于主关键字。

3NF 不存在传递依赖

3NF,即第三范式是设R是一个关系模式,R属于第三范式当且仅当R是2NF,且每个非主属性都非传递函数依赖于候选码。

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。满足第三范式(3NF)必须先满足第二范式(2NF)。

鲍依斯-科得范式(BCNF)

是数据库设计中的一种更高级的范式,它在第三范式(3NF)的基础上进一步消除了函数依赖。

BCNF要求一个关系模式R满足以下两个条件:

  1. R必须满足第三范式(3NF)。
  2. 对于关系模式R中的每个非平凡函数依赖X → Y,X必须是R的超键。

针对主键包含多个字段情况(A,B,C都是主键,A,B → C情况不能存在)

遵循BCNF可以避免数据冗余和更新异常,提高数据库的性能和可维护性。

4NF非多值依赖

设关系R(X,Y,Z),其中X,Y,Z是成对的、不相交属性的集合。若存在非平凡多值依赖,则意味着对R中的每个属性存在有函数依赖(X必包含键)。

在Boyce-Codd范式(BCNF)之后,4NF是下一级别的规范化。 尽管第二,第三和Boyce-Codd范式具有功能依赖性,但4NF却具有更为通用的依赖性类型,即多值依赖性。

例如,一个学生选课表的字段包括学生ID、课程ID和成绩。在第三范式下,成绩依赖于学生ID和课程ID,1个学生可以多个课程都考相同成绩,但是在第四范式下,应该将成绩拆分为独立的关系表,以避免多值依赖。

  • 12
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

Kingairy

你的鼓励将是我创作的最大动力

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

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

打赏作者

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

抵扣说明:

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

余额充值