8.1问题的提出
数据库逻辑设计的一个强有力的工具--关系数据库的规范化理论。
一个关系既可以用来描述一个实体及其属性，又可以用来描述实体间的联系。
关系模式是用来定义关系的。
一个数据库包含一组关系，定义这些关系的关系模式的全体就构成了该数据库的模式，建成模式Scheme。
数据依赖指数据间的相互关联（主要体现于值的是否相等）。
关系模式应当是一个五元组:
R<U,D,DOM,F>
（1）关系名R它是符号化的元组语义；
（2）一组属性U；
（3）属性组U中属性所来自的域D;
（4）属性到域的映射DOM;
（5）属性组U上的一组数据依赖F。
数据依赖分类：函数依赖（Function Dependency）、多指依赖（Multivalued Dependency）。
函数依赖：如学号（S#）、姓名（SN）、系名（SD）。一个学号对应一个学生，一个学生只能在一个系。就像自变量X确定后，相应的函数值f(x)也就唯一确定了一样。我们说S#函数决定SN、SD或者说SN、SD函数依赖于S#,记为S# ->SN,s#->SD。1:1单调函数，n:1费单调函数。
例如：现在建一个数据库描述学校中的情况，面临的对象有：学生（用学号S#描述），系（用系名SD描述），系主任（用姓名MN描述），课程（用课程名CN描述）和成绩（G）。于是得到了一组属性。
U={S#,SD,MN,CN,G}
根据现实需求：
1.一个系有若干学生，一个学生只能属于一个系。
2.一个系只有一个系主任。
3.一个学生可以选多门课，一门课可以供多个学生选修。
4.每个学生选修一门课有一个成绩。
于是得到了属性组U上的一组函数依赖：F={S#->SD,SD->MN,(S#,CN)->G}
如果只考虑函数依赖，得到一个关系模式S<U,F>。
在一个关系模式中，必然存在一个属性组E,对于该关系模式的任何一个关系，当E的值确定之后，关系中别的属性的值也唯一地被确定了，并且E的任何一个真子集不再具有这样的性质。那么E就是这个关系模式的一个码，或叫做候选码。一个关系模式可有多个候选码，指定其中一个作为主码。在上面的关系模式中只有唯一码(S#,CN)。
以上例子有三个“毛病”：
1.如果系刚成立，还没有学生，或者有学生但是没有安排课程。则无法把该系及其负责人的信息存入数据库。这叫插入异常。
2.反过来，如果某系学生全部毕业，我们在删除该系同学的时候把这个系及其负责人的信息也删除了，这叫删除异常。
3.冗余太大。每一个系负责人的信息与该系每一个学生的每门课成绩出现一样多次数。浪费存储空间，维护困难。如换系主任了，逐一更改每一个学生选课元组。
分析原因，函数依赖X->Y不仅给出了对关系的一个完整性约束，而且给出了数据库用作存储的某种联系：从X的信息应该知道Y的信息。若X不含码，就不能从X确定其他信息。即从存储的观点看，一个关系只能反映出码函数决定关系中别的属性的函数依赖。于是，本来S#->SD,SD->MN,但由于他们都不是码，这些信息就无法依附于S#或SD在数据库中存在，而必须让他们依附于(S#,CN)这个属性组（码）存在。这样就导致了三个“毛病”。
解决办法就是使模式中的各个关系模式打到某种程度的“分离”。可以把关系模式S分成三个关系模式：SD<S#,SD,S#->SD>,SG<S#,CN,G,(S#,CN)->G>,D<SD,MN,SD->MN>。这就是一事一地的原则（one fact one place）一种关系值用来描述一个实体或实体间的属性。下面介绍规范化理论就是基于这样一个简单的概念。
8.2规范化（Normalization）
上节的例子说明并非所有满足1NF的关系都能很好的描述现实世界，必须做进一步的分析，以确定如何设计一个好的、反应显示世界的模式。本节描述如何将具有不合适性质的关系转换为更合适的形式。
完全函数依赖：R(U)中，若X->Y,且对X的任何真子集X'均有X'->Y不成立，则，Y对X完全函数依赖。
主属性：包含在任何一个候选码中的属性，叫做主属性。不包含在任何码中的属性叫做非主属性。
传递依赖：R(U)中，若X->Y，(Y不是X的子集)Y->X不成立（n:1），Y->Z,则称Z对X传递函数依赖。若X<->Y（1:1）则X->Z,不是传递依赖了。
全码：整个属性集U作为码。属性间多对多对多的关系为全码。
范式：通常按照属性间的依赖情况区分关系规范化的程度为1NF,2NF,3NF,4NF,4NF等。
投影运算：简单的说便是在关系中选择某些属性列。
规范化：一个低一级范式的关系模式，通过投影运算可以转换为若干个高一级范式的关系模式的集合，这种过程就叫做规范化。
2NF:若R∈1NF,且每一个非主属性完全函数依赖于码。-----不要有联合主键就满足2NF
如：上一节的例子码为（S#,C#），函数依赖有：
(S#,C#)->G,S#->SD, (S#,C#)->SD, (S#,C#)->SL,S#->SL,SD->SL(因为每个系只住一个地方)。 (S#,C#)为码，决定G，SD,SL。可实际上S#就可以决定SD,SL。因此非主属性部分依赖于码。
不满足2NF就会产生插入异常，删除异常，冗余太大。
解决办法，用投影运算把关系模式分解为两个模式，SC=S-L-C[S#,C#,G];SL=S-L-C[S#,SD,SL]这样，均满足2NF。
3NF:每个非主属性既不部分依赖于码(2NF)，也不传递依赖于码。
上例中SC∈3NF,SL不∈3NF,SL中有传递依赖。传递依赖会产生于2NF相似的问题。
解决办法，用投影运算分解S-L为S-D[S#,SD]与D-L[SD,SL]。
BCNF:关系模式R(U,F)∈1NF,若X->Y且Y不包含于X时，X必包含有码（表中（非主，主）属性必须依赖于码），则R<U,F>∈BCNF。BCNF比3NF又进一步。为修正的第三范式，有时也称第三范式。
属性间关系：1:1X<->Y ; 1:nX->Y; n:n无函数依赖关系； 1:1：n X<->Y->Z; 1:m:mn X->Y->Z传递依赖
3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的度量。一个模式中的关系模式如果都属于BCNF,n那么在函数依赖范畴，已经实现了彻底分离，已经消除了插入和删除异常。3NF的不彻底性表现在可能存在主属性对码的部分依赖和传递依赖。
BCNF是否就完美了呢？在函数依赖范畴内完美了，可是没有考虑多值依赖。
多值依赖：设R(U)是属性集U上的一个关系模式，X、Y是U的子集。若对R(U)的任一关系R,对于X的一个给定值，存在Y的一组值与其对应。而Y的这组值又不以任何方式与U-X-Y中的属性值相关，那么就说Y多值依赖与X,记为X->->Y(n:m或1：n)。当Y的这组值的个数总为1时，X->->Y就成了X->Y。
多值依赖具有对称性，若X->->Y,则x->->Z，其中Z=U-X-Y（多值依赖定义中的蓝字）。函数依赖可以看作是多值依赖的一种特殊形式。在关系模式中，若删除一些元组，则多值依赖可能被破坏。
若X->->Y,而Z=∅,则称X->->Y为平凡的多值依赖。
多值依赖与函数依赖的比较：
首先，在关系模式R(U)中函数依赖X->Y的有效性仅决定于X、Y这两个属性集的值。只要在R(U)的任何一个关系R中，元组在X和Y上的值满足定义8.1，则函数依赖X->Y在任何属性集W(XY包含于W包含于U)上成立。也就是说X->Y在R[W](XY包含于W包含于U)上成立的充要条件为X->Y在R[XY]上成立。
而多值依赖并非如此。X->->Y在U上是否成立，不仅要检查X、Y上的值，而且要检查Z=U-X-Y上的值。因此若X->->Y在w(w包含于U)上成立，而在U上则不一定成立。所以多值依赖的有效性与属性集的范围有关。X->->Y在U上成立则在W(XY包含于W包含于U)上成立，反之则不然。
4NF:关系模式R<U，F>∈1NF，如果对于R的每个非平凡多值依赖X→→Y（Y X），X都含有候选码，则R∈4NF。（X→Y）如果R ∈ 4NF， 则R ∈ BCNF4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。因为根据定义，对于每一个非平凡的多值依赖X→→Y，X都含有候选码，于是就有X→Y，所以4NF所允许的非平凡的多值依赖实际上是函数依赖。
总结：
在关系数据库中，对关系模式的基本要求是满足第一范式。这样的关系模式就是合法的、允许的。但是，人们发现有些关系模式存在插入、删除异常、修改复杂，数据冗余等毛病。人们寻找解决这些问题的方法，这就是规范化的目的。
规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的‘分离’，即‘one fact one place’的模式设计原则。让一个关系描述一个概念，一个实体或者实体间的一种联系。若多于一个概念就把它‘分离出去’。因此所谓规范化实质上是概念的单一化。关系模式的规范化过程是通过对关系模式的分解来实现的。用投影运算把低一级的关系模式分解为若干个高一级的关系模式。这种投影分解不是唯一的。投影运算的原则下节会介绍。
按照one fact one place的原则构造关系模式（建表）。
1.建表不要定义联合主键，避免违反2NF。
2.one fact one place，表中的码只能取一到两个，再多就要拆表了，避免违反3NF的传递依赖。
3.两个以上多值依赖就拆分表，变成4NF。
4.拿不准具体属性的表，用本章的规范化方法，画图，分析依赖关系，符合BCNF,投影运算，拆表,多值依赖变成4NF。