第3章_SQL的高级应用

第3章SQL 的高级应用3.1 SQL 中的完整性约束SQL把各种完整性约束作为数据库模式定义的一部分。

既有效防止了对数据库的意外破坏，提高了完整性检测的效率，又可以减轻编程人员的负担。

SQL对三种不同完整性约束的设置及检测，采取了不同的方式加以实现。

下面分别介绍。

3.1.1 实体完整性和主码前面1.2.4节中已讲过，实体完整性规定，主码的任何属性都不能为空，因为，概念模型中实体和联系都是可区分的，而且它们以码为唯一性标识。

如果，主码的属性值可以为空，则意味着在概念模型中存在着不以码为唯一性标识的实体。

这显然是前后矛盾的。

那么怎样保证实体完整性呢？SQL中实体完整性是通过主码来实现的。

一旦某个属性或属性组被定义为主码，该主码的每个属性就不能为空值，并且在关系中不能出现主码值完全相同的两个元组。

主码的定义是在Create Table 语句中使用Primary Key关键字来实现的。

方法有两种：a)在属性定义后加上关键字Primary Key；b)在属性表定义后加上额外的定义主码的子句：Primary Key（<主码属性名表>）（例如P42例3.1）说明：✧如果主码仅由一个属性组成，上述两种方法都可定义，若由两个或以上的属性组成，则只能用上述第二种方法定义了。

✧对于候选码的说明方法，可以用Unique说明该属性的值不能重复出现。

Unique的使用与Primary Key相似。

✧一个表中只能有一个主码定义，但可以有多个Unique说明。

✧SQL中，并没有强制为每个关系指定主码，但为每个关系指定主码通常会更好一些。

（因为主码的指定可以确保关系的实体完整性）3.1.2 参照完整性约束与外部码参照完整性是对关系间引用数据的一种限制。

即：若属性组A是基本关系R1的外码，它与基本关系R2的主码K相对应，则R1中每个元组在A上的值必须：要么取空值，要么等于R2中某元组的主码值。

一、外部码约束的说明：SQL中就是利用外部码的说明来实现参照完整性约束，限制表中某些属性的取值的。

外部码的说明也有两种方法：1、在该属性的说明后直接加上关键字”REFERENCES <表名>（<属性名>）”，其中表名称为参照关系名，属性名称为参照关系的主码。

2、在Create Table 语句的属性清单后，加上外部码说明子句，格式为：FOREIGN KEY <属性名表1> REFERENCES <表名>(<属性名表2>) 上式中的属性名表1和属性名表2中属性可以多于一个，但必须前后对应。

（见P43下部例3.3）二、参照完整性约束的实现策略前面讲了，外部码的取值只有两种情况：要么取空，要么取参照关系中的主码值。

可是当用户操作违反了这个规则时，如何保持此约束呢？SQL提供了三种可选方案：1、RESTRICT(限制策略)：当用户对表进行违反了上述完整性约束、条件的插入、删除或修改操作时，将会被系统拒绝。

2、CASCADE（级联策略）：当对参照关系进行删除和修改时，SQL所提供的一种方案。

在这种策略下，当删除或修改参照关系中某元组的主码值时，被参照关系中，那些外部码具有该值的元组也将被删除或修改，以保证参照完整性。

3、SET NULL（置空策略）：置空策略也是针对参照关系的删除或修改操作的。

在这种策略下，当删除参照关系中的某一元组或修改某一元组的主码值时，被参照关系中外码值等于该主码值的元组在该外码上的值将被置空说明：当用户不指定参照完整性的实现策略时，一般被默认为RESTRICT(限制策略)。

实现策略的说明通常被加在外部码的说明后面，格式为：ON DELETE SET NULL ON UPDATE CASCADE。

3.1.3 用户自定义完整性约束对于用户自定义完整性约束，SQL提供了非空约束、对属性的CHECK约束、对元组的CHECK 约束、触发器等来实现用户的各种完整性要求。

1、非空约束：在CRETE TABLE 中的属性定义后面加上NOT NULL关键字即定义了该属性不能取空值。

2、基于属性的CHECK约束使用CHECK（检查）子句可保证属性值满足某些前提条件。

其一般格式为：CHECK（<条件>）它既可跟在属性定义的后面，也可在定义语句中另增一子句加以说明。

如：CHECK（age>=18 AND age<=65）;CHECK（sex IN (“男”,”女”)）;CHECK（dno IN(select dno from department)）;从上例中可以看出，CHECK子句的条件中还可以带子查询。

3、基于元组的CHECK约束如P46 例3.6工资表salary 的定义中的CHECK（Insure+Fund<Basepay）;基于元组的CHECK约束往往要涉及到表中的多个域。

所以它是元组约束。

在对整个元组完成插入或对某一元组的修改完成之后，系统将自动检查是否符合CHECK条件表达式。

若不符合条件，系统将拒绝该插入或修改操作。

基于元组CHECK约束的说明方法是在CREATE TABLE语句中的属性表、主码、外部码的说明之后加上CHECK子句。

3.1.4 约束的更新约束与数据库中的表和视图一样，可以进行增、删、改的更新操作。

为了改和删约束，需要在定义约束时对其进行命名，在各种约束的说明前加上关键字CONSTRAINT 和该约束的名称即可。

例如：在employee表的create table语句中：eno char(4) CONSTRAINT PK_employee PRIMARY KEY,dno char(4)CONSTRAINT FK_employee FOREIGN KEY REFERENCES department(dno);当对各种约束进行命名后，就可以用ALTER TABLE语句来更新与属性或表有关的各种约束。

如：ALTER TABLE employee DROP CONSTRAINT FK_employee;ALER TABLE Salary ADD CONSTRAINT RightSalary CHECK(Insure+Fund<Rest);上述的增加约束，实际上也是通过ALTER TABLE语句定义约束的一种形式。

SQL不能直接修改约束，修改某一个约束实际上是用ALTER TABLE 语句先删除该约束，然后再增加一个与该约束同名的新约束。

3.2 SQL中的触发器触发器（Trigger）不仅能实现完整性规则，而且能保证一些较复杂业务规则的实施。

它是一类由事件驱动的特殊过程，一旦由某个用户定义，任何用户对该触发器指定的数据进行增、删或改操作时，系统都将自动激活之，并在核心层对其进行集中的完整性控制。

3.2.1 触发器的组成和类型触发器的定义包括两个方面：✧指明触发器的触发事件：✧指明触发器执行的动作。

1、触发事件包括：表中行的插入、删除和修改，即执行INSERT、DELETE、UPDA TE语句，在UPDATE中还可以指定，特定的属性或属性组的修改为触发条件。

事件的触发，还有两个相关的时间：Before 和After。

顾名思义，before触发器是在事件发生之前触发，After触发器是在事件发生之后触发。

2、触发动作：是一系列SQL语句，可以有两种方式：（1）对被事件影响的每一行（FOR EACH ROW）——每一元组执行触发过程。

称为行级触发器。

（2）对整个事件只执行一次触发过程（FOR EACH STA TEMENT），称为语句级触发器。

此为触发器的默认方式。

3.2.2 创建触发器1、建触发器的语句格式：CREATE TRIGGER<触发器名>［｛BEFORE｜AFTER｝］｛［DELETE｜INSERT｜UPDATE OF［列名清单］］｝ON <表名>[REFERENCING <临时视图名>]［WHEN<触发条件>］<触发动作>［FOR EACH｛ROW｜STA TEMENT｝］2、说明（1）BEFORE／AFTER：指示DBMS在执行触发语句之前／后激发触发器（2）DELETE／INSERT：指明是DELETE／INSERT触发器，每当一个DELETE／INSERT 语句从／向表中删除／插入一行时激发触发器。

（3）UPDATE：指明是UPDA TE触发器，每当UPDATE语句修改由OF子句指定的列值时，激发触发器。

（如果忽略OF子句，则意味着修改表中任何列值时，DBMS都将激发触发器）。

（4）RFFERENCING<临时视图名>：指定临时视图的别名。

在触发器运行过程中，系统会生成两个临时视图，分别存放被更新的值（旧值）和更新后的值（新值）。

对于行级触发器，默认临时视图分别为OLD和NEW；对于语句级触发器，默认为OLD_TABLE和NEW_TABLE。

一旦触发器运行结束，临时视图将不复存在。

（5）WHEN<触发条件>：指定触发器的触发条件。

当满足触发条件时，DBMS才激发触发器。

触发条件中必须包含临时视图名，不包含查询。

参考P48 下部例3.9。

3.3 嵌入式SQL的使用SQL语言是非过程化的、面向集合的数据操纵语言，它大部分语句的使用的是独立的，与上下文条件无关。

而在事务处理中，常常需要流程控制，而SQL语句却不具备这种控制。

另一方面，普通编程语言（如C、BASIC、PASCAL、FORTRAN等）虽然具有很强的流程控制能力，而在涉及数据库的操作时，却不能高效率地进行数据的存取。

所以将SQL语句嵌入到普通编程语言中使用，很好地结合了编程语言的过程性和SQL语言的数据操纵能力。

从而提高了数据库应用程序的效率。

把这种嵌入到普通编程语言中的SQL语言称为嵌入式SQL语言（Embedded SQL）。

在这里把嵌入SQL语句的普通编程语言称为宿主语言或主语言。

DBMS有两种方法处理嵌入式SQL语言：预编译和扩充编译程序法。

✧预编译方法：是站在DBMS一方来处理嵌入式的SQL语句。

DBMS的预编译器首先把它们从程序代码中识别出来，并转换成纯宿主语言源代码，最后由宿主语言编译器将整个代码译成目标码。

✧扩充编译程序法：是站在宿主语言一方来处理嵌入式SQL语句的。

它是通过修改和扩充宿主语言的编译程序。

使其能够直接处理SQL语句。

目前使用较多的上述第一种方法，即预编译方法。

使用嵌入式SQL，必须解决下列三个问题：（1）如何让预编译器识别程序代码中的SQL语句，即程序中必须要有区分SQL语句与宿主语句的标记；（2）DBMS和宿主语言程序如何进行信息传递，即进行数据交换；（3）一条SQL语句原则上可产生或处理一组记录，而宿主语句一次只能处理一个记录，如何协调好这两种处理方式。