《设计数据完整性》ppt课件

《《设计数据完整性》ppt课件》由会员分享，可在线阅读，更多相关《《设计数据完整性》ppt课件（35页珍藏版）》请在金锄头文库上搜索。

1、第 6 讲 设计数据完整性,大型数据库应用（SQL Server 2008）,本讲要点,关系数据库设计概述,设计数据完整性,数据库表的规范化,1,2,3,1 美 Rob, P. Coonel, C. 数据库系统 设计、实现与管理（第5版）. 陈立军 等译. 电子工业出版社，2004.3 2 美 Ramakrishnan, R. Gehrke, J. 数据库管理系统原理与设计（第3版）. 周立柱 等译. 北京：清华大学出版社，2004.3,本讲参考书目,DBMS (DataBase Management System) 从产生直至发展到现在, 出现了多种类型. 按 其数据模型来分，主要有层次数据

2、库、网状数 据库和关系数据库. 前两者在二十世纪六七十 年代较为流行，然而他们表示数据之间的联系 太过于复杂，现在已经很少使用，只是在讲解 数据库的时候才有所提及. 关系数据库以关系的数学理论为基础，是 数据库技术的一项重大突破.,一. 关系数据库设计概述,关系数据库简单严谨，四十多年来有了长 足发展，现在已经成为事实上的标准，当今几 乎所有的数据库产品都是基于关系数据库的. 数据库设计是数据库应用的一个关键因素, 设计结构合理、功能齐全的数据库对于提高数 据库应用程序的开发效率和程序的性能都是非 常重要的. 数据库设计是指对于一个给定的应用环境, 构造最优的数据模式，建立数据库，使其能够 有

3、效地存储数据记录，并能满足各种应用需求.,数据库设计,对于一个数据密集型应用来说，数据库设 计是它的一个核心部分，但对于大型的软件系 统设计来说, 它只是其中一个部分. 数据库设计的过程可以分为 6 步. (1) 需求分析 (2) 概念数据库设计 (3) 逻辑数据库设计 (4) 模式的细化 (5) 物理数据库设计 (6) 应用与安全设计,进行数据库规划是所有数据库编程的第一步, 也是最重要的一步. 首先，列出客户所关心的所有数据和建立这 个数据库的主要目的. 这可以通过收集各种相关 的数据报表和表格来完成. 需求分析是数据库设 计的第一阶段，不断的调查与研究，了解组织机 构的情况，了解部门的业

4、务流程等系统需求，对 于设计好数据库是非常重要的. 然后，数据表规划是整个数据库设计中技巧 性最强的一个步骤. 数据表要满足第三范式.,数据库规划,规划数据库有以下三条基本原则： 数据库中的记录个数应该反映现实世界 对象的个数. 如果一个对象的实例在现实世界中 存在，则在数据库中有且只有一条记录存在. 每行记录的字段应该表达现实世界对象 的属性. 现实世界对象之间的关系应该反映在数 据库记录之间的关系上.,数据库规划基本原则,关系数据库的目的是建立现实世界的模型. 基于这一点, 用来实施数据完整性的规则和方法 无论对于理论和数据库开发的实践都很重要. 数据完整性是指存储在数据库中的数据的正 确

5、性和相容性. 设计数据完整性的目的是为了确保数据的质 量. 即防止数据库中存在不符合语义的数据, 防 止错误信息的输入和输出.,二. 设计数据完整性,数据完整性可以分为四类： 实体完整性 每个实体都保持惟一性. 值域完整性 如何限制向表中输入值的范围. 参照完整性 处理数据时维护表之间数据的一致性. 用户定义的完整性 体现实际运用的业务规则.,数据完整性分类,实体完整性把数据表中的每行看作一个实体, 且具有唯一标识. 即每一个实体都必须拥有一个 主键或者其他的惟一标识列. 要求：所有的主键项都是唯一的，并且主键 的任何部分都不能为空. 目的：保证每个实体有惟一的标识，确保外 键值可以正确地引用

6、主键值. 例子：发货单没有重复的号码，号码也不能 为空.,实体完整性,哈尔滨师范大学恒星学院,在 SQL Server 中， 可以通过建立 Primary Key 约束、Unique 约束、唯一索 引，以及列 Identity 属性等措施来实施实体 完整性.,实体完整性的实现,大型数据库应用（SQL Server 2008）,域完整性要求数据表中指定列的数据具 有正确的数据类型、格式和有效的数据范围. 域完整性通过默认值、Foreign Key、 Check 等约束，以及默认、规则等数据库对 象来实现.,域完整性,参照完整性维持被参照表和参照表之间的 数据一致性. 在 SQL Server 中

7、，参照完整性通 过建立 Foreign Key 约束来实施. 要求：外键可能是空-只要它不是它自己 所在表的主键的一部分 - 每个非null外键值必 须参照已经存在的主键值. 主键值被其他表所参 照时，该行不能被删除，也不允许改变. 目的：不能有无效的项. 例子：客户可以没有给定的代理商号码， 但是不能有无效的代理商号码.,参照完整性,SQL Server提供的用来实施数据完整性的 方法主要是: 数据类型 ( data type ) 约束 ( constraint ) 标识列 ( identity column) 默认值 ( default ) 索引 ( index ) 规则 ( rule )

8、 触发器 ( trigger ) 存储过程 ( stored procedure ),约束完整性是指数据的正确性和完备性. 在用 INSERT、 DELETE、 UPDATE 语句修改数据库 内容时，数据的完整性可能会遭到破坏， 有如下 几种情况： - 无效的数据被添加到数据库中，如某订单 所指的产品不存在. - 对数据库的修改不一致， 如为某产品增加 了订单，但却没有调整产品的库存信息. - 将存在的数据修改为无效的数据.,约束,在 SQL Server 中实现数据完整性的主要方法就是约束. 使用这种方法简单且不容易出错， 它把完整性的要求定义在表和列上. 约束由 SQL Server 强制

9、实行，它能够限制用户存放到表中的数据的格式和范围. 约束是在CREATE TABLE、ALTER TABLE 语句中，通过 CONSTRAINT 和 DEFAULT实现. 同时，约束独立于表的结构，可以在不改变表结 构的情况下，使用 ALTER TABLE 语句来添加或 删除.,约束,数据库设计的挑战：相冲突的目标 数据库设计者必须对互相冲突的目标进行平 衡：遵守设计标准，处理速度和信息约束. (1) 数据库设计必须符合一定的标准. 以使得 数据冗余最小, 数据不一致降到最低. (2) 在很多时候, 数据库设计最优先考虑的目 标是高的处理速度. 这可能要求对单表内的数据 进行合并, 另一方面,

10、 为达到一定的设计标准, 设 计者可能已经倾向于将数据保存在不同的表中.,数据库设计的挑战,(3) 对实时信息的追求可能成为数据库设计的 焦点. 复杂信息约束可能需要数据变换, 从而在 设计时会增加实体和属性的数量. 因此, 数据库 可能不得不牺牲一些它的”干净的” 设计结构和高的处理速度, 以保证生成最多的信息. 设计要满足所有这些合理要求和设计惯例, 是一个重要的目标. 然而, 如果这些完美的设计 不能满足顾客的事务处理速度或信息约束要求, 那么从终端用户眼中看来, 该设计者的工作做得 并不正确.,数据库设计的挑战,即使我们集中精力于实体、属性、联系和约 束, 我们也应该首先考虑终端用户的

11、要求, 比如 性能、安全、共享访问、数据完整性等. 设计者 必须考虑处理要求并保证所有的更新、检索和删 除选项都是可用的. 最后除非最终的产品可以成 功地完成所有指定的查询和报表约束, 否则设计 就几乎没有价值. 文档工作是保证数据相容性和一致性工作中 的一个十分重要的部分.,数据库设计的挑战,表是存储数据的主要对象, 设计数据库的关键 是设计表结构. 本节我们将学习如何评价和设计好的数据库 表，控制数据冗余，从而避免数据异常，这就是 规范化. 为了识别和鉴赏好的表结构的特性，考察一 个不好的表结构是很有用的. 利用这种方法，我 们将学会如何设计好的表结构，如何修改已有的 不好的表结构.,三.

12、 数据库表的规范化,通过规范化不仅可以消除数据异常，而且适 当规范化的表结构实际上要比没有规范化的来得 简单，它还能反映出一个组织的实际运行情况. 拥有好的关系数据库软件，并不足以避免 数据冗余. 即使在一个好的数据库设计中, 也有 可能生成不好的表结构.,规范化,那么，如何识别不好的表结构，如何创建 好的表结构呢？两个问题的答案都是基于规范 化的. 规范化是给实体分配属性的过程. 它能 够减少但不能够消除数据冗余；相反，它通过 生成有控制的冗余来连接数据库表.,规范化,规范化通过一系列称为范式的阶段来完成. 最前面的三个阶段分别叫做第一范式 (1NF)、 第二范式 (2NF)和第三范式 (3

13、NF). 从结构化 的观点来看，2NF 比 1NF 好，3NF 比 2NF 好. 对于大多数的事物数据库设计，我们只要能规 范到 3NF 就已经足够了. 虽然规范化是数据库设计的一个重要组成 部分，但是并不是规范化级别越高越好. 通常, 范式级别越高，产生制定输出所要求的连接就 越多，系统对终端用户请求的响应就越慢.,三种范式,我们考察某建筑公司的一个简单数据库行 为. 该公司管理几个建筑项目，每个项目都有 它自己的项目号、项目名、员工等属性，每个 员工有员工号、姓名和职位级别等属性. 公司根据每个合同需要花费的小时数来向 客户收费. 每小时的报酬由员工的职位决定. 该应用周期性地生成信息报表

14、. 由这个报 表对应地生成一个表.,一个实例,这个表的结构不符合完整性的要求，它也 没有很好的处理数据. 项目号（PROJ_NUM）很明显是希望 作为一个主键，或者至少是主键的一部分，但 是它包含空值. 表的数据输入引起数据的不一致. 如， Elect.Engineer 可能写成Elect.Eng, El.Eng,EE. 该表中有数据冗余，会产生异常： 更新异常: 如修改105号的 JOB_CLASS. 插入异常，删除异常. 当把某员工分配到某项目时,重复输入数据.,一个实例, 消除组重复 在作为主键的列中加入合适的项即可. 主键应能恰当地、惟一地确定任何属性 值. 取主键为 PROJ_NUM

15、 和 EMP_NUM 的 组合. 这样得到了符合第一范式的表.,确定主键,属性关系图,术语 1NF 描述了如下的表格式： 定义了所有的键属性. 表中没有重复组. 所有的属性都依赖于主键. 所有的关系表都属于 1NF. 上图所示的第 一范式的表结构的问题是它包含部分依赖, 也 就是说，基于部分主键的依赖. 虽然有时为了提高性能需要使用部分依赖, 但要谨慎使用. 因为这样的表仍有数据冗余(由 每行记录都要求有数据副本而产生), 重复输入 使效率很低，也会助长数据异常的产生.,第一范式,一个表属于第二范式是指： 它属于 1NF . 它不包含部分依赖，即，没有属性只依 赖于主键的一部分. 到第二范式的

16、转换是，将原表分为三个表: PROJCT ( PROJ_NUM, PROJ_NAME ) EMPLOYEE ( EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR ) ASSIGN ( PROJ_NUM, EMP_NUM, ASSIGN_HOUR),第二范式,将三个表再分出一个表，消除传递依赖: EMPLOYEE ( EMP_NUM, EMP_NAME, JOB_CLASS ) JOB ( JOB_CLASS, CHG_HOUR ) 表属于第三范式是指： 它属于 2NF . 它不包含传递依赖. 消除了表结构中的部分依赖和传递依赖后, 还要集中改善数据库提供信息和增强关系特性.,第三范式,练习