老师课件-第5章数据库

第5章

数据库的完整性和安全性本章学习目标掌握数据库完整性的基本概念。清楚数据库完整性约束条件的分类。掌握并运用SQL实现实体完整性和参照完整性的定义。运用SQL灵活实现用户自定义完整性的各种约束。掌握完整性约束的修改方法。理解触发器的概念和作用。掌握数据库安全性的基本概念。清楚DBMS中的安全性保护措施。清楚SQL中的安全机制。掌握并运用SQL实现授权和角色机制。了解其他安全措施。本章概述数据库作为资源共享和存放大量数据的场所，如何能更好地保护数据库中的数据就显得尤为重要。数据的完整性和安全性是数据库保护的两个不同方面。安全性是防止非法用户恶意破坏和越权存取数据，确保用户被限制在其想做的事情范围之内。完整性则是防止合法用户使用数据库时无意中造成的破坏，确保用户所做的事情是正确的。即安全性措施的防范对象是非法用户和非法操作，完整性措施的防范对象是不合语义的数据。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.1.1完整性概念数据库的完整性(integrity)的基本含义是指数据库中数据的正确性、有效性和相容性，其目的是防止不符合语义、不正确的数据进入数据库，从而来保证数据库系统能够真实的反映客观现实世界。正确性(correctness)是指数据的合法性，例如成绩属于数值型数据，只能含有数字而不能含有字母。有效性(valid)是指数据是否属于所定义域的有效范围，例如性别只能是男或女。相容性(consistency)是指表示同一事实的两个数据应当一致，不一致即是不相容。例如一个学生不能有两个学号。DBMS必须提供一种功能来确保数据的正确性，避免不合语义的数据造成的无效操作和错误结果，还要检查先后输入的数据是否一致。5.1.2完整性约束条件

数据库中的数据要成为有意义的信息，必须满足一定的语义约束条件。数据库中数据应当满足的条件称为“完整性约束条件”，也称为“完整性规则”。它是DBMS控制数据完整性的依据，是整个完整性控制机制的核心。

完整性约束条件作用的对象是关系、元组和属性，这三种对象的状态可以是静态的，也可以是动态的。5.1.2完整性约束条件

静态约束是关于数据库状态合理性的约束，是指数据库每一确定状态时的数据对象所应满足的约束条件。分别作用于属性、元组和关系就表现为：(1)静态属性级约束：是对一个属性的取值域的说明，即对数据类型、数据格式和取值范围的约束。如，学生的出生年月日必须为日期型，成绩的取值范围必须在0～100等。(2)静态元组级约束：是对元组中各个属性值之间关系的约束。如图书管理表中有总库存量，借出量，和剩余量三个属性，其中借出量和剩余量都不得超过总库存量。(3)静态关系级约束：是一个关系中各个元组之间或者若干个关系之间常常存在的各种联系的约束。常见的静态关系约束有：①实体完整性；②参照完整性；③函数依赖约束，大部分函数依赖约束都在关系模式中定义；④统计约束，即字段值与关系中多个元组的统计值之间的约束关系。5.1.2完整性约束条件

动态约束是指数据库从一种正确状态转移到另一种状态时，新、旧值之间所应满足的约束条件。例：学生的最高学位，如下动态转移是正确的：学士到硕士、硕士到博士。(1)动态属性级约束：是修改定义或属性值时应满足的约束条件，包括两种情况。修改定义时的约束。例：将允许空值的属性改为不允许空值时，如果该属性当前已存在空值，则规定拒绝修改。修改属性值时的约束。例：修改属性值时有时需要参照其旧值，或新旧值之间应该满足某种约束条件，如学生的年龄只能增长。(2)动态元组级约束：是指修改某个元组的值时需要参照该元组的原有值，或者元组中各个字段之间应当满足某种约束条件。例：给职工提升工资时新工资不得低于原工资+现工龄×10。(3)动态关系级约束：是加在关系变化前后状态上的限制条件。例：事物一致性、原子性等约束条件。5.1.2完整性约束条件

完整性约束条件从执行时间上又可分为立即执行约束(immediateCONSTRAINTS)和延迟执行约束(deferredCONSTRAINTS)。立即执行约束是指在执行用户事物过程中，某一条语句执行完后，系统立即对此数据进行完整性约束条件检查。如果发现用户操作请求违背了立即执行约束，则可以拒绝该操作，以保证数据的完整性。延迟执行约束是指在整个事物执行结束后再对约束条件进行完整性检查，结果正确后才能提交。如果发现用户操作请求违背了延迟执行约束，而又不知道是哪个事物的操作破坏了完整性，则只能拒绝整个事物，把数据库恢复到该事物执行前的状态。完整性约束条件还可以作用在数据库上，说明数据库的合法取值。通常，数据库的约束检查是可以延迟到事务提交时进行的，而上述作用于属性、元组和关系的约束检查是立即进行的。所有数据库的更新都不能破坏数据库的完整性。5.1.3完整性控制机制为了维护数据库的完整性，DBMS必须提供以下三种机制：1.完整性约束条件定义

完整性约束条件也称为完整性规则，是数据库中的数据必须满足的语义约束条件。SQL标准使用了一系列概念来描述完整性，包括关系模型的实体完整性、参照完整性和用户定义完整性。这些完整性一般由SQL的DDL语义来实现，它们作为数据库模式的一部分存入数据字典中。2.完整性检查方法

检查数据是否满足已定义的完整性约束条件称为完整性检查。一般在INSERT、UPDATE、DELETE语句执行后开始检查，也可以在事务提交时检查。检查这些操作执行后数据库中的数据是否违背了完整性约束条件。3.违约处理

若发现用户操作违背了完整性约束条件，应采取一定的措施，如拒绝(NOACTION)执行该操作，或级连(CASCADE)执行其它操作，进行违约处理以保证数据的完整性。目前商用的数据库管理系统都支持完整性控制。即完整性定义和检查控制由DBMS实现，不必由应用程序来完成，从而减轻了应用程序员的负担。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.2实体完整性

实体完整性要求基本表的主码值唯一且不允许为空值。

在SQL中，实体完整性定义是使用CREATETABLE语句中的PRIMARYKEY短语来实现，或通过使用ALTERTABLE语句中的ADDPRIMARYKEY短语来实现。

对单属性构成的码有两种说明方法：定义为列级约束条件定义为表级约束条件对多个属性构成的码只有一种说明方法，即定义为表级约束条件。5.2.1实体完整性定义[例5-1]将Student表中的Sno属性定义为码。CREATETABLEStudent(SnoCHAR(7),SnameCHAR(8)NOTNULL,SsexCHAR(2),SageSMALLINT,SdeptCHAR(20),

PRIMARYKEY(Sno));/*在表级定义主码*/其中，Sno为表Student的主码，它由主码约束说明PRIMARYKEY实现。对于这种情况，还可以直接在列Sno定义的同一行上定义为表Student的主码。如：CREATETABLEStudent(SnoCHAR(7)PRIMARYKEY,/*在列级定义主码*/SnameCHAR(8)NOTNULL,SsexCHAR(2),SageSMALLINT,SdeptCHAR(20));注意，如果主码包含多列，则只能在表级定义。5.2.1实体完整性定义[例5-2]将SC表中的Sno,Cno属性组定义为主码。CREATETABLESC(SnoCHAR(7),CnoCHAR(4),GradeSMALLINT,PRIMARYKEY(Sno，Cno));/*只能在表级定义主码*/5.2.2实体完整性检查和违约处理

在用PRIMAYRKEY语句定义了关系的主码后，每个用户程序对基本表插入一条记录或者对主码列进行更新操作时，RDBMS将按实体完整性规则自动进行检查。包括：(1)检查主码值是否唯一，如果不唯一则拒绝插入或修改。(2)检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。检查主码值的唯一性，可以采用全表扫描法或B+树索引扫描法。全表扫描法：从外存依次将表的每个数据块读入内存，判断块中的每一条记录的主码值与待插入(或修改)记录的主码值是否相同，如果相同，则阻止插入(或修改)。全表扫描法如图5-1所示。待插入或修改的记录码值i属性值i1属性值i2……码值11属性值11属性值12……码值21属性值21属性值22……码值31属性值31属性这32…………5.2.2实体完整性检查和违约处理B+树索引扫描法

全表扫描法是十分耗时的，为了避免对基本表进行全表扫描，DBMS核心一般都在主码上自动建立一个B+树索引，通过扫描索引来查找基本表中是否存在相同的主码值，这将大大提高效率。

例如，如果新插入记录的主码值是25，通过主码索引，从B+树的根结点开始查找，只要读取3个结点就可以知道该主码值已经存在，所以不能插入这条记录。这3个结点是根结点(51)、中间结点(1230)、叶节点(152025)。如果新插入记录的主码值是86，也只要查找3个结点就可以知道该主码值不存在，所以可以插入该记录，如图5-2所示。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.3参照完整性

参照完整性是指基本关系R的任何一个元组在外码F上的取值要么是空值，要么是被参照关系S中一个元组的主码值。

SQL不仅可以实现实体完整性的定义，还可以通过CREATETABLE语句定义参照完整性规则。即用户可以在建表时定义哪些列为外码列，这个外码对应于哪个表的主码。

一般来讲，参照完整性的定义包括两个部分：(1)

外码说明，它由FOREIGNKEY(列名)语句来描述。(2)

被引用的表名和列名，由REFERENCES语句描述。5.3.1参照完整性定义[例5-3]关系SC中一个元组表示一个学生选修的某门课程的成绩，Sno代表Student中的一个学生，Cno代表Course中的一门课程。因此Sno，Cno分别是对Student和Course的参照引用。CREATETABLESC(SnoCHAR(7),CnoCHAR(4),GradeSMALLINT,PRIMARYKEY(Sno，Cno),/*在表级定义实体完整性*/FOREIGNKEYSnoREFERENCESStudent(Sno),

/*在表级定义参照完整性*/FOREIGNKEYCnoREFERENCESCourse(Cno)/*在表级定义参照完整性*/);5.3.2参照完整性检查和违约处理定义了参照完整性，对参照表和被参照表进行修改操作有可能会破坏参照完整性，系统首先会检查是否违反了参照完整性，如果违反了，则进行违约处理。违约处理的策略如下：(1)拒绝(NOACTION)执行。不允许该操作执行，该策略一般设置为默认策略。在被参照关系中删除元组：仅当参照关系中没有任何元组的外码值与被参照关系中要删除元组的主码值相同时，系统才执行删除操作，否则拒绝此操作。参照关系中可以随意删除元组。在参照关系中修改元组：仅当参照关系中修改后的元组的外码值依然在被参照关系中，系统才执行修改操作，否则拒绝该操作。在被参照关系中修改元组：仅当被参照关系中修改前的元组的主码值没有出现在参照关系的外码中，系统才执行修改操作，否则拒绝该操作。在参照关系中插入元组：仅当参照关系中插入的元组的外码值等于被参照关系中某个元组的主码值时，系统才执行插入操作，否则拒绝该操作。被参照关系可以随意插入新元组。5.3.2参照完整性检查和违约处理(2)级联(CASCADE)操作。当删除或修改被参照表的一个元组造成了与参照表的不一致，则删除或修改参照表中的所有造成不一致的元组。级联操作必须在定义外码时给出显式定义。(3)设置为空值(SETNULL)。当删除或修改被参照表的一个元组时造成了不一致，则将参照表中的所有造成不一致的元组的对应属性设置为空值。(4)置空值删除(NULLIFIES)。删除被参照关系的元组，并将参照关系中相应元组的外码值置空值。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.4用户自定义完整性

用户自定义完整性就是针对某一具体应用的数据必须满足的语义要求，由RDBMS提供，而不必由应用程序承担。5.4.1属性上的约束条件

在CREATETABLE中定义属性的同时可以根据应用要求，定义属性上的约束条件，即属性值限制。当往表中插入或修改属性值时，系统检查是否满足约束条件，如果不满足，则拒绝相应的操作。属性上的约束主要包括：列值非空(NOTNULL短语)列值唯一(UNIQUE短语)设置默认值(DEFAULT短语)检查列值是否满足一个布尔表达式(CHECK短语)5.4.1属性上的约束条件[例5-4]规定Student表的姓名属性不能取空值。CREATETABLEStudent(SnoCHAR(7)PRIMARYKEY,SnameCHAR(8)NOTNULL,SsexCHAR(2),SageSMALLINT,SdeptCHAR(20));1.不允许取空值NOTNULL约束指定在某一列上用户不能输入空值。5.4.1属性上的约束条件[例5-5]规定Student表的姓名和性别两个属性的组合不能取重复值。CREATETABLEStudent(SnoCHAR(7)PRIMARYKEY,SnameCHAR(8),SsexCHAR(2),SageSMALLINT,SdeptCHAR(20),UNIQUE(SnameSsex));2.唯一值约束UNIQUE约束指定一列的值不能于该表另一行数据在该列上的值相同。5.4.1属性上的约束条件[例5-6]规定Student表的年龄默认值是18，不允许为空值。CREATETABLEStudent(SnoCHAR(7)PRIMARYKEY,SnameCHAR(8),SsexCHAR(2),SageSMALLINTDEFAULT18NOTNULL,SdeptCHAR(20),UNIQUE(SnameSsex));3.设置默认值

DEFAULT指定一列的默认取值。5.4.1属性上的约束条件[例5-7]Student表的Ssex只允许取“男”或“女”。CREATETABLEStudent(SnoCHAR(7)PRIMARYKEY,SnameCHAR(8),SsexCHAR(2)CHECK(SsexIN(‘男’，’女’)),

SageSMALLINTDEFAULT18NOTNULL,SdeptCHAR(20),UNIQUE(SnameSsex));当往表中插入元组或修改属性的值时，RDBMS就检查属性上的约束条件是否被满足，如果不满足则操作被拒绝执行。4.检查列值是否满足某个表达式CHECK约束可以对一个属性的值加以限制，只允许满足条件的值输入。5.4.2元组上的约束条件

[例5-8]在学生表Student中定义，当学生的性别是男时，其姓名不能以张开头。CREATETABLEStudent(SnoCHAR(7)PRIMARYKEY,SnameCHAR(8),SsexCHAR(2)CHECK(SsexIN(‘男’,’女’)),

SageSMALLINT,SdeptCHAR(20),CHECK(Ssex=’男’ANDSnameNOTLIKE‘张%’)

);元组上的约束可以设置不同属性之间的取值的相互约束条件，它也是用短语CHECK引出的约束。插入元组或修改属性的值时，RDBMS检查元组上的约束条件是否被满足，如果不满足则操作被拒绝执行。5.4.3域约束

DBMS提供了一些标准的数据类型(域)，用户可以使用它们说明属性类型。域的定义允许用户定义新的域，声明一个域包括下面几个方面：(1)域值类型。包括数据的类型、长度、单位、精度等，(2)缺省值。例如，可以规定Student表中的Sage属性的缺省值为20。(3)域值的格式。例如，可以规定日期的格式为：YYYY.MM.DD。(4)对取值范围或取值集合的约束。例如，可以规定性别域的取值集合为｛男，女｝，学生成绩域的取值范围为[0,100]。

域完整性是保证数据库字段取值的合理性。域完整性约束是最简单、最基本的约束。一个属性能否取空值由其语义决定。域约束使得新的值插入到数据库中时，系统可根据约束对新插入的值进行完整性检查。另外，域约束的恰当定义还可以对查询进行检测，从而保证比较是有意义的。5.4.3域约束1.创建域CREATEDOMAIN<域名>[AS]<数据类型>[DEFAULT<缺省值>][<域约束>,…,<域约束>];

该语句创建了一个名为<域名>的域，它的值类型由“AS<数据类型>”说明。可选的DEFAULT子句定义缺省值，“缺省值”必须是域中的一个合法值(满足域约束)。

注意：每个域都包含一个特殊值NULL(空值)，但是可以通过域约束排除空值。

域定义中可以包含零个或多个(域约束)，用来约束域值的取值。每个<域约束>具有如下形式：

[CONSTRAINT<约束名>]CHECK(<条件>)[<约束性质>];可选短语“CONSTRAINT<约束名>”为约束命名。<条件>的常见形式是涉及域值的布尔表达式，其中域值用VALUE表示。可选的“<约束性质>”可以是NOTDEFERRABLE(不可延迟的)或DEFERRABLE(可延迟的)，缺省时为不可延迟(约束立即检查)。5.4.3域约束[例5-9]对Student表的属性Sage创建域约束，设置其域名为SSage，数据类型为INT，默认值为20，取值范围为18~22。CREATEDOMAINSSageASINTCONSTRAINTAgeCHECK(VALUEBETWEEN18AND22);5.4.3域约束2.修改域约束

域约束可以进行修改，包括设置缺省值、删除缺省值、添加约束和删除约束。

ALTERDOMAIN<域名><修改动作>;其中<修改动作>可以是：(1)SETDEFAULT<缺省值>。设置缺省值。(2)DROPDEFAULT。删除缺省值。(3)ADD<域约束>。添加域约束，其中<域约束>与CREATEDOMAIN相同。(4)DROPCONSTRAINT<约束名>。删除<约束名>命名的域约束。[例5-10]

修改上例中的域SSage，取消其缺省值。ALTERDOMAINSSageDROPDEFAULT;5.4.3域约束3.删除域

当不需要某个域约束时，可以使用DROPDOMAIN语句将它删除。语句格式为DROPBOMAIN<域名>[CASCADE|RESTRICT];其中CASCADE表示级联删除，RESTRICT表示受限删除。声明RESTRICT时，如果存在基于该域定义的列，则不能删除。然而，声明CASCADE时，与删除模式和删除基本表不同，域删除后并不删除依赖于该域定义的列，而是将列定义(包括类型、缺省值、约束)用定义域的标准类型取代。[例5-11]级联删除域SSage。DROPBOMAIN

SSageCASCADE;5.4.4断言约束

断言约束方法使用一种约束定义语言来定义显式约束，是一种形式化方法。约束定义语言通常是关系演算语言的变种。

显式约束的断言定义方法是把约束集合和完整性验证子系统严格分开。约束集合存储在约束库中，完整性验证子系统则存取相应约束库中的约束，然后将其应用到相应的数据库更新事务中。

在显式约束的断言定义方法中，完整性约束被称为完整性断言或断言，完整性约束定义语言又被称为断言定义语言。

断言定义方法已经应用于关系数据库系统，其语法格式为：

CREATEASSERTION<断言名>CHECK<谓词>;5.4.4断言约束[例5-12]定义一个断言ASSER_c，要求每门课程最多50名学生选修。CREATASSERTIONASSER_c CHECK(50>=ALL(SELECTCOUNT(SC.Sno)FROMS,SC WHERES.sno=SC.snoGROUPBYCno));使用断言定义方法后，数据库管理系统需要提供一个完整性控制子系统。完整性控制子系统负责编译完整性断言，并将其存入数据库管理系统的约束库。当一个事务执行更新数据库的操作时，完整性控制子系统自动从约束库中读取相应的完整性断言，验证该事务是否违背完整性断言以确保数据库的完整性。这种方法简化了数据库更新事务的编写，程序员不再需要考虑如何在事务中编写完整性验证代码，而且完整性约束发生变化时，相应的事务代码不需任何修改，但是这一技术实现复杂，系统开销也很大。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.5完整性约束的修改

为了可以灵活地增加、删除一个完整性约束条件，为此SQL还为CREATETABLE语句中提供了完整性约束条件命名子句CONSTRAINT，用来对完整性约束条件命名。5.5.1完整性约束命名

CONSTRAINT<完整性约束条件名>[PRIMARYKEY短语|FOREIGNKEY短语|CHECK短语][例5-13]将Student表的码约束条件命名为StudentKey。CREATETABLEStudent(SnoCHAR(7),SnameCHAR(8)NOTNULL,SsexCHAR(2),SageSMALLINT,SdeptCHAR(20),CONSTRAINTStudentKeyPRIMARYKEY(Sno));5.5.1完整性约束命名[例5-14]建立教师表Teacher，要求姓名不能取空值，年龄小于55岁，性别只能是“男”或“女”。每个教师的实发工资不低于3000元，实发工资实际上就是应发工资列Sal与扣除项Deduct之差。CREATETABLETeacher(TnoNUMERIC(4)PRIMARYKEY,TnameCHAR(10),CONSTRAINTC1NOTNULL,Tage

NUMERIC(3),CONSTRAINTC2CHECK(Tage

<

55),TsexCHAR(2),CONSTRAINTC3CHECK(TsexIN(‘男’,’女’)),JobCHAR(8),SalNUMERIC(7,2),DeductNUMERIC(7,2),CONSTRAINTC4CHECK(Sal-Deduct

>=

3000));5.5.2修改完整性约束

我们可以使用ALTERTABLE语句修改表中的完整性限制，通过关键字ADD来增加一个完整性约束条件，或使用关键字DROP来删除原有的约束条件。[例5-15]增加表Student中Ssex只能取‘男’和‘女’的约束。ALTERTABLEStudentADDCONSTRAINTGenderCHECK(SsexIN(‘男’,’女’));[例5-16]去掉表Teacher中对性别的限制。

ALTERTABLETeacherDROPCONSTRAINTC3;[例5-17]修改表Teacher中的约束条件，年龄小于55岁改成小于60。ALTERTABLETeacherDROPCONSTRAINTC2;ALTERTABLETeacherADDCONSTRAINTC5CHECK(Tage<60);主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.6触发器

触发器主要有以下优点：触发器是自动的，在对表的数据作了修改之后立即被激活。触发器可以实现数据库中相关表的级联修改。触发器能实现比CHECK语句更为复杂的约束。触发器能提供数据库修改前后数据变化的前后状态。触发器能维护非规范化数据。非规范化数据是指在表中派生的、冗余的数据值。维护非规范化数据保证了数据库中低级数据的完整性。触发器(Trigger)是用户定义在关系表上的一类由事件驱动的特殊过程，其特殊性在于它不需要由用户调用执行，而是在用户对表中的数据进行UPDATE、INSERT或DELETE操作时自动触发执行的。也是一种保证数据完整性的方法。5.6.1定义触发器SQL使用CREATETRIGGER命令建立触发器，其一般格式为CREATETRIGGER<触发器名>｛BEFORE|AFTER|INSTEADOF｝<触发事件>ON<表名>

FOREACH{ROW|STATEMENT}[WHEN<触发条件>]<触发动作体>;

触发器名在数据库中必须是唯一的。

ON子句用于指定在其上执行触发器的表名或者是视图名。

AFTER：在触发事件完成之后，测试WHEN条件是否满足，若满足则执行动作部分的操作。

BEFORE：在触发事件进行以前，测试WHEN条件是否满足。若满足则先执行动作部分的操作，然后再执行触发事件的操作。5.6.1定义触发器

INSTEADOF：在触发事件发生时，只要满足WHEN条件，就执行动作部分的操作，而触发事件的操作不再执行。

INSERT、DELETE和UPDATE是触发事件，若同时有两个以上触发事件，则各操作之间用逗号分隔。

元组级(行级)触发器带有“FOREACHROW”子句，表示对每一个修改的元组都要检查一次。语句级触发器不带有“FOREACHROW”子句，只检查一次SQL语句执行的结果。

触发动作体既可以是匿名PL/SQL过程块，也可以是对已建立存储过程的调用。如果是行级触发器，在两种情况下，用户都可以在过程体中使用NEW和OLD引用UPDATE/INSERT事件之后的新值和UPDATE/DELETE事件之前的旧值。如果是语句级触发器，则不能在触发动作体中使用NEW和OLD进行引用。如果触发动作体执行失败，激活触发器的事件就会终止执行，触发器的目标表或触发器可能影响的其它对象不发生任何变化。5.6.1定义触发器创建触发器时，我们还需要注意以下几点：(1)在一个表上可以建立多个名称不同、类型各异的触发器，每个触发器可由INSERT、DELETE和UPDATE三个操作来引发。对于AFTER型的触发器，可以在同一种操作上建立多个触发器；对于INSTEADOF型的触发器，在同一种操作上只能建立一个触发器。(2)大部分SQL语句都可用在触发器中，但也有一些限制。例如，所有的创建和更改数据库以及数据库对象的语句、所有的DROP语句都不允许在触发器中使用。(3)在触发器中可以使用两个特殊的临时表：INSERTED和DELETED表，这两个表的结构同建立触发器的表的结构完全相同，而且这两个临时表只能用在触发器代码中。INSERTED表保存了INSERT操作插入的数据和UPDATE操作中更新后的数据。DELETED保存了DELETE操作中被删除的数据和UPDATE操作中更新前的数据。在触发器中对这两个临时表的使用方法同一般基本表一样，可以通过这两个临时表记录的数据来判断所进行的操作是否符合约束。5.6.1定义触发器[例5-18]定义一个BEFORE行级触发器，为教师表Teacher定义完整性规则“教授的工资不得低于3500元，如果低于3500元，自动改成3500元”。CREATETRIGGERT1/*在教师表Teacher上定义触发器*/

BEFOREINSERTORUPDATEONTeacher/*触发事件是插入或更新操作*/

FOREACHROW/*这是行级触发器*/ASBEGIN/*定义触发动作体，这是一个PL/SQL过程块*/

IF(NEW.Job=’教授’)

AND(NEW.Sal<3500)THENNEW.Sal:=3500

/*因为是行级触发器，可在过程体中使用插入或更新操作后的新值*/ENDIF;END;/*触发动作体结束*/5.6.1定义触发器[例5-19]定义AFTER行级触发器，当教师表Teacher的工资发生变化后就自动在工资变化表Sal_log中增加一条相应记录。首先建立工资变化表Sal_log。CREATETABLESal_log(TnoNUMERIC(4)REFERENCESteacher(Tno)，SalNUMERIC(7,2),Usernamechar(10),DateTIMESTAMP);CREATETRIGGERInsert_Sal/*建立了一个触发器*/AFTERINSFRTONTeacher/*触发事件是INSERT*/FOREACHROWASBEGININSERTINTOSal_logVALUES(NEW.Tno,NEW.Sal,CURRENT_USER,CURRENT_TIMESTAMP);END;CREATETRIGGERUpdate_Sal/*建立了一个触发器*/AFTERUPDATEONTeacher/*触发事件是UPDATE*/FOREACHROWASBEGINIF

(NEW.Sal

<>

OLD.Sal)THENINSERTINTOSal_logVALUES(NEW.Tno,NEW.Sal,CURRENT_USER,CURRENT_TIMESTAMP);

ENDIF;END;5.6.2激活触发器

触发事件激活触发器，并由数据库服务器自动执行。在一个数据表上可以定义多个触发器，比如多个BEFORE触发器，多个AFTER触发器等。同一表上的多个触发器激活时遵循以下执行顺序：(1)执行该表上的BERORE触发器；(2)激活触发器的SQL语句；(3)执行该表上的AFTER触发器。

此外，对于同一个表上的多个BEFORE(AFTER)触发器，遵循“谁先创建谁先执行”的原则，即按照触发器创建的时间先后顺序执行。有些RDBMS是按照触发器名称的字母排序顺序来执行触发器的。5.6.2激活触发器[例5-20]执行修改某个教师工资的SQL语句，激活上述定义的触发器。

UPDATETeacherSETSal=800WHRERTname=’陈平’;执行顺序：(1)执行触发器T1；(2)执行SQL语句“UPDATETeacherSETSal=800WHRERTname=’陈平’;”；(3)执行触发器Insert_Sal；(4)执行触发器Update_Sal。5.6.3删除触发器删除触发器的SQL语法如下：

DROPTRIGGER<触发器名>ON<表名>；

这里的触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。[例5-21]删除教师表Teacher上的触发器Update_Sal。

DROPTRIGGERUpdate_SalONTeacher；

注意：原则上并不限制一张表上定义的触发器的数量，但由于触发器是自动执行的，因此，如果为一张表建立了多个触发器，必然会加大系统的开销。另外，如果触发器设计的不好，会带来不可预知的后果。所以触发器常常用于维护复杂的完整性约束，一般的约束限制最好是使用检查约束CHECK来实现。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.7安全性概述安全性问题不是数据库系统所独有的，所有计算机系统都有这个问题。只是数据库系统作为一种特殊的应用系统，存放了大量数据，而且为许多最终用户直接共享，从而使安全性问题更为突出。数据库的安全性和计算机系统的安全性，包括操作系统、网络系统的安全性是紧密联系、相互支持的，因此我们结合计算机系统的安全性问题讨论数据库系统的安全性。5.7.1数据库安全性的保护范围

数据库的安全性不是孤立的，需要在几个层面上采取安全性措施。数据库的安全性控制整体结构如图5-3所示。5.7.2数据库安全保护的任务和措施对数据库不合法的使用，称为数据库的滥用。数据库的滥用分为无意和恶意两类。无意的滥用主要指以下情况：(1)在事务处理时发生系统故障。(2)并发访问数据库时引起的异常现象。(3)数据的分布式处理引起的异常现象。(4)违反数据完整性规则约束的逻辑错误。恶意的滥用主要指以下形式：(1)读取数据(窃取信息)(2)修改数据。(3)删除数据。5.7.2数据库安全保护的任务和措施数据库的安全性旨在保证数据库的任何部分不受恶意侵害或的存取和修改，即主要防止对数据库的恶意滥用。完全杜绝数据库的恶意滥用是不可能的，但是可以使那些企图在没有适当授权情况下访问数据库的代价足够高，阻止绝大多数这样的访问企图。数据库管理员(DBA)的重要责任之一是保证数据库的安全性，保护数据库涉及以下几个任务。(1)防止对数据的未经过授权的存取，确保敏感信息没有被不“需要知道”这些信息的人访问得到。(2)防止未经过授权的人员删除和修改数据。(3)监视对数据的访问和更改等使用情况。5.7.2数据库安全保护的任务和措施

数据库系统的安全保护措施是否有效是数据库系统主要的性能指标之一。如图5-3所示，当前数据库系统采用的安全性控制方法主要有以下几种：用户标识和鉴别、身份认证、存取控制策略、视图机制、数据加密和审计跟踪。数据库系统的安全机制如图5-4所示。主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.8DBMS中的安全性保护数据库安全保护目标是确保只有授权用户才能访问数据库，而所有未被授权的人员则无法接近数据。通常，安全措施是指计算机系统中用户直接或通过应用程序访问数据库所要经过的安全认证过程。在一般计算系统中，安全措施是一级一级层层设置的，可以有如图5-5所示计算机系统的安全模型。与DBMS有关的安全控制技术：用户标识和鉴别、存取控制和审计跟踪。5.8.1用户标识和鉴别用户标识与鉴别是系统提供的最外层安全保护措施。其基本方法是：系统提供一定的方式让用户标识自己的名字或身份，每次用户要求进入系统(与数据库连接)时，由系统核对用户提供的身份标识，通过鉴别的用户才拥有机器的使用权。对于获得上机权的用户若要使用数据库时数据库管理系统还要进一步进行用户标识和鉴别。常用的方法有：(1)用户标识和口令(2)标识方式(3)利用用户的物理特征鉴别用户5.8.2存取控制

数据库安全性所关心的主要是DBMS的存取控制机制。数据库安全最重要的一点就是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，这主要通过数据库系统的存取控制机制实现。

存取控制有两种——自主存取控制和强制存取控制。两者之间的区别是：在自主存取控制(DiscretionaryAccessControl,DAC)中，同一用户对于不同的数据对象具有不同的权限，但是哪些用户对哪些数据对象具有哪些存取权限并无固定限制。在强制存取控制(MandatoryAccessControl,MAC)中，每一个数据对象被标以一定的密级，每一个用户也被授予某一许可证级别。只有具有一定许可证级别的用户才能访问具有一定密级的数据对象。这种授权状态一般情况下不能改变。自主存取控制比较灵活，DBMS提供对它的支持；而强制存取控制比较严格，只有那些“安全的”DBMS才提供对它的支持。5.8.2存取控制(1)自主存取控制

自主存取控制是一种基于存取矩阵的存取控制模型。此模型由3种元素组成，即主体、客体和存取操作，它们构成一个矩阵，列表示主体，行表示客体，矩阵中的元素表示存取控制操作，如读(R)、写(W)、删除(D)和修改(U)操作，如图5-6所示。主体1主体2……主体n客体1RW……R客体2DR/W……D/R…………………………客体mRU……R/W主体是指数据库的访问者，包括用户、进程和线程等。客体是指数据库中的数据和载体，如基本表、视图、存储过程和数据文件等。在自主存取控制中，主体按存取矩阵的要求访问客体，存取矩阵中的元素可以通过授权方式进行修改，如UNIX操作系统属于该方式。由于主体可以自主地变更某些操作权限，因此有可能会给数据库系统带来不安全因素。5.8.2存取控制(2)强制存取控制

强制存取控制不是用户能直接感知或进行控制的。它适用于对数据有严格而固定密级分类的部门，如军事部门或政府部门。对于主体和客体，DBMS为每个实例(值)指派了一个敏感度标记(label)。敏感度标记被分成若干级别，例如绝密(TopSecret)、机密(Secret)、可信(Confidential)和公开(Public)等。主体的敏感度标记称为许可证级别(ClearanceLevel)，客体的敏感度标记称为密级(ClassificationLevel)。MAC机制通过对比主体和客体的敏感度标记，最终确定主体是否能够存取客体。5.8.3审计跟踪

审计是一种监视措施，它把用户对数据的所有操作自动记录下来，存放在一个特殊文件中，即审计日志。审计日志一般包括下列内容：(1)操作类型(如查询、修改、删除等)。(2)操作终端标识与操作人员标识。(3)操作日期和时间。(4)操作的数据对象(如表、视图、记录、元组、属性等)。(5)数据修改前后的值。

利用审计日志中的信息，可以重现导致数据库现有状况的一系列事件，以进一步找出非法存取数据的人、时间和内容等。5.8.3审计跟踪审计功能也不是十全十美的，也存在以下缺陷：(1)审计通常很耗费时间和空间，在现实应用中实际意义不大。所以，很多DBMS只是将其作为一种可选功能。(2)审计能够探测到的违规操作类型是有限的，因为它基于假设：违规操作总是可以通过分析异常行为的审计记录探测到。因此，审计功能一般用于安全性要求较高的部门。审计一般可以分为用户级审计和系统级审计。用户级审计是任何用户可设置的审计，主要是用户针对自己创建的数据库表或视图进行审计，记录所有用户对这些表或视图的一切成功(或)不成功的访问要求以及各种类型的SQL操作。5.8.3审计跟踪

系统级审计只能由DBA设置，用以检测成功或失败的登录要求、检测授予权限和回收权限的操作。AUDIT语句用来设置审计功能，NOAUDIT语句取消审计功能。[例5-22]对修改Student表结构或修改Student表数据的操作进行审计。

AUDITALTER,UPDATEONStudent;[例5-23]取消对Student表的一切审计。

NOAUDITALTER,UPDATEONStudent;主要内容5.1完整性概述5.3参照完整性5.4用户自定义完整性5.2实体完整性5.5完整性约束的修改5.6触发器5.8DBMS中的安全性保护5.9SQL中的安全性机制5.7安全性概述5.10其它安全机制5.9SQL中的安全性机制 SQL中提供了三种安全机制，分别是：授权(authorization)机制、视图(view)机制和角色(role)机制。5.9.1授权机制 SQL支持受控的存取保护，即在自主存取控制中，用户对于不同的数据对象有不同的存取权限，不同的用户对同一对象也有不同的权限，而且用户还可将其拥有的存取权限转授给其它用户。 SQL通过GRANT和REVOKE语句实现自主存取控制。GRANT语句向用户授予权限，REVOKE语句收回授予的权限。5.9.1授权机制1.GRANTGRANT语句的一般格式为

GRANT<权限>[，<权限>]…

ON<对象类型><对象名>[，<对象类型><对象名>]…

TO<用户>[，<用户>]…

[WITHGRANTOPTION]其语义为：将指定操作对象的指定操作权限授予指定的用户。发出该GRANT语句的可以是DBA，也可以是该数据库对象创建者(既属主Owner)，也可以是已经拥有该权限的用户。接受权限的用户可以是一个或多个具体用户，也可以是PUBLIC，即全体用户。包含可选语句WITHGRANTOPTION时，获得授权的用户还可以把自己拥有的权限或其子集传递授予给其它用户，但不允许循环授予，即被授权者不能把权限再授回给授权者或其祖先。5.9.1授权机制[例5-24]把查询Course表的权限授予所有用户。

GRANTSELECTONCourseTOPUBLIC;[例5-25]把对Student表和Course表的全部操作权限授予给用户U1和U2。GRANTALLPRIVILEGESONTABLEStudent,CourseTOU1,U2;上例中U1和U2不能传播他们获得的权限。若允许他们传播得到的权限，可以用GRANTALLPRIVILEGESONTABLEStudent,CourseTOU1,U2WITHGRANTOPTION;

执行此SQL语句后，U1和U2可以把自己拥有的权限或其子集传递授予给其它用户。例如U1可以把对Student的插入权限授予给U3：

GRANTINSERTONTABLEStudentTOU3;[例5-26]把查询Student表和修改学生学号的权限授给用户U3。

GRANTUPDATE(Sno),SELECTONTABLEStudentTOU3;

这里实际上要授予U3用户的是对基本表Student的SELECT权限和对属性列Sno的UPDATE权限。对属性列的授权时必须明确指出相应的属性列名。5.9.1授权机制2.REVOKE

授予的权限可以由DBA或其它授权者用REVOKE语句收回，REVOKE语句的一般格式为：

REVOKE<权限>[,<权限>]…

ON<对象类型><对象名>[，<对象类型><对象名>]…

FROM<用户>[，<用户>]…[CASCADE|RESTRICT];[例5-27]收回所有用户对Course表的查询权限。 REVOKESELECT(Sno) ONTABLEStudent;[例5-28]收回用户U3修改学生学号的查询权限。

REVOKEUPDATE(Sno)ONTABLEStudentFROMU3;5.9.1授权机制[例5-29]收回用户U1对Student表的所有操作权限。REVOKEALLPRIVILEGESONTABLEStudentFROMU1CASCADE;

收回用户U1对Student的操作权限时必须级联(CASCADE)收回，不然系统将拒绝(RESTRICT)执行该命令。因为在[例5-25]中，U1把对Student的插入权限授予给了U3。

注：此处的缺省值为RESTRICT，有的DBMS缺省值为CASCADE，会自动执行级联操作而不必明显地写出CASCADE。如果U3还从其它用户处获得对Student表的INSERT权限，则他仍具有此权限，系统只收回直接或间接从U1处获得的权限。5.9.1授权机制3.创建数据库模式的权限

GRANT和REVOKE语句向用户授予或收回对数据的操作权限。对数据库模式的授权则由DBA在创建用户时实现。创建用户语句CREATEUSER的格式如下。

CREATEUSER<username>[WITH][DBA|RESOURCE|CONNECT];只有系统的超级用户才有权创建一个新的数据库用户。新创建的数据库用户有3种权限：CONNECT、RESOURCE和DBA。如果没有指定创建的新用户的权限，默认该用户拥有CONNECT权限。拥有CONNECT权限的用户不能创建新用户、模式和基本表，只能登录数据库。然后由DBA或其它用户给他授予应有的权限。拥有RESOURCE权限的用户可以创建基本表和视图，并成为所创建对象的属主；但不能创建模式和新用户。数据库对象的属主可以使用GRANT语句把该对象上的存取权限授予给其它用户。拥有DBA权限的用户是系统中的超级用户，可以创建新用户、模式、基本表和视图等；DBA拥有对所有数据库对象的存取权限，还可以将这些权限授予给一般用户。5.9.2视图机制

利用视图机制实现安全保护的基本思想是：首先通过定义视图，屏蔽掉一部分需要对某些用户保密的数据；然后，在视图上定义存取权限，将对视图的访问权授予这个用户，而不允许他们直接访问定义视图的关系(基本表)。

由于视图是用查询定义的，而查询是求满足某个谓词(查询条件)的元组集，因此视图与授权配合使用实际上间接地实现支持存取谓词的用户权限定义。[例5-30]建立2012001班学生信息的视图，把对该视图的SELECT权限授予给张行老师，把该视图上的所有操作权限授予周丽。CREATEVIEWV_Student/*先建立视图V_Student*/ASSELECT*FROMStudentWHEREClass=’2012001’;GRANTSELECTONV_StudentTO张行;GRANTALLPRIVILEGESONV_StudentTO周丽;5.9.3角色机制

数据库角色是指被命名的一组与数据库操作相关的权限。角色是权限的集合，可以为一组具有相同权限的用户创建一个角色，角色简化了授权操作。

使用角色进行授权必须先创建角色，将数据库对象上的存取权限授予角色，才能将角色授予用户，使得用户拥有角色所具有的所有存取权限。此外，SQL还允许收回赋予角色的存取权，收回授予用户的角色。SQL中，对角色的创建、授权、转授和收回语句的语法如下。(1)角色的创建

CREATEROLE<角色名>

该语句创建一个角色，用<角色名>命名。可以像对用户授权那样，使用GRANT对角色进行授权。(2)给角色授权

GRANT<权限>[,<权限>]…

ON<对象类型>对象名

TO<角色>[,<角色>]…5.9.3角色机制(3)将一个角色授予其它的角色或用户

GRANT<角色1>[,<角色2>]…

TO<角色3>[,<用户1>]…

[WITHADMINOPTION]该语句把角色授予某用户，或授予另一个角色。这样，一个角色(例如角色3)所拥有的权限就是授予它的全部权限(例如角色1和角色2)所包含的权限和总和。授予者或者是角色的创建者，或者拥有在这个角色上的ADMINOPTION。如果指定了WITHADMINOPTION子句，则获得某种权限的角色或用户还可以把这种权限授予其它的角色。一个角色包含的权限包括直接授予这个角色的全部权限加上其他角色授予这个角色的全部权限。5.9.3角色机制(4)角色权限的收回

REVOKE<权限>[,<权限>]…

ON<对象类型><对象名>

FROM<角色>[,<角色>]…用户可以收回角色的权限，从而修改角色拥有的权限。REVOKE动作的执行者或者是角色的创建者，或者拥有在这个(些)角色上的ADMINOPTION。[例5-31]通过角色实现将一组权限授予一个用户。①创建一个