数据库范式

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,还又称完美范式)。满足最低要求的范式是第一范式(1NF),在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。

讲范式之前顺便说下下面几个概念:

实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。

属性:实体所具有的某一特性”,比如说,“性别”是“人”的一个属性。在关系数据库中,属性可以看作是“表的一列”。

元组:表中的一行就是一个元组。

码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码,如果一个码包含了所有的属性,这个码就是全码。例如:在关系模式供应(供应商名称,供货名称,供应单价)中,属性的组合(供应商名称,供货名称)是唯一的候选码,也是主码。

主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。

非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。

外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。

第一范式(1NF):

所谓第一范式(1NF)是指在关系模型中,对域添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。

例如:订单(订单编号,订单名称,地址),因为地址又可以分为省市等信息,如果只是想查市的信息,则会有很多多余操作,所以不满足第一范式,应把地址划分为省市区详细地址等,如:订单(订单编号,订单名称,省,市,区,详细地址)则满足第一范式。

第二范式(2NF):第二范式在第一范式的基础之上,要求实体的属性完全依赖于主关键字,所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。简而言之,就是属性完全依赖于主键,从而消除非主属性对主码的部分函数依赖。

例如:订单(订单编号、商品编号、商品名称、定购日期、价格),这个表中是以订单编号和商品编号作为联合主键,这样在该表中商品名称不与该表的主键相关,而仅仅是与商品编号相关也就是部分依赖于主键,也就是说如果没有订单编号,我们就无法知道商品名称所对应的编号,所以显然不满足第二范式,应删除商品名称列并新建商品(商品编号,商品名称)满足第二范式。

第三范式(3NF)::第三范式在第二范式的基础上,确保每列都和主键列直接相关,而不是间接相关,也就是消除传递依赖。

例如:订单表(订单编号,定购日期,顾客编号,顾客姓名),订单编号和顾客编号相关,顾客编号和顾客姓名又相关,最后经过传递依赖,订单编号和顾客姓名相关,也就是说没订单顾客姓名就不存在了,但是顾客姓名是实际存在的,满足第三范式,所以应去掉顾客姓名列,单独建一个顾客(顾客编号,顾客姓名)满足第三范式。

巴斯-科德范式(BCNF)::在第三范式的基础上,确保主属性不依赖主属性,也就是说若关系模式属于第一范式,且每个属性都不传递依赖于键码,那么它属于BCNF范式,还可以说若一个关系达到了第三范式,并且它只有一个候选码,或者它的每个候选码都是单属性,则该关系自然达到BCNF范式。

第四范式:要求把同一表内的多对多关系删除。

第五范式:从最终结构重新建立原始结构。

一般一个数据库设计符合3NF或BCNF就可以了,并且,某些情况下,过于范式化甚至会对数据库的逻辑可读性和使用效率起到阻碍。数据库中一定程度的冗余并不一定是坏事情。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值