数据表的BCNF规范实例
1 简介
- 依赖
设R(U)是在属性U上的关系模式,X,Y是U的子集,若对于R(U)的任意一个可能的关系r,r中的任意两个元组在X上的属性值相等,那么在Y上的属性值也相等,则称“X函数确定Y”或“Y函数依赖于X”,记作X→Y。
X称为这个函数依赖的决定属性组,也称为决定因素。
- 公理:
Armstrong公理:从已知的一些函数依赖,可以推导出另外一些函数依赖,这就需要一系列推理规则,这些规则常被称作“Armstrong 公理”设关系式R(U,F),U是关系模式R的属性集,F是U上一组函数依赖,则有以下三条推理规则:
●A1自反律:若YCXCU,则X→Y为F所蕴含;
●A2增广律:若X→Y为F所蕴含,且ZCU,则XZ→>YZ为F所蕴含;
●A3传递律:若X→Y,Y→Z为F所蕴含,则X→Z为F所蕴含。
根据上面三条推理规则,又可推出下面三条推理规则:
●合并规则:若X→Y,X→Z,则X→YZ为F所蕴含;
●伪传递规则:若X→Y,WY→Z,则XW→Z为F所蕴含;
●分解规则:若X→Y,ZCY,则X→Z为F所蕴含。
第一范式(1NF):若关系模式R的每一个分量是不可再分的数据项,则关系式R属于第一范式。
第二范式(2NF):若关系模式R∈1NF,并且每一个非主属性完全依赖主键时,则R是2NF。
第三范式(3NF): 当2NF消除了非主属性对主键的传递函数依赖则为3NF。
BC范式: 通常认为BCNF是修正的第三范式,在3NF的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。BC范式消除主属性的传递依赖。
2 案例
现在企业需要新建线上销售系统,为用户提供便捷的互联网商品销售服务、
该系统除了常规商品展示、订单、用户交流与反馈功能外,还需要提供当前热销产品排名、评价分类管理等功能,
以下为规范化设计后部分数据库的表:
供应商(供应商ID,供应商名称,联系方式,供应商地址);
商品(商品ID,商品名称,商品型号,商品价格,供应商ID)
商品库存(商品ID,当前库存数量);
订单(订单号码,商品ID,供应商ID,商品数量,订单金额)
3 修改
为了使这些表符合BCNF(Boyce-Codd范式)的要求,我们需要确保每个表中每个非主属性都完全依赖于候选键,并且候选键的每个属性都不能依赖于任何非主属性。
BCNF是3NF的一个强化版本,要求更严格。我们逐一分析如何修改这些表以满足BCNF。
-
-
供应商表
供应商(供应商ID,供应商名称,联系方式,供应商地址)
-
分析与修改:
这个表已经符合BCNF的要求。供应商ID 是主键,其他非主属性(供应商名称、联系方式、供应商地址)都完全依赖于主键,没有部分依赖或传递依赖问题。
-
-
商品表
商品(商品ID,商品名称,商品型号,商品价格,供应商ID)
-
假设商品只能有一个供应商:
那么 商品ID 是主键,所有非主属性(商品名称、商品型号、商品价格、供应商ID)都完全依赖于商品ID,没有依赖于部分键或非主属性。这个表符合BCNF。
假设一个商品可以由多个供应商提供:
表结构不再符合BCNF,因为会存在多个候选键,导致 供应商ID 和 商品ID 之间的依赖关系需要被分解。
因此,建议将供应商关系单独放在一张表中,如下所示:
商品表(商品ID, 商品名称, 商品型号, 商品价格)
商品供应商表(商品ID, 供应商ID)
这种设计可以确保每个属性完全依赖于候选键(商品ID 或 商品ID, 供应商ID),从而满足BCNF的要求。
-
-
商品库存表
商品库存(商品ID,当前库存数量)
-
商品ID 是主键,当前库存数量 完全依赖于 商品ID,不存在部分依赖或传递依赖。这张表已经符合BCNF。
-
-
订单表
订单(订单号码,商品ID,供应商ID,商品数量,订单金额)
-
分析与修改:
这个表存在的问题是 供应商ID 可以通过 商品ID 获取到,因此它在此表中是冗余的,违反了BCNF中的依赖规则。
为了解决这个问题,可以将 供应商ID 从订单表中移除,并通过查询商品供应商表来获取供应商信息。修改后的表结构如下:
订单表(订单号码, 商品ID, 商品数量, 订单金额)
删除 供应商ID,因为它是可以通过 商品ID 获取的。
4 符合BCNF规范的表结构:
供应商表
供应商(供应商ID, 供应商名称, 联系方式, 供应商地址)
商品表
商品(商品ID, 商品名称, 商品型号, 商品价格)
商品供应商表
商品供应商(商品ID, 供应商ID)
商品库存表
商品库存(商品ID, 当前库存数量)
订单表
订单(订单号码, 商品ID, 商品数量, 订单金额)
通过这些调整,所有表都符合BCNF的要求,去除了依赖性问题,使每个表中的非主属性完全依赖于候选键,并且候选键的每个属性不会依赖于非主属性。
- 点赞
- 收藏
- 关注作者
评论(0)