数据库的各个范式


备注:此文偏专业术语,不易理解,佶屈聱牙,晦涩难懂,新总结了一篇,链接如下 数据库范式2

数据库范式是为了设计出高效、规范的数据库而总结出的一些规则和标准,主要用于消除数据冗余、提高数据的一致性和完整性。

第一范式(1NF)

  • 定义:数据库表中的每一列(属性)都是不可再分的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。
  • 示例:在一个学生信息表中,“联系方式”列不能同时包含多个电话号码,而应该将电话号码拆分成“手机号码”和“家庭电话”等不同的列。

第二范式(2NF)

  • 定义:在满足第一范式的基础上,要求表中的每一个非主属性完全依赖于主键,而不能只依赖于主键的一部分。如果一个关系模式R是1NF,并且每一个非主属性都完全函数依赖于R的码,则R属于2NF。
  • 示例:在一个订单明细表中,主键是(订单编号,商品编号),如果存在“商品名称”这个非主属性,它只依赖于“商品编号”,而不是整个主键,就不满足第二范式。应该将商品相关信息单独提取到一个商品表中,通过商品编号与订单明细表关联。

第三范式(3NF)

  • 定义:在满足第二范式的基础上,要求表中的每一个非主属性都不传递依赖于主键。也就是说,非主属性之间不能存在函数依赖关系。如果关系模式R是2NF,且每个非主属性都不传递函数依赖于R的候选码,则R属于3NF。
  • 示例:在一个员工信息表中,有员工编号、部门编号、部门名称等字段。员工编号是主键,部门名称依赖于部门编号,而部门编号又依赖于员工编号,这就存在传递依赖。应该将部门信息单独提取到一个部门表中,通过部门编号与员工信息表关联。

BC范式(BCNF)

  • 定义:在满足第三范式的基础上,对于关系模式R中的每一个函数依赖X→Y(Y不属于X),X都必须包含候选码。也就是说,每一个决定因素都包含码。
  • 示例:在一个仓库管理系统中,有仓库编号、管理员编号、货物编号等字段。假设一个仓库只有一个管理员,一个管理员可以管理多个仓库,一个仓库可以存放多种货物。存在函数依赖(仓库编号→管理员编号)和(管理员编号,货物编号→仓库编号),这里(管理员编号,货物编号)是候选码,但决定因素“仓库编号”不包含码,不满足BCNF。可以将仓库和管理员的关系单独提取到一个表中,以满足BCNF。

第四范式(4NF)

  • 定义:关系模式R满足BCNF,且对于R的每个非平凡多值依赖X→→Y(Y不属于X),X都含有码,则R属于4NF。它主要用于处理多值依赖问题,消除表中的多值依赖关系,使数据更加规范化。
  • 示例:在一个学校课程管理系统中,有学生、课程和教师三个实体。一个学生可以选多门课程,一门课程可以有多个教师授课,一个教师可以教多门课程。如果将这些信息放在一个表中,就会存在多值依赖。例如,学生A选了课程C1,课程C1有教师T1和T2授课,那么就会出现(学生A,课程C1)→→教师T1和(学生A,课程C1)→→教师T2这样的多值依赖。可以将其拆分成两个表,一个是学生选课表(学生,课程),另一个是课程教师表(课程,教师),以满足第四范式。

第五范式(5NF)

  • 定义:也称为投影连接范式(PJNF),是在第四范式的基础上,要求关系模式R中的每一个连接依赖都由R的候选码所蕴含。它是一种更高级的范式,用于处理非常复杂的关系模式中的数据依赖问题。
  • 示例:假设存在一个关系模式R(A,B,C,D),其中存在连接依赖JD(AB,BC,CD),即关系R可以通过投影到AB、BC和CD三个子模式上,然后再通过自然连接恢复到原关系R。如果关系模式R满足5NF,那么这个连接依赖必须是由R的候选码所蕴含的。如果不满足,就需要进一步分解关系模式,以消除连接依赖对数据操作的不良影响。

一般在实际的数据库设计中,通常会满足第三范式或BC范式就可以了,能够保证数据库的高效性和数据的完整性。更高的范式虽然可以进一步消除数据冗余,但可能会导致数据库设计过于复杂,增加查询和维护的成本。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值