转自: http://hi.baidu.com/qicaiqinxian/blog/item/a8bb0bdf31ae081b63279887.html

E-R图向关系模型转换时犯糊涂了，找到下面这篇文章， 话说的真别扭， 不过问题算是能解决了，

E-R图向关系模式的转换要解决的问题是如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。

关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体型、实体的属性和实体型之间的联系3个要素组成。所以将E-R图转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。这种转换一般遵循如下的原则：

一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
对于实体型间的联系则有以下不同的情况：

1、一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及 联系本身的属性均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

2、一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

3、一个m：n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码子组成关系的码或关系码的一部分。
4、3个或3个以上实体的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
5、具有相同码的关系模式可以合并。
 

转载于:https://www.cnblogs.com/diegodu/p/4483954.html

目录

如何判断R为第几范式？

规范化

关系模型

数据依赖

什么是函数依赖

定义

平凡函数依赖与非平凡函数依赖

完全函数依赖与部分函数依赖

传递函数依赖

确定函数依赖的方法

码

外部码

范式

1NF

2NF

3NF

BCNF

多值依赖

4NF

如何判断R为第几范式？

已知一个关系模式的属性之间的语义，也就是相互依赖的关系，如何判断该模式满足第几范式？

1、首先要通过语义把属性之间的函数依赖关系列出来，

2、然后确定哪些属性组合可以候选码，从而找出非主属性和主属性。

3、然后判断是否存在非主属性与码之间的部分函数依赖关系，如果存在，则不满足2NF，如不存在部分函数依赖，则属于2NF，

4、继续进行下一步判断；判断非主属性与码之间存在传递依赖关系，不存在，则为3NF；

5、决定因素是否包含码，满足条件则为BCNF 

简而言之





规范化

规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。

关系模型

关系模式由五部分组成，即它是一个五元组： R(U, D, DOM, F)

R：关系名

U：组成该关系的属性名集合

D：属性组U中属性所来自的域

DOM：属性向域的映象集合

F：属性间数据的依赖关系集合

简化为一个三元组：R(U, F)

数据依赖


	
什么是函数依赖
	



	
定义
	



	
平凡函数依赖与非平凡函数依赖
	





	
完全函数依赖与部分函数依赖
	





	
传递函数依赖
	





	
确定函数依赖的方法
	


码





外部码



范式

一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化

1NF

如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF

第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库

但是满足第一范式的关系模式并不一定是一个好的关系模式



（F为完全依赖，P为部分依赖）



（Sno，Cno）能完全决定S-L-C



2NF

若R∈1NF，且每一个非主属性完全函数依赖于码，则R∈2NF。





采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

将一个1NF关系分解为多个2NF的关系，并不能完全消除关系模式中的各种异常情况和数据冗余。

3NF



若R∈3NF，则每一个非主属性既不部分依赖于码也不传递依赖于码。  







BCNF











关系模式STJ中有学生S，教师T和课程J这样的三个属性，约定的语义是每一个教师只教一门课，每门课有若干个教师，教师与课程之间是一对多的联系，也就是说教师函数决定课程。某个学生选定某门课，就对应一个固定的教师。

我们先来看一下这个关系模式的候选码都有哪些？大家记得候选码的定义吧，要求能够函数决定整个关系R的，而且它的真子集不能函数决定R。照这个标准来判断，我们看（S，J）可以作为候选码，因为学生选定某门课，就对应一个固定的教师，单独的学生和课程都不能决定老师；除此之外，（S，T）是不也可以作为候选码的？因为学生和老师定了，则选的课也就定下来了，但是，其中的S不能决定J和T,T不能决定S(!!!!!)。所以有两个候选码（S，J）和（S，T），这样看来，根据主属性的定义，出现在任何候选码中的属性均为主属性，则三个属性均为主属性，没有非主属性，所以自然满足3NF。

是否满足BCNF呢？就要看一下主属性的依赖关系了，根据定义，如果决定因素都包含码，则是BCNF，这里的T也是主属性，因为教师定了，课程也定了，但是T不包含码，所以不满足BCNF。大家对这里的理解主要是对候选码的定义上，候选码与其余属性的关系不一定要求是完全函数依赖的。这里列出来的3个函数依赖关系，第一个为完全函数依赖，第二个为部分函数依赖，第三个为完全函数依赖，因为决定因素为单个属性。 



多值依赖

设R(U)是一个属性集U上的一个关系模式， X、 Y和Z是U的子集，并且Z＝U－X－Y。关系模式R(U)中多值依赖 X→→Y成立，当且仅当对R(U)的任一关系r，给定的一对（x，z）值，有一组Y的值，这组值仅仅决定于x值而与z值无关

Teaching(C, T, B) C课程 T教员 B参考书



平凡多值依赖和非平凡的多值依赖若X→→Y，而Z＝φ，

则称     X→→Y为平凡的多值依赖

否则称X→→Y为非平凡的多值依赖

性质：

（1）多值依赖具有对称性

  若X→→Y，则X→→Z，其中Z＝U－X－Y

（2）多值依赖具有传递性

  若X→→Y，Y→→Z， 则X→→Z –Y

（3）函数依赖是多值依赖的特殊情况。

  若X→Y，则X→→Y。

（4）若X→→Y，X→→Z，则X→→YÈ Z。

（5）若X→→Y，X→→Z，则X→→Y∩Z。

（6）若X→→Y，X→→Z，则X→→Y-Z，X→→Z -Y。

4NF





 

 

关系的描述称为关系模式。它可以形式化地表示为R(U,D,DOM,F)，其中R为关系名，U为组成该关系的属性名集合，D为U中属性所来自的域，DOM为属性向域的映射集合，F为属性间数据的依赖关系集合。

E-R图向关系模型的转换要解决的问题是，如何将实体型和实体间的联系转换为关系模式，如何确定这些关系的属性和码。

一般的转换原则为：一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。

对于实体型间的联系有以下不同的情况：

1.一个1：1联系可以转换成一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

2.一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

3.一个m：n联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

4.三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

5.具有相同码的关系可以合并。

 

示例：将下面的E-R图转换为关系模式，关系的码用下划线标出



部门（部门号，部门名，经理的职工号，…）

此为部门实体对应的关系模式，该关系模式已包含了联系“领导所对应的关系模式。经理的职工号是关系的候选码。

职工（职工号，部门号，职工名，职务，…）

此为职工实体对应的关系模式，该关系模式已包含了联系“属于”所对应的关系模式。

产品（产品号，产品名，产品组长的职工号，…）

此为产品实体对应的关系模式。

供应商(供应商号，姓名，…）

此为供应商实体对应的关系模式 。

零件（零件号，零件名，…）

此为零件实体对应的关系模式。

生产（职工号，产品号，工作天数，…）

此为联系“生产”所对应的关系模式。

供应（产品号，供应商号，零件号，供应量）

此为联系“联系”所对应的关系模式。

数据库原理（十 二）- 逻辑结构设计
前言
E-R图向关系模型的转换
数据模型的优化
设计用户子模式

前言
概念结构是独立于任何一种数据模型的信息结构，逻辑结构设计的任务就是概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
E-R图向关系模型的转换
E-R图向关系模型的转换要解决的问题：

如何将实体型和实体间的联系转换为关系模式
如何确定这些关系模式的属性和码

转换的一般规则：
一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码

不同联系的转换规则：

一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并
一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并
一个m:n联系可以转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转为关系的属性，各实体的码组成关系的码或关系码的一部分
多元联系转换为一个关系模式，与该多元联系相连的各实体的码以及联系本身的属性均转为关系的属性，各实体的码组成关系的码或关系码的一部分
具有相同码的关系模式可以合并

上面的几条转换规则不知道你们看不看得懂，如果看不懂用下面的例子说明
1:1联系，如下图中



一共有两个关系实体，我们可以转化为两个关系模式，分别是顾客和会员卡，按照转换规则，我们选择任意一端合并，并将一端的主码添加为合并端关系模式的外码
顾客（姓名，性别，年龄）
会员卡（卡号，消费金额，积分，顾客姓名）

1:n联系和m:n联系，如下图：



1:n联系中，可以看到有班级和学生两个实体，按照转换规则，选择n端合并，1端的主码添加到n端的关系模式做外码
班级（班级号，班级名，辅导员）
学生（学号，姓名，性别，年龄，班级号）

m:n联系中，可以看到有学生和课程两个实体，以及一个选修联系实体，按照转换规则，学生和课程两个实体的码和属性不变，将各自的主码添加进选修联系实体中做主码和外码
学生（学号，姓名，性别，年龄，班级号）
课程（课程号，课程名，学分）
选修（学号，课程号，成绩）

如果m:n联系中，没有联系的属性，那么就合并n端，m端的主码作n端的外码，在关系模式中主码用下划线标识，外码用波浪线标识
数据模型的优化
数据逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，方法为：

确定数据依赖
对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系
按照数据依赖的理论对关系模式逐一分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式属于第几范式
根据需求分析阶段得到的处理要求分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解
对关系模式进行必要分解，提高数据操作效率和存储空间利用率

设计用户子模式
将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体关系数据库管理系统的特点设计用户的外模式。

定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以注重考虑用户的习惯与方便，具体包括一下几个方面：

使用更符合用户习惯的别名
可以对不同级别的用户定义不同的视图
简化用户对系统的使用