数据库范式

->（一）第一范式

关系模式中属性的域是原子的，不可分割；具体来说，第一范式是对属性不具有任何子结构这个思想的形式化，也即是属性不能是复合属性或者是组合属性。在E-R模型转化为关系模式的设计过程中，就已经消除了属性子结构。
1.含有复合属性的实体集：
当在一些使用场景中希望希望引用αdrress的整体属性，在另一些场景中有希望引用αddress属性的一部分，例如省份。那么αddress就应该设计为复合属性，而不是简单属性。

:表1：

E-R模型转化为关系模式：对于复合属性，让每个子属性本身成为一个属性，也就是：

表2：

 

2、含有多值属性的例子：一个用户可以有0个，1个或者多个爱好：

表3

E-R模型转化为关系模式：对于多值属性，为多值属性的每个项创建一个元组，也就是：

表4：

以上：表1，表3不满足第一范式，表2，表4满足第一范式。满足第一范式。

（二）BC范式

满足第一范式使得关系模式中的属性不具有任何子结构；
满足BC范式则解决模式中数据冗余及不一致性问题。（数据重复存储）

记符号R为关系模式r(R)的属性集，α，β表示属性集。
函数依赖：考虑关系模式r(R)，α，β为R子集，该关系模式一个实例满足函数依赖α->β的条件时：对于实例中所有元组对t1和t2，如果t1[α]=t2[α],则t1[β]=t2[β]。如果关系模式r(R)每个实例都满足函数依赖α->β，则说函数依赖α->β在关系模式r(R)上成立；
平凡函数依赖：在任意关系中都满足的函数依赖；
(1)β为α子集,形如α->β的函数依赖是平凡函数依赖。    （超集->子集）
(2)函数依赖A->A在任意包含属性A的关系模式上满足，所以是平凡函数依赖 。（这个可以看做(1)的一个特例）
例如，元组t1和元组t2在属性集α={ID,name,dept,age}上取值相等，{(ID,1),(name:Alice),(dept:math),(age:20）}，则元组t1和元组t2在属性集β={name,dept}也会取值相等。

考虑关系模式r(R)，α，β为R子集，所有函数依赖
满足BC范式的条件：至少下列一项成立：
（1）α->β是平凡函数依赖（β为α子集);
（2）α是模式R的一个超码；
不满足BC范式的条件：以上两项都不成立，即存有一个非平凡函数依赖α->β，α不是模式R的超码。
换句话说，如果存在非平凡函数依赖α->β，α必须是模式R的超码，才满足BC范式。譬如：

存在非平凡函数typename->typedesc,（α=typename，β=typedesc）其中type不是该模式的超码，所以不满足BC范式。
不满足BC范式，最直观的影响是数据冗余，每次记录相同type值，都会记录以便typedesc值。除此之外，还给博客类别的增删改带来麻烦。
如果新增一个博客类别，如果还没有用户用该类别写博客，则id,author,content都要设置为空值；
如果修改类别是“自然”的typedesc,那么则需要对全表的多条记录进行修改，修改不完全就会出现数据不一致的问题。

通过模式分解使得满足BC范式。
模式1：α并β
模式2：R-(β-α)
以上的例子处理为：模式1：blog（id,author,content,type),模式2：blogtype(typename,typedesc);
通俗的来看，满足BC范式也就是属性是该实体的直接属性，类型描述（typedesc)字段并不是博客实体的1直接属性，所以他的存在使得关系模式不满足BC范式。
（三）第三范式

考虑关系模式r(R)，α，β为R子集，
满足第三范式的条件：至少下列一项成立：
1.满足BC范式;
2.对于函数依赖α->β，β-α中的每个属性A都包含与R的一个候选码中。（这里，每个属性A不一定包含于同一个候选码，可以是不同的候选码）
(也就是满足2NF必定满足3NF,但是满足3NF不一定满足2NF,2NF比3NF更加严格)
重新考虑上面的关系模式：

1.从上面可知，该关系模式是不满足BC范式的；
2.看第二个条件：
该关系模式的候选码只有id，存在非平凡函数typename->typedesc，（α=typename，β=typedesc），β-α=typedesc，tyoedesc不在任一个候选码之后，所以不满足第三范式。
不满足第三范式的条件是：不满足BC范式，并且对于存在的非平凡函数依赖αβ，β-α中的每个属性α不在任一个候选码中。

参考书籍《数据库系统概念》