数据库面试基础知识总结

1. 数据抽象：物理抽象、概念抽象、视图级抽象，内模式、模式、外模式

提示：

(1). 概念模式：(面向单个用户的)

是数据中全部数据的整体逻辑结构的描述。它由若干个概念记录类型组成。

(2). 外模式：(面向全局的)

是用户与数据库系统的接口，是用户用到的那部分数据的描述。它由若干个外部记录类型组成。

(3). 内模式：(面向存储的)

是数据库在物理存储方面的描述，它定义所有的内部记录类型、索引、和文件的组织方式，以及数据控制方面的细节。

模式描述的是数据的全局逻辑结构，外模式描述的是数据的局部逻辑结构。对应与同一个模式可以有任意多个外模式。在数据库中提供两级映像功能，即外模式/模式映像和模式/内模式映像。对于没一个外模式，数据库系统都有一个外模式/模式映像它定义了该外模式与模式之间的对应关系。这些映像定义通常包括在各自外模式的描述中，当模式改变时，由数据库管理员对各个外模式/模式的映像做相应改变，可以使外模式保持不变，从而应用程序不必修改，保证了数据的逻辑独立性。数据库中只有一个模式，也只有一个内模式，所以模式/内模式映像是唯一的，它定义了数据全局逻辑结构与存储结构之间的对应关系。当数据库的存储结构改变了，由数据库管理员对模式/内模式映像做相应改变，可以使模式保持不变，从而保证了数据的物理独立性。

2. SQL语言包括数据定义、数据操纵(Data Manipulation)，数据控制(Data Control)

数据定义：Create Table，Alter Table，Drop Table，Craete/Drop Index等

数据操纵：Select ，insert，update，delete，

数据控制：grant，revoke

3. SQL常用命令

CREATE TABLE Student(

ID NUMBER PRIMARY KEY，

NAME V ARCHAR2(50) NOT NULL);//建表

CREATE VIEW view_name AS

Select * FROM Table_name;//建视图

Create UNIQUE INDEX index_name ON TableName(col_name);//建索引

INSERT INTO tablename {column1，column2，…} values(exp1，exp2，…);//插入

INSERT INTO Viewname {column1，column2，…} values(exp1，exp2，…);//插入视图实际影响表

UPDA TE tablename SET name=’zang 3’ condition;//更新数据

DELETE FROM Tablename WHERE condition;//删除

GRANT (Select，delete，…) ON (对象) TO USER_NAME [WITH GRANT OPTION];//授权

REVOKE (权限表) ON(对象) FROM USER_NAME [WITH REVOKE OPTION] //撤权

列出工作人员及其领导的名字：

Select https://www.360docs.net/doc/8d1406980.html,，https://www.360docs.net/doc/8d1406980.html, FROM EMPLOYEE E S

WHERE E.SUPERName=https://www.360docs.net/doc/8d1406980.html,

4. 视图

提示：

计算机数据库中的视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的

查询所引用的表，并且在引用视图时动态生成。

从用户角度来看，一个视图是从一个特定的角度来查看数据库中的数据。从数据库系统内部来看，一个视图是由SELECT语句组成的查询定义的虚拟表。从数据库系统内部来看，视图是由一张或多张表中的数据组成的，从数据库系统外部来看，视图就如同一张表一样，对表能够进行的一般操作都可以应用于视图，例如查询，插入，修改，删除操作等。

5. 完整性约束：实体完整性、参照完整性、用户定义完整性

提示：

定义：关系完整性是为保证数据库中数据的正确性和相容性，对关系模型提出的某种约束条件或规则。完整性通常包括域完整性，实体完整性、参照完整性和用户定义完整性，其中域完整性，实体完整性和参照完整性，是关系模型必须满足的完整性约束条件。

(1). 域完整性约束：域完整性是保证数据库字段取值的合理性。

属性值应是域中的值，这是关系模式规定了的。除此之外，一个属性能否为NULL，这是由语义决定的，也是域完整性约束的主要内容。域完整性约束是最简单、最基本的约束。在当今的关系DBMS中，一般都有域完整性约束检查功能。

包括检查(CHECK)、默认值(DEFAULT)、不为空(NOT NULL)等。

(2). 实体完整性

实体完整性是指关系的主关键字不能重复也不能取“空值\"。

一个关系对应现实世界中一个实体集。现实世界中的实体是可以相互区分、识别的，也即它们应具有某种惟一性标识。在关系模式中，以主关键字作为惟一性标识，而主关键字中的属性(称为主属性)不能取空值，否则，表明关系模式中存在着不可标识的实体(因空值是“不确定\"的)，这与现实世界的实际情况相矛盾，这样的实体就不是一个完整实体。按实体完整性规则要求，主属性不得取空值，如主关键字是多个属性的组合，则所有主属性均不得取空值。

如表1．1将编号作为主关键字，那么，该列不得有空值，否则无法对应某个具体的职工，这样的表格不完整，对应关系不符合实体完整性规则的约束条件。

(3). 参照完整性

参照完整性是定义建立关系之间联系的主关键字与外部关键字引用的约束条件。

关系数据库中通常都包含多个存在相互联系的关系，关系与关系之间的联系是通过公共属性来实现的。所谓公共属性，它是一个关系R(称为被参照关系或目标关系)的主关键字，同时又是另一关系K(称为参照关系)的外部关键字。如果参照关系K中外部关键字的取值，要么与被参照关系R中某元组主关键字的值相同，要么取空值，那么，在这两个关系间建立关联的主关键字和外部关键字引用，符合参照完整性规则要求。如果参照关系K的外部关键字也是其主关键字，根据实体完整性要求，主关键字不得取空值，因此，参照关系K外部关键字的取值实际上只能取相应被参照关系R中已经存在的主关键字值。

在学生管理数据库中，如果将选课表作为参照关系，学生表作为被参照关系，以“学号\"作为两个关系进行关联的属性，则“学号\”是学生关系的主关键字，是选课关系的外部关键字。选课关系通过外部关键字“学号’’参照学生关系。

(4). 用户定义完整性

实体完整性和参照完整性适用于任何关系型数据库系统，它主要是针对关系的主关键字和外部关键字取值必须有效而做出的约束。用户定义完整性则是根据应用环境的要求和实际的需要，对某一具体应用所涉及的数据提出约束性条件。这一约束机制一般不应由应用程序提供，而应有由关系模型提供定义并检验，用户定义完整性主要包括字段有效性约束和记录有效性。

6. 第三范式：

提示：

(1).第一范式(1NF)：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表(一个人可能有一个办公室电话和一个家里电话号码)规范成为1NF有三种方法：

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

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

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

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

(2).第二范式(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相联系，需要时再进行自然联接，恢复了原来的关系

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

例：如S1(SNO，SNAME，DNO，DNAME，LOCATION)各属性分别代表学号，

姓名，所在系，系名称，系地址。

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

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

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

解决方法：分为两个关系S(SNO，SNAME，DNO)，D(DNO，DNAME，LOCATION)

注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

7. ER(实体/联系)模型

提示：

实体-关系模型是面向现实世界，而不是面向实现方法的，它主要是用于描述现实信息世界中数据的静态特性，而不涉及数据的处理过程。

基本概念：

实体：现实世界中任何可以相互区分的事物。解释：实体可以是人，也可以是物；可以指实际的对象，也可以指某些概念。例如，一个职工、一个学生、一门课，学生的一些选课。

属性：实体(或联系)所具有的某方面特征(相当于数据库表的字段(列)。例如：学生实体，可由学号、姓名、性别、年龄、系、年级。(9673101，王平，男，22，计算机系，三年级)这些属性组合起来就表现了一个学生的情况。(相当于记录，特性为字段)。

联系：发生在实体之间具有特定含义的对应关系

PS：实体、属性一般是名词，联系一般是动词

ER图中的四个基本成分：

1.矩形框，表示实体

2.菱形框，表示实体之间的联系

3.椭圆形框，表示实体或联系的属性

4.直线，连接实体、属性、和联系。直线端部标注联系的种类(1：1、1：N或M：N)

连个实体(或表)之间的联系分为三类：

(1). 一对一联系(1：1)如果实体集合A中的每一个实体，实体集合B中至少都一个实体与之联系，反之亦然，则称为实体集合A与实体集合B具有一对一联系，记为1：1。例如，一个班级有一个班长。

(2). 一对多联系(1：n)如果实体集合A中的每一个实体，实体集合B中至少都n(n>=0)个实体与之联系，反之，对于实体集合B中每一个实体，实体集合A中的至多有一个实体与之联系，则称为实体集合A与实体集合B具有一对多联系，记为1：n。例如，一个班级有多个班干部。

(3). 多对多联系(m：n)如果实体集合A中的每一个实体，实体集合B中至少有n(n>=0)个实体与之联系，反之，对于实体集合B中每一个实体，实体集合A中的至少有m(m>=0)个实体与之联系，则称为实体集合A与实体集合B具有多对多联系，记为m：n。例如，一个学生可以选修多门课，一门课可以有多个学生选修。

8. 索引的作用

提示：

可以利用索引快速访问数据库表中的特定信息。索引是对数据库表中一个或多个列(例如，employee 表的姓氏(lname) 列)的值进行排序的结构。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行

相比，索引有助于更快地获取信息。

索引提供指针以指向存储在表中指定列的数据值，然后根据指定的排序次序排列这些指针。数据库使用索引的方式与使用书的目录很相似：通过搜索索引找到特定的值，然后跟随指针到达包含该值的行。

在数据库关系图中，可以为选定的表创建、编辑或删除索引/键属性页中的每个索引类型。当保存附加在此索引上的表或包含此表的数据库关系图时，索引同时被保存。有关详细信息，请参见创建索引。

通常情况下，只有当经常查询索引列中的数据时，才需要在表上创建索引。索引将占用磁盘空间，并且降低添加、删除和更新行的速度。不过在多数情况下，索引所带来的数据检索速度的优势大大超过它的不足之处。然而，如果应用程序非常频繁地更新数据，或磁盘空间有限，那么最好限制索引的数量。

在创建索引前，必须确定要使用的列和要创建的索引类型。

9. 事务

提示：

数据库事务(Database Transaction)，是指作为单个逻辑工作单元执行的一系列操作。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID(原子性、一致性、隔离性和持久性)属性。

数据库事务的ACID特性

(1). 原子性(atomic)(atomicity)

事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。

(2). 一致性(consistent)(consistency)

事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构(如 B 树索引或双向链表)都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。

(3). 隔离性(insulation)(isolation)

由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。防止数据丢失

(4). 持久性(Duration)(durability)

事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。

10. 数据库中的锁

提示：

在数据库中引入锁的原因：

多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:

(1). 丢失更新：A，B两个用户读同一数据并进行修改，其中一个用户的修改结果破坏了另一个修改的结果，比如订票系统。

(2). 脏读：A用户修改了数据，随后B用户又读出该数据，但A用户因为某些原因取消了对数据的修改，数据恢复原值，此时B得到的数据就与数据库内的数据产生了不一致。

(3). 不可重复读：A用户读取数据，随后B用户读出该数据并修改，此时A用户再读取数据时发现前后两次的值不一致。

并发控制的主要方法是封锁，锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致。

在数据库中主要使用两种锁：

(1). 共享锁

共享(S) 锁允许并发事务读取(SELECT)一个资源。资源上存在共享(S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享(S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享(S) 锁。

(2). 排它锁

排它(X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它(X) 锁锁定的数据。锁的粒度

锁粒度是被封锁目标的大小，封锁粒度小则并发性高，但开销大，封锁粒度大则并发性低但开销小。两段锁协议

所谓两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁：

1. 在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁，而且

2. 在释放一个封锁之后，事务不再申请和获得任何其他封锁。

所谓“两段”锁的含义是，事务分为两个阶段，第一阶段是获得封锁，也称为扩展阶段。在这阶段，事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁。第二阶段是释放封锁，也称为收缩阶段。在这阶段，事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。

例如事务T1遵守两段锁协议，其封锁序列是：(如右)

又如事务T2不遵守两段锁协议，其封锁序列是：

Slock A … Unlock A … Slock B … Xlock C … Unlock C … Unlock B；

可以证明，若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。

另外要注意两段锁协议和防止死锁的一次封锁法的异同之处。一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行，因此一次封锁法遵守两段锁协议；但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。

11. 死锁及处理

提示：

所谓死锁：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。

产生死锁的原因

1. 竞争资源引起进程死锁

当系统中供多个进程共享的资源如打印机、公用队列的等，其数目不足以满足诸进程的需要时，会引起诸进程对资源的竞争而产生死锁。

(1). 可剥夺资源和不可剥夺资源

系统中的资源可以分为两类，一类是可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺。例如，优先权高的进程可以剥夺优先权低的进程的处理机。又如，内存区可由存储器管理程序，把一个进程从一个存储区移到另一个存储区，此即剥夺了该进程原来占有的存储区，甚至可将一进程从内存调到外存上，可见，CPU和主存均属于可剥夺性资源。另一类资源是不可剥夺资源，当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机、打印机等。

(2). 竞争不可剥夺资源

在系统中所配置的不可剥夺资源，由于它们的数量不能满足诸进程运行的需要，会使进程在运行过程中，因争夺这些资源而陷于僵局。例如，系统中只有一台打印机R1和一台磁带机R2，可供进程P1和P2共享。假定PI已占用了打印机R1，P2已占用了磁带机R2，若P2继续要求打印机R1，P2将阻塞；P1若又要求磁带机，P1也将阻塞。于是，在P1和P2之间就形成了僵局，两个进程都在等待对方释放自己所需要的资源，但是它们又都因不能继续获得自己所需要的资源而不能继续推进，从而也不能释放自己所占有的资源，以致进入死锁状态。

(3). 竞争临时资源

上面所说的打印机资源属于可顺序重复使用型资源，称为永久资源。还有一种所谓的临时资源，这是指由一个进程产生，被另一个进程使用，短时间后便无用的资源，故也称为消耗性资源，如硬件中断、信号、消息、缓冲区内的消息等，它也可能引起死锁。例如，SI，S2，S3是临时性资源，进程P1产生消息S1，又要求从P3接收消息S3；进程P3产生消息S3，又要求从进程P2处接收消息S2；进程P2产生消息S2，又要求从P1处接收产生的消息S1。如果消息通信按如下顺序进行：

P1: ···Relese(S1)；Request(S3)；···

P2: ···Relese(S2)；Request(S1)；···

P3: ···Relese(S3)；Request(S2)；···

并不可能发生死锁。但若改成下述的运行顺序：

P1: ···Request(S3)；Relese(S1)；···

P2: ···Request(S1)；Relese(S2)；···

P3: ···Request(S2)；Relese(S3)；···

则可能发生死锁。

2.进程推进顺序不当引起死锁

由于进程在运行中具有异步性特征，这可能使P1和P2两个进程按下述两种顺序向前推进。

(1)进程推进顺序合法

当进程P1和P2并发执行时，如果按照下述顺序推进：P1：Request(R1)；P1：Request(R2)；P1: Relese(R1)；P1: Relese(R2)；P2：Request(R2)；P2：Request(R1)；P2: Relese(R2)；P2: Relese(R1)；这两个进程便可顺利完成，这种不会引起进程死锁的推进顺序是合法的。

(2)进程推进顺序非法

若P1保持了资源R1,P2保持了资源R2，系统处于不安全状态，因为这两个进程再向前推进，便可能发生死锁。例如，当P1运行到P1：Request(R2)时，将因R2已被P2占用而阻塞；当P2运行到P2：Request(R1)时，也将因R1已被P1占用而阻塞，于是发生进程死锁。

编辑本段产生死锁的必要条件

虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件：

(1)互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。

(2)请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。

(3)不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。

(4)环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

处理死锁的基本方法

在系统中已经出现死锁后，应该及时检测到死锁的发生，并采取适当的措施来解除死锁。目前处理死

锁的方法可归结为以下四种：

(1) 预防死锁。

这是一种较简单和直观的事先预防的方法。方法是通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或者几个，来预防发生死锁。预防死锁是一种较易实现的方法，已被广泛使用。但是由于所施加的限制条件往往太严格，可能会导致系统资源利用率和系统吞吐量降低。

(2) 避免死锁。

该方法同样是属于事先预防的策略，但它并不须事先采取各种限制措施去破坏产生死锁的的四个必要条件，而是在资源的动态分配过程中，用某种方法去防止系统进入不安全状态，从而避免发生死锁。

(3)检测死锁。

这种方法并不须事先采取任何限制性措施，也不必检查系统是否已经进入不安全区，此方法允许系统在运行过程中发生死锁。但可通过系统所设置的检测机构，及时地检测出死锁的发生，并精确地确定与死锁有关的进程和资源，然后采取适当措施，从系统中将已发生的死锁清除掉。

(4)解除死锁。

这是与检测死锁相配套的一种措施。当检测到系统中已发生死锁时，须将进程从死锁状态中解脱出来。常用的实施方法是撤销或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程，使之转为就绪状态，以继续运行。死锁的检测和解除措施，有可能使系统获得较好的资源利用率和吞吐量，但在实现上难度也最大。

解除与预防

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配。因此，对资源的分配要给予合理的规划。

有序资源分配法

这种算法资源按某种规则系统中的所有资源统一编号(例如打印机为1、磁带机为2、磁盘为3、等等)，申请时必须以上升的次序。系统要求申请进程：

1、对它所必须使用的而且属于同一类的所有资源，必须一次申请完；

2、在申请不同类资源时，必须按各类设备的编号依次申请。例如：进程PA，使用资源的顺序是R1，R2；进程PB，使用资源的顺序是R2，R1；若采用动态分配有可能形成环路条件，造成死锁。

采用有序资源分配法：R1的编号为1，R2的编号为2；

PA：申请次序应是：R1，R2

PB：申请次序应是：R1，R2

这样就破坏了环路条件，避免了死锁的发生。

银行算法

避免死锁算法中最有代表性的算法是Dijkstra E.W 于1968年提出的银行家算法：

该算法需要检查申请者对资源的最大需求量，如果系统现存的各类资源可以满足申请者的请求，就满足申请者的请求。

这样申请者就可很快完成其计算，然后释放它占用的资源，从而保证了系统中的所有进程都能完成，所以可避免死锁的发生。

死锁排除的方法

1、撤消陷于死锁的全部进程；

2、逐个撤消陷于死锁的进程，直到死锁不存在；

3、从陷于死锁的进程中逐个强迫放弃所占用的资源，直至死锁消失。

4、从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程，以解除死锁状态。

12. 存储过程

提示：

存储过程(Stored Procedure)是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。

存储过程的种类

1. 系统存储过程

以sp_开头,用来进行系统的各项设定.取得信息.相关管理工作。

2. 本地存储过程

用户创建的存储过程是由用户创建并完成某一特定功能的存储过程，事实上一般所说的存储过程就是指本地存储过程。

3. 临时存储过程

分为两种存储过程：

一是本地临时存储过程，以井字号(#)作为其名称的第一个字符，则该存储过程将成为一个存放在tempdb数据库中的本地临时存储过程，且只有创建它的用户才能执行它;

二是全局临时存储过程，以两个井字号(##)号开始，则该存储过程将成为一个存储在tempdb数据库中的全局临时存储过程，全局临时存储过程一旦创建，以后连接到服务器的任意用户都可以执行它，而且不需要特定的权限。

4. 远程存储过程

在SQL Server2005中，远程存储过程(Remote Stored Procedures)是位于远程服务器上的存储过程，通常可以使用分布式查询和EXECUTE命令执行一个远程存储过程。

5. 扩展存储过程

扩展存储过程(Extended Stored Procedures)是用户可以使用外部程序语言编写的存储过程，而且扩展存储过程的名称通常以xp_开头。

存储过程的优点

1.存储过程因为SQL语句已经预编绎过了，因此运行的速度比较快。

2. 可保证数据的安全性和完整性。通过存储过程可以使没有权限的用户在控制之下间接地存取数据库，从而保证数据的安全。通过存储过程可以使相关的动作在一起发生，从而可以维护数据库的完整性。

3.可以降低网络的通信量。存储过程主要是在服务器上运行，减少对客户机的压力。

4. 存储过程可以接受参数、输出参数、返回单个或多个结果集以及返回值。可以向程序返回错误原因

5. 存储过程可以包含程序流、逻辑以及对数据库的查询。同时可以实体封装和隐藏了数据逻辑。

基本语法

1. 创建存储过程

create procedure sp_name

@[参数名] [类型],@[参数名] [类型]

as

begin

.........

end

以上格式还可以简写成：

create proc sp_name

@[参数名] [类型],@[参数名] [类型]

as

begin

.........

end

/*注：“sp_name”为需要创建的存储过程的名字，该名字不可以以阿拉伯数字开头*/

2.调用存储过程

基本语法：exec sp_name [参数名]

3.删除存储过程

(1) 基本语法：

drop procedure sp_name

(2) 注意事项：不能在一个存储过程中删除另一个存储过程，只能调用另一个存储过程

4. 其他常用命令

(1) show procedure status

显示数据库中所有存储的存储过程基本信息，包括所属数据库，存储过程名称，创建时间等

(2) show create procedure sp_name

显示某一个mysql存储过程的详细信息

(3) exec sp_helptext sp_name

显示你这个sp_name这个对象创建文本

13. 触发器

提示：

触发器(trigger)是个特殊的存储过程，它的执行不是由程序调用，也不是手工启动，而是由事件来触发，比如当对一个表进行操作( insert，delete，update)时就会激活它执行。触发器经常用于加强数据的完整性约束和业务规则等。触发器对表进行插入、更新、删除的时候会自动执行的特殊存储过程。触发器一般用在check约束更加复杂的约束上面。触发器可以从DBA_TRIGGERS ，USER_TRIGGERS 数据字典中查到。触发器和普通的存储过程的区别是：触发器是当对某一个表进行操作。诸如：update、insert、delete这些操作的时候，系统会自动调用执行该表上对应的触发器。

SQL Server 2005中触发器可以分为两类：DML触发器和DDL触发器，其中DDL触发器它们会影响多种数据定义语言语句而激发，这些语句有create、alter、drop语句。

DML触发器分类(根据触发时间来分)

1. after触发器(之后触发)

(1). insert触发器

(2). update触发器

(3). delete触发器

2. instead of 触发器(之前触发)

其中after触发器要求只有执行某一操作insert、update、delete之后触发器才被触发，且只能定义在表上。而instead of触发器表示并不执行其定义的操作(insert、update、delete)而仅是执行触发器本身。既可以在表上定义instead of触发器，也可以在视图上定义。

触发器有两个特殊的表：插入表(instered表)和删除表(deleted表)。这两张是逻辑表也是虚表。有系统在内存中创建者两张表，不会存储在数据库中。而且两张表的都是只读的，只能读取数据而不能修改数据。这两张表的结果总是与被改触发器应用的表的结构相同。当触发器完成工作后，这两张表就会被删除。Inserted表的数据是插入或是修改后的数据，而deleted表的数据是更新前的或是删除的数据。

Update数据的时候就是先删除表记录，然后增加一条记录。这样在inserted和deleted表就都有update 后的数据记录了。注意的是：触发器本身就是一个事务，所以在触发器里面可以对修改数据进行一些特殊的检查。如果不满足可以利用事务回滚，撤销操作。

insert触发器示例

create trigger tri_insert

on student

for insert

as

declare @student_id char(10)

select @student_id=s.student_id from

student s inner join inserted i

on s.student_id=i.student_id

if @student_id='0000000001'

begin

raiserror('不能插入1的学号!',16,8)

rollback tran

end

go

update触发器示例

create trigger tri_update

on student

for update

as

if update(student_id)

begin

raiserror('学号不能修改!',16,8)

rollback tran

end

go

delete触发器示例

create trigger tri_delete

on student

for delete

as

declare @student_id varchar(10)

select @student_id=student_id from deleted

if @student_id='admin'

begin

raiserror('错误',16,8)

rollback tran

end

14.内联接和外联接的区别

提示：

连接查询

通过连接运算符可以实现多个表查询。连接是关系数据库模型的主要特点，也是它区别于其它类型数据库管理系统的一个标志。

在关系数据库管理系统中，表建立时各数据之间的关系不必确定，常把一个实体的所有信息存放在一个表中。当检索数据时，通过连接操作查询出存放在多个表中的不同实体的信息。连接操作给用户带来很大的灵活性，他们可以在任何时候增加新的数据类型。为不同实体创建新的表，尔后通过连接进行查询。

连接可以在SELECT 语句的FROM子句或WHERE子句中建立，似是而非在FROM子句中指出连接时有助于将连接操作与WHERE子句中的搜索条件区分开来。所以，在Transact-SQL中推荐使用这种方法。

SQL-92标准所定义的FROM子句的连接语法格式为：

FROM join_table join_type join_table

[ON (join_condition)]

其中join_table指出参与连接操作的表名，连接可以对同一个表操作，也可以对多表操作，对同一个表操作的连接又称做自连接。

join_type 指出连接类型，可分为三种：内连接、外连接和交叉连接。内连接(INNER JOIN)使用比较运算符进行表间某(些)列数据的比较操作，并列出这些表中与连接条件相匹配的数据行。根据所使用的比较方式不同，内连接又分为等值连接、自然连接和不等连接三种。外连接分为左外连接(LEFT OUTER JOIN 或LEFT JOIN)、右外连接(RIGHT OUTER JOIN或RIGHT JOIN)和全外连接(FULL OUTER JOIN或FULL JOIN)三种。与内连接不同的是，外连接不只列出与连接条件相匹配的行，而是列出左表(左外连接时)、右表(右外连接时)或两个表(全外连接时)中所有符合搜索条件的数据行。

交叉连接(CROSS JOIN)没有WHERE 子句，它返回连接表中所有数据行的笛卡尔积，其结果集合中的数据行数等于第一个表中符合查询条件的数据行数乘以第二个表中符合查询条件的数据行数。

连接操作中的ON (join_condition) 子句指出连接条件，它由被连接表中的列和比较运算符、逻辑运算符等构成。

无论哪种连接都不能对text、ntext和image数据类型列进行直接连接，但可以对这三种列进行间接连接。例如：

SELECT p1.pub_id,p2.pub_id,p1.pr_info

FROM pub_info AS p1 INNER JOIN pub_info AS p2

ON DATALENGTH(p1.pr_info)=DATALENGTH(p2.pr_info)

(一)内连接

内连接查询操作列出与连接条件匹配的数据行，它使用比较运算符比较被连接列的列值。内连接分三种：

1、等值连接：在连接条件中使用等于号(=)运算符比较被连接列的列值，其查询结果中列出被连接表中的所有列，包括其中的重复列。

2、不等连接：在连接条件使用除等于运算符以外的其它比较运算符比较被连接的列的列值。这些运算符包括>、>=、<=、<、!>、!<和<>。

3、自然连接：在连接条件中使用等于(=)运算符比较被连接列的列值，但它使用选择列表指出查询结果集合中所包括的列，并删除连接表中的重复列。

例，下面使用等值连接列出authors和publishers表中位于同一城市的作者和出版社：SELECT *

FROM authors AS a INNER JOIN publishers AS p

ON a.city=p.city

又如使用自然连接，在选择列表中删除authors 和publishers 表中重复列(city和state)：

SELECT a.*,p.pub_id,p.pub_name,p.country

FROM authors AS a INNER JOIN publishers AS p

ON a.city=p.city

(二)外连接

内连接时，返回查询结果集合中的仅是符合查询条件( WHERE 搜索条件或HA VING 条件)和连接条件的行。而采用外连接时，它返回到查询结果集合中的不仅包含符合连接条件的行，而且还包括左表(左外连接时)、右表(右外连接时)或两个边接表(全外连接)中的所有数据行。如下面使用左外连接将论坛内容和作者信息连接起来：

SELECT a.*,b.* FROM luntan LEFT JOIN usertable as b

ON https://www.360docs.net/doc/8d1406980.html,ername=https://www.360docs.net/doc/8d1406980.html,ername

下面使用全外连接将city表中的所有作者以及user表中的所有作者，以及他们所在的城市：

SELECT a.*,b.*

FROM city as a FULL OUTER JOIN user as b

ON https://www.360docs.net/doc/8d1406980.html,ername=https://www.360docs.net/doc/8d1406980.html,ername

(三)交叉连接

交叉连接不带WHERE 子句，它返回被连接的两个表所有数据行的笛卡尔积，返回到结果集合中的数据行数等于第一个表中符合查询条件的数据行数乘以第二个表中符合查询条件的数据行数。例，titles表中有6类图书，而publishers表中有8家出版社，则下列交叉连接检索到的记录数将等于6*8=48行。

SELECT type,pub_name

FROM titles CROSS JOIN publishers

ORDER BY type

例题说明内连接和外连接的区别

有两个表A和表B。

表A结构如下：

Aid：int；标识种子，主键，自增ID

Aname：varchar

数据情况，即用select * from A出来的记录情况如下图1所示：

图1：A表数据

表B结构如下：

Bid：int；标识种子，主键，自增ID

Bnameid：int

数据情况，即用select * from B出来的记录情况如下图2所示：

图2：B表数据

为了把Bid和Aid加以区分，不让大家有误解，所以把Bid的起始种子设置为100。

有SQL基本知识的人都知道，两个表要做连接，就必须有个连接字段，从上表中的数据可以看出，在A表中的Aid和B表中的Bnameid就是两个连接字段。

下图3说明了连接的所有记录集之间的关系：

图3:连接关系图

对内连接和外连接一一讲解

1.内连接：利用内连接可获取两表的公共部分的记录，即图3的记录集C

语句如下：Select * from A JOIN B ON A.Aid=B.Bnameid

运行结果如下图4所示：

图4:内连接数据

其实select * from A,B where A.Aid=B.Bnameid与Select * from A JOIN B ON A.Aid=B.Bnameid的运行结果是一样的。

2.外连接：外连接分为两种，一种是左连接（Left JOIN）和右连接（Right JOIN）

(1)左连接（Left JOIN）：即图3公共部分记录集C＋表A记录集A1。

语句如下：select * from A Left JOIN B ON A.Aid=B.Bnameid

运行结果如下图5所示：

图5:左连接数据

说明：

在语句中，A在B的左边，并且是Left Join，所以其运算方式为：A左连接B的记录=图3公共部分记录集C＋表A记录集A1

在图3中即记录集C中的存在的Aid为：2 3 6 7 8

图1中即表A所有记录集A中存在的Aid为：1 2 3 4 5 6 7 8 9

表A记录集A1中存在的Aid=(图1中即A表中所有Aid)-(图3中即记录集C中存在的Aid)，最终得出为：1 4 5 9

由此得出图5中A左连接B的记录=图3公共部分记录集C＋表A记录集A1,

最终得出的结果图5中可以看出Bnameid及Bid非NULL的记录都为图3公共部分记录集C中的记录；Bnameid及Bid为NULL的Aid为1 4 5 9的四笔记录就是表A记录集A1中存在的Aid。

(2)右连接（Right JOIN）：即图3公共部分记录集C＋表B记录集B1。

语句如下：select * from A Right JOIN B ON A.Aid=B.Bnameid

运行结果如下图6所示：

图6:右连接数据

说明：

在语句中，A在B的左边，并且是Right Join，所以其运算方式为：A右连接B的记录=图3公共部分记录集C+表B记录集B1

在图3中即记录集C中的存在的Aid为：2 3 6 7 8

图2中即表B所有记录集B中存在的Bnameid为：2 3 6 7 8 11

表B记录集B1中存在的Bnameid=(图2中即B表中所有Bnameid)-(图3中即记录集C中存在的Aid)，最终得出为：11

由此得出图6中A右连接B的记录=图3公共部分记录集C＋表B记录集B1,

最终得出的结果图6中可以看出Aid及Aname非NULL的记录都为图3公共部分记录集C中的记录；Aid 及Aname为NULL的Aid为11的记录就是表B记录集B1中存在的Bnameid。

总结

通过上面的运算解说，相信很多人已经想到，上面的情况（包括图3的关系图）说明的都只是A在B的左边的情况，

以下语句B在A的右边的又会出现什么情况呢？？

select * from B Left JOIN A ON A.Aid=B.Bnameid

select * from B Right JOIN A ON A.Aid=B.Bnameid

其实对图3左右翻转一下就可以得出以下结论：

select * from B Left JOIN A ON A.Aid=B.Bnameid和select * from A Right JOIN B ON A.Aid=B.Bnameid所得出的记录集是一样的

而select * from B Right JOIN A ON A.Aid=B.Bnameid和select * from A Left JOIN B ON A.Aid=B.Bnameid所得出的记录集也是一样的。