完整性 Flashcards
数据库的完整性概念与数据库的安全性概念之间存在什么区别和联系
数据库的完整性和安全性是两个不同的概念,但是它们存在一定的联系。
数据的完整性是为了防止数据库中存在不符合语义的数据,也就是防止数据库中存在不正确的数据,防止错误信息的输入和输出所造成的无效操作和错误结果。数据的安全性是保护数据库防止恶意的破坏和非法的存取。
完整性检查和控制的防范对象是不合语义的、不正确的数据,防止它们进入数据库。安全性控制的防范对象是非法用户和非法操作,防止他们对数据库的非法存取。
数据库的完整性
数据的正确性和相容性。
为维护数据库的完整性,DBMS必须能够
(RDBMS的完整性控制机制应具有哪些功能)
1。定义功能,即提供定义完整性约束条件的机制。
2。检查功能,即检查用户所发出的操作请求是否违背完整性约束条件。
3。违约处理,如果发现用户的操作请求使数据违背了完整性约束条件,则采取一定的措施来保证数据库的完整性。
完整性约束条件
也称为完整性规则,是数据库中的数据必须满足的语义约束条件。
SQL标准使用了一系列概念来描述完整性
包括关系模型的实体完整性、参照完整性和用户定义完整性。这些完整性一般由SQL的DDL语句来实现。它们作为数据库模式的一部分存入数据字典中。
完整性检查
DBMS中检查数据是否满足完整性约束条件的机制。
一般在INSERT、UPDATE、DELETE语句执行后开始检查,也可以在事务提交时检查。检查这些操作执行后数据库中的数据是否违背了完整性约束条件。
违约处理
DBMS若发现用户的操作违背了完整性约束条件,就采取一定的动作,如拒绝(NO ACTION)执行该操作,进行违约处理以保证数据的完整性。
完整性控制
目前商用的DBMS产品都支持完整性控制。即完整性定义和检查控制由DBMS实现,不必由应用程序来完成,从而减轻了应用程序员的负担。更重要的是使得完整性控制成为DBMS核心支持的功能,从而能够为所有的用户和所有的应用提供一致的数据库完整性。因为由应用程序来实现完整性控制是有漏洞的。有的应用程序定义的完整性约束条件可能被其他应用程序破坏。数据库数据的正确性仍然无法保障。
实体完整性
在CREATE TABLE中用PRIMARY KEY定义。
对单属性构成的码有两种说明方法,一种是定义为列级约束条件,另一种是定义为表级约束条件。对多属性构成的码只有一种说明方法,即定义为表级约束条件。
实体完整性检查和违约处理
用PRIMARY KEY短语定义了关系的主码后,每当用户程序对基本表插入一条记录或者对主码列进行更新操作时,RDBMS将按照实体完整性规则自动进行检查。包括:
1。检查主码值是否唯一,如果不唯一则拒绝插入或修改。
2。检查主码的各个属性是否为空,只要有一个为空就拒绝插入或修改。
从而保证了实体完整性。
检查记录中主码值是否唯一的方法
1。全表扫描。依次判断表中每一条记录的主码值与将插入记录上的主码值(或者修改的新主码值)是否相同。
2。全表扫描是十分耗时的。为了避免对基本表进行全表扫描,RDBMS核心一般都在主码上自动建立一个索引,如B+树索引。通过索引查找基本表中是否已经存在新的主码值,将大大提高效率。
参照完整性
在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码,用REFERENCES短语指明这些外码参照哪些表的主码。
参照完整性检查和违约处理
(RDBMS在实现参照完整性时需考虑哪些内容)
一个参照完整性将两个表中相应元组联系起来了。因此,对被参照表和参照表进行增删改操作时有可能破坏参照完整性,必须进行检查。
被参照表 参照表 违约处理
可能破坏参照完整性 插入元组 拒绝
可能破坏参照完整性 修改外码值 拒绝
删除元组 可能破坏参照完整性 拒绝/级联删除/设置为空值
修改主码值 可能破坏参照完整性 拒绝/级联修改/设置为空值
违约处理的策略
1。拒绝(NO ACTION)执行。不允许该操作执行。该策略一般设置为默认策略。
2。级联(CASCADE)操作。当删除或修改被参照表的一个元组造成了与参照表的不一致,则删除或修改参照表中的所有造成不一致的元组。
3。设置为空值。当删除或修改被参照表的一个元组时造成了不一致,则将参照表中的所有造成不一致的元组的对应属性设置为空值。
一般地,当对参照表和被参照表的操作违反了参照完整性,系统选用默认策略,即拒绝执行。如果想让系统采用其他的策略必须在创建表的时候显式地加以说明。
可以对DELETE和UPDATE采用不同的策略。
外码能否接受空值的问题
RDBMS在实现参照完整性时,除了要定义主码、外码的机制外,还应该定义外码列是否允许空值,还需要提供不同的策略供用户选择。选择哪种策略,要根据应用环境的要求确定。