范式（避免数据冗余和操作异常）

函数依赖

A->B A和B是两个属性集，来自同一关系模式，对于同样的A属性值，B属性值也相同

平凡的函数依赖

X->Y，如果Y是X的子集

非平凡的函数依赖

X->Y，如果Y不是X的子集

部分函数依赖

X->Y，如果存在W->Y，且W⊂X

传递函数依赖

在R(U)中，如果X→Y(非平凡函数依赖,完全函数依赖)，Y→Z，则称Z对X传递函数依赖。

记为：X Z

super key&candidate key&primary key&主属性&非主属性

super key：在关系中能唯一标识元素的属性集

candidate key或key：不含有多余属性的super key

primary key：在candidate key 中任选一个

candidate key中X决定所有属性的函数依赖是完全函数依赖

包含在任何一个candidate key中的属性，称为主属性

不包含在candidate key中的属性称为非主属性

1NF 列不可分

列不可分

2NF 消除了非主属性对键的部分函数依赖

在关系T上有函数依赖集F，F+是F的闭包。

F满足2NF，当且仅当每个非平凡的函数依赖X->A(F+),A是单个非主属性，要求X不是任何key的真子集（有可能是super key，也有可能是非key）。

3NF 消除了非主属性对键的传递函数依赖

F满足3NF，当且仅当每个非平凡的函数依赖X->A(F+),A是单个非主属性，要求X是T的super key。

BCNF 消除了主属性对键的部分函数依赖和传递函数依赖

F满足BCNF，当且仅当每个非平凡的函数依赖X->A(F+),A是单个属性，要求X是T的super key。

对于F+中的任意一个X->A，如果A是单个属性，且A不在X中，那么X一定是T的super key。

反范式（减少连接，提高查询效率）

没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提高查询效率，因为在数据库的操作中查询的比例要远远大于DML的比例。但是反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的。

Pattern1：合并1对1关系

car_id	car_name
1	c1
2	c2
3	c3

teacher

teacher_id	teacher_name
1	t1
2	t2
3	t3
4	t4

合并后

car_and_teacher

car_id	car_name	teacher_id	teacher_name
1	c1	1	t1
2	c2	2	t2
3	c3	3	t3
NULL	NULL	4	t4

问题：会产生大量空值，若两边都部分参与则不能合并；

部分参与为大部分参与时比较适合Pattern1

Pattern2：1对N关系中复制非键属性以减少连接

两表连接时复制非键属性以减少连接

例：查询学生以及所在学院名，可以在学生表中不仅存储学院id，并且存储学院名

faculty

fid	fname
1	f1

student

sid	sname	fid	fname
1	s1	1	f1

维护时：

1）如果在UI中，只允许用户进行选择，不能自行输入，保证输入一致性

2）如果是程序员，对于类似学院名这种一般不变的代码表，在修改时直接对两张表都进行修改；如果经常变化，则可以加一个触发器。

Pattern3：1对N关系中复制外键以减少连接

把另一张表的主键复制变成外键

应用后：

Pattern4：N对N关系中复制属性，把两张表中经常需要的内容复制到中间关系表中以减少连接

Pattern5：引入重复值

通常对于一个多值属性，值不太多，且不会经常变，可以在表中建立多个有关此属性的列

address1 | address2 | address3 | address4

Pattern6：建立提取表

为了解决查询和更新之间不可调和的矛盾，可以将更新和查询放在两张表中，从工作表中提取查询表，专门用于查询。只适用于查询实时性不高的情况。

Pattern7：分表

水平拆分

垂直拆分

关系数据库——范式/反范式的利弊权衡和建议相关推荐

大数据互联网架构阶段数据库三范式与反范式
数据库范式一. 三范式主键: 创建表时可以不设置主键 , 但是没有设置主键的表 , 底层会认为所有的键都是主键 ,所以在创建时使用了所有的字段创建索引 , 在查询时索引的存在几乎没有意义 . 复合 ...
mysql范式与反范式_MySQL 三种范式以及反范式 | 剑花烟雨江南
第一范式确保数据表中每列(字段)的原子性,即每个字段都是最小单位,不可拆分. 如:用户表(user)中的 user_name,password,nick_name. 第二范式在第一范式的基础上,保 ...
数据库设计：范式与反范式
三范式第一范式(1NF):数据表中的每一列(每个字段)必须是不可拆分的最小单元,也就是确保每一列的原子性: 第二范式(2NF):满足1NF后,要求表中的所有列,都必须依赖于主键,而不能有任何一列与主 ...
数据建模：三大范式和反范式
范式是数据库规范化的⼀个⼿段,是数据库设计中的⼀系列原理和技术,⽤于减少数据库中的数据冗余,并增进数据的⼀致性. 数据规范化通常是将⼤表分成较⼩的表,并且定义它们之间的关系.这样做的⽬的是为了避免冗余 ...
数据库设计的三范式和反范式
数据库设计的三范式和反范式范式的概念三范式范式一范式二范式三反范式总结范式的概念为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式 ...
关系数据库的范式和反范式
为什么80%的码农都做不了架构师?>>> 范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结 ...
超码、候选码、主码（主键）、主属性、非主属性、关系数据库中的依赖、关系数据库范式、反范式
超码:可以区分记录的一个属性或多个属性的集合. 候选码:超码的最小集,即包含最少属性的超码.超码的最小集可以有多个,即多个集合大小相同,但元素构成不完全相同的最小集. 主码(主键):被选中的一个候选码 ...
数据库设计之范式与反范式
范式设计什么是范式? 范式来自英文Normal Form,简称NF.要想表之间设计-个好的关系,必须使关系满足一定的约束条件,此约束已经形成了规范,分成几个等级,一级比一级要求得严格.满足这些规 ...
Java学习笔记：数据库中的范式和反范式
范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法.数据库的设计范式是数据库设计所需要满足的规范.只有理解数据库的设计范式,才能设计出率.优雅的数据库,否则可能会设计出 ...

关系数据库——范式/反范式的利弊权衡和建议