数据库设计范式深入浅出
关系数据库设计之时是要遵守一定的规则的，尤其是数据库设计范式。现简单介绍1NF(第一范式)，2NF(第二范式)，3NF(第三范式)和BCNF，另有第四范式和第五范式留到以后再介绍。在你设计数据库之时，若能符合这几个范式，你就是数据库设计的高手。
第一范式(1NF)：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。
例：如职工号，姓名，电话号码组成一个表(一个人可能有一个办公室电话和一个家里电话号码)，规范成为1NF有三种方法：
1、重复存储职工号和姓名。这样关键字只能是电话号码。
2、职工号为关键字，电话号码分为单位电话和住宅电话两个属性
3、职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
第二范式(2NF)：如果关系模式R(U,F)中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R是属于第二范式的。
例：选课关系SCI(SNO,CNO,GRADE,CREDIT)其中SNO为学号，CNO为课程号，GRADEGE为成绩，CREDIT为学分。由以上条件，关键字为组合关键字(SNO,CNO)
在应用中使用以上关系模式有以下问题：
a.数据冗余，假设同一门课由40个学生选修，学分就重复40次。
b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。
c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。
d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。
解决方法：分成两个关系模式 SC1(SNO,CNO,GRADE)，C2(CNO,CREDIT)。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系
第三范式(3NF)：如果关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
例：如S1(SNO,SNAME,DNO,DNAME,LOCATION)各属性分别代表学号、姓名、所在系、系名称、系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键字 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> DNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S(SNO,SNAME,DNO)，D(DNO,DNAME,LOCATION)
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
BCNF：如果关系模式R(U,F)的所有属性(包括主属性和非主属性)都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字(而不是被关键字所包含)，则RCNF的关系模式。
例：配件管理关系模式 WPE(WNO,PNO,ENO,QNT)分别表仓库号、配件号、职工号、数量。有以下条件：
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析：由以上得 PNO 不能确定QNT，由组合属性(WNO,PNO)来决定，存在函数依赖(WNO,PNO) -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性(WNO,PNO)才能确定负责人，有(WNO,PNO)-> ENO。因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 (ENO,PNO)-> QNT。
找一下候选关键字，因为(WNO,PNO) -> QNT，(WNO,PNO)-> ENO ，因此 (WNO,PNO)可以决定整个元组，是一个候选关键字。根据ENO->WNO，(ENO,PNO)->QNT，故(ENO,PNO)也能决定整个元组，为另一个候选关键字。属性ENO,WNO,PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字(ENO,PNO)的部分依赖，因为(ENO,PNO)-> ENO但反过来不成立，而PNO->WNO，故(ENO,PNO)-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
解决办法：分成管理EP(ENO,PNO,QNT)，关键字是(ENO,PNO)工作EW(ENO,WNO)其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。
一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。
1NF直到BCNF的四种范式之间有如下关系：
BCNF > 3NF > 2NF > 1NF
小结：
目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
原则：遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式“等价”，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。
各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？
我见过的数据库设计，很少有人做到很符合以上几个范式的，一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它，当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。
附：对6个范式的通俗归纳
------------------------------------------------------------------
1NF：一个table中的列是不可再分的(即列的原子性)
例：(A,B,C-D-E) 分解为 (A,B,C,D,E)
2NF：非主键列必须完全依赖整个主键
例：(A,B,C,D)主键(A,B)，且(A,B)->C,A->D，则分解为(A,B,C)主键(A,B)外键A,(A,D)主键A
3NF：一个table中的非主键列C不存在 A->B->C 情况
例：(A,B,C,D)主键A，且A->B,A->C,B->D，则分解为(A,B,C)主键A外键B,(B,D)主键B
BCNF：3NF去掉非主键限制
例：(A,B,C,D)主键(A,B,C)，且(A,B)->C,C->A，则分解为(A,B,D),(C,A)，但是会失去(A,B)->C，破坏数据一致性
注：如果满足3NF，且主键只有一个属性或主键属性间无依赖，则自动满足BCNF
4NF：禁止主键列和非主键列一对多关系(消除多值依赖)
例：(A,B,C)主键(A,B)，且(A,B)->C，则分解为(A,C),(B,C)
5NF：将一个table尽可能的分割成小的块，以排除在table中所有连接依赖
例：(A,B,C)主键(A,B,C)，则分解为(A,B),(B,C),(A,C)
再稍微详细一点的举例说明：
-----------------------------------------------------------------
第一范式:
定义：如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空，
3)主键不能重复,
4)字段不可以再分
例如：
StudyNo | Name | Sex | Contact
20040901 john Male Email:kkkk@ee.net,phone:222456
20040901 mary famale email:kkk@fff.net,phone:123455
以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male
kkkk@ee.net
222456
20040902 mary famale
kkk@fff.net
123455
第二范式：
定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。
所以第二范式的主要任务就是满足第一范式的前提下，消除部分函数依赖。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john Male
kkkk@ee.net
222456 200401 A楼2
02 mary famale
kkk@fff.net
123455 200402 A楼3
这个表完全满足于第一范式,主键由StudyNo和ClassNo组成，这样才能定位到指定行
但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),所以要变为两个表
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male
kkkk@ee.net
222456 200401
02 mary famale
kkk@fff.net
123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
第三范式：
满足第二范式的前提下，消除传递依赖。
例:
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male
kkkk@ee.net
优秀 $1000
20040902 mary famale
kkk@fff.net
良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为：
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
这里我比较喜欢用bounsNo作为主键，基于两个原因
1) 不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？
2) 但是如果等级名称更改了，不叫 1,2,3或优,良，这样就可以方便更改，所以我一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
第四范式：
主要任务：满足第三范式的前提下，消除多值依赖
product | agent | factory
Car A1 F1
Bus A1 F2
Car A2 F2
在这里，Car的定位，必须由 agent 和 Factory才能得到（所以主键由agent和factory组成）,可以通过 product依赖了agent和factory两个属性
所以正确的是
表1 表2：
product | agent factory | product
Car A1 F1 Car
Bus A1 F2 Car
Car A2 F2 Bus
第五范式：
定义: 如果关系模式R中的每一个连接依赖, 都是由R的候选键所蕴含, 称R是第五范式的
看到定义，就知道是要消除连接依赖,并且必须保证数据完整
例子
A | B | C
a1 b1 c1
a2 b1 c2
a1 b2 c1
a2 b2 c2
如果要定位到特定行，必须三个属性都为关键字。
所以关系要变为 三个关系，分别是A 和B,B和C,C和A
如下：
表1 表2 表3
A | B B | C C | A
a1 b1 b1 c1 c1 a1
a1 b2 b1 c2 c1 a2
范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦，但是操作难，因为需要联系多个表才能得到所需要数据，而且越高范式性能就会越差。要权衡是否使用更高范式是比较麻烦。
一般我在做项目中都，用得最多的也就是第三范式，我认为使用到第三范式也就足够了，性能好而且方便管理数据。
-The End-