关系数据库设计范式

  关系数据库范式设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。一般说来,数据库只需满足第三范式(3NF)就行了。

第一范式(First Normal Form,1st NF)

  无重复的列。

  第一范式(1NF)要求数据库表的每一列都是不可分割的原子数据项,而不能是集合、数组等非原子数据项;如果实体中的某个属性有多个值时,必须拆分为不同的属性。

  第一范式(1NF)要求每一列不能存储集合或数组(例如1个列存储电话号码数组,这属于1对多关系,应该关联出另一个数据表)且不能存储多个属性(例如1个列存储姓名和电话)。

  第一范式(1NF)是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。

第二范式(Second Normal Form,2nd NF)

  有主键,非主键字段依赖主键。

  第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。

  第二范式(2NF)要求每个表必须有有且仅有一个数据元素为主关键字(Primary key),其他数据元素与主关键字一一对应。通常称这种关系为函数依赖(Functional dependence)关系,即表中其他数据元素都依赖于主关键字,或称该数据元素惟一地被主关键字所标识。

  第二范式(2NF)是数据库规范化中所使用的一种正规形式。它的规则是要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系;如果有哪些非主属性只和主键的一部份有关的话,它就不符合第二范式。同时可以得出:如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式(前提是该数据表符合第一范式)。

第三范式(Third Normal Form,3rd NF)

  非主键字段不能相互依赖。

  第三范式(3NF)是第二范式(2NF)的一个子集,即满足第三范式(3NF)必须满足第二范式(2NF)。

  第三范式(3NF)要求表中的所有数据元素不但要能惟一地被主关键字所标识且它们之间还必须相互独立,不存在其他的函数关系。例如在员工表中存在以下字段:员工ID(PK),所在部门ID,部门名称。其中部门名称依赖于所在部门ID,所以该设计不满足第三范式(3NF)。

  不满足第三范式(3NF)的设计初衷可能是为了查询方便(例如在上述例子中,不用关联部门表就能查出来部门名称),但是你能保证查出来的部门名称就一定正确吗?

巴斯-科德范式(BCNF)

  主键字段不能相互依赖。

  巴斯-科德范式(BCNF)是第三范式(3NF)的一个子集,即满足巴斯-科德范式(BCNF)必须满足第三范式(3NF)。通常情况下,巴斯-科德范式被没有新的设计规范加入,只是对第二范式与第三范式中设计规范要求更强,因而被认为是修正第三范式,使数据库冗余度更小。这也是BCNF不被称为第四范式的原因。巴斯-科德范式(BCNF)要求所有非主属性对每一个码都是完全函数依赖,所有主属性对每一个不包含它的码也是完全函数依赖,没有任何属性完全函数依赖于非码的任何一组属性。

(待补充)

                                                                                          优秀的设计才会产生卓越的性能。

转载于:https://www.cnblogs.com/yuyuefly/p/9712183.html

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值