下载文档原格式
关系数据库范式
关系数据库范式是一种用于设计关系数据库的规则和标准，以确保数据的一致性、完
整性和有效性。
主要目的是减少数据冗余和数据维护的复杂性，从而提高数据库的性能和
可靠性。
在关系数据库中，范式共有6个阶段，分别为第一范式（1NF）、第二范式（2NF）、
第三范式（3NF）、巴斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
第一范式（1NF）：属性不可分
第一范式指任何一个关系模式的所有属性都是不可分的原子值，也就是属性的值都不
能再细分成更小的部分。
例如，一个表中的地址字段，可以将其拆分为街道、城市、州和邮政编码等多个部分，但是在1NF中，这些部分都必须被当做单独的属性来存储。
第二范式（2NF）：满足1NF的基础上，消除部分依赖
第二范式指任何非主键属性都必须完全依赖于主键，也就是非主键属性不能只依赖于
主键的一部分。
例如，一个订单表中的商品名称、商品价格和商品数量，都必须依赖于唯一的订单编
号（主键），而不能只依赖于日期等其他属性。
如果存在部分依赖，需要对表进行拆分。
例如，一个客户和订单表中，一个客户可以下多个订单，但是每个订单只能对应一个
客户。
如果将客户的联系方式和收货地址存储在订单表中，就会出现多值依赖的问题。
因此，需要对表进行拆分。
第五范式（5NF）：尽量避免冗余
第五范式指关系模式中的数据不能通过拆分为更小的关系模式来避免冗余数据。
例如，一个图书馆书籍表中，如果将每个书籍作者的个人信息存储在作者表中，就会
出现多次重复的数据。
因此，需要将重复的数据存储在单独的表中，并通过关联方式进行
连接。
关系数据库的规范化之第⼀范式、第⼆范式、第三范式以及BC范式 关系数据库设计的⽅法之⼀就是设计满⾜适当范式的模式，通常可以通过判断分解后的模式达到⼏范式来评价模式规范化的程度。
范式有1NF,2NF,3NF,BCNF,4NF,5NF，其中1NF的级别最低。
这⼏种范式之间，5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF成⽴。
通过分解，可以将⼀个低⼀级范式的关系模式转化成若⼲个⾼⼀级范式的关系模式，这个过程为规范化。
下⾯我们来看⼀个栗⼦（好吃），有错误的地⽅希望读者可以提出改正。
供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下： FIRST(Sno,Sname,Status,City,Pno,Qty)（公司编号，名称，状态，城市，产品编号，数量） F={Sno->Sname,Sno->Status,Status->City,(Sno,Pno->Qty)} 可以很明显的看出，该关系中不含有可以再分的数据项（什么是可以再分的数据项？想象⼀张table，不应存在两个相同的字段，即两个相同的数据项。
如果存在了，就说明他有了可以再分的数据项，就不是关系模式的数据库了。
存在了可再分的数据项，就要考虑新增实体，将两个数据项分别放到两个实体上），所以该关系满⾜第⼀范式的条件。
1NF 第⼀范式 定义：若关系模式R的每⼀个分量是不可再分的数据项，则关系模式R属于第⼀范式 第⼀范式有四个缺点：（1）冗余度⼤（2）引起数据修改不⼀致（3）插⼊异常（4）删除异常此处对该四个缺点不进⾏详细描述 当我们使⽤第⼀范式设计数据库的时候，会发现我们以Sno作为主键（码）的时候，不能唯⼀标识⾮主键字段（⾮主属性）Qty，但是⾮主属性Sname，Status却可以被Sno唯⼀标识且和Pno没有关系，此时对于数据库的使⽤会存在影响，所以要消除这种部分函数依赖的情况。
消除了这种部分函数依赖关系后，所得到的两个关系中⾮主属性完全依赖于码，这种规范称为第⼆范式。
补充讲义一、范式举例BCNF.如：课程号与学号）例4：R(X,Y,Z),F={XY->Z},R为几范式？BCNF。
例5：R(X,Y,Z),F={Y->Z，XZ->Y},R为几范式？3NF。
R的候选码为{XZ,XY}，（R中所有属性都是主属性，无传递依赖）二、求闭包数据库设计人员在对实际应用问题调查中，得到的结论往往是零散的、不规范的（直观问题好办，复杂问题难办了），所以，这对分析数据模型，达到规范化设计要求，还有差距，为此，从规范数据依赖集合的角度入手，找到正确分析数据模型的方法，以确定关系模式的规范化程度。
例1．已知关系模式R(U、F)，其中，U={A,B,C,D,E}; F={AB→ C, B→ D, EC → B , AC→B} ,求（AB）+F.解：设X(0)=AB○1计算X(1),在F中找出左边为AB子集的FD,其结果是：AB→C,B→D∴X(1)=X(0)UB=ABUCD=ABCD 显然，X(1)≠X(0)○2计算X(2),在F中找出左边为ABCD子集的FD，其结果是：C→E,AC→B∴X(2)=X(1)UB=ABCDUBE=ABCDE 显然，X(2)=U所以，（AB）+ F=ABCDE.（等于U，所以AB是唯一候选关键字）例2．设有关系模式R(U、F)，其中U={A,B,C,D,E，I};F={A→D,AB→E,B→E,CD→I,E→C},计算（AE）+解：令X={AE},X(0)=AE○1在F中找出左边是AE子集的FD,其结果是：A→D,E→C∴X(1)=X(0)UB=X(0)UDC=ACDE 显然，X(1)≠X(0)○2在F中找出左边是ACDE子集的FD，其结果是：CD→I∴X(2)=X(1)UI=ACDEI显然，X(2)≠X(1)，但F中未用过的函数依赖的左边属性已含有X(2)的子集，所以不必再计算下去，即（AE）+=ACDEI.因为，X（3）＝X（2），所以，算法结束。
关系数据库范式关系数据库范式是指在关系数据库中，为了避免数据冗余和数据不一致性而设计的一种规范化方法。
范式分为一般范式和高级范式，一般范式包括第一范式、第二范式和第三范式，高级范式包括BC 范式和第四范式。
第一范式（1NF）第一范式是指关系模式中的所有属性都是原子性的，即不可再分解。
例如，一个学生的信息包括姓名、性别、年龄、地址等，这些属性都是原子性的，不可再分解。
如果将地址拆分成省、市、区、街道等多个属性，则不符合第一范式。
第二范式（2NF）第二范式是指关系模式中的非主属性必须完全依赖于主键，而不是依赖于主键的一部分。
例如，一个订单的信息包括订单号、商品编号、商品名称、商品单价、商品数量等，其中商品名称、商品单价、商品数量都依赖于商品编号，而不是订单号。
因此，应该将商品编号作为主键，将商品名称、商品单价、商品数量作为非主属性。
第三范式（3NF）第三范式是指关系模式中的非主属性不应该存在传递依赖关系。
传递依赖关系是指非主属性依赖于其他非主属性，而不是直接依赖于主键。
例如，一个学生的信息包括学号、姓名、班级、学院、学院地址等，其中学院地址依赖于学院，而不是直接依赖于学号。
因此，应该将学院作为一个独立的关系，与学生信息关系进行关联。
BC范式BC范式是指关系模式中的所有非主属性都必须依赖于候选键，而不是依赖于主键。
候选键是指可以唯一标识一个元组的属性集合。
例如，一个订单的信息包括订单号、商品编号、商品名称、商品单价、商品数量等，其中商品名称、商品单价、商品数量都依赖于商品编号，而商品编号不是主键，而是候选键。
因此，应该将商品编号作为主键，将商品名称、商品单价、商品数量作为非主属性。
第四范式（4NF）第四范式是指关系模式中的多值依赖关系必须被消除。
多值依赖关系是指一个关系模式中的某些属性可以有多个取值，而这些属性之间存在依赖关系。
例如，一个学生的信息包括学号、姓名、选修课程、成绩等，其中选修课程和成绩之间存在多值依赖关系，即一个学生可以选修多门课程，每门课程有一个成绩。
数据库范式分解数据库范式分解是关系数据库设计中非常重要的步骤。
其作用是将一个复杂的关系模式分解成多个更小的、更简单的关系模式，以便于数据的存储和管理。
数据库范式分解能够提高数据库的数据完整性和可靠性，避免数据冗余和不一致性，提高数据处理效率。
在数据库设计中，范式分解的目的是消除冗余数据，保持数据的完整性和一致性。
数据库设计要保证数据的每个属性只有一个地方存放，在数据库有多个实例时，这个属性的值就必须保持一致。
如果数据有冗余，由于这个属性值在不同的地方存放，就可能会产生不一致的情况。
因此，范式分解的目的就是尽量减少数据的冗余。
根据关系数据库理论，数据库中的数据分为不同的范式，从第一范式（1NF）到第五范式（5NF）。
每个范式都有其独特的规则和要求，用于确保数据的正确性和一致性。
在范式分解中，关系模式根据其范式级别进行分解，范式越高则数据冗余越少，关系模式结构越简单。
在实际数据库设计中，我们通常采用前三范式（1NF、2NF、3NF）进行范式分解。
其中，第一范式要求每个属性只包含一个值，即属性具有原子性；第二范式要求将关系模式的每个非主属性都完全依赖于主属性，即表中的每个非主属性都只依赖于主属性；第三范式要求关系模式的非主属性之间不存在传递依赖，即任何非主属性都不依赖于其他非主属性。
在范式分解时，首先要进行函数依赖分析，即确定每个属性之间的依赖关系。
然后根据依赖关系将关系模式进行分解，使其尽量符合范式要求。
例如，可以将一个原始的关系模式分解为多个符合第三范式的关系模式，从而消除冗余数据并确保数据的一致性。
但是，范式分解也存在一些问题。
范式分解会使得数据的查询效率降低，因为查询需要在多个表中进行，而且不同表的之间的关联也需要花费较多的时间。
此外，在进行范式分解时，有时候会出现数据丢失或不一致的情况，需要做好相关的数据备份和恢复措施。
总之，数据库范式分解是数据库设计中必不可少的一部分。
通过范式分解，我们可以提高数据库的数据完整性和可靠性，避免数据冗余和不一致性，提高数据处理效率。
第一第二范式第三范式关系关系数据库是现代应用开发中常用的数据存储和管理方式，而范式化是一种设计数据库的方法。
在关系数据库中，范式分为第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
本文将介绍三个范式的概念、原则和关系，以帮助读者更好地理解和运用范式化方法。
第一范式是关系数据库设计中的基本要求，它要求每个数据列都是原子的，不可再分。
具体来说，每个表的每个字段都只能有一个单一值，不能包含多个值或重复的分组。
这样可以确保数据的唯一性和一致性，方便数据的查询和管理。
例如，一个学生信息表应该将学生姓名、学号、性别等信息分开存储，而不是将它们合并在一个字段中。
第二范式在第一范式的基础上进一步规范了关系数据库的设计。
第二范式要求每个非主键字段都完全依赖于主键，即非主键字段必须和主键直接相关，而不能和其他非主键字段相关。
这种规范化可以避免数据的冗余和更新异常。
举个例子，一个订单表中，订单号是主键，订单日期和客户名称完全依赖于订单号，而不是互相依赖。
第三范式在第二范式的基础上进一步规范了数据库的设计。
第三范式要求所有非主键字段都不传递依赖于主键，即非主键字段之间不能相互依赖。
这样可以消除数据冗余和处理更新异常的可能性。
例如，一个员工表中，员工编号是主键，部门号和部门名称之间存在函数依赖关系，因此应该将它们分开存储，而不是将部门名称作为员工表的字段。
范式化的好处是可以提高数据的一致性、完整性和可维护性，减少数据冗余和更新异常的可能性。
但过度范式化也可能导致查询性能下降，因此在实际应用中需要权衡范式化和性能的关系。
一般来说，高频查询的字段可以冗余存储，以提高查询性能，但需要注意保持数据的一致性。
在数据库设计过程中，应该根据实际需求选择合适的范式化级别。
如果数据结构相对简单，可以选择较高的范式化级别；如果数据结构复杂，可以适当冗余存储以提高查询性能。
同时，还可以使用索引、优化查询语句等方法来提高数据库的性能。
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。
反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
范式说明第一范式（1NF）无重复的列所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
例如，如下的数据库表是符合第一范式的：字段1 字段2 字段3 字段4而这样的数据库表是不符合第一范式的：字段1 字段2 字段3 字段4字段字段数据库表中的字段都是单一属性的，不可再分。
这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。
因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式（2NF）属性完全依赖于主键[ 消除部分子函数依赖]如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称为第二范式模式。
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
详解第⼀范式、第⼆范式、第三范式、BCNF范式什么是”范式(NF)”按照教材中的定义，范式是“符合某⼀种级别的关系模式的集合，表⽰⼀个关系内部各属性之间的联系的合理化程度”。
很晦涩吧？实际上你可以把它粗略地理解为⼀张数据表的表结构所符合的某种设计标准的级别。
就像家⾥装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。
数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。
⼀般在我们设计关系型数据库的时候，最多考虑到BCNF就够。
符合⾼⼀级范式的设计，必定符合低⼀级范式，例如符合2NF的关系模式，必定符合1NF。
接下来就对每⼀级范式进⾏⼀下解释。
1. 第⼀范式（1NF）符合1NF的关系（你可以理解为数据表。
“关系模式”和“关系”的区别，类似于⾯向对象程序设计中”类“与”对象“的区别。
”关系“是”关系模式“的⼀个实例，你可以把”关系”理解为⼀张带数据的表，⽽“关系模式”是这张数据表的表结构。
1NF的定义为：符合1NF的关系中的每个属性都不可再分。
表1所⽰的情况，就不符合1NF的要求。
表1实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作⼀定是不能成功的。
也就是说，只要在RDBMS中已经存在的数据表，⼀定是符合1NF的。
如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2但是仅仅符合1NF的设计，仍然会存在数据冗余过⼤，插⼊异常，删除异常，修改异常的问题，例如对于表3中的设计：表31. 每⼀名学⽣的学号、姓名、系名、系主任这些数据重复多次。
每个系与对应的系主任的数据也重复多次——数据冗余过⼤2. 假如学校新建了⼀个系，但是暂时还没有招收任何学⽣（⽐如3⽉份就新建了，但要等到8⽉份才招⽣），那么是⽆法将系名与系主任的数据单独地添加到数据表中去的（注１）——插⼊异常注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意⼀个属性都不能为空，所有属性的组合也不能重复。
数据库函数依赖和范式总结1 函数依赖1.1 定义：一个集合R(U,F)，U为属性全集，F为函数依赖集合。
F中存在着{Xi->Yi...};对于每个X都存在着一个Y与之唯一对应。
意思就是相当于X为主键，Y由主键决定。
比如一个学生他的学号相当于X，而他的姓名与年龄这些其他信息相当于Y。
但是X有时候并不是一个值，比如一个学生他的成绩需要有两个属性才能知道他的成绩，学号+课程号->成绩1.2 平凡函数依赖与非平凡函数依赖平时我们主要讨论的是非平凡函数依赖。
平凡函数依赖概念：Y集合属性属于X集合属性的子集非平凡函数则相反1.3 逻辑蕴涵(为后面求闭包做好基础)X,Y为属性集合U的子集，且X->Y不存在于F中。
即我们需要通过F中的函数依赖推出X->Y称为函数依赖。
而所有函数依赖的集合则称为闭包1.4 函数依赖的推理规则(就是求函数依赖的逻辑蕴涵)1.4.1 几个公理1.4.1.1 公理一(自反律):Y属于X的子集，则X->Y 数学公式描述 Y?X?U1.4.1.2 公理二(增广律):X->Y成立，Z?U也成立，则 XZ?YZ1.4.1.3 公理三(传递律):X->Y成立，Y->Z成立，则 X->Z1.4.2 公理的推广1.4.2.1 推广一(合并律):X->Y,X->Z,则X->YZ1.4.2.2 推广二(伪传递律):X->Y,YW->Z,则XW->Z(证明只需要在XY两边*W)1.4.2.3 推广三(分解律):X->Y成立，Z?Y，则 X->Z1.4.2.4 推广四(复合律):X->Y,W->Z,则XW->YZ1.5 完全函数依赖与部分函数依赖(范式中基础知识)X->Y的集合中，若X的任一真子集x都能 x->Y则为部分函数依赖，若不能则的完全函数依赖，如果X没有真子集则也称为完全函数依赖。
1.关系模式设计不规范会带来一系列的问题
数据冗余
更新异常
插入异常
删除异常
因此需要一个标准的模式来解决这些问题，引入模式分解来解决存在问题。
2.无损连接的概念比较好懂，就是要保证模式分解后仍然可以根据分解后的关系回退回分解前。
这可以保证分解过程没有丢失信息，不会破坏和更改已经存在的。
而检验无损连接的方法分为两种：
①当R分解为两个关系模式R1和R2时，有一种简便的方法可以测试无损连接性
p＝{R1,R2}
p是无损连接的分解当且仅当下面之一满足
（R1 ∩R2）→（R1－R2）
（R1 ∩R2）→（R2－R1）
其中R1 ∩R2指模式的交，返回公共属性
R2－R1表示模式的差集，返回属于R2但不属于R1的属性集
也可以理解为R1∩R2的结果是R的超码，即该结果可以推出全部R属性。
②当R分解为多个关系模式时，可以使用chase算法：
举个栗子
R(A,B,C,D,E)
R1(A,D), R2(A,B), R3(B,E), R4(C,D,E), R5(A,E)
F={A→C, B→C, C→D, DE→C, CE→A}
判断R分解为p＝{R1,R2,R3,R4,R5}是否是无损连接的分解？第一步，构造初始表。
第二步，处理表
A→C：将b23，b53改为b13
B→C：将b33改为b13
C→D：将b24，b34，b54改为a4
DE→C：将第3行和第5行的C改为a3
CE→A：将第3行和第4行的A改为a1
处理后BE行将全变为a，证明为无损连接。
3.函数依赖（FD）的表现形式是x→y,可以根据函数的概念理解,当x属性的值相同时，可以断定y也一定相同。
在实际关系模式中，x与y会存在逻辑上的相关性，如一个学号会对应一个姓名。
要理解函数依赖是关系模式的内涵，保持函数依赖才能保持关系模式中存在的关系。
举个栗子：
R(city, street, zip), F={(city,street)→zip, zip→city}
分解为p={R1(street,zip),R2(city,zip)}
在R1中插入（’a’,’100081’）和（’a’,’100082’）
R2中插入（’Beijing’,’100081’）和（’Beijing’,’100082’）
R1∞R2：得到
违反了(city,street)→zip，因为它被丢失了，语义完整性被破坏。
4.范式是满足特定要求的模式，也就是我们追求的标准。
使关系模式符合某种范式可以容易验证其合理性并解决或规避最开始提及的那些问题。
1NF:对于关系模式R的任一实例，其元组的每一个属性值都只含有一个值，则R符合1NF。
1NF是关系的基本要求。
R不满足1NF会带来更新时的二义性。
2NF：（假定R只有一个候选码，且该候选码为主码）当且仅当R属于1NF，且R的每一个非主属性都完全函数依赖于主码时，R 符合2NF。
（完全函数依赖：对于函数依赖W→A，若不存在X∈W，并且X→A成立，则称W→A为完全函数依赖，否则为局部函数依赖。
即非主属性只能由全部主码推出，不能由部分主码推出。
）
3NF：（假定R只有一个候选码，且该候选码为主码）当且仅当R属于2NF，且R的每一个非主属性都不传递依赖于主码时，R 符合3NF。
（传递依赖：若Y→X，X→A，并且X →Y，A不是X的子集，则称A传递依赖于Y）
BCNF：如果关系模式R的所有不平凡的、完全的函数依赖的决定因素（左边的属性集）都是候选码，则R符合BCNF。
（用于解决存在多组候选码的情况）
介绍几个模式分解的算法。
保持函数依赖分解到3NF的算法：
求出R的最小函数依赖集（仍记为F）
把所有不在F中出现的属性组成一个关系模式R’，并在U中去掉这些属性(剩余属性仍记为U)
若F中存在X →A，且XA=U, 则输出R(U)和R’，算法结束，否则
对F按相同的左部分组，将所有X →A1, X →A2,…, X →Ak形式的FD分为一组，并将每组涉及的所有属性作为一个关系模式输出。
若某个关系模式Ri的属性集是另一个关系模式的属性集的子集，则在结果中去掉Ri。
设最后得到关系模式R1，R2，…，Rk，则
p={R1,R2,…,Rk,R’}一个保持函数依赖的分解，并且满足3NF。
举个栗子：
R(ABCDEF), F={A→B,AC→E}
求最小FD集F={A→B,AC→E}
R’(DF)
按左部分组: R1(AB), R2(ACE)
p={R’(DF), R1(AB), R2(ACE)}
保持函数依赖和无损连接分解到3NF的算法：
首先用算法1求出R的保持函数依赖的3NF分解，设为q={R1,R2,…,Rk}
设X是R的主码，求出p=q {R(X)}
若X是q中某个Ri的子集，则在p中去掉R(X)
得到的p就是最终结果
举个例子：
R(S#,SN,P,C,S,Z),
F={S#→SN,S#→P,S#→C,S#→S ,S#→Z,{P,C,S}→Z, Z→P,Z→C}？
求出最小FD集：F={S# →SN, S# →P,S# →C, S#→S, {P,C,S} →Z, Z →P,Z →C} // S# →Z冗余
q={R1(S#,SN,P,C,S), R2(P,C,S,Z), R3(Z,P,C)}
R3是R2的子集，所以去掉R3
q={R1(S#,SN,P,C,S), R2(P,C,S,Z)}
R的主码为S＃，于是
p=q U {R(X)}={R1(S#,SN,P,C,S), R2(P,C,S,Z), R(S#)}
因为{S＃}是R1的子集，所以从p中去掉R(S#)
p ={R1(S#,SN,P,C,S), R2(P,C,S,Z)}即最终结果 .
无损连接分解为BCNF算法：
输入：R; 输出：p
p:={R};
检查p中各关系模式是否都属于BCNF，若是，则算法终止
设p中S(Us)非BCNF关系模式,则必存在X→A,其中X不是S的超码；
将S分解为S1(XA)和S2(Us－A)，此分解是无损联接的；//({XA} {Us－A}=X)→(A={XA}－{Us－A})
p:={p－S} {S1, S2}；//用S1和S2替换p中的S
转到第2步；
由于U的属性有限，因此有限次循环后算法终止。
举个例子：
R(S#,C#,G,TN,D),
F={{S#,C#} →G, C#→TN, TN→D}
p:={R};
TN→D不满足BCNF定义，分解R
p:={R1(S#,C#,G,TN), R2(TN,D)}
R1中C#→TN不满足BCNF，分解R1为R3和R4
p:={R3(S#,C#,G), R4(C#,TN), R2(TN,D)}
p中各模式均满足BCNF，结束
5.总结所学范式要知道，范式存在是用来解决数据冗余，更新异常，插入异常，删除异常这些实际问题的。
在具体的情况中，有些时候我们并不介意数据冗余的问题，范式自然也就不是越严苛越好。
关于多值依赖和4NF范式没有继续总结。
在具体关系数据库设计时需要灵活运用。
