1.表关系分类:
 
总体可以分为三类: 一对一 、一对多(多对一) 、多对多
 
2.如何区分表与表之间是什么关系?
 
#分析步骤:
 
#多对一/一对多
 
#1.站在左表的角度去看右表(情况一)
 
如果左表中的一条记录,对应右表中多条记录.那么他们的关系则为 一对多 关系.约束关系为:左表普通字段, 对应右表foreignkey字段.
 
注意:如果左表与右表的情况反之.则关系为 多对一 关系.约束关系为:左表foreignkey字段, 对应右表普通字段.
 
#一对一
 
#2.站在左表的角度去看右表(情况二)
 
如果左表中的一条记录 对应 右表中的一条记录. 则关系为 一对一关系.
 
约束关系为:左表foreign key字段上 添加唯一(unique)约束, 对应右表 关联字段.
 
或者:右表foreign key字段上 添加唯一(unique)约束, 对应右表 关联字段.
 
#多对多
 
#3.站在左表和右表同时去看(情况三)
 
如果左表中的一条记录 对应 右表中的多条记录,并且右表中的一条记录同时也对应左表的多条记录. 那么这种关系 则 多对多 关系.
 
这种关系需要定义一个这两张表的[关系表]来专门存放二者的关系
 
3.建立表关系
 
1.一对多关系
 
例如:一个人可以拥有多辆汽车，要求查询某个人拥有的所有车辆。
 
分析：人和车辆分别单独建表，那么如何将两个表关联呢？有个巧妙的方法，在车辆的表中加个外键字段(人的编号)即可。
 
* (思路小结：’建两个表，一’方不动，’多’方添加一个外键字段)*
 

 

 
//建立人员表CREATE TABLEpeople(
 
idVARCHAR(12) PRIMARY KEY,
 
snameVARCHAR(12),
 
ageINT,
 
sexCHAR(1)
 
);INSERT INTO people VALUES('H001','小王',27,'1');INSERT INTO people VALUES('H002','小明',24,'1');INSERT INTO people VALUES('H003','张慧',28,'0');INSERT INTO people VALUES('H004','李小燕',35,'0');INSERT INTO people VALUES('H005','王大拿',29,'1');INSERT INTO people VALUES('H006','周强',36,'1');//建立车辆信息表CREATE TABLEcar(
 
idVARCHAR(12) PRIMARY KEY,
 
markVARCHAR(24),
 
price NUMERIC(6,2),
 
pidVARCHAR(12),CONSTRAINT fk_people FOREIGN KEY(pid) REFERENCESpeople(id)
 
);INSERT INTO car VALUES('C001','BMW',65.99,'H001');INSERT INTO car VALUES('C002','BenZ',75.99,'H002');INSERT INTO car VALUES('C003','Skoda',23.99,'H001');INSERT INTO car VALUES('C004','Peugeot',20.99,'H003');INSERT INTO car VALUES('C005','Porsche',295.99,'H004');INSERT INTO car VALUES('C006','Honda',24.99,'H005');INSERT INTO car VALUES('C007','Toyota',27.99,'H006');INSERT INTO car VALUES('C008','Kia',18.99,'H002');INSERT INTO car VALUES('C009','Bentley',309.99,'H005');
 
创建表
 

 

 
例子1:学生和班级之间的关系
 
班级表
 
id class_name1python脱产100期2python脱产300期
 
学生表foreign keyid name class_id1 alex 2
 
2 刘强东 2
 
3 马云 1例子2: 一个女孩 拥有多个男朋友...
 
例子3:....
 
其他示例
 
2.一对一关系
 
例如：一个中国公民只能有一个身份证信息
 
分析: 一对一的表关系实际上是 变异了的 一对多关系. 通过在从表的外键字段上添加唯一约束(unique)来实现一对一表关系.
 

 

 

 
#身份证信息表CREATE TABLEcard (
 
idint NOT NULL AUTO_INCREMENT PRIMARY KEY,
 
codevarchar(18) DEFAULT NULL,UNIQUE un_code (CODE) --创建唯一索引的目的,保证身份证号码同样不能出现重复
 
);INSERT INTO card VALUES(null,'210123123890890678'),
 
(null,'210123456789012345'),
 
(null,'210098765432112312');
 
#公民表CREATE TABLEpeople (
 
idint NOT NULL AUTO_INCREMENT PRIMARY KEY,
 
namevarchar(50) DEFAULT NULL,
 
sexchar(1) DEFAULT '0',
 
c_idint UNIQUE, --外键添加唯一约束,确保一对一
 
CONSTRAINT fk_card_id FOREIGN KEY (c_id) REFERENCEScard(id)
 
);INSERT INTO people VALUES(null,'zhangsan','1',1),
 
(null,'lisi','0',2),
 
(null,'wangwu','1',3);
 
创建表
 

 

 
例子一：一个用户只有一个博客
 
用户表：
 
主键
 
id name1egon2alex3wupeiqi
 
博客表
 
fk+unique
 
id url user_id1 xxxx 1
 
2 yyyy 3
 
3 zzz 2例子2: 一个男人的户口本上，一辈子最多只能一个女主的名字.等等
 
其他示例
 
3.多对多关系
 
例如：学生选课，一个学生可以选修多门课程，每门课程可供多个学生选择。
 
分析：这种方式可以按照类似一对多方式建表，但冗余信息太多，好的方式是实体和关系分离并单独建表，实体表为学生表和课程表，关系表为选修表，
 
其中关系表采用联合主键的方式(由学生表主键和课程表主键组成)建表。
 

 

 

 
#//建立学生表CREATE TABLEstudent(
 
idVARCHAR(10) PRIMARY KEY,
 
snameVARCHAR(12),
 
ageINT,
 
sexCHAR(1)
 
);INSERT INTO student VALUES('S0001','王军',20,1);INSERT INTO student VALUES('S0002','张宇',21,1);INSERT INTO student VALUES('S0003','刘飞',22,1);INSERT INTO student VALUES('S0004','赵燕',18,0);INSERT INTO student VALUES('S0005','曾婷',19,0);INSERT INTO student VALUES('S0006','周慧',21,0);INSERT INTO student VALUES('S0007','小红',23,0);INSERT INTO student VALUES('S0008','杨晓',18,0);INSERT INTO student VALUES('S0009','李杰',20,1);INSERT INTO student VALUES('S0010','张良',22,1);
 
#//建立课程表CREATE TABLEcourse(
 
idVARCHAR(10) PRIMARY KEY,
 
snameVARCHAR(12),
 
creditDOUBLE(2,1),
 
teacherVARCHAR(12)
 
);INSERT INTO course VALUES('C001','Java',3.5,'李老师');INSERT INTO course VALUES('C002','高等数学',5.0,'赵老师');INSERT INTO course VALUES('C003','JavaScript',3.5,'王老师');INSERT INTO course VALUES('C004','离散数学',3.5,'卜老师');INSERT INTO course VALUES('C005','数据库',3.5,'廖老师');INSERT INTO course VALUES('C006','操作系统',3.5,'张老师');
 
#//建立选修表CREATE TABLEsc(
 
sidVARCHAR(10),
 
cidVARCHAR(10),PRIMARY KEY(sid,cid),CONSTRAINT fk_student FOREIGN KEY(sid) REFERENCESstudent(id),CONSTRAINT fk_course FOREIGN KEY(cid) REFERENCEScourse(id)
 
);INSERT INTO sc VALUES('S0001','C001');INSERT INTO sc VALUES('S0001','C002');INSERT INTO sc VALUES('S0001','C003');INSERT INTO sc VALUES('S0002','C001');INSERT INTO sc VALUES('S0002','C004');INSERT INTO sc VALUES('S0003','C002');INSERT INTO sc VALUES('S0003','C005');INSERT INTO sc VALUES('S0004','C003');INSERT INTO sc VALUES('S0005','C001');INSERT INTO sc VALUES('S0006','C004');INSERT INTO sc VALUES('S0007','C002');INSERT INTO sc VALUES('S0008','C003');INSERT INTO sc VALUES('S0009','C001');INSERT INTO sc VALUES('S0009','C005');
 
创建表
 

 

 
例子1:中华相亲网: 男嘉宾表+相亲关系表+女嘉宾表
 
男嘉宾:1孟飞2乐嘉
 
女嘉宾:1小乐2小嘉
 
相亲表:(中间表)
 
男嘉宾 女嘉宾 相亲时间1 1 2017-10-12 12:12:12
 
1 2 2017-10-13 12:12:12
 
1 1 2017-10-15 12:12:12例子2: 用户表,菜单表,用户权限表...
 
其它示例

 
ER图转换关系模式
 
(2013-03-21 14:09:07)
 
标签：
 
it
 
转换一般遵循如下原则：
 
1．一个实体型转换为一个关系模式。实体的属性就是关系的属性。实
 
体的码就是关系的码。
 
例如在我们的例子中，学生实体可以转换为如下关系模式，其中学号
 
为学生关系的码：
 
学生(学号，姓名，出生日期，所在系，年级，平均成绩) 同样，性
 
别、宿舍、班级、档案材料、教师、课程、教室、教科书都分别转换
 
为一个关系模式。
 
2.一个联系转化为一个关系模式，与该联系相连的各实体的码以及联系
 
的属性转化为关系的属性，该关系的码则有三种情况：
 
若联系为1：1，则每个实体的码均是该关系的后选码。
 
若联系为1：n，则关系的码为n端实体的码。
 
若联系为m：n，则关系的码为诸实体码的组合。
 
2.1 联系为1：1
 
一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对
 
应的关系模式合并。
 
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及
 
联系本身的属性均转换为关系的属性，l 每个实体的码均是
 
该关系的候选码。
 
如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加
 
入另一个关系模式的码和联系本身的属性。
 
例如在我们的例子中，"管理"联系为1:1联系，我们可以将其转换为
 
一个独立的关系模式：
 
管理(职工号，班级号)或 管理(职工号，班级号)
 
管理"联系也可以与班级或教师关系模式合并。如果与班级关系模式合
 
并，则只需在班级关系中加入教师关系的码，即职工号：
 
班级：｛班级号，学生人数，职工号｝
 
同样，如果与教师关系模式合并，则只需在教师关系中加入班级关系
 
的码，即班级号：
 
教师：｛职工号，姓名，性别，职称，班级号，是否为优秀班主任｝
 
2.2 联系为1：n
 
一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的
 
关系模式合并。
 
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及
 
联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
 
如果与n端对应的关系模式合并，则在n端实体对应模式中加入1端
 
实体所对应关系模式的码，以及联系本身的属性。而关系的码为n端
 
实体的码。
 
例如在我们的例子中，"组成"联系为1:n联系，将其转换为关系模式。
 
一种方法是使其成为一个独立的关系模式：
 
组成(学号，班级号)
 
其中学号为"组成"关系的码。
 
另一种方法是将其学生关系模式合并，这时学生关系模式为：
 
学生(学号，姓名，出生日期，所在系，年级，班级号，平均成绩)
 
后一种方法可以减少系统中的关系个数，一般情况下更倾向于采用这
 
种方法。
 
2.3 联系为m：n
 
一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及
 
联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
 
例如在我们的例子中，"选修"联系是一个m:n联系，可以将它转换为如
 
下关系模式，其中学号与课程号为关系的组合码：
 
选修(学号，课程号，成绩)
 
三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多
 
元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。
 
例如在我们的例子中，"选修"联系是一个m:n联系，可以将它转换为如
 
下关系模式，其中学号与课程号为关系的组合码：
 
选修(学号，课程号，成绩)
 
三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多
 
元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。
 
而关系的码为各实体码的组合。
 
例如在我们的例子中，"讲授"联系是一个三元联系，可以将它转换为
 
如下
 
关系模式，其中课程号、教师号和书号为关系的组合码： 讲授(课程号，教师号，书号)
 
3．同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和
 
m:n三种情况分别处理。
 
例如，如果教师实体集内部存在领导与被领导的1:n自联系，我们可
 
以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不
 
同，可用不同的属性名加以区分，比如在合并后的关系模式中，主码
 
仍为职工号，再增设一个"系主任"属性，存放相应系主任的职工号。
 
4．具有相同码的关系模式可合并。
 
为了减少系统中的关系个数，如果两个关系模式具有相同的主码，可
 
以考虑将他们合并为一个关系模式。合并方法是将其中一个关系模式
 
的全部属性加入到另一个关系模式中，然后去掉其中的同义属性(可
 
能同名也可能不同名)，并适当调整属性的次序。
 
例如我们有一个"拥有"关系模式：拥有(学号，性别)
 
有一个学生关系模式： 学生(学号，姓名，出生日期，所在系，年级，
 
班级号，平均成绩)
 
这两个关系模式都以学号为码，我们可以将它们合并为一个关系模式，
 
假设合并后的关系模式仍叫学生：
 
学生(学号，姓名，性别，出生日期，所在系，年级，班级号，平均
 
成绩)
 
按照上述4条原则，学生管理子系统中的18个实体和联系可以转换为
 
下列关系模型：
 
学生(学号，姓名，性别，出生日期，所在系，年级，班级号，平均
 
成绩，档案号)
 
性别(性别，宿舍楼)
 
宿舍(宿舍编号，地址，性别，人数)
 
班级(班级号，学生人数)
 
教师(职工号，姓名，性别，职称，班级号，是否为优秀班主任)
 
教学(职工号，学号)
 
课程(课程号，课程名，学分，教室号)
 
选修(学号，课程号，成绩)
 
教科书(书号，书名，价钱)
 
教室(教室编号，地址，容量)
 
讲授(课程号，教师号，书号)
 
档案材料(档案号，......)
 
该关系模型由12个关系模式组成。其中学生关系模式包含了"拥有"联
 
系、"组成"联系、"归档"联系所对应的关系模式；教师关系模式包含
 
了"管理"联系所对应的关系模式；宿舍关系模式包含了"住宿"联系所
 
对应的关系模式；课程关系模式包含了"开设"联系所对应的关系模式。
 
分享：
 
喜欢
 
0
 
赠金笔
 
加载中，请稍候......
 
评论加载中，请稍候...
 
发评论
 
登录名： 密码： 找回密码 注册记住登录状态
 
昵   称：
 
评论并转载此博文
 

 
发评论
 
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。

Content
 
/*重点归纳*/
1.求第几范式的题目，一般均需经过（01.求最小函数依赖集 02.求候选码 03.求第几范式）这三个步骤。
2.主键由单属性构成，必没有部分函数依赖。
3.仅仅出现在最小函数依赖集左边的属性，一定在候选码中。

/*错题再练整理*/
1.A->B，A函数确定B（B函数依赖于A），属性A与属性B的联系是多对一。
 
 
 
数据库第6章应用题复习请着重关注课上的两道习题
 传送门
 
 
一、选择题
 
 
 
BCNF范式及4NF范式不考察，因此题8、15、22请跳过！
 
 
1．关系规范化中的删除操作异常是指     ①     ，插入操作异常是指    ②    。
A．不该删除的数据被删除      B．不该插入的数据被插入
C．应该删除的数据未被删除     D．应该插入的数据未被插入
参考解答：A,D
解析：（书本P179，见本段代码块下方解析图片）  
 
2．设计性能较优的关系模式称为规范化，规范化主要的理论依据是( )。
A．关系规范化理论    B．关系运算理论
C．关系代数理论      D．数理逻辑
参考解答：A
解析：（见本段代码块下方解析图片）

3．规范化理论是关系数据库进行逻辑设计的理论依据。根据这个理论，
关系数据库中的关系必须满足：其每一属性都是（ ）。
A．互不相关的    B．不可分解的
C．长度可变的    D．互相关联的
参考解答：B
解析：（书本P178）
作为一个二维表，关系要符合一个最基本的条件：每一个分量必须是不可分的数据项。
满足了这个条件的关系模式就属于第一范式（1NF）。
   
4．关系数据库规范化是为解决关系数据库中（ ）问题而引入的。
A．插入、删除和数据冗余    B．提高查询速度
C．减少数据操作的复杂性    D．保证数据的安全性和完整性
参考解答：A
解析：（书本P179，见本段代码块下方解析）
 
5．规范化过程主要为克服数据库逻辑结构中的插入异常，删除异常以及（ ）的缺陷。
A．数据的不一致性    B．结构不合理
C．冗余度大         D．数据丢失
参考解答：C
解析：同题4
  
6．当关系模式R(A，B)已属于3NF，下列说法中（ ）是正确的。
A．它一定消除了插入和删除异常   B．仍可能存在一定的插入和删除异常
C．一定属于BCNF              D．A和C都是
参考解答：B
解析：（见本段代码块下方解析图片）

7．关系模型中的关系模式至少是( )。   
A．1NF    B．2NF    C．3NF    D．BCNF
参考解答：A
       
**8．在关系模式R中，若其函数依赖集中所有决定因素都是候选键，则R最高范式是（ ）。
A．2NF    B．3NF    C．BCNF   D.1NF
参考解答：C
解析：（书本P184）
关系模式R<U,F>中，若每一个决定因素都包含码，则R<U,F>∈BCNF。即->左边全是码，则R∈BCNF。
网上有2种答案：BCNF或者4NF。
题干“若其函数依赖集中所有决定因素都是候选键”表明->左边全是码，
说明R至少为BCNF。如果将“R最高范式”理解成“R最高能达到的范式”的话，选择4NF，
因为在BCNF的基础上，再消除非平凡且非函数依赖的多值依赖，R就能达到4NF。
本题选项中没有4NF，因此选择BCNF。

9.在一个关系R中，若每个数据项都是不可再分割的，那么R一定属于(）。
A．2NF       B．3NF       C．BCNF 	   D.1NF
参考解答：D
解析：（书本P178）
作为一个二维表，关系要符合一个最基本的条件：每一个分量必须是不可分的数据项。
满足了这个条件的关系模式就属于第一范式（1NF）。

10．当B属性函数依赖于A属性时，属性A与B的联系是( )。
A．1对多    B．多对1    C．多对多    D．以上都不是
参考解答：B
解析：
A->B，A函数确定B（B函数依赖于A）
    
11．在关系模式中，如果属性A和B存在1对1的联系，则说( )。
A．A→B    B．B→A    C．A←→B    D．以上都不是
参考解答：C
   
12．候选键中的属性称为( )。
A．非主属性  B．主属性    C．复合属性  D．关键属性
参考解答：B
解析：（书本P181）
包含在任何一个候选码中的属性称为主属性。
   
13．关系模式中各级模式之间的关系为( ) 。
A．3NF⊂2NF⊂1NF    B．3NF⊂1NF⊂2NF
C．1NF⊂2NF⊂3NF    D．2NF⊂lNF⊂3NF
参考解答：A
解析：（书本P182图6.2）

14．关系模式中，满足2NF的模式( ) 。
A．可能是1NF    B．必定是1NF
C．必定是3NF    D．必定是BCNF
参考解答：B
   
**15．关系模式R中的属性全部是主属性，则R的最高范式必定是( )。
A．2NF    B．3NF    C BCNF    D．4NF
参考解答：B
解析：
一个全部是主属性的关系必然不会有非主属性部分或者传递依赖的问题，故至少是3NF。
但此关系无法保证消除了主属性对码的部分和传递函数依赖，所以R的最高范式至少是3NF。
   
16．消除了部分函数依赖的1NF的关系模式，必定是( )。
A．1NF    B．2NF    C．3NF    D．4NF
参考解答：B
解析：（书本P182/P189图6.8）
若R∈1NF，且每一个非主属性完全依赖于任何一个候选码（消除了非主属性对码的部分函数依赖），则R∈2NF。
    
17．关系模式的候选键可以有    ①    ，主关键字有    ②    。
A．0个    B．1个    C．1个或多个  D．多个
参考解答：C、B
解析：在一个关系模式中，候选码可以有多个，但主码只有一个。
    
18．候选关键字中的属性可以有( )。
A．0个    B．1个    C．1个或多个  D．多个
参考解答：C
解析：（见本段代码块下方解析图片）
 
19．关系模式的分解 ( )。
A．唯一    B．不唯一
参考解答：B
解析：（书本P190）
关系模式的规范化过程是通过对关系模式的分解来实现的。把低一级的关系模式分解为若干个高一级的关系模式。
这种分解不是唯一的。
    
20．根据关系数据库规范化理论，关系数据库中的关系要满足第一范式。下面“部门”关系中，
因哪个属性而使它不满足第一范式?( )。
部门(部门号，部门名，部门成员，部门总经理)
A．部门总经理    B．部门成员    C．部门名      D．部门号
参考解答：B
解析：（见本段代码块下方解析图片）
 
21．设有关系W(工号，姓名，工种，定额)，将其规范化到第三范式正确的答案是 ( )。
A．W1(工号，姓名) ,W2(工种，定额)
B．W1(工号，工种，定额)    W2(工号，姓名)
C．W1(工号，姓名，工种)    w2(工号，定额)
D．以上都不对
参考解答：C
解析：
该关系的函数依赖集为{工号->姓名，工号->工种，工种->定额}，候选码为“工号”。
经分析可知：“定额”经“工种”传递函数依赖于“工号”，这个传递函数依赖应消除。
选项A的w1关系中没有工种，不正确；
选项B未消除传递函数依赖，不正确。
选项C满足题意，故选C。

**22．设有关系模式W(C，P，S，G，T，R)，其中各属性的含义是：C为课程，P为教师，S为学生，
G为成绩，T为时间，R为教室，根据定义有如下函数依赖集：
F＝{C→P，(S，C)→G，(T，R)→C，(T，P)→R，(T，S)→R}
关系模式W的一个关键字是（1），W的规范化程度最高达到（2）。
若将关系模式W分解为3个关系模式W1(C，P)，W2(S，C，G)，W3(S，T，R，C)，
则W1的规范化程度最高达到（3），W2的规范化程度最高达到（4） ，W3的规范化程度最高达到（5）。
（1）A．(S，C)   B．(T，R)    C．(T，P)    D．(T，S)    E．(T，S，P)
（2）（3）（4）（5） A．1NF     B．2NF      C．3NF      D．BCNF     E．4NF
参考解答：
（1）D
（2）B
......

23. 关系规范化设计的目的是( )
A.完全消除数据冗余		          B.简化关系模式
C.控制冗余，避免插入和删除异常     D.提高数据查询效率
参考解答：C

24. 关系模式：学生（学号，姓名，系别，宿舍区），函数依赖集F={学号→姓名，学号→系别，系别→宿舍区}，
则学生关系满足(     )。
A．2NF          B．3NF        C．BCNF  	  D.1NF
参考解答：A
解析：（见下方图解）
候选码为学号。
因为每一个非主属性完全函数依赖于码（不部分依赖于码），所以学生关系∈2NF。
又不满足每一个非主属性不传递依赖于码，即学生关系∉3NF。
因此学生关系∈2NF。

25若关系为1NF，且它的每一非主属性都                 候选键，则该关系为2NF。
A.部分函数依赖于   	B.完全函数依赖于
C.传递函数依赖于      D.函数依赖于
参考解答：B
解析：（书本P182）
若R∈1NF，且每一个非主属性完全依赖于任何一个候选码（消除了非主属性对码的部分函数依赖），则R∈2NF。

26. 在关系数据库的规范化理论中，在执行“分解”时，必须遵守规范化原则，保侍原有的函数依赖性和（）
A.数据完整性   B.关系模式   C.查询效率   D. 无损连接性
参考解答：D
解析：（书本P195）
分解既要保持函数依赖，又要具有无损连接性。

27.对于非规范化的模式，经过使属性域变为简单域转变为1NF，将1NF经过    ①     转变为2NF，
将2NF经过     ②     转变为3NF。
A.消除非主属性对候选键的部分依赖
B.消除非主属性对候选键的传递依赖
C.消除主属性对候选键的部分依赖
D.消除主属性对候选键的传递依赖
参考解答：A,B
解析：（书本P189图6.8）
1NF->2NF（消除非主属性对码的部分函数依赖）
2NF->3NF（消除非主属性对码的传递函数依赖）
 
题1解析图片：
 
 
题2解析图片：
 
 
题4解析图片：
 
 
题6解析图片：
 
 
题18解析图片：
 
 
题20解析图片：
 
 
题24解析图片：
 
 
二、应用题
 
 
题目分析：
每个专业每年只招一个班：Class->Dept；一个系的学生住在同一个宿舍区：Dept->Rno；
学生参加学生会有一个入会年份：(Sno,Mname)->Myear。
最小函数依赖集：保留完全函数依赖，去除部分函数依赖和传递函数依赖。

参考解答：
（1）
学生关系模式的最小函数依赖集：
{Sno->Sname,Sno->Sbirth,Sno->Class,Class->Dept,Dept->Rno}
存在传递函数依赖:
01.Sno->Dept,Dept->Rno,Sno->Rno属于传递函数依赖。
02.Class->Dept,Dept->Rno,Class->Rno属于传递函数依赖。
03.Sno->Class,Class->Dept,Sno->Dept属于传递函数依赖。

班级关系模式的最小函数依赖集：
{Class->Pname,Class->Cnum,Class->Cyear,Pname->Dept)
存在传递函数依赖:
01.Class->Pname,Pname->Dept,Class->Dept属于传递函数依赖。

系关系模式的最小函数依赖集：
{Dept->Dno,Dno->Dept,Dept->Office,Dept->Dnum}
不存在传递函数依赖。

学会关系模式的最小函数依赖集：
{Mname->Myear,Mname->Maddr,Mname->Mnum}
不存在传递函数依赖。
（2）
模式名          候选键           外键
学生			   Sno			   Dept,Class
班级  		   Class		   Dept
系			   Dept/Dno		   无外键
学会 		   Mname		   无外键
 
 
参考解答（第三小问请跳过）：
 
 
 
参考解答（第四小问请跳过）：
 
 
 
参考解答（第二小问请跳过）：
 
 
 
参考解答（只做第六小问）：
 
 
 
参考解答（第二小问请跳过）：
 

 
最近开始做数据库的大实验，其中有一条实验要求如下：
 
通过网络查找相关文献并参考所给资料进行需求分析，画出系统的 E-R 图，给出实体或联系的属性，标明联系的种类，并写出关系模式。
 
画ER图没有什么问题，但是关系模式是什么就不知道了。所以，还是有必要学习一下的。
 
关系模式的定义
 
通过google和课本上对关系模式的定义得出如下定义：
 
关系模式(Relation Schema)是对关系的描述,它可以形式化地表示为：R(U，D，dom，F)。
 
其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合。
 
通常简记为：R(U)或R(A1，A2，…,An)其中R为关系名，U为属性名集合，A1，A2，…,An为各属性名。
 
有了定义，对关系模式有一个大概的认识(可以说基本上还是蒙的)，那么按照实验的要求，我们要如何从ER图中的到一个关系模式呢？
 
ER图转关系模式
 
这里我会以学生管理系统中常见的几个实体关系为例，设计简单你的ER图，并做转换说明。
 
1对1转换关系
 
首先我们先从最简单的做起。这里我们将教师和课程的关系看做是1:1的关系(班主任),然后ER图如下:
 

 
通过定义，我们可以初步的到一组关系模式：
 
教师(性别，职工号，手机号，年龄，姓名)
 
班级(班级名称，班级号)
 
负责(职工号，班级号)
 
这就是一组关系模式，有人会说，负责这组关系模式好像多余呀。是的，下面我们就着手将其进行合并。
 
这里可以将教师和负责两个关系合并到一起，也可以选择将班级和负责合并到一起。
 
1.合并教师和负责
 
教师(性别，职工号，手机号，年龄，姓名，班级号)
 
班级(班级名称，班级号)
 
合并就是将关系负责的属性添加到教师的属性中去，然后合并重复的属性。
 
2.合并班级和负责
 
教师(性别，职工号，手机号，年龄，姓名)
 
班级(班级名称，班级号，职工号)
 
通过上面的合并，我们发现，合并后的两个关系才更像是我们最终的数据表结构。
 
1对n转换关系
 
班级和学生是1对n的关系，ER图如下：
 

 
同样的，我们有可以先得到一组独立地关系模式：
 
学生(学号，姓名，性别)
 
班级(班级名称，班级号)
 
包含(学号，班级号，人数)
 
然后将联系的关系进行合并。在1对n的关系中，需要将联系的关系添加到n的一方的关系模式中。
 
学生(学号，姓名，性别，班级号)
 
班级(班级名称，班级号)
 
m对n转换关系
 
最后看一下多对多的关系是如何转换的。首先还是先给出ER图：
 

 
学生和课程的关系是m:n的。然后得到初步的关系模型：
 
学生(学号，姓名，性别)
 
课程(课程号，课程名)
 
选修(学号，课程号，成绩)
 
按照上面的惯例，下面我们应该合并关系模型了。但是在多对多的关系下，三种关系模式是不能进行合并的。而两个实体联系的关系模式正式我们常说的中间表的结构。
 
理解关系模式的作用
 
在上面通过ER图得到关系模式和合并关系模式的过程中，我们发现关系模式其实就是对应我们的数据表结构。那么关系模式有什么用呢，以往我们不通过关系模式一样可以得到表结构。
 
其实是没错的，但是通过范式的学习，发现我们的关系模式更多的时候是得到最终数据表的一个分析工具。就像我们上面一样，一开始会得到一个初始的独立的关系模式，然后对关系模式做合并，得到一个更加合理的关系模式。
 
使用范式也是一样的，我们会从基本的关系模式出发，然后利用范式的规则，得到最终更加合理的关系模式。这个过程如果只是靠抽象的想象的话，如果实体数量少还好说的，但是随着实体数越来越多，就会显得不大现实，而且准确性也会下降。
 
总的来说，通过对关系模式的化简合并，才会得到我们最终的实际编程用的数据表结构，比如下面这样：
 

 
总结
 
通过学习，自己理解了一下关系模式。发现自己原来创建数据表的方式有点随意了。我只是做到了给出了一种数据表的解决办法，但是还不能算是数据库设计的范畴。看来自己还是处在一个程序员的位置，想要成为一个工程师，还有很长的路要走。
 
后面我还会继续更新对范式的相关学习。