一、函数依赖
记 A->B 表示 A 函数决定 B，也可以说 B 函数依赖于 A。
如果 {A1，A2，... ，An} 是关系的一个或多个属性的集合，该集合函数决定了关系的其它所有属性并且是最小的，那么该集合就称为键码。
对于 A->B，如果能找到 A 的真子集 A'，使得 A'-> B，那么 A->B 就是部分函数依赖，否则就是完全函数依赖。
对于 A->B，B->C，则 A->C 是一个传递函数依赖。
二、范式
高级别范式依赖于低级别范式
- 第一范式（1NF）：属性不可分
- 第二范式（2NF）：每个非主属性完全依赖于键码。
- 第三范式（3NF）：非主属性不传递依赖于键码
三、特点
- 在范式化的数据库中，每个事实数据会出现并且只出现一次。
- 在反范式化的数据库中，信息是冗余的，可能会存储在多个地方。
范式的优点
当为性能问题寻求帮助时，常会被建议对schema进行范式化设计，尤其是写密集的场景。
- 范式化的更新操作通常比反范式快。
- 当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
- 范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快。
- 很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。
范式的缺点
- 通常需要关联。稍微复杂一些的查询语句在符合范式的schema上都可能需要至少一次关联，也许更多。
- 代价昂贵
- 可能使一些索引策略无效。如，范式化可能将列存放在不同的表中，而这些列如果在一个表中本可以属于同一个索引。
反范式的优点
- 所有数据都在一张表中，可以很好地避免关联。大部分查询最差情况是全表扫描。当数据比内存大时，这可能比关联要快得多，因为这样避免了随机IO。全表扫描基本上是顺序IO，跟引擎的实现有关。
- 能使用更有效的索引策略。
反范式的缺点
- 冗余数据
- 修改异常：修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
- 删除异常：删除一个信息，那么也会丢失其它信息。
- 插入异常：缺少属性，无法加入
