数据库-----范式

Network porter

已于 2022-06-30 16:48:26 修改

阅读量1.9k

点赞数 1

分类专栏：数据库文章标签：数据库 java 开发语言

于 2022-06-30 16:47:53 首次发布

本文链接：https://blog.csdn.net/qq_45438019/article/details/123849943

版权

数据库专栏收录该内容

10 篇文章 0 订阅

订阅专栏

文章目录

一、数据库范式是什么
二、主要范式内容
参考文章

一、数据库范式是什么

数据库规范化，又称正规化、标准化，是数据库设计的一系列原理和技术，以减少数据库中数据冗余，增进数据的一致性。关系模型的发明者埃德加·科德最早提出这一概念，并于1970年代初定义了第一范式、第二范式和第三范式的概念，还与Raymond F. Boyce于1974年共同定义了第三范式的改进范式——BC范式。

除外还包括针对多值依赖的第四范式，连接依赖的第五范式、DK范式和第六范式。

现在数据库设计最多满足3NF，普遍认为范式过高，虽然具有对数据关系更好的约束性，但也导致数据关系表增加而令数据库IO更易繁忙，原来交由数据库处理的关系约束现更多在数据库使用程序中完成。

一般来说，数据库只需满足第三范式(3NF）就行了。

Normal Form 范式

UNF: 非标准化形式
1NF: 第一范式
2NF: 第二范式
3NF: 第三范式
EKNF: 主键范式
BCNF: Boyce–Codd 范式（巴斯-科德范式）
4NF: 第四范式
ETNF: 关键元组范式
5NF: 第五范式
DKNF: 域键范式
6NF: 第六范式

在这里插入图片描述

二、主要范式内容

2.0、UNF: 非标准化形式

2.1、 1NF: 第一范式

第一范式意味着：表中没有重复的行、重复的列；不存在行序、列序。

第一范式（1NF）是数据库正规化所使用的正规形式。第一范式是为了要排除重复组的出现，要求数据库的每一列的论域都是由不可分割的原子值组成；每个字段的值都只能是单一值。1971年埃德加·科德提出了第一范式。

重复群（repeating group）是指含有多值的一个列。原子性（atomicity）的操作语义可以说如果关系数据库管理系统的类型系统允许的值，例如date类型、VARCHAR(20)类型。严格意义上，NULL违背了第一范式；通常把NULL理解为标记（marker），而不是值（value），用专门的函数、运算符去处理NULL。

如果设置了主键的话，理论上不可能会有任何关系数据库的资料表会违反第一范式的原则。
不过就算是在这种情况下，还是可以设计出在骨子里违反第一范式的资料表。最简单的方法就是把多个有意义的值编码过后存进一个字段里，然后在资料表中用很多字段来表达同一个事实。

2.1.1、不符合情况

重复群，数量这个不定个数的值就不符合第一范式

修改可用的
没有唯一标识符，就是缺少类似主键的标识符，下面两个数据就无法去区分记录，标识符可以是一个字段，也可以是一组字段，可以保证在这个资料中的唯一标识符不会重复出现，

改正
用很多字段来表达同一个事实，也是违法的

就算我们能确定每个人不喜欢吃的食物最多不会超过三样，这还是一个很糟的设计。举例来说，我们想要知道所有不喜欢同一种食物的人的组合的话，这就不是件容易的事，因为食物有可能出现在任何一个字段，也就是说每一次的查询都要去检查
9 (3 x 3) 组不同的字段组合。

2.2、2NF: 第二范式

第二范式（2NF）是数据库正规化所使用的正规形式。
规则是要求资料表里的所有资料都要和该资料表的键（主键与候选键）有完全依赖关系：每个非键属性必须独立于任意一个候选键的任意一部分属性。如果有哪些资料只和一个键的一部分有关的话，就得把它们独立出来变成另一个资料表。如果一个资料表的键只有单个字段的话，它就一定符合第二范式。

一个资料表符合第二范式当且仅当

它符合第一范式
所有非键字段都不能是候选键非全体字段的函数

就是当他符合第二范式的时候他一定是符合“所有非键字段都不能是候选键非全体字段的函数and第一范式”，如果他符合“所有非键字段都不能是候选键非全体字段的函数and第一范式”，那他就一定符合第二范式。

2.2.1、问题情况

在这里插入图片描述
这里符合了第一范式，每个值都是单一值。

因为同一个组件有可能由不同的供应商提供，所以得把组件 ID 和供应商 ID 合在一起组成一个主键。
组件（关键词）和价格之间的关系很正确：同一个组件在不同供应商有可能会有不同的报价，所以价格确实和主键完全相关（完全依赖）。
另一方面，供应商的名称和住址就只和供应商 ID 有关（部分依赖），这不符合第二范式的原则。
仔细看就会发现 “Stylized Parts” 这个名称和 “VA” 这个住址重复出现了两次；要是它改名了或是被其他公司并购了怎么办？这时候最好把这些资料存到第二个资料表中：
这么一来，原本的 “组件来源” 资料表就得要做相对应的改动：

检查资料表里的每个字段，确认它们是不是都和关键词完全相关，这样才能知道这个资料表是不是符合第二范式；

如果不是的话，就把那些不完全相关的字段移到独立的资料表里。

2.3、3NF: 第三范式

第三范式（3NF）是数据库正规化所使用的正规形式。
要求所有非主键属性都只和候选键有相关性，也就是说非主键属性之间应该是独立无关的。

如果再对第三范式做进一步加强就成了BC正规化，强调的重点在于“资料间的关系是奠基在主键上、以整个主键为考量、而且除了主键之外不考虑其他因素”。

R表一个关系；
F 表维持 R 所需的一组函数依赖；
X 表 R 属性的子集合；
A 表 R 的一个属性

最早由埃德加·科德在1971年给出的第三范式定义为
1- 关系R(表)满足第二范式 (2NF)；
2- R的每个非键属性是R的每个候选键的非传递依赖。
Carlo Zaniolo于1982年给出的一个等价定义为：
如果对于X——》A这种形式的函数依赖而言，满足一下任意一个条件，R就可以说是满足第三范式：
- A∈（属于） X；也就是说 A 是明显函数依赖
- X是超键
- A 是R 的候选键的一部分

2.3.1、示例

示例 1、

在这里插入图片描述

表中的制造商地址应该是和制造商直接关联的，而不是和组件关联的，应该吧制造商地址独立出来一个表

示例 2、在这里插入图片描述
对于这个表的所有非主键字段都依赖于主键编号，通过主键可以导出唯一非主键字段值，符合第二范式的要求记录有惟一标识，但第三范式要求所有非主键属性之间没有相关联的，应该是独立无关的，小计这个值需要根据 UnitPrice 和Quantity 的值来获得，所以不符合第三范式

修改符合3NF需要把小记拿掉
但在查询时就需要麻烦了： SELECT UnitPrice * Quantity FROM Order
在这里插入图片描述

2.4、EKNF: 主键范式

2.5、BCNF: Boyce–Codd 范式（巴斯-科德范式）

Boyce-Codd范式（英语：Boyce-Codd normal form，缩写BCNF），是数据库规范化的一种正规形式。是在第三范式的基础上加上稍微更严格约束，每个BCNF关系都满足第三范式。 BCNF去除了属性间的不必要的函数依赖。

BCNF的定义是：

如果对于关系模式R中存在的任意一个非平凡函数依赖X->A，都满足X是R的一个超键，那么关系模式R就属于BCNF。
对上述定义，可以理解为：平凡函数依赖关系是指，如果属性集合X包含了属性集合A，那么就一定有X->A；超键是指能够唯一确定表中各行的属性集合，因此一个超键的最小化就是一个候选键；BCNF是说，如果一个属性集合X能“不平凡”地推导出另一个属性集合A，而且X还不能唯一区分表的各行，那么这个表中一定包含了一些冗余信息。

BCNF与第三范式的不同之处在于：第三范式中不允许非主属性被另一个非主属性决定，但第三范式允许主属性被非主属性决定；而在BCNF中，任何属性（包括非主属性和主属性）都不能被非主属性所决定。

就是第三范式只规定了非主键之间不能相关，但主属性（举例，学生id）可以被其他非主属性（“姓名”、“年龄”、“性别”、“班级”）影响，而在bcnf中任何属性都不能被非主属性影响

任何一个BCNF必然满足：