BCNF范式(修正的第三范式)

本文介绍了Boyce-Codd范式(BCNF),这是一种比第三范式更为严格的数据库规范化标准,确保所有属性不传递依赖于候选键。通过配件管理表案例分析,展示了如何判断和实现BCNF。

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

修正的第三范式(BCNF

    一定义

当下面性质成立时,一个数据库模式中的表T及函数依赖集F被称为符合Boyce-Codd范式(BCNF):任何F可推导出的函数依赖X->A都在T中,这里A是不在X中的单一属性,X必须是T的一个超键。当一个数据库模式包含的所有表都符合BCNF时,这个数据库被称为符合BCNF.

说明

BCNF是比第三范式更严格一个范式。它要求关系模型中所有的属性(包括主属性和非主属性)都不传递依赖于任何候选关键字。也就是说,当关系型表中功能上互相依赖的那些列的每一列都是一个候选关键字时候,该满足BCNF

BCNF实际上是在第三范式的基础上,进一步消除了主属性的传递依赖。

三举例

有这样一个配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示仓库号,PNO表示配件号,ENO表示职工号,QNT表示数量。

有以下约束要求:

 一个仓库有多名职工;

2 一个职工仅在一个仓库工作;

每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件;

同一种型号的配件可以分放在几个仓库中。

分析表中的函数依赖关系,可以得到:

  1 ENO->WNO;

  2WNOPNO->QNT

  3WNOPNO->ENO

  4ENOPNO->QNT

可以看到,候选键有:(ENO,PNO;(WNO,PNO)。所以,ENO,PNO,WNO均为主属性,QNT为非主属性。显然,非主属性是直接依赖于候选键的。所以此表满足第三范式。

而我们观察一下主属性:(WNO,PNO->ENO;ENO->WNO。显然WNO对于候选键(WNO,PNO)存在传递依赖,所以不符合BCNF.

解决这个问题的办法是分拆为两个表:管理表EPENOPNOQNT);工作表EWENOWNO)。但这样做会导致函数依赖(WNO,PNO->ENO丢失。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值