34,874
社区成员
发帖
与我相关
我的任务
分享GGJJ们给我讲讲数据库的范式设计吧，偶总是看不懂。
手头缺少资料，希望GGJJ们帮帮我，尤其是对3NF和BCNF就是不懂。有好的例子吗？
...全文
请发表友善的回复…
发表回复
iloveyoustt 2003-11-12
- 打赏
- 举报
谢谢大家偶懂了
fenglaotou 2003-11-11
- 打赏
- 举报
学习!
wanghuan1983 2003-11-11
- 打赏
- 举报
借个地方说话，请问范式在数据库设计中起到什么样的作用？在具体设计中应该注意那些问题？如果不按照范式的方法进行设计将带来什么后果？
wzyu 2003-11-11
- 打赏
- 举报
所谓范式就是符合某一种级别的关系模式的集合。通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合。这一过程称为规范化。
1、 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、 第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、 第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。
1、 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、 第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、 第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。
lvltt 2003-11-11
- 打赏
- 举报
楼主可以买本萨师煊，王珊的《数据库系统概述》没事翻翻，很好的数据库基础教科书，我们大学就用的这本。。。
iloveyoustt 2003-11-11
- 打赏
- 举报
看来我的问题出在了不会分析函数依赖上了，弱弱的问大家，你们怎么分析函数依赖？
gmlxf 2003-11-11
- 打赏
- 举报
范式
构造数据库必须遵循一定的规则在关系数据库中这种规则就是范式范式是符合
某一种级别的关系模式的集合关系数据库中的关系必须满足一定的要求即满足不同的
范式目前关系数据库有六种范式第一范式1NF 第二范式2NF 第三范式3NF
第四范式4NF 第五范式5NF 和第六范式6NF 满足最低要求的范式是第一
范式1NF 在第一范式的基础上进一步满足更多要求的称为第二范式2NF 其余
范式以次类推一般说来数据库只需满足第三范式3NF 就行了下面我们举例介绍
第一范式1NF 第二范式2NF 和第三范式3NF
第一范式1NF
在任何一个关系数据库中第一范式1NF 是对关系模式的基本要求不满足第一
范式1NF 的数据库就不是关系数据库
所谓第一范式1NF 是指数据库表的每一列都是不可分割的基本数据项同一列中
不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性如果出现重复
的属性就可能需要定义一个新的实体新的实体由重复的属性构成新实体与原实体之
间为一对多关系在第一范式1NF 中表的每一行只包含一个实例的信息例如对
于图3-2 中的员工信息表不能将员工信息都放在一列中显示也不能将其中的两列或多
列在一列中显示员工信息表的每一行只表示一个员工的信息一个员工的信息在表中只
出现一次简而言之第一范式就是无重复的列
第二范式2NF
第二范式2NF 是在第一范式1NF 的基础上建立起来的即满足第二范式2NF
必须先满足第一范式1NF 第二范式2NF 要求数据库表中的每个实例或行必须可
以被惟一地区分为实现区分通常需要为表加上一个列以存储各个实例的惟一标识如
图3-2 员工信息表中加上了员工编号emp_id 列因为每个员工的员工编号是惟一的
因此每个员工可以被惟一区分这个惟一属性列被称为主关键字或主键主码
第二范式2NF 要求实体的属性完全依赖于主关键字所谓完全依赖是指不能存在
仅依赖主关键字一部分的属性如果存在那么这个属性和主关键字的这一部分应该分离
出来形成一个新的实体新实体与原实体之间是一对多的关系为实现区分通常需要为表
加上一个列以存储各个实例的惟一标识简而言之第二范式就是非主属性非部分依赖
于主关键字
第三范式3NF
满足第三范式3NF 必须先满足第二范式2NF 简而言之第三范式3NF
要求一个数据库表中不包含已在其它表中已包含的非主关键字信息例如存在一个部门
信息表其中每个部门有部门编号dept_id 部门名称部门简介等信息那么在图3-2
的员工信息表中列出部门编号后就不能再将部门名称部门简介等与部门有关的信息再加
入员工信息表中如果不存在部门信息表则根据第三范式3NF 也应该构建它否则
就会有大量的数据冗余简而言之第三范式就是属性不依赖于其它非主属性
构造数据库必须遵循一定的规则在关系数据库中这种规则就是范式范式是符合
某一种级别的关系模式的集合关系数据库中的关系必须满足一定的要求即满足不同的
范式目前关系数据库有六种范式第一范式1NF 第二范式2NF 第三范式3NF
第四范式4NF 第五范式5NF 和第六范式6NF 满足最低要求的范式是第一
范式1NF 在第一范式的基础上进一步满足更多要求的称为第二范式2NF 其余
范式以次类推一般说来数据库只需满足第三范式3NF 就行了下面我们举例介绍
第一范式1NF 第二范式2NF 和第三范式3NF
第一范式1NF
在任何一个关系数据库中第一范式1NF 是对关系模式的基本要求不满足第一
范式1NF 的数据库就不是关系数据库
所谓第一范式1NF 是指数据库表的每一列都是不可分割的基本数据项同一列中
不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性如果出现重复
的属性就可能需要定义一个新的实体新的实体由重复的属性构成新实体与原实体之
间为一对多关系在第一范式1NF 中表的每一行只包含一个实例的信息例如对
于图3-2 中的员工信息表不能将员工信息都放在一列中显示也不能将其中的两列或多
列在一列中显示员工信息表的每一行只表示一个员工的信息一个员工的信息在表中只
出现一次简而言之第一范式就是无重复的列
第二范式2NF
第二范式2NF 是在第一范式1NF 的基础上建立起来的即满足第二范式2NF
必须先满足第一范式1NF 第二范式2NF 要求数据库表中的每个实例或行必须可
以被惟一地区分为实现区分通常需要为表加上一个列以存储各个实例的惟一标识如
图3-2 员工信息表中加上了员工编号emp_id 列因为每个员工的员工编号是惟一的
因此每个员工可以被惟一区分这个惟一属性列被称为主关键字或主键主码
第二范式2NF 要求实体的属性完全依赖于主关键字所谓完全依赖是指不能存在
仅依赖主关键字一部分的属性如果存在那么这个属性和主关键字的这一部分应该分离
出来形成一个新的实体新实体与原实体之间是一对多的关系为实现区分通常需要为表
加上一个列以存储各个实例的惟一标识简而言之第二范式就是非主属性非部分依赖
于主关键字
第三范式3NF
满足第三范式3NF 必须先满足第二范式2NF 简而言之第三范式3NF
要求一个数据库表中不包含已在其它表中已包含的非主关键字信息例如存在一个部门
信息表其中每个部门有部门编号dept_id 部门名称部门简介等信息那么在图3-2
的员工信息表中列出部门编号后就不能再将部门名称部门简介等与部门有关的信息再加
入员工信息表中如果不存在部门信息表则根据第三范式3NF 也应该构建它否则
就会有大量的数据冗余简而言之第三范式就是属性不依赖于其它非主属性
gmlxf 2003-11-11
- 打赏
- 举报
所谓范式就是符合某一种级别的关系模式的集合。通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合。这一过程称为规范化。
1、 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、 第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、 第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。
不到第一范式:
create 学生(姓名,性别年龄) ----(因为性别年龄列包括了两个属性)
第一范式不到第二范式:
create 学生(姓名,性别,年龄,语文老师名) --(因为老师列不是完全函数依赖于键码)
第二范式不到第三范式
create 学生(姓名,性别,年龄,语文老师id,数学老师id)
create 老师(老师id,老师名,老师年龄)
第三范式不到第四范式
create 学生(学生id,姓名,性别,年龄,籍贯)
create 关系表(学生id,老师id)
create 老师(老师id,老师名,老师年龄,籍贯)
第四范式
create 学生(学生id,姓名,性别,年龄,籍贯id)
create 关系表(学生id,老师id)
create 老师(老师id,老师名,老师年龄,籍贯id)
cteate 籍贯表(id,籍贯)
1、 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、 第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、 第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。
不到第一范式:
create 学生(姓名,性别年龄) ----(因为性别年龄列包括了两个属性)
第一范式不到第二范式:
create 学生(姓名,性别,年龄,语文老师名) --(因为老师列不是完全函数依赖于键码)
第二范式不到第三范式
create 学生(姓名,性别,年龄,语文老师id,数学老师id)
create 老师(老师id,老师名,老师年龄)
第三范式不到第四范式
create 学生(学生id,姓名,性别,年龄,籍贯)
create 关系表(学生id,老师id)
create 老师(老师id,老师名,老师年龄,籍贯)
第四范式
create 学生(学生id,姓名,性别,年龄,籍贯id)
create 关系表(学生id,老师id)
create 老师(老师id,老师名,老师年龄,籍贯id)
cteate 籍贯表(id,籍贯)
伍子V5 2003-11-11
- 打赏
- 举报
数据库设计范式
--------------------------------------------------------------------------------
关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍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，如果每个决定因素都包含关键字（而不是被关键字所包含），则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但反过来不成立，而P->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中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。
--------------------------------------------------------------------------------
关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍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，如果每个决定因素都包含关键字（而不是被关键字所包含），则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但反过来不成立，而P->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中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。
shuiniu 2003-11-11
- 打赏
- 举报
搬个凳子，坐下慢慢听！
iloveyoustt 2003-11-11
- 打赏
- 举报
大力哥好快呀，能给个例子吗？
pengdali 2003-11-11
- 打赏
- 举报
所谓范式就是符合某一种级别的关系模式的集合。通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合。这一过程称为规范化。
1、 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、 第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、 第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。
1、 第一范式（1NF）：一个关系模式R的所有属性都是不可分的基本数据项。
2、 第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。
3、 第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。
4、 BC范式（BCNF）：关系模式R属于第一范式，且每个属性都不传递依赖于键码。
