数据库设计规范化及性能折衷

在上一篇《第二篇：严格的概念认识——关系、关系模型》，我们已经对关系及关系模型有了一个比较好的把握，并在文章结尾引了了关系模型的概念。在这篇文章中，我们会把关系模型的表示方法暂时简化一下，以便我们进一步研究、学习。简化后的表示方法如下：

　　R(U,F)

R：关系的名称

U：关系的属性集合

F：在关系内部属性与属性的依赖关系。

这遍文章的重点将是讨论属性与属性之间的依赖、决定关系。可能有一个问题是：这些属性间的依赖是从何而来？比如说学号为什么就能确定班级？在这里告诉大家，属性间的依赖来自于需求，而并非固定不变。比如说，在省教育厅的数据库中，学习往往确定不了任何东西。

规范化

根据我的理解，数据库的规范化有这么几层：1NF、2NF、3NF、BCNF、4NF、5NF这么几种。而且，后边的范式包含了前边的范式，换句话说，一个关系，只要满足了后边的范式，那么它必定也满足前边的范式。在详细讲解每个范式之前，先提示大家一下：BCNF范式在实战中非常有用，因为它的判断相对简单、明了。这个我们在第一篇文章中已经讲过，在这里你可以把它与其它范式比较下：

　　BCNF定义：关系模式R<U,F>符合1NF，若X->Y且Y不属于X时X必含有码，则R<R,F>符合BCNF

　　附

1NF定义：每一个分量必须是不可分的数据项。其中，分量你可以看做表中一个属性的具体的值，不可分的意思其实就是能实实在在用明确的数字表示出来，需不是“利润率＝Ｘ／Ｘ”这种没法用数据库直接存储的抽象公式。

R：关系模式的名称

U：属性集，相当于列名

F：属性集上的函数依赖，可以把它理解的一套“哪些属性决定了哪些属性”的集合

1NF

上边已经给出了1NF的定义，可见1NF是基本，但并没有多少实际意义。

函数依赖

在讲其它范式之前，还必须讲几个相关的概念。像以前一样，我会以尽量通俗的文字描述。

函数依赖中有几个比较重要的依赖：传递函数依赖、完全函数依赖、及与其相对的部分函数依赖，这些概念是比较重要的。即使如此以下我会把其它的一些相关的概念也描述下，有兴趣的朋友可以了解下：

X->Y：X、Y都代表具体的属性集的子集，->表示函数确定（函数确定就是指知道了X就能知道Y，就像我们在学习里学习的函数那样，有x\y一一对应的关系，理解这个很重要，下面内容都是基于这点）整个表达式意思是：X函数确定Y，也可称为Y函数依赖于X。

平凡的函数依赖：x->Y，且Y包含于X。

非平凡的函数依赖：x->Y，且Y不包含于X。

完全函数依赖：在R(U)中，如果X->Y，并且对于X的任何一个真子集X1，都有X1不函数确定Y，那么称Y对X完全函数依赖。

部分函数依赖：对应的，如果X->Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖。

传递函数依赖：在R(U)中，如果X->Y，(Y不包含于X)，Y不函数确定X，但Y->Z，则称Z对X传递函数依赖，记作X_传递_>Y.

2NF

定义：如果R满足1NF，且每一个非主属性都完全函数依赖于码，则R满足2NF。举一个反例

(用户IP，页面)-->用户点击数；

用户IP-->用户地址

如果关系为R(用户IP，页面，用户点击数，用户地址)，那么这个关系R不满足2NF。

这种不满足范式的关系，总是让人觉得有大多冗余，有冗余就必定会造成更新的不一致。另外，这种关系本身的意义往往不能明确地表达出来，比如上例：一眼看上去，那个一个记录用户点击页面次数的表，但如果说它是一张用户访问来源的表也未尝不可。这种模棱两可的含义，势必造成后期困扰。

当然，以上说法比较经验化。理论上来说，这种不满足2NF的关系会造成插入异常、删除异常、修改复杂。但我觉得这种理论上的说法没什么可操作性。

3NF

关系模式R(U,F)中，若不存在这样的码X、属性组Y及非属性组Z（Z不包括与Y），使得X->Y,Y->Z成立，且Y不函数依赖于X，则称R满足3NF。

是不是很复杂？没实战意义吧？不如我们直接进入BCNF。因为两者差距甚小，但后者非常简洁、可操作。

BC`NF

我喜欢在中间加个符号^ ^，B、C其实是两个老外名字的首字母，这套我们已经吃习惯，不是么。这里就偏不道出他们的名字。

定义：关系模式R满足1NF，若X->Y且Y不包含于X时，X必含有码，则R满足BCNF。