共计 3500 个字符，预计需要花费 9 分钟才能阅读完成。
关系数据库设计之时是要恪守肯定的规定的。尤其是数据库设计范式 现简略介绍 1NF（第一范式），2NF（第二范式），3NF（第三范式）和 BCNF，另有第四范式和第五范式留到当前再介绍。
在你设计数据库之时，若能合乎这几个范式，你就是数据库设计的高手。
第一范式（1NF）：在关系模式 R 中的每一个具体关系 r 中，如果每个属性值 都是不可再分的最小数据单位，则称 R 是第一范式的关系。
例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码）标准成为 1NF 有三种办法： 一是反复存储职工号和姓名 。这样，关键字只能是电话号码。 二是职工号为关键字 ，电话号码分为单位电话和住宅电话两个属性 三是职工号为关键字，但强制每条记录只能有一个电话号码。以上三个办法，第一种办法最不可取，按理论状况选取后两种状况。
第二范式（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 -> LOCATION 实现的。也就是说，SNO 不间接决定非主属性 LOCATION。 解决目标 ：每个关系模式中不能留有传递依赖。 解决办法 ：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION） 留神：关系 S 中不能没有外关键字 DNO。否则两个关系之间失去分割。
BCNF：如果关系模式 R（U，F）的所有属性（包含主属性和非主属性）都不传递依赖于 R 的任何候选关键字，那么称关系 R 是属于 BCNF 的。或是关系模式 R，如果每个决定因素都蕴含关键字（而不是被关键字所蕴含），则 BCNF 的关系模式。例：配件治理关系模式 WPE（WNO，PNO，ENO，QNT）别离表仓库号，配件号，职工号，数量。有以下条件 a. 一个仓库有多个职工。b. 一个职工仅在一个仓库工作。c. 每个仓库里一种型号的配件由专人负责，但一个人能够治理几种配件。d. 同一种型号的配件能够分放在几个仓库中。剖析：
- （1）由以上得 PNO 不能确定 QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO）-> ENO。
- （2）因为每个仓库里的一种配件由专人负责，而一个人能够治理几种配件，所以有组合属性（WNO，PNO）能力确定负责人，有（WNO，PNO）-> ENO。
因为 一个职工仅在一个仓库工作，有 ENO -> WNO。因为每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有（WNO，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 中可通过触发器解决其毛病。当前咱们独特做设计之时，也心愿大家恪守以上几个范式。