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

函数依赖

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：分表

水平拆分

垂直拆分