数据库范式--三范式理论
泛域名ssl证书 239元1年送1个月、单域名39元1年,Sectigo(原Comodo证书)全球可信证书,强大的兼容性,高度安全性,如有问题7天内可退、可开发票
加微信VX 18718058521 备注SSL证书
【腾讯云】2核2G4M云服务器新老同享99元/年,续费同价
我们在设计关系型数据库模型的时候,需要对关系内部各个属性之间联系的合理化程度进行定义,这就有了不同等级的规范要求,这些规范要求被称为范式(NF)。你可以把范式理解为,一张数据表的设计结构需要满足的某种设计标准的级别。
目前关系型数据库一共有 6 种范式,按照范式级别,从低到高分别是:1NF(第一范式)、2NF(第二范式)、3NF(第三范式)、BCNF(巴斯 - 科德范式)、4NF(第四范式)和 5NF(第五范式,又叫做完美范式)。
数据库的范式设计越高阶,冗余度就越低,同时高阶的范式一定符合低阶范式的要求,比如满足 2NF 的一定满足 1NF,满足 3NF 的一定满足 2NF,依次类推。
范式相关概念定义
范式的定义会使用到主键和码/候选键(因为主键和候选键可以唯一标识元组),数据库中的键(Key)由一个或者多个属性组成。我总结了下数据表中常用的几种键和属性的定义(便于了解范式中的一些定义):
超键:能唯一标识元组的属性集叫做超键。
码/候选键:码中可以包含1到多个属性,码一确定,数据就确定(也可以理解为表的主键)
主属性:包含在码中的每个属性(比如id, name两个字段构成该表的主键,那么它们分别是一个主属性)
非主属性:不包含在码中的属性(非主键的其他字段)
三种依赖:
完全函数依赖 - F:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。
例子:存在学生基本信息表R(学号,班级,姓名),假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)-> (姓名)不成立,(班级)-> (姓名)不成立,所以姓名完全函数依赖于(学号,班级);
部分函数依赖 - P(主属性至少两个):设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。存在某一个主属性可以确定一到多个非主属性
例子:学生基本信息表R(学号,身份证号,姓名),学号属性是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖于(学号,身份证号);
传递函数依赖 - T(至少存在三个属性):设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。
例子:在关系R(学号 ,宿舍, 费用)中,(学号) -> (宿舍),宿舍 !-> 学号,(宿舍) -> (费用),费用 !-> 宿舍,所以符合传递函数的要求;
范式定义
1NF:最基本的要求,是指数据库表的每一列(即每个属性)都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之,第一范式就是无重复的列,列中不含有多个值,每个属性不可再分
2NF:消除了非主属性对于码的部分函数依赖(码中的部分主属性能决定某个非主属性),若主属性只有一个则肯定满足
实体属性要完全依赖主键,不能依赖部分主键。
3NF:消除了非主属性对于码的传递函数依赖(某个非主属性可以决定另一个非主属性)(若非主属性只有一个则肯定满足)
一个表中不能包含其它表中已包含的非主关键字信息。不严谨地说就是这个表只包含其他表的ID。
BCNF(巴斯范式):消除主属性对于码的部分与传递函数依赖(至少两个主属性)(一般是因为存在多个码,多个主属性,一个主属性可以决定另外一个主属性(另外的主属性又可以反过来决定原来的主属性))
一般来说,我们都会遵循第一和第二范式, 但是为了性能,为了避免过多的join, 有时候会违反第三范式,冗余一些字段的信息。