在关系数据库设计中，设计关系模式（二维表）是数据库设计中哪个阶段的任务？

正确答案: A   你的答案: C (错误)

逻辑设计阶段

概念设计阶段

物理设计阶段

需求分析阶段解析：按照规范的设计方法,一个完整的数据库设计一般分为以下六个阶段：⑴需求分析：分析用户的需求,包括数据、功能和性能需求；⑵概念结构设计：主要采用E-R模型进行设计,包括画E-R图；⑶逻辑结构设计：通过将E-R图转换成表,实现从E-R模型到关系模型的转换；设计表格的关系和字段⑷数据库物理设计：主要是为所设计的数据库选择合适的存储结构和存取路径；⑸数据库的实施：包括编程、测试和试运行；⑹数据库运行与维护：系统的运行与数据库的日常维护.

在Visual FoxPro中，表结构中的逻辑型、通用型、日期型字段的宽度由系统自动给出，它们分别为：

A．1、4、8
B．4、4、10
C．1、10、8
D．2、8、8

正确答案

A

答案解析

[解析] 在Visual FoxPro系统的表结构设计中，系统自动给某些字段指定宽度，其中日期型字段宽度为8，备注型和通用型字段宽度为4，逻辑型字段宽度为1。因此答案为选项A。

数据库 外模式=====模式======内模式 映射：逻辑独立性和物理独立性，数据的

自然连接运算

自然连接是构成新关系的有效方法一般情况下，当对关系R和S使用自然连接时，要求R和S含有一个或多个共有的( )。

A．元组
B．行
C．记录
D．属性

正确答案

D

答案解析

[解析]

自然连接是构成新关系的有效方法一般情况下，当对关系R和S使用自然连接时，要求R和S含有一个或多个共有的属性。准确地说，如果A1，A2，…，An是在关系R和S上都有的公共属性，那么仅当R中的元组r和S中的元组s在属性A1，A2，…，An都完全一致时，R中的元组r和S巾的元组s才能组合成一对，这种运算形式称为自然连接运算，表示为R∞S。

1、自然连接一定是等值连接，但等值连接不一定是自然连接。等值连接不把重复的属性除去；而自然连接要把重复的属性除去。　　2、等值连接要求相等的分量，不一定是公共属性；而自然连接要求相等的分量必须是公共属性。　　3、等值连接不把重复的属性除去；而自然连接要把重复的属性除去。

自然连接是一种特殊的等值连接，他要求多个表有相同的属性字段，然后条件为相同的属性字段值相等，最后再将表中重复的属性字段去掉，即为自然连接。如A中a,b,c字段，B中有c,d字段，则select * from A natural join B  相当于 select A.a,A.b,A.c,B.d from A.c = B.c  。

1、条件连接就是在多个表的笛卡尔积中选取满足条件的行的连接，例如  select * from A,B where A.a > A.b  之类的有条件的查询。

2、等值连接就是特殊的条件连接，当条件为某字段=某字段时，即为等值连接。如SELECT ename,sal,dname FROM emp,dept WHERE emp.deptno=dept.deptno;

3、自然连接是一种特殊的等值连接，他要求多个表有相同的属性字段，然后条件为相同的属性字段值相等，最后再将表中重复的属性字段去掉，即为自然连接。如A中a,b,c字段，B中有c,d字段，则select * from A natural join B  相当于 select A.a,A.b,A.c,B.d from A.c = B.c  。

内连接与等值连接的区别：

内连接：两个表（或连接）中某一数据项相等的连接称为内连接。等值连接一般用where字句设置条件，内连接一般用on字句设置条件，但内连接与等值连接效果是相同的。

内连接与等值连接其实是一回事情（等效）。

经常有人会问到select a.id,b.name from a,b where a.id=b.pid  与

select a.id,b.name from a inner join b on a.id=b.pid   有什么区别，哪个效率更高一些。

1、内联接（典型的联接运算，使用像 =  或 <> 之类的比较运算符）。包括相等联接和自然联接。     
内联接使用比较运算符根据每个表共有的列的值匹配两个表中的行。例如，检索 students和courses表中学生标识号相同的所有行。  
2、外联接。外联接可以是左向外联接、右向外联接或完整外部联接。     
在 FROM子句中指定外联接时，可以由下列几组关键字中的一组指定：

1）LEFT  JOIN或LEFT OUTER JOIN     
左向外联接的结果集包括  LEFT OUTER子句中指定的左表的所有行，而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值。

2）RIGHT  JOIN 或 RIGHT  OUTER  JOIN     
右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。       
3）FULL  JOIN 或 FULL OUTER JOIN
完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。  
3、交叉联接   
交叉联接返回左表中的所有行，左表中的每一行与右表中的所有行组合。交叉联接也称作笛卡尔积。   
FROM 子句中的表或视图可通过内联接或完整外部联接按任意顺序指定；但是，用左或右向外联接指定表或视图时，表或视图的顺序很重要。有关使用左或右向外联接排列表的更多信息，请参见使用外联接。

解读：1NF,2NF,3NF,BCNF

第一范式：关系模式中，每个属性不可再分。属性原子性

第二范式：非主属性完全依赖于主属性，即消除非主属性对主属性的部分函数依赖关系。

第三范式：非主属性对主属性不存在传递函数依赖关系。

BNCF范式：在第三范式的基础上，消除主属性之间的部分函数依赖

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。

例：如职工号，姓名，电话号码组成一个表（一个人可能有多个电话号码） 规范成为1NF有三种方法：

　　一是重复存储职工号和姓名。这样，关键字只能是电话号码。

　　二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性

　　三是职工号为关键字，但强制每条记录只能有一个电话号码。

以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。

第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意候选关键字，则称关系R 是属于第二范式的。

例：选课关系 sc（sid，cid，grade，credit）其中sid为学号， cid为课程号，grade为成绩，credit为学分。 由以上条件，关键字为组合关键字（sid，cid）

在应用中使用以上关系模式有以下问题：

　　a.数据冗余，假设同一门课由40个学生选修，学分就重复40次。

　　b.更新异常，若调整了某课程的学分，相应的元组credit值都要更新，有可能会出现同一门课学分不同。

　　c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。

　　d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。

原因：非关键字属性credit仅函数依赖于cid，也就是credit部分依赖组合关键字（sid，cid）而不是完全依赖。

解决方法：分成两个关系模式sc（sid，cid，grade），c（cid，credit）。新关系包括两个关系模式，它们之间通过sc中的外关键字cid相联系，需要时再进行自然联接，恢复了原来的关系

第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式的。

例：如s（sid，sname，did，dname，location） 各属性分别代表学号，姓名，所在系，系名称，系地址。

　　关键字sid决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性did，dname，location将重复存储，插入，删除和修改时也将产生类似以上例的情况。

　　原因：关系中存在传递依赖造成的。即sid -> did。 而did ->sid却不存在，did -> location, 因此关键字sid对location函数决定是通过传递依赖did->location实现的。也就是说，sid不直接决定非主属性location。

　　解决目地：每个关系模式中不能留有传递依赖。

　　解决方法：分为两个关系 s（sid，sname，did），d（dno，dname，location）

　　注意：关系s中必须有外关键字did。否则两个关系之间失去联系。

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R中，每个决定因素都包含关键字（而不是被关键字所包含）。

例：配件管理关系模式 wpe（wid，pid，eid，qnt）分别表仓库号，配件号，职工号，数量。有以下条件:

　　a.一个仓库有多个职工。

　　b.一个职工仅在一个仓库工作。

　　c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。

　　d.同一种型号的配件可以分放在几个仓库中。

　　分析：

　　1. pid不能确定qnt，由组合属性（wid，pid）来决定，存在函数依赖（wid，pid）->
qnt。

　　2. 每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有（wid，pid）->
eid。

　　3. 一个职工仅在一个仓库工作，有eid -> wid。

　　4. 每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有（eid，pid）->
qnt。

　　找一下候选关键字。因为（wid，pid）->
qnt，（wid，pid）->
eid，因此（wid，pid）可以决定整个元组，是一个候选关键字。根据eid
-> wid，（eid，pid）->
qnt，故（eid，pid）也能决定整个元组，为另一个候选关键字。属性eid，eid，pid均为主属性，只有一个非主属性qnt。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。

　　分析一下主属性。因为eid -> wid，主属性eid是wid的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性wid对另外一个候选关键字（eid，pid）的部分依赖，因为（eid，pid）-> eid但反过来不成立，而pid
-> wid，故（eid，pid）-> wid 也是传递依赖。　

　　虽然没有非主属性对候选关键字的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分pid而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。

　　解决办法：分成管理ep（eid，pid，qnt），关键字是（eid，pid）和工作ew（eid，wid）其关键字是eid

　　缺点：分解后函数依赖的保持性较差。如此例中，由于分解，函数依赖（wid，pid）-> eid 丢失了，因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。

　　一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

1NF直到BCNF的四种范式之间有如下关系：

BCNF包含了3NF包含2NF包含1NF

小结：

　　目的：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新

　　原则：遵从概念单一化原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

　　方法：将关系模式投影分解成两个或两个以上的关系模式。

　　要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。

注意：一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

数据库的（ 完整性）是指数据的正确性和相容性。数据库完整性定义：数据库完整性（Database Integrity）是指数据库中数据在逻辑上的一致性、正确性、有效性和相容性。

活锁和死锁：：

一、活锁

如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，...，T2有可能永远等待，这就是活锁的情形，如图8.4(a)所示。 避免活锁的简单方法是采用先来先服务的策略。

二、死锁

如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。

1. 死锁的预防

在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法：

① 一次封锁法

一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。 一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。

② 顺序封锁法

顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。 顺序封锁法可以有效地防止死锁，但也同样存在问题。事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。 可见，在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。

2. 死锁的诊断与解除

① 超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。

② 等待图法

事务等待图是一个有向图G=(T,U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2,则T1、T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。

DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去。当然，对撤消的事务所执行的数据修改操作必须加以恢复。

1、外模式 外模式又称子模式，对应于用户级。它是某个或某几个用户所看到的数据库的数据视图，是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集，包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式)，也可以利用数据操纵语言(DML)对这些数据记录进行。外模式反映了数据库的用户观。
 2、内模式 内模式又称存储模式，对应于物理级，它是数据库中全体数据的内部表示或底层描述，是数据库最低一级的逻辑描述，它描述了数据在存储介质上的存储方式翱物理结构，对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义，它是数据库的存储观。 3、模式． 模式又称概念模式或逻辑模式，对应于概念级。它是由数据库设计者综合所有用户的数据，按照统一的观点构造的全局逻辑结构，是对数据库中全部数据的逻辑结构和特征的总体描述，是所有用户的公共数据视图(全局视图)。它是由数据库管理系统提供的数据模式描述语言(DDL)来描述、定义的，体现、反映了数据库系统的整体观。

关系规范化中的 删除 异常是指( )

正确答案: A   你的答案: C (错误)

不该删除的数据被删除

不该插入的数据被插入

应该删除的数据未被删除

应该插入的数据未被插入

插入异常：不该插入的数据被插入