计算机 数据库原理课件
文档属性
| 名称 | 计算机 数据库原理课件 |  | |
| 格式 | rar | ||
| 文件大小 | 116.1KB | ||
| 资源类型 | 教案 | ||
| 版本资源 | 通用版 | ||
| 科目 | 信息技术（信息科技） | ||
| 更新时间 | 2008-05-13 16:34:00 | ||
图片预览
文档简介
(共255张PPT)
数据库原理与应用
第一章 绪论
数据库是数据管理的工具。数据管理经历了从手工管理阶段、文件管理阶段到数据库管理阶段的变迁。
1.1 数据库系统概述
1.1.1 数据、数据库、数据库管理系统、数据库系统
一、数据库(Data Base)
——存放数据的仓库（顾名思义/不准确的含义）
——信息的载体/表示
尽管数据库技术已发展成熟，但还没有一个普遍接受的、严格的定义。
数据库应具备的特征/定义：
（1）数据库是相互关联的数据的集合
数据库中的数据不是孤立的，数据与数据之间是相互关联的，在数据库中不仅要能够表示数据本身，还要能够表示数据与数据之间的联系。
如：学籍管理——学生、课程两类数据。
（2）用综合的方法组织数据
顺序、索引、聚簇Cluster
1.1.1 数据、数据库、数据库管理系统、数据库系统
例：人事部门有一个职工文件：
职工基本情况
有关人事管理的数据
教育部门也有一个职工文件：
职工基本情况
有关教育培训的数据
其中，“职工基本情况”重复存储，浪费空间。可共享存 储类似这样的共同数据，以降低数据的冗余度。
（3）具有较小的数据冗余，可供多个用户共享
低冗余与数据共享：在数据库技术之前，数据文件都是独立的，任何数据文件都必须含有满足某一应用的全部数据。
1.1.1 数据、数据库、数据库管理系统、数据库系统
（4）具有较高的数据独立性
数据独立性：（包括物理独立性、逻辑独立性。具体见萨师煊等主编《数据库系统概论》Page11）
指数据的组织和存储方法与应用程序互不依赖，彼此独立的特性。可降低应用程序的开发代价和维护代价。
1.1.1 数据、数据库、数据库管理系统、数据库系统
在数据库技术之前，数据文件的组织方式和应用程序是密切相关的。数据结构改变，相应的应用程序也必须随之修改==〉开发/维护代价
1.1.1 数据、数据库、数据库管理系统、数据库系统
（5）具有安全控制机制，能够保证数据的安全、可靠 数据库要有一套安全机制，以便有效地防止数据库中的数据被非法使用/修改；
数据库还要有一套备份/恢复机制，以保证当数据遭到破坏时将数据立刻完全恢复==〉继续、可靠地运行。
（6）允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和完整性
一致性：数据库中的数据是共享的，并且允许多个用户同时使用相同的数据。这就要求数据库能够协议一致，保证各个用户之间对数据的操作不发生矛盾和冲突。
正确性、完整性：
保证数据正确的特性——数据完整性
可通过建立一些约束条件保证数据库中的数据是正确的。
如：学生年龄20 （2或100则错误）
1.1.1 数据、数据库、数据库管理系统、数据库系统
二、数据库管理系统（DataBase Management System ，DBMS）
上节提到的数据库的功能/特性不是数据库中的数据固有的，是靠管理或支持数据库的系统软件——DBMS——提供的。
DBMS任务：
·对数据资源进行管理，使之能为多个用户共享。
·保证数据的安全性/可靠性/完整性/一致性/独立性
1.1.1 数据、数据库、数据库管理系统、数据库系统
1.1.1 数据、数据库、数据库管理系统、数据库系统
2． 数据库操纵功能
完成对数据库中数据的操作：插入、删除、修改；
重新组织数据库的存储结构；
完成对数据库的备份/恢复等.
DBMS功能：
1． 数据库定义功能
定义数据库结构和存储结构；
定义数据库中数据之间的联系；
定义数据完整性约束条件和保证完整性的触发机制等.
3．数据库查询功能
以各种方式提供灵活的查询功能，以便方便使用数据.
4． 数据库控制功能
完成对数据库的安全性控制/完整性控制/并发控制
5． 数据库通信功能
在分布式数据库或提供网络操作功能的数据库中还必须提供通信功能。
1.1.1 数据、数据库、数据库管理系统、数据库系统
三、数据库系统和数据库管理员
1．数据库系统 (DataBase System，DBS)
——基于数据库的计算机应用系统，包括：
·以数据为主体的数据库
·管理数据库的系统软件DBMS
·支持数据库系统的计算机硬件环境和操作系统环境
·管理和使用数据库系统的人，特别是DBA
·方便使用和管理系统的技术说明书和使用说明书
1.1.1 数据、数据库、数据库管理系统、数据库系统
1.1.1 数据、数据库、数据库管理系统、数据库系统
2．数据库管理和数据库管理员 (DataBase Administrator，DBA)
——从事数据库管理工作的人员，负责数据库的全面管理工作（维护、设计）
数据库的使用会改变企事业单位的管理方式，但因为要把众多部门或用户的数据放在同一数据库中，会带来一些问题，如：数据冲突；越权使用数据；重要数据丢失……
因此需要管理部门：负责和数据管理有关的工作。
1.1.1 数据、数据库、数据库管理系统、数据库系统
注: DBA工作繁重、重要、关键：
除了要掌握一定的数据处理、数据库技术之外，还应有处理好人际关系的素质、能力。在一个企事业中，特别是一个规模较大的数据库，不能指望一两个人来完成管理工作，所以DBA常指数据库管理部门。
开发DBS时，一开始就应设置DBA的职位或相应的机构，以明确DBA职责、权限。
数据处理是计算机应用领域中最大的一类应用
用计算机实现数据管理经历了三个发展阶段：
1． 人工管理阶段
数据库管理的初级阶段。
在50年代中期以前，计算机采用的是批处理方式，主要用于科学计算。（具体见萨师煊等主编《数据库系统概论》Page6）
1.1.2 数据管理技术的产生和发展
2． 文件系统阶段（50年代后期——60年代中期）
特点：
·计算机技术有了很大的发展，开始广泛应用于信息处理
·存储设备有了磁盘、磁鼓等可直接存取的设备
·计算机有了操作系统，包括文件管理系统，用户可将数
据组织成文件体交给系统进行自动管理。
·数据可长期保存在磁盘等存储设备上
·程序和数据有了一定的独立性，且文件有多种形式的组
织结构：顺序、链接、索引、直接
1.1.2 数据管理技术的产生和发展
缺点：
（1）数据冗余较大
∵每个文件都是为特定的用途设计的，
∴同样数据在多个文件中重复存储
进能提供以文件为单位的数据共享。
（2）程序和数据之间的独立性较差
应用程序依赖于文件的存储结构，修改文件存储结构就要修改程序
1.1.2 数据管理技术的产生和发展
（3）对数据的表示和处理能力较差
文件的结构和操作比较单一，不够丰富。
（4）数据不一致
由（1）造成，更新时会造成同一数据在不同文件 中的不一致。
（5）数据联系弱
文件与文件之间是独立的，文件之间的联系必须通 过程序来构造。
尽管如此，文件系统在数据管理技术的发展中仍起 着很重要的作用。
1.1.2 数据管理技术的产生和发展
1.1.2 数据管理技术的产生和发展
3.数据库系统阶段
从60年代后期开始，计算机用于信息处理的规模越来越大，对数据管理的技术提出了更高的要求，此时开始提出计算机网络系统和分布式系统，出现了大容量的磁盘，文件系统已不再能胜任多用户环境下的数据共享和处理。一个新的数据库管理技术——DBMS由此而形成，它对所有用户数据实行统一的、集中的管理、操作和维护。
特点：（具体见萨师煊等主编《数据库系统概论》Page9-13）
按照数据模型的进展情况，数据库系统的发展可划分为三代：
第一代：层次数据库系统和网状数据库系统
主要支持层次和网状数据模型
第二代：关系数据库系统
支持关系数据模型，该模型有严格的理论基础， 概念简单、清晰，易于用户理解和使用。因此一 经提出便迅速发展，成为实力性最强的产品。
1.1.2 数据管理技术的产生和发展
第三代：新一代数据库系统——面向对象数据库系统
基于扩展的关系数据模型或面向对象数据模型的尚未 完全成熟的一代数据库系统 。
特点：支持包括数据、对象和知识的管理
在保持和继承第二代技术的基础上引进新技术(如OO)
对其他系统开放，具有良好的可移植性、可连结性、
可扩充性、互操作性。
1.1.2 数据管理技术的产生和发展
1.2 数据模型
模型——对客观事物、现象、过程或系统的简化描述
所有的数据库系统都为它所要描述的世界建立了模型：
数据建模：描述了组织数据的框架结构。
如：楼房住户-数据；房间规格-数据模型
———数据建模最后发展成为数据的存储方式（数据字典 中的定义）
业务功能建模：用户的最终需求。
——业务功能建模最后发展成为应用程序
产生高效的应用程序的前提是良好的数据模型。（正如10 平米的房间无法成为会议厅一样，一个糟糕的数据模型也无法产生高质量的应用。
1.2 数据模型
为什么要建立数据模型（Data Model）：
象盖大楼的设计图一样，DM可使所有的
项目参与者都有一个共同的数据标准
避免出现问题再解决（边干便改的方式）
可及早发现问题
加快应用开发速度
1.2.1 数据模型的三要素
1．数据结构
——描述数据的静态特征，包括对数据结构和数据 建联系的描述。
通常按照数据结构的类型来命名数据模型：
层次结构——层次模型
网状结构——网状模型
关系结构——关系模型
2．数据操作
——描述数据的动态特征：一组定义在数据上的操作（ 包括操作的含义、操作符、运算规则及其语言等）
主要操作：检索与更新（插入、删除、修改）
1.2.1 数据模型的三要素
3．3. 数据的约束条件
——完整性规则的集合，数据库中的数据必须满足
这组规则。
约束条件的主要目的是使数据库与它所描述的现实系
统相符合。
设计时：时数据模型正确、真实、有效地反映现实
运行时：保证数据库中的数据值真实地体现现实世 界的状态
1.2.2常见数据模型
根据数据模型应用目的不同，数据模型有以下几种：
● 概念（数据）模型（Conceptual Data Model）
———面向现实世界建模
———主要用来描述现实世界的概念化结构，与具 体的DBMS无关；
- 现实世界的事物经过人脑的抽象加工，提取出对用
户有用的信息，经过组织整理加工形成结余现实世
界和计算机世界之间的中间模型；
- CDM只关心现实世界中的事物、事务特征、联系，
完全没有与具体及其相关的任何概念；
1.2.2常见数据模型
CDM是系统分析员、程序设计员、维护人员、用户
之间相互理解的共同语言；
- CDM能时数据库的设计人员在设计的初始阶段摆脱
计算机系统及DBMS的具体技术问题，集中精力分析
数据、数据之间的联系；
- 概念模型必须转换成逻辑模型，才能在DBMS中实
现；
- 最常用的概念模型是E-R模型
1.2.2常见数据模型
● 逻辑（数据）模型（Logical Data Model）
——面向用户建模
—— 用户从数据库所看到的数据模型；
- 是具体的DBMS所支持的数据模型（网状/层次
/关系/面向对象）；
- 既要面向用户，也要面向系统；
- LDM表示数据建联系的方法
- 一般的DBMS支持一种LDM（特殊的DBMS支
持多种LDM）
1.2.2常见数据模型
● 物理（数据）模型（Physical Data Model）
——面向具体的DBMS，面向机器
——描述数据在存储介质上的组织结构
- PDM不仅与具体的DBMS有关，还与操作系统 和硬件有关
- 每一种逻辑模型在实现时都有其对应的物理模型
- PDM加入了概念模型中为考虑的因素：触发器、 存储过程、主键、外键、索引等
- DBMS为保证其独立性和可以执行，大部分PDM 的实现工作由系统自动完成，而设计者只设计索 引、聚簇等特殊结构
1.2.3概念模型
实体-联系（Entity-Relationship）概念模型
首先介绍E-R模型中常用的几个重要概念，利用它们可
构造出现实世界的数据的抽象描述。
1．实体、实体型、实体集
● 实体（Entity）
——客观存在并能相互区分的事物
如：人；数据库课程；正是用的计算机；一 场足球赛不能严格地定义实体，正如几何中“ 点”，“线”一样。
关键之处：一个实体能和别的实体区分开。
1.2.3概念模型
● 实体型（Entity Type）
——用实体名及属性名集合来抽象刻画同类实体
● 实体集（Entity Set）
——同型的实体组成的集合。
2．属性（Attribute）
——指实体所具有的某一方面的特性，一个实体可 由若干个属性来刻划。
- 属性取值在一定的范围，称为该属性的值域/域 （Domain）
- 唯一标识实体的属性集称为码(Key)
1.2.3概念模型
3．联系（Relationship）
——实体集合间存在的相互关系
为了建立现实世界的完整模型，常常需要对联系 分
类，根据一个实体集合的实体可以和多少个另一类
实体集合的实体相联系，可将联系分为如下几种：
(1) 一对一联系（1：1） 系——系主任
(2) 一对多联系（1：n） 班级——学生
(3) 多对多联系（m：n） 课程——学生
1.2.3概念模型
举例1：（具体见萨师煊等主编《数据库系统概论》 Page17-18）
两个实体型之间的联系（图1.10）
三个实体型之间的联系（图1.11）
一个实体型之间的联系（图1.12）
举例2：（具体见萨师煊等主编《数据库系统概论》 Page19-20）图1.14、图1.15
1.2.3概念模型
4． 实体-联系图
（1） 确定所有实体集合
用矩形方框表示实体集合，方框内标明实体集合名 称；
（2） 选择实体集应包含的属性
用椭圆框表示属性，通过无向边连接到实体集。只 有一个属性的实体集可用属性代替，附加到它参加 的联系上；
（3） 确定实体集之间的联系
用菱形框表示，框内标明联系的名称，通过无向边 （或有向边）连接到参加联系的每个实体集合；
1.2.3概念模型
（ 4）确定实体集的关键字
用下划线在属性上标明关键字的属性集合；
（5） 确定联系的类型
在用无向边连接联系到实体集时，在边上注明1或 n（多）来知名联系的类型。（在用有向边连接 联系到实体集时，让边的箭头指向1的实体集的 一方，多对多因为都是多方，故无箭头）
1.2.4 三种主要的逻辑数据模型
上节讨论的概念数据模型是“概念上”的，是抽象的，它与具体的数据库管理系统无关。这节要讨论的数据模型将与具体的DBMS有关，与DBMS支持的数据和联系的表示或存储有关。
前面提到过，数据库中不仅要存放数据本身，还要存放数据间的联系，可用不同的方法表示数据与数据之间的联系。
把表示数据与数据之间联系的方法称为逻辑（数据）模型。
1.2.4 三种主要的逻辑数据模型
一、 层次模型（Hierarchical Model）
用树型结构来表示实体之间联系的模型。
支持层次模型的典型系统诞生于1970年前后，是IBM
公司的IMS（Information Management System）系统。
1. 层次模型的数据结构
层次模型示例（萨师煊等主编《数据库系统概论》
Page22 图1.17）
举例： Page23
1.2.4 三种主要的逻辑数据模型
2．层次模型的数据操纵与完整性约束
3．层次模型的存储结构
4．层次模型的优缺点
优点：结构简单
缺点：插入、删除限制多
1.2.4 三种主要的逻辑数据模型
二、网状模型（Network Model）
典型代表：DBTG（Data Base Task Group）数据
库任务组
1． 网状模型的数据结构
2． 网状模型的数据操纵与完整性约束
3． 网状模型的存储结构
4．网状模型的优缺点
优点：更能直接描述世界
缺点：结构复杂
1.2.4 三种主要的逻辑数据模型
三、 关系模型（Relational Model）
1970，IBM，E.F.Codd
关系模型源于数学，它把数据看成是二维表（关系） 中的元素。（其严格定义下一章给出）
用关系表示（不需用指针）实体和实体之间联系的模 型称为关系模型。
基本术语：萨师煊等主编《数据库系统概论》Page31
举例见教材
对于用户，关系方法应该是很简单的，但RDBMS很 复杂，因为将大量工作都转嫁给了RDBMS。
1.2.4 三种主要的逻辑数据模型
RDBMS的设想在层次、网状数据库诞生的同时产生的，但研制开发RDBMS却花费了比人们想象的要长得多的时间。所以成为商品并投入使用比层次、网状数据库晚了十几年。但一投入使用就显示了旺盛的活力，并逐步取代层次、网状数据库。
1.3 数据库系统的结构
1.3.1 数据库系统模式的概念
当设计数据库时，对数据库的结构感兴趣；
即模式（Schema）：数据库中数据的逻辑结 构和特征的描述
当应用数据库时，关心的是数据库中存在的数据——
实例（Instance）。
数据库中的数据经常变化，而数据库的结构在一定时
间范围内不会改变。
数据库中结构的定义可以在多个抽象级别进行，形成
多个级别的数据库模式。
1.3.2 数据库系统的三级模式结构
数据库系统的三级模式不仅可以使数据具有独立性，而且还可以使数据达到共享，使同一数据满足更多用户的不同要求。
一、 内模式（Internal Schema）
——存储模式
● 是数据在数据库系统的内部表示，即对数据的物 理结构/存储方式的描述，是低级描述，一般由 DBMS提供的语言或工具完成；
1.3.2 数据库系统的三级模式结构
● 要修改存储数据库的结构（例如，用倒排文件代替多
链表），那么仅仅需要把这些修改反映在存储模式中；
● 通常我们不关心内模式的具体技术实现，而是从一般组
织的观点（即概念模式）或用户的观点（外模式）来讨
论数据库的描述。但我们必须意识到基本的内模式和存
储数据库的存在。
1.3.2 数据库系统的三级模式结构
二、 模式（Schema）
——逻辑模式
● 是数据库中全体数据的逻辑结构和特性的描述， 是所有用户的公共数据视图；
● DBMS提供数据定义语言DDL来描述逻辑模式，严 格定义数据的名称、特征、相互关系、约束等。
1.3.2 数据库系统的三级模式结构
三、 外模式（External Schema）
——用户模式（视图）
● 是模式的子集或变形，是与某一应用有关的数据 的逻辑表示；
● 不同用户需求不同，看待数据的方式也可以不同 ，对数据保密的要求也可以不同，使用的程序设 计语言也可以不同，因此不同用户的外模式的描 述可以使不同的。
1.3.2 数据库系统的三级模式结构
举例：
民航售票系统包括处理航班程序和处理旅客程序。
- 程序的使用人员不必知道关于人事档案、丢失的行 李、飞行员的航行分配等信息；
- 调度员可能需要知道关于航班、飞机和人事档案等 信息（如那些飞行员有资格驾驶747），但不必知道雇员的工资、旅客等信息。
所以可以为订票部门建立一个数据库视图，为调度部门建立另一个完全不同的部门。
1.3.2 数据库系统的三级模式结构
Note：视图处理的数据并不实际存储在数据库中，而仅可以从逻辑数据库中构造出来。视图比（逻辑）模式的抽象级别更高。
举例：“年龄”在人事部门数据库中，但（逻辑）模式重金包含出生年月。当用户希望通过访问视图得到年龄时，DBMS翻译这个要求，在从物理数据库上取出的数据完成计算。
注：一个数据库只有一个模式，一个内模式，但可以有多个外模式。
1.3.3 数据库的二级映象
在三级模式中提供了两级映象，保证了数据库系统的数据独立 性，既物理独立性与逻辑独立性。
一、 外模式/模式映象
数据库系统投入使用后，可能有必要修改模式（如增加新关系、属性、改变类型），这时：
重新定义外模式/模式映象==〉现存外模式不变==〉应用程序不变
DBA职责
1.3.3 数据库的二级映象
二、 模式/内模式映象
当内模式发生变化时：
重新定义模式/内模式映象==〉模式保持不变==〉外模式保持不变==〉建立在外模式上的应用程序保持不变
1.5 数据库技术的研究领域
1. 数据库管理系统软件的开发
2．数据库设计
3．数据库理论
具体见萨师煊等主编《数据库系统概论》page39-40
第二章 关系数据库
1．关系操作
查询操作：选择/ 投影/ 连接/
除/ 并/ 交/ 差
2.1 关系模型概述
从数据模型的三要素加以介绍
一、数据结构
——关系
二、 关系操作
增加、删除、修改
2.1 关系模型概述
元组关系演算：谓词变元的基本对象是元组变量
域关系演算：谓词变元的基本对象是域变量
Note：关系代数和关系演算是抽象的查询语言，与具体的DBMS中实际语言不一样，但彼此等价，是从抽象的观点出发学习数据库查询的问题。
3．关系数据语言（具体见萨师煊等主编《数据库系统概论》page47）
2．关系操作的表示方法：
·关系代数：用对关系的运算表达查询要求
·关系演算：用谓词表达查询要求
2.1 关系模型概述
实体完整性
关系模型必须满足的完整性约束条件
参照完整性
三、关系的完整性约束条件
用户定义的完整性：针对某一具体数据库的约束条件
反映某一具体应用所设计的数据 必须满足的语义要求。
（关系系统自动支持）
2.2 关系数据结构及形式化定义
2.2.1 关系
一、 基本概念（具体见萨师煊等主编《数据库系统概论》page47-）
1． 域（Domain）
2． 笛卡尔积（Cartesian Product）
元组（Tuple）
3． 关系（Relation）
分量（Component）
候选码 Candidate Key
非码属性Non-key attribute
主码 Primark Key
全码 All-key
主属性Prime attribute
2.2 关系数据结构及形式化定义
二、关系的三种类型
基本关系（基本表）：实际存在的表，是实际存 储数据的逻辑表示
三、 关系的性质（6条，具体见萨师煊等主编《数据库系统概论》P50）
查询表：查询结果对应的表
视图表 ：由基本表或其它视图标导出的表，
虚表，不对应实际存储的数据
2.2.2 关系模式
值（Value）：是型的一个具体赋值
——关系是值
型（Type）：对某一类数据的结构和属性的说明
——关系模式是型（关系模式是对关 系的描述）
2.3 关系的完整性
（具体见萨师煊等主编《数据库系统概论》P52-55）
2.4 关系代数（Relational Algebra）
关系代数是对关系运算的总和，关系运算分两类:
2.4.1 传统的集合运算
——并／交／差／积（按行）
2.4.2 专门的关系运算
——选择/ 投影/ 连接/ 除（按行、列）
一、 几个记号和概念
１． 元组，分量
２． 属性列域，剩余属性组
３． 元组的连接
４． 象集
关系运算定义（具体见萨师煊等主编《数据库系统概论》P58-64）
第三章 关系数据库标准语言——SQL
关系代数和关系演算是形式化查询语言，商业DBMS使用SQL（Structured Query Language）。
·1974 年由IBM 的San Jose研究室提出，最初叫SEQUEL（Structured English Query Language）
·关系数据库系统通过SQL对数据库进行查询和更新
·目前有许多不同版本的SQL语言,有两个不同的主要标准:
ANSI(American National Standards Institute) 1986
ISO(International Standards Organization)：
SQL-89,SQL-92,SQL 2,正在制定SQL 3
3.1 SQL语言概貌及特点
一、SQL特点
1． 一体化
SQL是一种一体化的语言，它包括了数据定义、查询、 更新、控制四方面功能。
·可以完成数据库活动中的全部工作
·以前的非关系模型的数据语言一般包括：内模式描述语 言、模式描述语言、外模式描述语言、数据操纵语言等 。内容多，操作起来不像SQL那样简单。
3.1 SQL语言概貌及特点
2． 高度非过程化
没有必要一步步地告诉计算机“如何”去做，只需描述清楚用户要“做什么”，SQL就可以将要求交给系统，自动完成全部工作。
3． 面向集合的操作方式
操作对象、查询结果是元组的集合；
插入、删除、更新操作的对象也可以是元组的集合。
3.1 SQL语言概貌及特点
4． 两种使用形式，统一的语法结构
自含式：将SQL作为操作命令独立使用
现在许多数据库开发工具都将SQL直接融入到自身的语言中。
宿主式：将SQL嵌入到高级语言中使用
3.1 SQL语言概貌及特点
5． 语言简洁
SQL虽然功能强且使用两种方式，但只有为数不多的几条命令，另外语法也非常简单，接近自然语言，易掌握、学习。
除了以上特点之外，SQL语言还支持数据库的三级模式结构。（具体见萨师煊等主编《数据库系统概论》Page87）
3.1 SQL语言概貌及特点
二、SQL语言组成
SQL同一般的程序设计语言一样,由以下几个部分组成：
1． 常量：文本常量（字符串）、整型常量、数值常量
2． 数据类型：以IBM DB2 SQL为例，具体见萨师煊等主
编《数据库系统概论》P89
3． 空值：NULL
3.1 SQL语言概貌及特点
集合运算符：∩、∪、-
算术运算符：+，-，*，/
5 . 函数
SQL 提供了非常丰富的内部函数——聚集函数
（详见萨师煊等主编《数据库系统概论》P100）
4. 运算符
字符串运算符：|| （连接）
比较运算符：6个
逻辑运算符：NOT，AND，OR
3.1 SQL语言概貌及特点
6． 谓词
SQL为了具有强大的查询能力，提供了一系列的谓词：
· BETWEEN AND / NOT BETWEEN AND
介于两者之间 /介于两者之外
· IN / NOT IN 在其中/不在其中
· LIKE 匹配
· IS NULL / IS NOT NULL
· EXISTS/ NOT EXISTS 存在/不存在量词
· ANY 任意一个存在量词
· ALL 全程量词
3.1 SQL语言概貌及特点
7． 表达式
8． 条件
由一个或多个含有比较运算符的表达试及逻辑运算符组合而成。
命令（具体见萨师煊等主编《数据库系统概论》P86 表3.1）
3.2 数据定义
存储过程定义
基本表定义
定义功能
数据库的定义：和物理数据有关，以后介绍
视图定义
索引定义
规则定义
与数据完整性有关，以后介绍
3.2.1 定义、删除与修改基本表
(具体见萨师煊等主编《数据库系统概论》P88)
3.2.2 建立与删除索引
(具体见萨师煊等主编《数据库系统概论》P90)
在使用关系数据库系统时，用户所看到和操作的数据好像在简单的二维表中，而实际上数据在磁盘上是如何存储的用户可能不知道。然而数据的物理存储如何却使数据库主要性能的主要因素。
——索引时最常见的改善数据库性能的技术。
CREATE TABLE 〈表名〉（〈列名〉〈数据类型〉[列级完整性约束条件][，…]…[，表级完整性约束条件]
例：CREATE TABLE Student (Sno CHAR(5) NOT NULL UNIQUE,SNAME CHAR(20) UNIQUE,SSEX CHAR(1),SAGE INT,SDEPT CHAR(15));
修改基本表：
ALTER TABLE 〈表名〉[ADD〈新列名〉〈数据类型〉[完整性约束]]
[DROP〈完整性约束名〉]
ALTER 〈列名〉〈数据类型〉]；
例：向学生表增加“入学时间”—日期型
ALTER TABLE STUDENT ADD Scome date;
修改年龄为半字长整数
ALTER TABLE STUDENT ALTER SAGE SMALLINT
删除学生姓名必须取唯一值的约束。
DROP TABLE Student DROP UNIQUE Tag Sname
DROP TABLE <表名>
3.2.2 建立与删除索引
关于索引
· 索引的建立和删除由DBA或建表的人负责，用户不必也不能在存取数据是选择索引；
· 作为一般规则，不应该在一个表上建立太多的索引（2-3个）。索引能改善查询效果，但也耗费了磁盘空间。降低了更新操作的性能。因为系统必须花时间来维护这些索引；
·表中数据越多，索引的优越性才越明显。
3.3.1 单表查询
指定列
消除重复行
● 选择表中若干列
全部列
经计算的列
● 选择表中若干元组
查询满足条件的元组
● 对查询结果排序
● 对查询结果分组
3.3.2 连接查询
● 等值/非等值连接
● 自身连接
● 外连接
● 复合条件连接
3.3.3 嵌套查询
● 带有IN谓词的查询
● 带有比较运算符的查询
● 带有ANY或ALL谓词的子查询
● 带有EXISTS谓词的查询
3.3.4 集合查询
具体见萨师煊等主编《数据库系统概论》P114
3.3.5 SELECT 语句的一般格式
具体见萨师煊等主编《数据库系统概论》P 115
3.4 数据更新
插入、修改、删除数据（具体见萨师煊等主编《数据库
系统概论》P117）
一、插入数据
1． 插入单个元组
2． 插入子查询结果
3.4 数据更新
二、修改数据
1． 修改一个元组的值
2． 修改多个元组的值
3． 带子查询的修改语句
3.4 数据更新
三、删除数据
1．删除一个元组的值
2．删除多个元组的值
3．带子查询的删除语句
4．更新操作与数据库的一致性
3.5 视 图
一、关于视图：
· 视图是原始数据库数据的一种变换，是查看表中数据
的另外一种方式；
· 可将视图看成是一个移动的窗口，通过它可看到感兴
趣的数据；
· 视图可从一个或多个实际表中获得；
· 视图的定义存在数据库中，而数据并没再存一份在数
据库中，通过视图看到的数据存放在基本表中；
· 对视图的操作同其它表一样，通过视图修改数据时，
实际是修改基本表中的数据，相反，基本表数据的改
变也会自动反映在由基本表产生的视图中。
3.5 视 图
二、视图的作用
1． 简单性
——看到的就是用户需要的
不仅可简化用户对数据的理解，也可简化它们的操 作。经常使用的查询可以被定义为视图。
3.5 视 图
2． 安全性
通过视图用户只能查询和修改他们能见到的数据， 数据库其它数据则既看不到也取不到。
数据库授权命令可是用户对数据库的检索限制到特 定的数据库对象上，但不能授权到数据库特定的行 、列上。
视图可防止未授权用户查看特定的行/列
3． 逻辑数据独立性
3.5 视 图
一、 定义视图
具体见萨师煊等主编《数据库系统概论》P121-124
二、 查询视图
具体见萨师煊等主编《数据库系统概论》P125
三、 更新视图
具体见萨师煊等主编《数据库系统概论》P126
3.6 数据控制
SQL数据控制功能对数据库中数据的安全控制提供保护，主要表现在对数据使用的授权(GRANT)和收回授权(REVOKE)。
每个用户对自己拥有的资源可以由任意的操作权限，同时也可以把其中的一部分权限授予他人。
（具体见萨师煊等主编《数据库系统概论》P130）
3.6 数据控制
一、授权
3.6 数据控制
二、收回权限
注：授权(GRANT)和收回授权(REVOKE)并不是数据库的全部控制功能，只是其中的一小部分，其它功能如安全性、完整性、并发控制和恢复在7、8、9、10章介绍。
3.7 嵌入式SQL
前面几节介绍的SQL,，是作为独立的数据语言直接由用户在交互环境下使用的。此外，SQL还可以作为子语言嵌入在宿主语言（PASCAL、C等）中使用。
SQL作为子语言嵌入在宿主语言中使用必须要解决以下三方面问题：
1．嵌入识别问题
宿主语言的编译程序不能识别SQL语句，所以首要问题要解决如何区分宿主语言的语句和SQL语句。
3.7 嵌入式SQL
2． 宿主语言与SQL语言的数据通信问题
DBMS将SQL语句的查询结果或执行状态必须交给宿主语言/应用程序处理（通过SQLCA）；运行时，宿主语言的数据通过变量（称为主变量）也要能够交给SQL使用。
3． 宿主语言的单记录与SQL的多记录的问题
宿主语言一般一次处理一条记录；SQL语言常常处理的是记录（元组）的集合，其查询结果通常是含多个记录的一张表。——“阻抗不匹配”
本节将围绕如何解决这三个问题来介绍。
3.7 嵌入式SQL
一、 嵌入识别与预编译
解决方法：为SQL语句加一个特殊的前缀。
在用宿主语言的编译系统编译源程序之前，首先由预编译系统将SQL语句转换为宿主语言的合法函数调用。
3.7 嵌入式SQL
3.7 嵌入式SQL
一、 数据通信区与主变量
1．数据通信区SQLCA
——SQL Communication Area
在嵌入SQL语句的程序中，一般在程序的前部 都要有一条语句：
EXEC SQL INCLUDE SQLCA
这里SQLCA即是SQL与宿主语言的通信区，它 类似于结构变量，各个变量分别反映SQL语句 的各种执行状态。
3.7 嵌入式SQL
DBMS：数据库厂商标识
0：成功
例如：SQL Anywhere 中SQLCA有16个属性：
SQLCode (long): 存放执行SQL后返回的代码—
100：SELECT找不到符合条件的记录
-1：SQL操作错误
DataBase
Userid
DBPass
SQLErrText：错误代码
SQLDBCode：错误信息
…
…
3.7 嵌入式SQL
SQL被执行时，DBMS将产生的各类系统信息（如执行状态信息）写入系统通信区，应用程序在调用SQL后，可通过读取数据通信区中信息来确定语句执行情况。
应用通过SQLCA与数据库通信
应用
SQLCA
DBMS
连接参数
状态信息
3.7 嵌入式SQL
输出主变量：SQL对其赋值或设置状态信息，返回给应 用程序。
利用它可得到SQL语句的结果数据和状态。
输入主变量：由应用程序赋值，SQL引用。
可用于：插入数据、修改值、制定条件 （WHERE）
2． 主变量
SQL语句使用宿主语言的变量来输入/输出数据
主变量（Host Variable）
主变量根据作用不同分为：
3.7 嵌入式SQL
Note：所有变量要在
BEGIN DECLARE SECTION
…
END DECLARE SECTION
之间说明。
3.7 嵌入式SQL
三、 游标（Cursor）
当查询结果超过一个元组时，不能一次性将结果值赋给宿主语言的变量，因为主变量仅能保存一个数据，而不是一组数据。为此，引进一个特殊的数据结构——游标（Cursor）。
游标是系统为用户开设的一个数据缓冲区，存放SQL的执行结果。可将其理解为一个指示器，指向数据库中满足条件的元组。
游标包含两部分内容：
结果集：游标内SELECT语句执行后产生的集合；
游标位置：游标指针的当前位置。
3.7 嵌入式SQL
游标的定义和使用分为下面几步：
● 声明游标
不可执行的指令，仅定义游标，SELECT语句没有执行
（类似于变量说明）
● 打开游标
执行SELECT语句，将结果放入结果集中。
● 推进游标
移动指针，该变结果集的当前记录。
● 通过游标更新数据
● 关闭游标
程序实例（具体见萨师煊等主编《数据库系统概论》 P136-146）
第四章 关系系统及查询优化
具体见萨师煊等主编《数据库系统概论》P151-167
4.1.3 全关系系统的12条基本准则
4.1 关系系统
4.1.1 关系系统的定义
4.1.2 关系系统的分类
4.2 关系数据库系统的查询优化
4.2.1 关系系统及其查询优化
4.2.6 优化的一般步骤
4.2.5 关系代数表达式的优化算法
4.2.4 关系代数等价变换规则
4.2.3 查询优化的一般准则
4.2.2 一个实例
第五章 关系数据理论
数据库设计的一个最基本的问题是如何建立一个好的数据库模式。
即给出一组数据，如何构造一个适合于它们的数据模式，使数据库系统无论是在数据存储方面，还是在数据操纵方面都有较好的性能。
E-R模型方法讨论了实体与实体之间的数据联系，现在来讨论实体内部属性与属性之间的数据关联，目标是要设计一个“好”的数据库模型。
5.1 问题的提出
1．关系模型定义——复习
2．在解决如何设计一个好的数据库模式之前，先看一 看什么是“不好”的数据库设计（关系数据库模式可 能出现的异常）。
例：建立一个关系数据库来描述学生的一些情况， 该数据库只包含一个关系模式： 学生（学号，姓 名，系名，系主任，课程，成绩）
3. 例：具体见萨师煊等主编《数据库系统概论》P171 页
5.1 问题的提出
（1）存在的问题：
i. 数据冗余：姓名，系名，系==〉重复出现。
ii. 更新异常：某一元组修改系主任，其他不变==〉 同一系，系主任不同，造成了数据潜在的不一致 性。
iii. 插入异常：系刚成立，尚未招收学生，主关键字 为空，则系主任、选的课都无法存入数据库，未 选课的学生信息也无法存入。
删除异常：一个系的学生毕业了，删除这些学生的记录，则系主任等信息也删除掉了。
5.1 问题的提出
（2）产生异常的原因：
这些异常的产生主要是因为关系模式的结构，即关系模式中的属性之间存在过多的数据依赖关系，与现实世界不符合。
注：数据依赖关系——最重要的一类是函数依赖。
· 主关键字（学号+课程）一定，元组就确定了， 元组分量也就确定了，即所有其它属性都依赖于 “学号”和“课程”。
· 但实际：学号→姓名，不需选课。
系名→系主任。
5.1 问题的提出
（3）解决：
分解为三个新的关系模式：
学生（学号，姓名，系名）
成绩（学号，课程，成绩）
系（系名，系主任）
这样上面提到的问题不存在了，将学生、成绩和系三个相对独立的实体划分开来，使之更符合现实世界的实际。
5.2 规范化（Normalization）
5.2.1 函数依赖(Functional Dependency)
回顾：函数——熟悉的概念。
Y=f(x)：x和Y之间数量上的对应关系。给定x值，Y值
与之对应。称x函数决定Y，或Y函数依赖于x。
在关系数据库中讨论函数或函数依赖注重的是语义上
的关系。
如：省=f(城市)
5.2.1 函数依赖(Functional Dependency)
定义⒈ 函数依赖（具体见萨师煊等主编《数据库系统概论》172页）
说明：
· t1[x]=t2[x]==〉t1[r]=t2[r]成立，就有x→Y。
·只有当t1[x]=t2[x]为真，而t1[Y]=t2[Y]为假时 ，x→Y。
·当t1[x]=t2[x]为假时，不管t1[Y]=t2[Y]为T/F， 都有x→Y。
比如：当x为关键字属性时，t1[x]=t2[x]肯定为F ，但x→Y成立。
5.2.1 函数依赖(Functional Dependency)
术语和记号：
⑴．非平凡的函数依赖(Nontrivial Functional Dependency)
——通常讨论。
x→Y，但Y≤x(Y不包含于x),则x→Y称为非平凡 的函数依赖。
若Y≤x, 显然x→Y成立。（称为平凡的函数依赖 。Trivial Functional Dependency）
5.2.1 函数依赖(Functional Dependency)
⑵ 决定因素（Determinant）
若x→Y，则x称为决定因素（决定方）。
⑶ x→Y,Y→x则记作x←→Y。 如：学号←→姓名。
⑷ 若Y不函数依赖于x，记作x→Y。
5.2.1 函数依赖(Functional Dependency)
定义⒉ 完全函数依赖（Full Functional Dependency）：
若x→Y，并且对x的任何一个真子集x',都有x’→Y, 则称Y完全函数依赖x,记作x →Y.
部分函数依赖（Partial Functional Dependency）：
若x’→Y成立，则称Y部分函数依赖于x.记作x→Y 。（与书上定义比较）
例：5.1 模式中，（学号，课程）→系名
f
p
p
5.2.1 函数依赖(Functional Dependency)
定义⒊传递函数依赖（Transitive Functional Dependency）:
若x→Y，（非平凡函数依赖，且Y→x），Y→Z, 则称Z传递函数依赖于x。
∵若Y→x，则x←→Y，x—→Z。
直接
5.2.1 函数依赖(Functional Dependency)
例：·教室（课程，班级，时间，教室）——完全函数依赖
（课程，班级，时间）→教室
·教师（姓名，职务，职务工资）——传递函数依赖
姓名→职务
职务→职务工资 则姓名→职务工资
·前面例子： 三个新的学生关系模式中：——非平凡 函数依赖
学号→姓名
学号→系
系→系主任
（学号，课程）→成绩
f
5.2.2 码
现实世界的每一实体集合，都有一关键字（码），即唯一确定各个实体的一组属性。同样，关系上最重要的约束是关系的关键字约束，即关键字/码唯一确定关系的元组。
⒈ 候选码（Candidate Key）与主码（Primary Key）
⒉ 外部码（Foreign Key）
例： 学生选课（学号，课号，成绩）
F
学生（学号，姓名，年龄）
P
注：主码与外码（主关键字与外关键字）提供了一个表示关系间联系的手段。
5.2.3 范式
在关系数据模式设计中，为了避免由依赖引起的数据的冗余和更新异常问题，必须进行关系数据模式的规范化。
自1971年，E.F.Codd提出关系规范化理论以来，人们对规范化问题进行了长期的研究，并已经有了很大进展。
范式(Normal Form)的概念最早是由E.F.Codd提出的，1971～1972年，先后提出了1NF,2NF,3NF(根据关系模式满足的不同性质和规范化的程度划分)。1974年，又和Boyce共同提出了BCNF（Boyce-Codd Normal Form）。1976年，Fagin提出了4NF，后又有人提出5NF。最重要的是3NF和BCNF。这是进行规范化的主要目标。
5.2.3 范式
（具体见萨师煊等主编《数据库系统概论》P 174页，图5-2）
1. 第一范式（1NF）：
（具体见萨师煊等主编《数据库系统概论》P170）
——每个关系模式都应满足的最低要求。
即关系的所有分量都必须是不可分的最小数据项。
系名称 高级职称人数
教授 副教授
5.2.3 范式
2. 第二范式（2NF）：
（具体见萨师煊等主编《数据库系统概论》P174）
㈠ 定义：若R∈1NF，且每一非主属性完全函数依赖
于码，则R∈2NF。
· 所有单属性关键字都是2NF关系。
· 复合关键字（多属性构成），且存在非主属性
对关键字的部分依赖，则否。
5.2.3 范式
㈡ 反例：
例：库存（仓库号，设备号，数量，地点）
1NF，但非2NF。
非主属性数量完全依赖于关键字。
非主属性地点部分依赖于关键字。
即有仓库号→地点。
（仓库号，设备号）→地点。
p
5.2.3 范式
㈢ 出现的问题：
一个仓库若只有一种设备，则删除设备→删除仓库。
·学生关系：
学生（学号，姓名，系名）
不是2NF。
只有成绩完全函数依赖于码，姓名、系名、系 主任对码部分依赖，因为它们由学号可决定。
5.2.3 范式
㈣ 解决办法——投影分解
· 将部分函数依赖关系洪的决定方和非主属性从关系 模式中提出，单独构成一个关系模式。
· 将余下属性加上码（仍要保留部分函数依赖的决定 方属性，起分解出来的新关系之间的关联作用）构 成另一关系模式。
5.2.3 范式
例：⑴库存（仓库号，设备号，数量）
仓库（仓库号，地点）
⑵学生记录（学号，姓名，系名，系主任）
r(学生记录)=Π（学号，姓名，系名，系主任） （r’(学生)）
成绩（学号，课程，成绩）
r(成绩)=Π<学号，课程，成绩>（r’(学生)）
5.2.3 范式
1. 第三范式（3NF）：
㈠定义：（具体见萨师煊等主编《数据库系统概论》P176）
若R∈2NF，并且所有非主属性都不传递依赖于关键字，则R∈3NF。
·若存在非主属性对关键字的传递依赖，则不是3NF。
5.2.3 范式
㈡ 反例：
例：仓库（仓库号，所在省，仓库面积，所在城市）
仓库号→所在城市，所在城市→所在省。
∴仓库号→所在省。 ↓非3NF
㈢ 问题：插入异常：
如插入（“WH30”，“湖北”，400，“邯郸”）
（“WH22”，“河北”，240，“ ”）
再如：在山东济南要设一个仓库，想先存入有关所
在城市信息，但无仓库号，则不能。
5.2.3 范式
㈣ 解决——投影分解：（将传递依赖的属性分解出来
——自己总结的）
仓库（仓库号，仓库面积，所在城市）
城市（省，城市）
再例：
学生记录（学号，姓名，系，系主任）不是3NF
∵学号→系， 系→系主任， ∴学号→系主任
系主任对码（学号）的传递依赖。
分解：学生档案（学号，姓名，系名）
系（系名，系主任）
5.2.3 范式
4. BCNF范式：
由于3NF仍存在一些操作异常，......
㈠ 定义：（具体见萨师煊等主编《数据库系统概论》
P176）
——即若R中的每个函数依赖的左部都是关
键字/码（或所有的决定因素 都是关键字）
，则R∈BCNF。
5.2.3 范式
——或：若R∈3NF，并且不存在主属性对 非主属性的函数依赖，则R∈BCNF。
——一个满足BCNF的关系模式一定是非主属性对 码完全函数依赖;
主属性对不包含它的码也是完全函数依赖；
设有属性完全函数依赖于码以外的属性组。
5.2.3 范式
㈡ 举例及讨论：
例：⑴.管理（仓库号，设备号，职工号） 3NF，非
BCNF。
语义：①.一个仓库可有多个职工；
②.一名职工仅在一个仓库工作；
③.在每个仓库，一种设备仅由一名职工保管
（但每名职工可以保管多种设备）。
根据语义有依赖：职工号→仓库号；
（仓库号，设备号）→职工号；
问题：·新职工分到一仓库，尚未负责设备，则不能
插入。
·插入异常：同一设备，两个职工，无法防止
这样插入，与③违背。
5.2.3 范式
例：⑵.学生（学号，姓名，专业，宿舍）
·假定无重名，则码为学号或姓名，非主属性
对这两个码不存在部分函数依赖和传递函数
依赖，∴是3NF。
而同时除{学号}和{姓名}以外没有其他决定
因素，∴也是BCNF。
5.2.3 范式
例： ⑶.通讯（城市，街道，邮编）
↓完全依赖于码，且无传递依赖，∴是3NF。
·但邮编→城市，它是决定因素，它不是码，也不 包含在码中，∴非BCNF。
·非BCNF分解→BCNF，会破坏函数依赖。
Solution: 保持3NF，警惕主属性对非主属性的函数依赖带 来的操作异常现象。
5.2.3 范式
5. 多值依赖与第四范式：
㈠. 多值依赖(Multivalent Dependency):
定义5.9(具体见萨师煊等主编《数据库系统概论》
P178)
例：⑴(P178)
①增加一名教师，要插入多个（三个）元组；
②去掉一本参考书，要删除多个（两个）元组
∴数据冗余明显，增加、删除不方便，日积
月累可能出现数据错误 。
5.2.3 范式
原因：关系上存在着一种多值依赖。
·对于（物理，光学物理）有一组值{李勇，王
C Z Y
军}——T与之对应。
这组值决定于课程上的值，与参考书的值无关。
↓即另一个（物理，普通物理学）对应的一组
值仍为 T。
∴ T多值依赖于C，即 C→→T 。
5.2.3 范式
例：⑵P180
(W1,C1)有一组值{S1,S2}与之对应，与无关。
(W1,C2)有一组值{S1,S2}与之对应，与无关。
... ...
对W的每一个值Wi，S有一完整的集合与之对应,
而与C无关.
∴W→→S, 同样W→→C。
5.2.3 范式
㈡ 多值依赖的性质：
（具体见萨师煊等主编《数据库系统概论》P181）
· 对称性：若x→→Y，则x→→Z.
· 函数依赖是多值依赖的特例（即函数依赖的一定是
多值依赖），多值依赖是函数依赖的概括（即存在
多值依赖的关系，不一定存在函数依赖关系。）：
若x→Y，则x→→Y.
· 平凡的多值依赖：若x→→Y，而Z=φ时。
· 若x→→Y，Z≤（包含于）Y，W→Z，且Y∩W=φ
，则x→W。
Notes：关系模式中至少有三个属性，才有可能存在
多值依赖。
5.2.3 范式
㈢ 多值依赖与函数依赖的区别：
· x→Y的有效性仅决定于x,Y这两个属性集的值，即仅
在 ∏xY(R)上成立即可；
而x→→Y的有效性与属性集的范围有关，需在U(整个
属性集)上成立。 R(U)
· x→Y在R(U)上成立，则对于∨Y’＜Y，有x→Y’成立；
而x→→Y在R(U)上成立，不能判定对∨Y’＜Y，有
x→→Y’成立。
5.2.3 范式
㈣4NF：
定义（具体见萨师煊等主编《数据库系统概论》P181）
一个关系模式若属于4NF，则必然属于BCNF，反之不一定；4NF关系消除了BCNF关系中不理想之处，因此比BCNF先进。
· 函数依赖只考虑关系模式的静态逻辑结构。
而多值依赖受关系模式取值的动态变化的影响，即当
在关系模式中删除一些元组时，多值依赖关系可能被
破坏。
5.2.3 范式
关于函数依赖
函数依赖——通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。
一个函数依赖成立就意味着关系在任意时刻的实例都满足函数依赖的条件。
要确定函数依赖成立，需弄清楚数据的语义（语义：是实现世界的反映，不是主观臆断或仅由关系的当前实例所决定。）
5.2.3 范式
多值依赖：（至少三个属性，才有可能存在多值依赖）
例: Transport(Cname,Caddr,Item,Sname,Saddr)
Item→→(Cname,Caddr)
一种商品可以有多位顾客订购，与由哪些供 应商供应无关。
Item→→(Sname,Saddr)
5.2.3 范式
多值依赖与函数依赖的区别：
·X→Y的有效性仅决定于X,Y这两个属性集的值，即
仅在 ∏xY(R)上成立可；
而X→→Y的有效性与属性集的范围有关，需在U(整
个属性集)上成立。 R(U)
·X→Y在R(U)上成立，则对于所有Y中的Y’,有x→Y’
成立；
而X→→Y在R(U)上成立，不能判定对所有Y’＜Y,
有x→→Y’成立。
·函数依赖只考虑关系模式的静态逻辑结构；
而多值依赖受关系模式取值的动态变化的影响，即当在
关系模式中删除一些元组时，多值依赖关系可能被破坏.
5.3 数据依赖的公有系统
——Armstrong公理
※ Armstrong公理：模式分解算法的理论基础。
已知R满足一组函数依赖F，如何知道R中还有哪些FD(函数依赖)？或由F还能推导出哪些FD？
——需要一套形式化的推理规则。
5.3 数据依赖的公有系统
一．Armstrong公理的内容及正确性。
（具体见萨师煊等主编《数据库系统概论》P183）
★ R(U,F)，X≤u，Y≤U，Z≤U。推导规则如下：
① 自反律（Reflexivity）：
若Y≤X，则x→Y。（平凡FD）
② 增广律（Augmentation）：
若X→Y，则x∪Z→Y∪Z。记为：XZ→YZ。
③传递律（Transitivity）：
若x→Y，Y→Z，则x→Z。
5.3 数据依赖的公有系统
★ 正确性：
·增广：若①t[XZ]=S[XZ]，则t[x]=S[x]， t[Z]=S[Z]；
②又由x→Y，有t[Y]=S[Y]；
由①和②得：t[YZ]=S[YZ]。
· 传递：s[x]=t[x]
↓x→Y
推出：s[Y]=t[Y]
↓Y→Z
推出：s[Z]=t[Z]。
5.3 数据依赖的公有系统
二．Armstrong公理的推论：(P184)
· 合并规则：若X→Y，X→Z，则X→YZ。
· 分解规则：若X→Y，Z≤Y，则X→Z。
·伪传递规则：若x→Y，YW→Z，XW→Z。
① ∵X→Y，X→Z（增广）；
∴X→XY，XY→YZ（传递）；
∴X→YZ。
② ∵x→Y，YW→Z（增广）；
∴xW→YW（传递）；
∴xW→Z。
5.3 数据依赖的公有系统
根据合并规则和分解规则得到结论：
引理1：（具体见萨师煊等主编《数据库系统概论》
P184）
x→A1A2A3...An←→ X→Ak成立（k=1,2,...n）
5.3 数据依赖的公有系统
三．逻辑蕴涵和闭包：
有时需要根据给定的一组函数依赖来判断另一些 FD是否成立，这是函数依赖逻辑蕴涵要研究的内 容。
例如：R(U,F),U{A,B,C},F={A→B,B→C}，问 A→C成立？
根据传递律∴A→C成立
这时说F逻辑蕴涵A→C。
5.3 数据依赖的公有系统
定义1. 逻辑蕴涵：（具体见萨师煊等主编《数据 库系统概论》P183定义5.11）
设有关系模式R(U,F),X≤U,Y≤U，如果 从F中的函数依赖能推导出x→Y，则称F 逻辑蕴涵x→Y。
5.3 数据依赖的公有系统
定义2. 闭包：（具体见萨师煊等主编《数据库系统概论》 P184，定义5.12）
在关系模式R(U,F)中，被F所逻辑蕴涵的函数依 赖的全体称作F的闭包，记为F+。
求闭包F+是理论上可计算而实际上不可计算的问 题。（麻烦）
如：从F={x→A1A2A3...An}出发，至少推导出2 的n次幂个不同的函数依赖。F+很大。
如：F={ x→Y，Y→Z }；
F+={x→x,x→Xy,xZ→xY,x→xYZ,xZ→xYZ...} 。
5.3 数据依赖的公有系统
定义3. 设F——函数依赖，X≤U,
XF+={A X→A能由F根据Armstrong公理导出}，
所有用Armstrong公理从F导出的函数依赖X→Ai 中Ai的属性集合,称为属性集X关于F的闭包.
例：R(U,F),U{A,B,C},F={A→B,B→C}，
若X={A}，则XF+={A,B,C}
X={B}，则XF+={B,C}
X={C}，则XF+={C}
5.3 数据依赖的公有系统
四．公理的完备性
定理：Armstrong公理系统是有效的，完备的。
有效性：对于关系模式R(U,F)，只要F中的函数 依赖为真，则用公理根据F推导出的函 数依赖也一定为T。
完备性：用公理能否推导出所有的FD 即F+中 所有的FD是否都能用公理推导出来？
若F+中有FD不能用公理推出，说明公 理不够用、不完全，就必须补充新的公 理。
5.3 数据依赖的公有系统
五．闭包的计算
★ XF+的计算可以间接解决F+计算的问题，即 可以帮助判定X→F是否属于F+。
算法：求属性集X关于U上的函数依赖集F的闭 包XF+（P185）.
例：（P185）设有R(U,F),U={A,B,C,D,E}
F={AB→C,B→D,C→E,EC→B,AC→B}
求：(AB) F+
(AB) F+={ABCED}
5.3 数据依赖的公有系统
附：关系规范化的基本原则
Normalization：一个低级范式的关系模式经投影分解→多个高一级范式的关系Scheme的集合。
主要思想：逐步消除数据依赖中不合适的部分，使各关系模式达到一定程度的分离——“一事一地”的模式设计原则。
即：让一个关系描述一个概念/一个实体/实体间的一种联系。
5.3 数据依赖的公有系统
规范化的程度越高→数据的冗余和更新异常就相对减少。
但连接运算费时→查询花时间多。
∴根据具体情况，权衡利弊。
数据变动不频繁，规范化程度可低一些。实际工作中，一般达到3NF。
5.3 数据依赖的公有系统
原则：⑴关系模式进行无损连接分解（且保持FD）， 分解过程中，数据不能丢失或增加。把全局 关系模式中的所有数据无损的分解到各个子 关系模式中。以保证数据的完整性。（P189）
例：S(SNO,SDEPT,MN) 注：MN为负责人
正确的结果：S(SNO,SDEPT)
D(SDEPT,MN)
未解决插入删除异常：S(SNO,SDEPT)
D(SNO,MN)
∵SDEPT→ MN 无
5.3 数据依赖的公有系统
⑵合理选择规范化程度：
① 若考虑存取效率——低级范式冗余大，浪费空间， 影响一致性。∴希望属性越少越好， 取高级范式。
② 若考虑查询效率——低级范式比高级范式好。 ∵连接运算代价较少
∴根据情况，合理选择规范化程度。
①和②是一对矛盾。
5.3 数据依赖的公有系统
⑶正确性与可实现性原则
举例：
学号 姓名 性别 专业 年级 课程成绩
课号 课名 学时 学分 教师 工资号 成绩
5.3 数据依赖的公有系统
基本函数依赖集：
F1={学号→（姓名，性别，专业，年级），
课号→（课名，学时，学分，工资号，教师），
（学号，课程）→成绩，
工资号→教师}
1NF：学生（学号，姓名，性别，专业，年级， 课号，课名，学时，学分，教师， 工资号，成绩）
↓消除部分函数依赖
5.3 数据依赖的公有系统
2NF：·学生（学号,姓名,性别,专业,年级）；
课程（课号,课名,学时,学分,教师,工资号）；
·成绩（学号,课号,成绩）。
↓消除传递函数依赖
3NF： ·课程（课号，课名，学时，学分，工资号）
课号→工资号
·教师（工资号，教师）
工资号→教师
也是BCNF。
5.3 数据依赖的公有系统
补充：Normalization在实际数据库设计中的应用
前面介绍的Normalizationd的过程：（理论上）
定先用某种方法得到一个关系模式R
↓
分析并确定R上的FD和MVD
↓
用机械的方法进行模式分解，消除不适当的数 据依赖关系，从而规范化。
5.3 数据依赖的公有系统
实际应用并非这样：
⒈ 找出所有数据依赖关系不是一件简单的事。
若遗漏/出错，则得不到理论上认为好的DB。
⒉ 就算正确找出，机械分解，而不考虑具体情况，全 规范化到同样程度，也不适当。（是否常更新）
⒊ 数据库设计一般先：E-R图
而E-R图实体集合分解较细（包含属性较小）
∴为了以后DB查询的方便，更多的情况是合并模式 ，而非分解。
5.3 数据依赖的公有系统
★ 在实际应用中，为得到好的DB设计，要视具体
情况对数据库处理，既可合并，也可能分解。
但Normalizationd理论仍起指导作用。
第六章 数据库设计
6.1 数据库设计概述
6.1.1结构化生命周期法
——基于软件工程思想的一种信息系统设计方法
⒈ 可行性分析（系统调查）
⑴经济可行性分析：资金投入
⑵技术可行性分析：相应技术
⑶使用可行性分析：系统被用户接受、使用。
⑴⑵⑶都是整个项目立项与否的重要阶段，∴高层 决策者参与讨论决定。
6.1.1结构化生命周期法
⒉ 需求分析（系统分析）
其方法在P210，过程在P211。
系统开发中最重要的一步。
∵认识现实世界，了解企业需求是设计数据库的基础 ，否则，即使有先进的技术、高超的水平，也不可 能设计出用户所需的系统。
目标：详细调查要处理的对象，了解原系统（年工/以 前计算机系统）情况，确定新系统功能、目标。
虽然“技术含量不高”，但非常重要，是系统成功与否的关键。并且强调用户参与，离开用户将寸步难行。
6.1.1结构化生命周期法
⒊ 总体设计（概念结构设计）
把用户的信息要求统一到一个整体的逻辑结构或概念
模式中，独立于任何硬件和数据库管理系统。
应用程序：完成于系统划分、功能模块划分。
数据库角度：概念模型设计。
⒋ 详细设计（逻辑结构设计）
应用程序：给出功能模块说明，考虑实施方法，设计
存储过程。
数据库角度：根据具体的DBMS设计DataBase、设计关
系，考虑数据的完整性、考虑数据的安全和备份策略。
6.1.1结构化生命周期法
⒌编程
根据上一步设计结果进行具体实施。
建立数据库并装入原始数据，建立存储过程。
编程，调用应用程序代码。
⒍调试与试运行
前一阶段作了局部测试，现在：各子系统、各模块要
联合调试和测试，并试运行（试运行：听取用户意见
）。
6.1.1结构化生命周期法
⒎系统运行，评价与维护（运行）
最后一步将系统交给用户使用。
使用过程中，可能还会出现新的问题，甚至提出新要求，∴不断对系统评价，维护。
数据库系统的维护不是一朝一夕的事。只要DataBase System存在，就要不断的评价、调试、修改，直至数据库生命周期结束、或完全重新设计为止。
6.1.1结构化生命周期法
要求开发过程严格按阶段进行，前一阶段完成，才开
始下一阶段，没一阶段都要有严格的文档资料。
优点：每一步目标明确，易于管理。
缺点：用户只参与了需求分析阶段工作，对即将建立 的新系统没有直观的预见，很可能开发方开发 的系统不是用户所需要的。
6.1.2快速原型方法（Rapid Prototyping Approach）
——为克服前述方法的缺陷应运而生
⒈基本思想
根据原型进行快速开发，对存在的问题反复修正，直至形成用户满意的系统。
6.1.2快速原型方法（Rapid Prototyping Approach）
⒉ 原型
——“企业作业原型”、“软件功能原型”
反映了最终系统的基本功能黑本特征，依此可快速开发一个可以演示的系统，用户在这个原型系统中得到启发，发现存在的问题，提出新的要求，并和开发人员一起修正和发展原型，如此反复，最后形成用户满意的原型。
用户参与了开发的全过程；
整个过程用户看得见；
因系统离自己的目标越来越近而兴奋。
6.1.2快速原型方法（Rapid Prototyping Approach）
⒊ 优点
提高系统开发质量，降低开发成本，缩短开发周期，
最大程度的满足用户需求。
注：①采用该方法要有快速开发工具的支持；
②靠原始手工作坊式一条条编程不行；
③要求开发人员熟练掌握快速开发工具，对用户
的修改意见课作出快速的反应。
6.1.2快速原型方法（Rapid Prototyping Approach）
其它方法：
l 面向对象法；
l DADM演示与讨论；
l 生长与原型法；
l 软件复用技术。
6.2 需求分析
一、需求分析的任务
见萨师煊等主编《数据库系统概论》P209
二、需求分析的方法
见萨师煊等主编《数据库系统概论》P210
6.2 需求分析
三、数据流图（DFD）与数据字典
1．定义：
—— 系统的逻辑模型，不依赖于硬件，软件和 DataStructure
—— 便于用户理解的数据流程的图形表示
—— 分析元与用户之间非常好的通信工具，进一 步系统设计的出发点
6.2 需求分析
2．DFD的组成元素：
· 数据流（→）：用名字标记的→ 表示数据流。
将DFD中其它元素连接起来。
· 处理/加工（○）：对数据进行的操作。
把流入的数据流转化为流出的数据流。
注：每个处理应有一个名字表示它的含义，并分配一 个编号，以便标识它在层次结构中的位置。
· 存储：暂时存储数据的工具。
磁带，磁盘，文件，表
· 数据源点和终点：（□）系统的输入/输出；
系统之外的人员/组织；
系统数据的发送者/接受者；
6.3 概念结构设计
概念结构设计：在需求基础上，用数据模型表示数据
及其联系。
需求分析包括了：功能需求分析；
数据需求分析（数据库设计的基础）。
概念模型：不依赖于任何DBMS；
从现实世界角度对数据的抽象、描述；
容易为用户所理解。
6.3 概念结构设计
一．设计局部E-R图
概念结构设计依据是需求分析阶段的DFD/DD。
在DFD中选择适当层次的DFD，作为设计局部E-R图的出发点。 中层 允许有一定的重叠↓
⒈ 确定实体集合
第一步（关键一步）
数据流 / 数据源 / 目的 / 数据存储
↓根据具体情况决定 ↓常作为实体集合
6.3 概念结构设计
⒉ 联系
标明：1:1，1:N，N:M。
原则上：与处理框相关的输入流（数据流）， 输出流（数据目的地），输入或输出 的工作之间的可能存在的联系。
6.3 概念结构设计
⒊ 属性
属性名尽量和数据流中数据项名相同。
数据流实体的属性——数据流包括的数据项。
数据存储
数据源
数据目标
为简化E-R图，属性可仅在DFD中描述。
· 准则（P219）
实体属性——进/出该实体集的 某个数据流中
6.3 概念结构设计
⒋ 主关键字
属性中标明作为PK的属性集合。
⒌ 其它
建E-R图，要完善DD(DD：包括实体集，联系，属 性的描述)
某些情况：描述产生频率（每年/月/季），是否长 期保存，变化快慢，保密级别，存在的约束。
6.3 概念结构设计
二．集成局部E-R图
在设计局部E-R图的基础上，将局部E-R图集成为全 局E-R图。
集成时要解决的问题：
⒈消除冲突
⑴命名冲突：（P225）
同名异义
异名同义
实体 联系 属性
6.3 概念结构设计
⑵结构冲突：
l 同一概念在不同E-R图中意义、作用不同：实 体 属性 联系
l 同一实体在不同E-R图中包括属性组不同——
常见：∵局部应用关心侧重不同
↓Solution
并集→调整次序
l 同一联系在不同E-R图中类型不同。
6.3 概念结构设计
⑶属性冲突（P225）
⑷约束E-R图：同一数据项在不同的E-R图中有不同 的约束条件和访问权限。
具体集成时的原则：最后形成的模型和所有局部 模型一致。
若做不到：或许局部E-R图有错→修改
或许本来就是不同概念→不应视作一个
6.3 概念结构设计
⒉ 消除冗余
冗余：破坏DB完整性，维护起来困难
冗余数据：由基本数据导出的数据。
冗余联系：由基本联系导出的联系。
方法：⑴分析方法：以DFD、DD为依据，根据 逻辑关系消除
⑵规范化理论
6.3 概念结构设计
⒊ 合并局部E-R图
合并局部E-R图中相同部分
保留特殊部分
尽可能的
删除冗余部分
用累加的方式一次集成两个局部E-R图
6.3 概念结构设计
三．优化全局E-R图
必要时应对全局E-R图进行修改，重构和优化
→得到最佳的全局E-R图方案
规范化理论：
如：·根据需求分析收集的信息，确定FD
·使实体的属性都只依赖于PK
·部分FD或传递FD，判断是否分解出新的实体
6.4 逻辑结构设计
掌握E-R图向关系模型的转换原则。
（见萨师煊等主编《数据库系统概论》P230）
6.5 数据库的物理设计
DB特点——高效存取大量数据的能力。（依靠各类加 速存取DB的物理存储技术）
6.5.1 物理数据模型
一、记录和文件
关系在物理级表示为文件
——具有相同格式的记录集合。纪录：存储元组， 由一个或多个字段（字段：存储元组的含量） 组成（初等Data Type）。
流式文件：只能实现顺序存取
记录是文件：多种方法存取
在物理级，DB是一组文件（存储文件）；
文件是纪录的集合；
记录由字段组成。
区别：
6.5.1 物理数据模型
二、永久存储和分块
数据库运行时，外部存储器和主存之间要频繁地进行数据交换，每次交换的数据量称为一个数据块。在内存中开辟的缓冲区的大小至少要等于一个数据块的大小。数据块越大，一次能调进调出的记录数就越多。这种情况对顺序处理能减少访问磁盘的次数，提高了处理速度，但是对于以随机处理为主的应用系统就不一定合适了。因为数据块包含的记录数越多，同本次处理无关的记录可能传送的就越多，这样造成有效的数据传送降低，并且占用了更多的内存。所以，数据块的大小是考虑多方面因素后由厂家而非用户确定的。
6.5.1 物理数据模型
数据块的长度不一定恰好等于记录的整数倍，通常有两种组织方式：
不跨块方式：即一个数据块只包含若干完整的记录，不 足以容纳一个记录的零头空间放弃不用；
跨块方式：允许一个记录跨在不同的数据块，这种组 织方式可节省空间，但由于实现较困难， 故很少使用。
6.5.1 物理数据模型
上面提到的缓冲区数目和大小，数据块的大小及组织方式，是由DBMS设计者安排和实现的，不同系统设置都不一样，这些细节对数据库用户而言是透明的。
除了大的数据对象，多数记录的长度＜快的大小
因此：多个记录存于一个快中
∵运算代价同内存，外存之间传输块的个数有关
∴存储文件时，要考虑如何在块中安排记录的占用较
少的块
6.5.1 物理数据模型
三、数据库存取代价
数据库存取代价=物理块存取代价+计算代价
可忽略
物理块存取次数×每块存取代价
——用块的存取次数来描述DB的存取代价
6.5.2 DB文件的存取组织方法
一．索引存取方法
索引文件
l 是DBS常采用的数据文件结构，按关键字存取文 件，效率较高。
l 索引表，有序的逻辑文件。
l 只反映与索引项有关的数据的存放位置而不是数 据本身
l 不能离开被索引的数据文件（主文件）而独立 存在
6.5.2 DB文件的存取组织方法
建立索引的方式多种多样：
①主索引（Primary Index）：以记录的主关键 字建索引。
②次索引（Secondary Index）：用非主关键字 建索引。
③倒排文件（Inverted File）：在所有属性上都 建索引。
6.5.2 DB文件的存取组织方法
④ 稠密文件（Dense Index）：索引文件中对每一个 索引项值都有一个索引记录。
⑤ 稀疏索引（Sparse Index）：索引文件中对一组 索引项值才有一个索引记录。
⑥ 聚集索引（Clustering Index）：将索引项值相同 的记录在物理上集中存储在同一块或相邻块。
⑦ 多级索引（Multilevel Index）：在索引文件的基 础上再建索引。
6.5.2 DB文件的存取组织方法
常用的较好的折中的办法
∵处理DB主要开销：把块从磁盘上取
到主存中所需时间，扫描整个块的
时间可忽略。
更快的定位一个记录
权衡
注：稠密索引
索引文件较大
插入/删除，维护开销小
空间开销
——决定于具体应用
稀疏索引
占用空间小
访问时间
6.5.2 DB文件的存取组织方法
注：索引本身有时也会变得非常大，而难于有效处理。
例：一个文件由100000（10万）个记录，一块存 10个记录，有一个索引记录。
∴索引有10000个记录，索引记录比数据记录小，
设一个块能容纳100个索引记录→索引占100个块
读取出块数高达log2(100)7=7次，读块7次
6.5.2 DB文件的存取组织方法
主索引上构造一个稀疏索引：
搜索一个记录，在外层索引上用二分法找到不大于所需索码值的最大搜索码值对应的记录，指针指向一个内层索引块，对这一块作扫描，直到找到不大于所需搜索码值的最大搜索码值对应的记录。
这样，如果外层索引一在主存中，那么使用两级索引时，只需读一次索引块。
6.5.2 DB文件的存取组织方法
B+树索引文件：
前面几种索引文件都是静态索引（静态索引适用于相对比较稳定的文件），即索引结构和级别都是固定不复的，但随着主文件记录的变动，索引文件也要变化，需要增加维护开销。而且，随着主文件的变化，索引文件的性能会逐渐下降，到一定时候要进行重组织。∴对变化较大的文件，用动态索引。主文件较大时，多级索引可提高速度，但文件内容不多，不必要，反而降低效率。
6.5.2 DB文件的存取组织方法
二、聚簇
Clustered Index：数据（以升序）物理的存放在页上，索引页中的值的顺序也升序。
很多RDBS将各个关系存储在一个个独立的文件中（很多DBMS在文件管理方面不直接依赖于下层OS，而让OS分配给DBS一个大的操作系统文件，所有关系都在这个文件中，其管理用DBS进行）——利用OS的文件管理。
这种实现关系数据库的简单方法在DB规模大时不合适。
6.5.2 DB文件的存取组织方法
例：（理解一个文件中存储多个关系的好处）
图
Select account_ number, customer_ name, street, city
From depositor, customer
Where .......
必须找到具有相同customer_ name的customer元
组（可用索引）
对depositor中的每个元组
但要从磁盘传到主存中
最快情况：每个记录在一个块，每个记录执行一次
块操作。
6.5.2 DB文件的存取组织方法
聚簇文件结构：
将两个关系的元组混合在一起，读customer一个元组时，包含该元组的整个块从磁盘到主存。∵相应depositor元组存储在靠近customer元组的磁盘上∴该块也包含了处理查询所需的关系depositor的元组，顾客账户太多，则存在临近块中。
6.5.3 存取方法
——数据库文件的组织方法
一．堆文件组织
· 记录无任何次序的状如块中，块之间无特殊的组 织，块间由指针联系。
· 一条记录可以放在文件中的任何地方，只有那个 地方有时间存放，记录无顺序，一个关系就是一 个单独的文件。
· 文本文件，数据文件等串行处理文件以堆文件组 织。
6.5.3 存取方法
二． 顺序文件组织
·为了快速的按搜索码获取记录，我们通过指针把记 录链起来，每个记录的指针指向在搜索码顺序上的 下一个记录。
·为了减少顺序文件处理中的块访问的次数，在物理 上按搜索码顺序存储起来。
三． 散列文件组织（HASH）
·通过计算所需记录搜索码上的一个函数直接获得包 含该记录的磁盘块地址。
桶——存储一条/多条记录的存储单位
第七章 数据库恢复技术
数据库是一种共享资源，因此，在数据库的使用过程中，保证数据的安全可靠，、正确可用就成为非常重要的问题，它是有效使用数据库的前提。
数据库被破坏的原因可归纳为：
⒈软硬件故障，造成数据被破坏。
⒉数据库的并发操作引起数据的不一致性。
⒊自然或人为地破坏，如失火、失窃、病毒和为 授权人的有意纂改数据。
⒋对数据库数据的更新操作有误，如操作时输入 错误的数据或存取数据库的程序有错等等。
第七章 数据库恢复技术
针对这四类问题，一般DBMS提供了相应的功能：
⒈数据库恢复：即系统失效后的数据库恢复，配合定时备份数据库，使数据不丢失数据。
⒉并发控制：即保证多用户能共享数据库，并维护数据的一致性。
⒊安全性保护：防止对数据库的非法使用，以避免数据泄漏、纂改、破坏。
⒋完整性保护：保证数据的正确性和一致性。
从系统的角度看，数据库保护主要是指控制哪类用户可用什么方式存取哪类数据对象，以及对各类数据对象有那些完整性约束等问题。
7.1 事务的基本概念
一． 事务（Transaction）：
事务——是一种机制，它确保多个SQL语句被当作 单个工作单元来处理。
二、四个特性
——ACID准则
7.1 事务的基本概念
⑴ 原子性（Atomicity）
· 即事务执行的原子性，事务“要么不做，要么全做”
，如果事务因故障没有完成，则该事务已做的操作
认为是无效的，在恢复时必须取消该事务对数据库
的影响。
· 保证原子性的思路：对于要执行写操作的数据项，
在磁盘上记录其旧值，若事务没能完成执行，旧值
将被恢复，好像事务从未执行。
· 保证原子性是 DBMS本身的责任，由“事务管理
部件”处理。
7.1 事务的基本概念
⑵ 一致性（Consistency）
· 事务作用于数据库过程中，数据应始终满 足完整性约束。
· 一个事务的执行是把DB从一个一致的状态 阿转换成另一个一致的状态。
· 确保单个事务的一致性是对该事务编码的 应用，程序元的责任，完整性给这项工作 带来了便利。
7.1 事务的基本概念
⑶ 隔离性（Isolation）
· 即事务并发执行的相对独立性，这是事务并发控 制的目标。使事务并发执行的结果和某一串行执 行的结果相同。
· 即使每个事务都能确保C、A，但如几个事务并 发执行，它们的操作会以人们不希望的某种发 式交叉执行，也会导致不一致状态。
· 一种解决方法：串行执行事务（一个接一个）。
· 隔离性保证—→事务并发执行的结果和某一串行 执行的结果相同。
7.1 事务的基本概念
⑷ 持久性（Durability）
· DBMS中“恢复管理部件”的责任。
· 完成了的事务对数据库的影响应是持久的 ，即使数据库因故障而受到破坏，DBMS 也应该能够正确的恢复数据。
7.2 数据库恢复概述
数据库恢复：即系统失效后的数据库恢复，配合定时备份数据库，使数据不丢失数据。
7.3 故障的种类
一、事务内部的故障
二、系统故障
三、介质故障
四、计算机病毒
7.4 恢复的实现技术
一、数据转储（备份）
二、登记日志文件
备份是定期的，而不是实时的，所以利用备份并不能完全恢复数据库，只能将数据库恢复制作备份的那一时刻。
日志是对备份的补充，它可以看作是一个值班日记，它将记录下所有对数据库的更新操作。日志文件是实时的。
当磁盘发生故障造成DB损坏时，先利用备份恢复大部分数据库，然后运行数据库日志，将备份后所做的更新操作在重做一遍，从而使DB完全恢复。
7.4 恢复的实现技术
为保证日志的安全，应该将日志和主数据库安排在不同的存储设备上，否则日志和DB可能会同时遭破坏，日志也就失去了本来的作用。
日志记录有几种，“更新日志记录”描述一次数据库写操作，它有如下几个字段：
· 事务标识：执行写操作的事务的唯一标识。
· 数据项标识：所写的数据项的唯一标识，通常 是数据项在磁盘上的位置。
· 旧值：数据项的写前值。
· 新指：数据项的写后值。
7.4 恢复的实现技术
其它特殊的日志记录用于记录事务处理过程中的重要事
件，如事务的开始，以及事务的提交或中止。
将各种类型的日志记录记为：
事务Ti开始
数据项 前 后
提交
中止
每次事务执行写之前，必须在DB修改前生成该次写操作的日志记录。一旦日志记录已创建，就可以根据需要对DB做修改，并且，能利用日志记录中的旧值消除已做的修改。
7.5 具有检查点的恢复技术
系统故障，检查日志，决定哪些事务需要(redo , undo)
原则上——搜索整个日志来决定该信息
问题：⑴ 搜索过程耗时
⑵ 根据提供的算法，大多数需要的事物都将其更 新写入了DB
⒈ 为降低开销——引入检查点
日志文件中的一类记录：检查点记录
⒉“重新开始文件”——记录各检查点，记录在日志文 件中的地址。
7.5 具有检查点的恢复技术
⒊ 恢复子系统在登陆日志文件期间动态的维护日志：
· 缓冲中日志记录——写入磁盘的日志文件
· 在日志文件中写一个检查点
· 缓冲中的数据记录——写入磁盘
· 检查点记录在日志文件中的地址——重新开始文件
建立检查点 预定时间间隔：
按某种规则：如日志写满一半
检查点前提交的事务对DB的修改一定已写入 DB.∴不用对”T”REDO
例：P258
7.6 数据库镜像
镜像的实质也是备份，在同一时刻保存数据的两个或多个副本。
镜像与转储本质不同：
转储：定期或不定期的、间断、非实时
镜像一般是OS的功能——硬盘级的
但DBMS为了防止介质出现故障而丢失数据 也提供了镜像功能
如果条件许可，尽量使用OS级的硬盘级的镜像
7.6 数据库镜像
SQL Server：镜像连续、实时的将一个 SQL Server设备上的信息复制到另一个设备上。
对该设备操作的所有事件都复制到它的副本镜像设备上。如果两个设备中的一个损坏了，另一个设备由于保存了所有事件轨迹的最新拷贝，所以系统会完成自动切换，并保存系统连读工作。
第八章 并发控制
8.1 并发控制概述
并发控制：保证多用户能共享数据库，并维护数据的一致 性。
不一致状态：由于系统的故障，系统的状态不再反映DB应 当描述的现实世界的真实状态，系统必然会 在某一时刻处于不一致状态，最终应该被一 致态所代替。
数据库是一个共享资源，不同的用户可能要同时操作一个数据库，同时操作一个基本表，甚至同时操作一条记录。
8.1 并发控制概述
那么这些用户会不会发生冲突呢？
不同用户同时实施的更新操作会不会矛盾呢
如果控制不当的确会发生这些问题，本节讨论这方面的问题。
并发存取可能出现的异常
事务的并发执行可以显著提高系统的资源利用率，提高系统的效率，但当多个事务对数据库进行并发操作时，如不加任何控制，可能会引起数据库数据的不一致性。
8.1 并发控制概述
⒈ 丢失修改（例P265）
⒉ 不能重复读：如果在一个事务要对一个项连续读两次 ，以进行项的校验，而在此之间，插入 另一个事务读对该项的值进行修改，则 可能造成事务对同一项两次读出来的结 果不一样。
8.1 并发控制概述
⒊ “脏”读（Dirty Read）：当一个事务T1在对数据库中 的某些项做了修改以后,因某 种原因而中途取消，则它对数 据库的修改是无效的，这些被 修改过的项称为“脏”数据。在 T1取消前，可能有其它事务已 经读过这些“脏”数据,如果根 据此数据计算出新数据并写回 数据库，则数据库中数据出错.
8.1 并发控制概述
以上是典型的“脏”读的例子，异常不可能一一列举完。
所以只要有适当的并发控制技术控制并发的事务正确的执行，互不干扰，以避免造成数据库中的数据不一致性。
要在数据库系统保证数据的一致性，系统是会有代价的，为了减少开销，有时允许一些数据不一致性的存在，只要对数据库影响不大。
项（Item）：数据库操作的基本数据单位，也是并发控 制的基本单位，可以是数据库/关系/元组/ 字段......(由系统设计人员选择)
8.2 封锁（Locking）
基本思想：当一个用户对一个表或记录进行更新时，封锁改表或记录，是其他用户不能在同一时刻更新相同的表或记录，迫使其它用户在更新后的基础上再实施另外的更新操作。
一、封/加锁的类型
⒈ X锁
最简单的加锁方式，只有一种X锁，即排它锁（Exclusive Locks），该锁既用于项的写操作，也用于项的读操作。
注：事务T一旦对某项R加了X锁，则其它事务不能在对该项加锁，直至T释放X锁。
8.2 封锁（Locking）
⒉ S,X锁
S锁（Share Locks）共享锁，用 于项的读操作。
设有两种锁
X锁 共享锁，用于项的写操作。
允许多个事务并发的读同一项，但对项的写操作必须排它。
（S，X）锁单独采用X锁提高了并发程度，但可能产生活锁（Live Lock），即由于不断有事务对某项加S锁，而使一些想对该项加X锁的事务长期等待，对系统性能有不良影响。
8.2 封锁（Locking）
⒊ S，U，X锁
增加了U锁（Update Lock）——更新锁，事务在更新一个项时，首先对该项加U锁，此时允许其它事务在该项加S锁，待事务读出并修改项后，再将加在该锁上的U锁升级为X锁，然后写入修改后的项。由于不必在事务执行的全过程加X锁，因此进一步提高了并发程度，仍也可能→ 活锁。
8.2 封锁（Locking）
二、调度的可串行性
在并行执行事务时，我们会发现，由于事务交叉执行顺序不同，可能会得到不同的结果，必须有一个准则来判断那个正确。假设事务执行的正确结果是在没有别的事务并发执行时执行它得到的结果。由于事务可以一个接一个的串行执行，所以下面的假设正确：
几个事务并发执行是正确的
←→其结果同以某种次序串行执行这些事务得到的结果相同
8.3 活锁和死锁
系统对数据项加锁不能太随意，否则可能引起死锁。
⒈ 活锁：当若干事务要对同一数据项加锁时，造成一 些事务的永久等待。例：P270
避免活锁的简单方法：采用先来先服务策略。
即让系统按请求加锁的先后次序对事务排队， 数据项上的锁一旦释放，就批准申请队列中第 一个事务获得加锁。
8.3 活锁和死锁
⒉ 死锁：指两个以上事务集合中的每个事务都在等待加 锁当前已被另一事务加锁的数据项，从而造成 相互等待的现象。
DB中解决死锁的方法：
⑴ 一次封锁法：
要求每个事务一次将所有要使用的数据全部加锁 ，否则就不能执行。
8.3 活锁和死锁
⑵ 采用按序加锁法：
预先规定一个对数据项加锁的顺序，要求所有事 务按照这个次序申请加锁，锁管理也按顺序批准 加锁。
⑶ 不采取任何措施预防死锁，而是周期性的检查 系统中是否有死锁，若发现，就设法解除。
选择一个需花费代价最小的方法处理死锁。
如：事务T撤销，释放被加的锁，使其它事务 继续运行下去
8.4 并发调度的可串行性
事务处理系统允许多个事务并发执行
多个事务并发更新数据→异常
如果串行执行，就OK
一次执行一个事务，每个事务仅当前一个事务执行 完毕才开始，但如下理由促使我们考虑并发。
u 一个事务由多个步骤组成
u 一些步骤涉及I/O活动
u 一些步骤涉及CPU活动
8.4 并发调度的可串行性
∴ 多个事务可并行执行，一个事务在磁盘上读写时，另一个可在CPU上运行，可增加系统的“吞吐量”——给定时间内执行的事务数增加，相应磁盘与CPU利用率提高，空闲时间较少。
· 系统中可能运行着各种各样的事务，一些较短，一些较长，若串行执行，短事务可能得等待她前面的长事务完成→难以预测的延时。如果各事务是针对DB的不同部分进行操作，事务并发执行会更好。
8.4 并发调度的可串行性
减少“平均响应时间”——一个事务从开始到完成所需的平均时间
DB中并发执行本质上与OS中使用多道程序的动机一样。
△ 多个事务并发执行时，即使每个事务都正确执行，数据库的一致性也可能被破坏。
∴ 讲述“调度”
可用于确定那些可以保证一致性的执行序列
执行顺序：指令在系统中执行的时间顺序。
8.4 并发调度的可串行性
串行调度：由类自各事务的指令序列组成
属于同一事务的指令在调度中紧挨在一起。
N个事务，由n！个有效的串行调度
例：P273,图8-5(a)(b)
并发执行时，调度不必是串行的，若有两个并发执行的事务，OS可能先选其中的一个事务执行以小段时间，然后执行第二个事务一段时间，接着又切换道第一个......所有事务共享CPU时间。
8.4 并发调度的可串行性
执行顺序有多种，可能的调度总数要比n！大得多。
如果并发执行的控制完全由OS负责，许多调度都是可能的，包括使DB处于不一致状态的调度，保证任何调度执行后DB总处于一致状态是DBMS中“并发控制部件”的责任。
“两段锁协议”可保证并发调度的可串行性（之一）。
8.5 两段锁协议
两段锁协议要求每个事务分两个阶段提出加锁和解锁申请。
⒈ 扩展阶段（Growing Phase）：事务可以获得锁，但不能释放锁。
⒉ 收缩阶段（Shrinking Phase）：事务可以释放锁，但不能获得锁。
一开始，事物处于扩展阶段，事务根据需要获得锁，一旦该事务释放了锁，它就进入了收缩阶段。
· 事务遵守两段锁协议是可串行化调度的充分条件（如前例：P273）
· 两阶段两段锁协议并不保证不会发生死锁。
8.6 封锁的粒度
⒈ 封锁粒度（Granularity）
——封锁对象的大小
逻辑单元 物理单元
属性值（集）；元组； 页（索引/数据页），块等
关系；索引；DB
8.6 封锁的粒度
⒉ 封锁粒度与并发度的关系
粒度越大→封锁的数据单元越少→并发读越小→系统开销 也越小
粒度越小→封锁的数据单元越多→并发读越大→系统开销 也越大
例：P276
∴需要一种允许系统定义多级粒度的级制
⒊ 多粒度封锁（Multiple Granularity Locking）
一个系统中同时支持多种封锁粒度以供不同的事务选择。
第九章 数据库安全性
安全性保护：防止对数据库的非法使用，以避免数据 泄漏、纂改、破坏。
9.1 安全性控制的一般方法
一． 用户标识和鉴定
安全系统的核心问题是身份识别：
⒈ 用户名（User）
⒉ 口令（Password）
⒊ 随机数
9.1 安全性控制的一般方法
需要有一定的方法验证用户的身份，防止他人假冒，辨别用户的最普通的方案是要求用户提供只有用户本人和系统知道的口令，由于口令一般不能太复杂，否则用户自己也会忘记，这就使得口令不够安全，容易被想非法进入数据库系统的人破译。解决这个问题的方法是要求用户经常更换口令，而更安全的办法是在网络上以加密方式传输口令，此外，口令最好不要太简单，也不要用生日之类，易被他人猜出的口令。另外，辨别用户的方法还有磁卡，签名，指纹，声音内容等。
9.1 安全性控制的一般
数据库原理与应用
第一章 绪论
数据库是数据管理的工具。数据管理经历了从手工管理阶段、文件管理阶段到数据库管理阶段的变迁。
1.1 数据库系统概述
1.1.1 数据、数据库、数据库管理系统、数据库系统
一、数据库(Data Base)
——存放数据的仓库（顾名思义/不准确的含义）
——信息的载体/表示
尽管数据库技术已发展成熟，但还没有一个普遍接受的、严格的定义。
数据库应具备的特征/定义：
（1）数据库是相互关联的数据的集合
数据库中的数据不是孤立的，数据与数据之间是相互关联的，在数据库中不仅要能够表示数据本身，还要能够表示数据与数据之间的联系。
如：学籍管理——学生、课程两类数据。
（2）用综合的方法组织数据
顺序、索引、聚簇Cluster
1.1.1 数据、数据库、数据库管理系统、数据库系统
例：人事部门有一个职工文件：
职工基本情况
有关人事管理的数据
教育部门也有一个职工文件：
职工基本情况
有关教育培训的数据
其中，“职工基本情况”重复存储，浪费空间。可共享存 储类似这样的共同数据，以降低数据的冗余度。
（3）具有较小的数据冗余，可供多个用户共享
低冗余与数据共享：在数据库技术之前，数据文件都是独立的，任何数据文件都必须含有满足某一应用的全部数据。
1.1.1 数据、数据库、数据库管理系统、数据库系统
（4）具有较高的数据独立性
数据独立性：（包括物理独立性、逻辑独立性。具体见萨师煊等主编《数据库系统概论》Page11）
指数据的组织和存储方法与应用程序互不依赖，彼此独立的特性。可降低应用程序的开发代价和维护代价。
1.1.1 数据、数据库、数据库管理系统、数据库系统
在数据库技术之前，数据文件的组织方式和应用程序是密切相关的。数据结构改变，相应的应用程序也必须随之修改==〉开发/维护代价
1.1.1 数据、数据库、数据库管理系统、数据库系统
（5）具有安全控制机制，能够保证数据的安全、可靠 数据库要有一套安全机制，以便有效地防止数据库中的数据被非法使用/修改；
数据库还要有一套备份/恢复机制，以保证当数据遭到破坏时将数据立刻完全恢复==〉继续、可靠地运行。
（6）允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和完整性
一致性：数据库中的数据是共享的，并且允许多个用户同时使用相同的数据。这就要求数据库能够协议一致，保证各个用户之间对数据的操作不发生矛盾和冲突。
正确性、完整性：
保证数据正确的特性——数据完整性
可通过建立一些约束条件保证数据库中的数据是正确的。
如：学生年龄20 （2或100则错误）
1.1.1 数据、数据库、数据库管理系统、数据库系统
二、数据库管理系统（DataBase Management System ，DBMS）
上节提到的数据库的功能/特性不是数据库中的数据固有的，是靠管理或支持数据库的系统软件——DBMS——提供的。
DBMS任务：
·对数据资源进行管理，使之能为多个用户共享。
·保证数据的安全性/可靠性/完整性/一致性/独立性
1.1.1 数据、数据库、数据库管理系统、数据库系统
1.1.1 数据、数据库、数据库管理系统、数据库系统
2． 数据库操纵功能
完成对数据库中数据的操作：插入、删除、修改；
重新组织数据库的存储结构；
完成对数据库的备份/恢复等.
DBMS功能：
1． 数据库定义功能
定义数据库结构和存储结构；
定义数据库中数据之间的联系；
定义数据完整性约束条件和保证完整性的触发机制等.
3．数据库查询功能
以各种方式提供灵活的查询功能，以便方便使用数据.
4． 数据库控制功能
完成对数据库的安全性控制/完整性控制/并发控制
5． 数据库通信功能
在分布式数据库或提供网络操作功能的数据库中还必须提供通信功能。
1.1.1 数据、数据库、数据库管理系统、数据库系统
三、数据库系统和数据库管理员
1．数据库系统 (DataBase System，DBS)
——基于数据库的计算机应用系统，包括：
·以数据为主体的数据库
·管理数据库的系统软件DBMS
·支持数据库系统的计算机硬件环境和操作系统环境
·管理和使用数据库系统的人，特别是DBA
·方便使用和管理系统的技术说明书和使用说明书
1.1.1 数据、数据库、数据库管理系统、数据库系统
1.1.1 数据、数据库、数据库管理系统、数据库系统
2．数据库管理和数据库管理员 (DataBase Administrator，DBA)
——从事数据库管理工作的人员，负责数据库的全面管理工作（维护、设计）
数据库的使用会改变企事业单位的管理方式，但因为要把众多部门或用户的数据放在同一数据库中，会带来一些问题，如：数据冲突；越权使用数据；重要数据丢失……
因此需要管理部门：负责和数据管理有关的工作。
1.1.1 数据、数据库、数据库管理系统、数据库系统
注: DBA工作繁重、重要、关键：
除了要掌握一定的数据处理、数据库技术之外，还应有处理好人际关系的素质、能力。在一个企事业中，特别是一个规模较大的数据库，不能指望一两个人来完成管理工作，所以DBA常指数据库管理部门。
开发DBS时，一开始就应设置DBA的职位或相应的机构，以明确DBA职责、权限。
数据处理是计算机应用领域中最大的一类应用
用计算机实现数据管理经历了三个发展阶段：
1． 人工管理阶段
数据库管理的初级阶段。
在50年代中期以前，计算机采用的是批处理方式，主要用于科学计算。（具体见萨师煊等主编《数据库系统概论》Page6）
1.1.2 数据管理技术的产生和发展
2． 文件系统阶段（50年代后期——60年代中期）
特点：
·计算机技术有了很大的发展，开始广泛应用于信息处理
·存储设备有了磁盘、磁鼓等可直接存取的设备
·计算机有了操作系统，包括文件管理系统，用户可将数
据组织成文件体交给系统进行自动管理。
·数据可长期保存在磁盘等存储设备上
·程序和数据有了一定的独立性，且文件有多种形式的组
织结构：顺序、链接、索引、直接
1.1.2 数据管理技术的产生和发展
缺点：
（1）数据冗余较大
∵每个文件都是为特定的用途设计的，
∴同样数据在多个文件中重复存储
进能提供以文件为单位的数据共享。
（2）程序和数据之间的独立性较差
应用程序依赖于文件的存储结构，修改文件存储结构就要修改程序
1.1.2 数据管理技术的产生和发展
（3）对数据的表示和处理能力较差
文件的结构和操作比较单一，不够丰富。
（4）数据不一致
由（1）造成，更新时会造成同一数据在不同文件 中的不一致。
（5）数据联系弱
文件与文件之间是独立的，文件之间的联系必须通 过程序来构造。
尽管如此，文件系统在数据管理技术的发展中仍起 着很重要的作用。
1.1.2 数据管理技术的产生和发展
1.1.2 数据管理技术的产生和发展
3.数据库系统阶段
从60年代后期开始，计算机用于信息处理的规模越来越大，对数据管理的技术提出了更高的要求，此时开始提出计算机网络系统和分布式系统，出现了大容量的磁盘，文件系统已不再能胜任多用户环境下的数据共享和处理。一个新的数据库管理技术——DBMS由此而形成，它对所有用户数据实行统一的、集中的管理、操作和维护。
特点：（具体见萨师煊等主编《数据库系统概论》Page9-13）
按照数据模型的进展情况，数据库系统的发展可划分为三代：
第一代：层次数据库系统和网状数据库系统
主要支持层次和网状数据模型
第二代：关系数据库系统
支持关系数据模型，该模型有严格的理论基础， 概念简单、清晰，易于用户理解和使用。因此一 经提出便迅速发展，成为实力性最强的产品。
1.1.2 数据管理技术的产生和发展
第三代：新一代数据库系统——面向对象数据库系统
基于扩展的关系数据模型或面向对象数据模型的尚未 完全成熟的一代数据库系统 。
特点：支持包括数据、对象和知识的管理
在保持和继承第二代技术的基础上引进新技术(如OO)
对其他系统开放，具有良好的可移植性、可连结性、
可扩充性、互操作性。
1.1.2 数据管理技术的产生和发展
1.2 数据模型
模型——对客观事物、现象、过程或系统的简化描述
所有的数据库系统都为它所要描述的世界建立了模型：
数据建模：描述了组织数据的框架结构。
如：楼房住户-数据；房间规格-数据模型
———数据建模最后发展成为数据的存储方式（数据字典 中的定义）
业务功能建模：用户的最终需求。
——业务功能建模最后发展成为应用程序
产生高效的应用程序的前提是良好的数据模型。（正如10 平米的房间无法成为会议厅一样，一个糟糕的数据模型也无法产生高质量的应用。
1.2 数据模型
为什么要建立数据模型（Data Model）：
象盖大楼的设计图一样，DM可使所有的
项目参与者都有一个共同的数据标准
避免出现问题再解决（边干便改的方式）
可及早发现问题
加快应用开发速度
1.2.1 数据模型的三要素
1．数据结构
——描述数据的静态特征，包括对数据结构和数据 建联系的描述。
通常按照数据结构的类型来命名数据模型：
层次结构——层次模型
网状结构——网状模型
关系结构——关系模型
2．数据操作
——描述数据的动态特征：一组定义在数据上的操作（ 包括操作的含义、操作符、运算规则及其语言等）
主要操作：检索与更新（插入、删除、修改）
1.2.1 数据模型的三要素
3．3. 数据的约束条件
——完整性规则的集合，数据库中的数据必须满足
这组规则。
约束条件的主要目的是使数据库与它所描述的现实系
统相符合。
设计时：时数据模型正确、真实、有效地反映现实
运行时：保证数据库中的数据值真实地体现现实世 界的状态
1.2.2常见数据模型
根据数据模型应用目的不同，数据模型有以下几种：
● 概念（数据）模型（Conceptual Data Model）
———面向现实世界建模
———主要用来描述现实世界的概念化结构，与具 体的DBMS无关；
- 现实世界的事物经过人脑的抽象加工，提取出对用
户有用的信息，经过组织整理加工形成结余现实世
界和计算机世界之间的中间模型；
- CDM只关心现实世界中的事物、事务特征、联系，
完全没有与具体及其相关的任何概念；
1.2.2常见数据模型
CDM是系统分析员、程序设计员、维护人员、用户
之间相互理解的共同语言；
- CDM能时数据库的设计人员在设计的初始阶段摆脱
计算机系统及DBMS的具体技术问题，集中精力分析
数据、数据之间的联系；
- 概念模型必须转换成逻辑模型，才能在DBMS中实
现；
- 最常用的概念模型是E-R模型
1.2.2常见数据模型
● 逻辑（数据）模型（Logical Data Model）
——面向用户建模
—— 用户从数据库所看到的数据模型；
- 是具体的DBMS所支持的数据模型（网状/层次
/关系/面向对象）；
- 既要面向用户，也要面向系统；
- LDM表示数据建联系的方法
- 一般的DBMS支持一种LDM（特殊的DBMS支
持多种LDM）
1.2.2常见数据模型
● 物理（数据）模型（Physical Data Model）
——面向具体的DBMS，面向机器
——描述数据在存储介质上的组织结构
- PDM不仅与具体的DBMS有关，还与操作系统 和硬件有关
- 每一种逻辑模型在实现时都有其对应的物理模型
- PDM加入了概念模型中为考虑的因素：触发器、 存储过程、主键、外键、索引等
- DBMS为保证其独立性和可以执行，大部分PDM 的实现工作由系统自动完成，而设计者只设计索 引、聚簇等特殊结构
1.2.3概念模型
实体-联系（Entity-Relationship）概念模型
首先介绍E-R模型中常用的几个重要概念，利用它们可
构造出现实世界的数据的抽象描述。
1．实体、实体型、实体集
● 实体（Entity）
——客观存在并能相互区分的事物
如：人；数据库课程；正是用的计算机；一 场足球赛不能严格地定义实体，正如几何中“ 点”，“线”一样。
关键之处：一个实体能和别的实体区分开。
1.2.3概念模型
● 实体型（Entity Type）
——用实体名及属性名集合来抽象刻画同类实体
● 实体集（Entity Set）
——同型的实体组成的集合。
2．属性（Attribute）
——指实体所具有的某一方面的特性，一个实体可 由若干个属性来刻划。
- 属性取值在一定的范围，称为该属性的值域/域 （Domain）
- 唯一标识实体的属性集称为码(Key)
1.2.3概念模型
3．联系（Relationship）
——实体集合间存在的相互关系
为了建立现实世界的完整模型，常常需要对联系 分
类，根据一个实体集合的实体可以和多少个另一类
实体集合的实体相联系，可将联系分为如下几种：
(1) 一对一联系（1：1） 系——系主任
(2) 一对多联系（1：n） 班级——学生
(3) 多对多联系（m：n） 课程——学生
1.2.3概念模型
举例1：（具体见萨师煊等主编《数据库系统概论》 Page17-18）
两个实体型之间的联系（图1.10）
三个实体型之间的联系（图1.11）
一个实体型之间的联系（图1.12）
举例2：（具体见萨师煊等主编《数据库系统概论》 Page19-20）图1.14、图1.15
1.2.3概念模型
4． 实体-联系图
（1） 确定所有实体集合
用矩形方框表示实体集合，方框内标明实体集合名 称；
（2） 选择实体集应包含的属性
用椭圆框表示属性，通过无向边连接到实体集。只 有一个属性的实体集可用属性代替，附加到它参加 的联系上；
（3） 确定实体集之间的联系
用菱形框表示，框内标明联系的名称，通过无向边 （或有向边）连接到参加联系的每个实体集合；
1.2.3概念模型
（ 4）确定实体集的关键字
用下划线在属性上标明关键字的属性集合；
（5） 确定联系的类型
在用无向边连接联系到实体集时，在边上注明1或 n（多）来知名联系的类型。（在用有向边连接 联系到实体集时，让边的箭头指向1的实体集的 一方，多对多因为都是多方，故无箭头）
1.2.4 三种主要的逻辑数据模型
上节讨论的概念数据模型是“概念上”的，是抽象的，它与具体的数据库管理系统无关。这节要讨论的数据模型将与具体的DBMS有关，与DBMS支持的数据和联系的表示或存储有关。
前面提到过，数据库中不仅要存放数据本身，还要存放数据间的联系，可用不同的方法表示数据与数据之间的联系。
把表示数据与数据之间联系的方法称为逻辑（数据）模型。
1.2.4 三种主要的逻辑数据模型
一、 层次模型（Hierarchical Model）
用树型结构来表示实体之间联系的模型。
支持层次模型的典型系统诞生于1970年前后，是IBM
公司的IMS（Information Management System）系统。
1. 层次模型的数据结构
层次模型示例（萨师煊等主编《数据库系统概论》
Page22 图1.17）
举例： Page23
1.2.4 三种主要的逻辑数据模型
2．层次模型的数据操纵与完整性约束
3．层次模型的存储结构
4．层次模型的优缺点
优点：结构简单
缺点：插入、删除限制多
1.2.4 三种主要的逻辑数据模型
二、网状模型（Network Model）
典型代表：DBTG（Data Base Task Group）数据
库任务组
1． 网状模型的数据结构
2． 网状模型的数据操纵与完整性约束
3． 网状模型的存储结构
4．网状模型的优缺点
优点：更能直接描述世界
缺点：结构复杂
1.2.4 三种主要的逻辑数据模型
三、 关系模型（Relational Model）
1970，IBM，E.F.Codd
关系模型源于数学，它把数据看成是二维表（关系） 中的元素。（其严格定义下一章给出）
用关系表示（不需用指针）实体和实体之间联系的模 型称为关系模型。
基本术语：萨师煊等主编《数据库系统概论》Page31
举例见教材
对于用户，关系方法应该是很简单的，但RDBMS很 复杂，因为将大量工作都转嫁给了RDBMS。
1.2.4 三种主要的逻辑数据模型
RDBMS的设想在层次、网状数据库诞生的同时产生的，但研制开发RDBMS却花费了比人们想象的要长得多的时间。所以成为商品并投入使用比层次、网状数据库晚了十几年。但一投入使用就显示了旺盛的活力，并逐步取代层次、网状数据库。
1.3 数据库系统的结构
1.3.1 数据库系统模式的概念
当设计数据库时，对数据库的结构感兴趣；
即模式（Schema）：数据库中数据的逻辑结 构和特征的描述
当应用数据库时，关心的是数据库中存在的数据——
实例（Instance）。
数据库中的数据经常变化，而数据库的结构在一定时
间范围内不会改变。
数据库中结构的定义可以在多个抽象级别进行，形成
多个级别的数据库模式。
1.3.2 数据库系统的三级模式结构
数据库系统的三级模式不仅可以使数据具有独立性，而且还可以使数据达到共享，使同一数据满足更多用户的不同要求。
一、 内模式（Internal Schema）
——存储模式
● 是数据在数据库系统的内部表示，即对数据的物 理结构/存储方式的描述，是低级描述，一般由 DBMS提供的语言或工具完成；
1.3.2 数据库系统的三级模式结构
● 要修改存储数据库的结构（例如，用倒排文件代替多
链表），那么仅仅需要把这些修改反映在存储模式中；
● 通常我们不关心内模式的具体技术实现，而是从一般组
织的观点（即概念模式）或用户的观点（外模式）来讨
论数据库的描述。但我们必须意识到基本的内模式和存
储数据库的存在。
1.3.2 数据库系统的三级模式结构
二、 模式（Schema）
——逻辑模式
● 是数据库中全体数据的逻辑结构和特性的描述， 是所有用户的公共数据视图；
● DBMS提供数据定义语言DDL来描述逻辑模式，严 格定义数据的名称、特征、相互关系、约束等。
1.3.2 数据库系统的三级模式结构
三、 外模式（External Schema）
——用户模式（视图）
● 是模式的子集或变形，是与某一应用有关的数据 的逻辑表示；
● 不同用户需求不同，看待数据的方式也可以不同 ，对数据保密的要求也可以不同，使用的程序设 计语言也可以不同，因此不同用户的外模式的描 述可以使不同的。
1.3.2 数据库系统的三级模式结构
举例：
民航售票系统包括处理航班程序和处理旅客程序。
- 程序的使用人员不必知道关于人事档案、丢失的行 李、飞行员的航行分配等信息；
- 调度员可能需要知道关于航班、飞机和人事档案等 信息（如那些飞行员有资格驾驶747），但不必知道雇员的工资、旅客等信息。
所以可以为订票部门建立一个数据库视图，为调度部门建立另一个完全不同的部门。
1.3.2 数据库系统的三级模式结构
Note：视图处理的数据并不实际存储在数据库中，而仅可以从逻辑数据库中构造出来。视图比（逻辑）模式的抽象级别更高。
举例：“年龄”在人事部门数据库中，但（逻辑）模式重金包含出生年月。当用户希望通过访问视图得到年龄时，DBMS翻译这个要求，在从物理数据库上取出的数据完成计算。
注：一个数据库只有一个模式，一个内模式，但可以有多个外模式。
1.3.3 数据库的二级映象
在三级模式中提供了两级映象，保证了数据库系统的数据独立 性，既物理独立性与逻辑独立性。
一、 外模式/模式映象
数据库系统投入使用后，可能有必要修改模式（如增加新关系、属性、改变类型），这时：
重新定义外模式/模式映象==〉现存外模式不变==〉应用程序不变
DBA职责
1.3.3 数据库的二级映象
二、 模式/内模式映象
当内模式发生变化时：
重新定义模式/内模式映象==〉模式保持不变==〉外模式保持不变==〉建立在外模式上的应用程序保持不变
1.5 数据库技术的研究领域
1. 数据库管理系统软件的开发
2．数据库设计
3．数据库理论
具体见萨师煊等主编《数据库系统概论》page39-40
第二章 关系数据库
1．关系操作
查询操作：选择/ 投影/ 连接/
除/ 并/ 交/ 差
2.1 关系模型概述
从数据模型的三要素加以介绍
一、数据结构
——关系
二、 关系操作
增加、删除、修改
2.1 关系模型概述
元组关系演算：谓词变元的基本对象是元组变量
域关系演算：谓词变元的基本对象是域变量
Note：关系代数和关系演算是抽象的查询语言，与具体的DBMS中实际语言不一样，但彼此等价，是从抽象的观点出发学习数据库查询的问题。
3．关系数据语言（具体见萨师煊等主编《数据库系统概论》page47）
2．关系操作的表示方法：
·关系代数：用对关系的运算表达查询要求
·关系演算：用谓词表达查询要求
2.1 关系模型概述
实体完整性
关系模型必须满足的完整性约束条件
参照完整性
三、关系的完整性约束条件
用户定义的完整性：针对某一具体数据库的约束条件
反映某一具体应用所设计的数据 必须满足的语义要求。
（关系系统自动支持）
2.2 关系数据结构及形式化定义
2.2.1 关系
一、 基本概念（具体见萨师煊等主编《数据库系统概论》page47-）
1． 域（Domain）
2． 笛卡尔积（Cartesian Product）
元组（Tuple）
3． 关系（Relation）
分量（Component）
候选码 Candidate Key
非码属性Non-key attribute
主码 Primark Key
全码 All-key
主属性Prime attribute
2.2 关系数据结构及形式化定义
二、关系的三种类型
基本关系（基本表）：实际存在的表，是实际存 储数据的逻辑表示
三、 关系的性质（6条，具体见萨师煊等主编《数据库系统概论》P50）
查询表：查询结果对应的表
视图表 ：由基本表或其它视图标导出的表，
虚表，不对应实际存储的数据
2.2.2 关系模式
值（Value）：是型的一个具体赋值
——关系是值
型（Type）：对某一类数据的结构和属性的说明
——关系模式是型（关系模式是对关 系的描述）
2.3 关系的完整性
（具体见萨师煊等主编《数据库系统概论》P52-55）
2.4 关系代数（Relational Algebra）
关系代数是对关系运算的总和，关系运算分两类:
2.4.1 传统的集合运算
——并／交／差／积（按行）
2.4.2 专门的关系运算
——选择/ 投影/ 连接/ 除（按行、列）
一、 几个记号和概念
１． 元组，分量
２． 属性列域，剩余属性组
３． 元组的连接
４． 象集
关系运算定义（具体见萨师煊等主编《数据库系统概论》P58-64）
第三章 关系数据库标准语言——SQL
关系代数和关系演算是形式化查询语言，商业DBMS使用SQL（Structured Query Language）。
·1974 年由IBM 的San Jose研究室提出，最初叫SEQUEL（Structured English Query Language）
·关系数据库系统通过SQL对数据库进行查询和更新
·目前有许多不同版本的SQL语言,有两个不同的主要标准:
ANSI(American National Standards Institute) 1986
ISO(International Standards Organization)：
SQL-89,SQL-92,SQL 2,正在制定SQL 3
3.1 SQL语言概貌及特点
一、SQL特点
1． 一体化
SQL是一种一体化的语言，它包括了数据定义、查询、 更新、控制四方面功能。
·可以完成数据库活动中的全部工作
·以前的非关系模型的数据语言一般包括：内模式描述语 言、模式描述语言、外模式描述语言、数据操纵语言等 。内容多，操作起来不像SQL那样简单。
3.1 SQL语言概貌及特点
2． 高度非过程化
没有必要一步步地告诉计算机“如何”去做，只需描述清楚用户要“做什么”，SQL就可以将要求交给系统，自动完成全部工作。
3． 面向集合的操作方式
操作对象、查询结果是元组的集合；
插入、删除、更新操作的对象也可以是元组的集合。
3.1 SQL语言概貌及特点
4． 两种使用形式，统一的语法结构
自含式：将SQL作为操作命令独立使用
现在许多数据库开发工具都将SQL直接融入到自身的语言中。
宿主式：将SQL嵌入到高级语言中使用
3.1 SQL语言概貌及特点
5． 语言简洁
SQL虽然功能强且使用两种方式，但只有为数不多的几条命令，另外语法也非常简单，接近自然语言，易掌握、学习。
除了以上特点之外，SQL语言还支持数据库的三级模式结构。（具体见萨师煊等主编《数据库系统概论》Page87）
3.1 SQL语言概貌及特点
二、SQL语言组成
SQL同一般的程序设计语言一样,由以下几个部分组成：
1． 常量：文本常量（字符串）、整型常量、数值常量
2． 数据类型：以IBM DB2 SQL为例，具体见萨师煊等主
编《数据库系统概论》P89
3． 空值：NULL
3.1 SQL语言概貌及特点
集合运算符：∩、∪、-
算术运算符：+，-，*，/
5 . 函数
SQL 提供了非常丰富的内部函数——聚集函数
（详见萨师煊等主编《数据库系统概论》P100）
4. 运算符
字符串运算符：|| （连接）
比较运算符：6个
逻辑运算符：NOT，AND，OR
3.1 SQL语言概貌及特点
6． 谓词
SQL为了具有强大的查询能力，提供了一系列的谓词：
· BETWEEN AND / NOT BETWEEN AND
介于两者之间 /介于两者之外
· IN / NOT IN 在其中/不在其中
· LIKE 匹配
· IS NULL / IS NOT NULL
· EXISTS/ NOT EXISTS 存在/不存在量词
· ANY 任意一个存在量词
· ALL 全程量词
3.1 SQL语言概貌及特点
7． 表达式
8． 条件
由一个或多个含有比较运算符的表达试及逻辑运算符组合而成。
命令（具体见萨师煊等主编《数据库系统概论》P86 表3.1）
3.2 数据定义
存储过程定义
基本表定义
定义功能
数据库的定义：和物理数据有关，以后介绍
视图定义
索引定义
规则定义
与数据完整性有关，以后介绍
3.2.1 定义、删除与修改基本表
(具体见萨师煊等主编《数据库系统概论》P88)
3.2.2 建立与删除索引
(具体见萨师煊等主编《数据库系统概论》P90)
在使用关系数据库系统时，用户所看到和操作的数据好像在简单的二维表中，而实际上数据在磁盘上是如何存储的用户可能不知道。然而数据的物理存储如何却使数据库主要性能的主要因素。
——索引时最常见的改善数据库性能的技术。
CREATE TABLE 〈表名〉（〈列名〉〈数据类型〉[列级完整性约束条件][，…]…[，表级完整性约束条件]
例：CREATE TABLE Student (Sno CHAR(5) NOT NULL UNIQUE,SNAME CHAR(20) UNIQUE,SSEX CHAR(1),SAGE INT,SDEPT CHAR(15));
修改基本表：
ALTER TABLE 〈表名〉[ADD〈新列名〉〈数据类型〉[完整性约束]]
[DROP〈完整性约束名〉]
ALTER 〈列名〉〈数据类型〉]；
例：向学生表增加“入学时间”—日期型
ALTER TABLE STUDENT ADD Scome date;
修改年龄为半字长整数
ALTER TABLE STUDENT ALTER SAGE SMALLINT
删除学生姓名必须取唯一值的约束。
DROP TABLE Student DROP UNIQUE Tag Sname
DROP TABLE <表名>
3.2.2 建立与删除索引
关于索引
· 索引的建立和删除由DBA或建表的人负责，用户不必也不能在存取数据是选择索引；
· 作为一般规则，不应该在一个表上建立太多的索引（2-3个）。索引能改善查询效果，但也耗费了磁盘空间。降低了更新操作的性能。因为系统必须花时间来维护这些索引；
·表中数据越多，索引的优越性才越明显。
3.3.1 单表查询
指定列
消除重复行
● 选择表中若干列
全部列
经计算的列
● 选择表中若干元组
查询满足条件的元组
● 对查询结果排序
● 对查询结果分组
3.3.2 连接查询
● 等值/非等值连接
● 自身连接
● 外连接
● 复合条件连接
3.3.3 嵌套查询
● 带有IN谓词的查询
● 带有比较运算符的查询
● 带有ANY或ALL谓词的子查询
● 带有EXISTS谓词的查询
3.3.4 集合查询
具体见萨师煊等主编《数据库系统概论》P114
3.3.5 SELECT 语句的一般格式
具体见萨师煊等主编《数据库系统概论》P 115
3.4 数据更新
插入、修改、删除数据（具体见萨师煊等主编《数据库
系统概论》P117）
一、插入数据
1． 插入单个元组
2． 插入子查询结果
3.4 数据更新
二、修改数据
1． 修改一个元组的值
2． 修改多个元组的值
3． 带子查询的修改语句
3.4 数据更新
三、删除数据
1．删除一个元组的值
2．删除多个元组的值
3．带子查询的删除语句
4．更新操作与数据库的一致性
3.5 视 图
一、关于视图：
· 视图是原始数据库数据的一种变换，是查看表中数据
的另外一种方式；
· 可将视图看成是一个移动的窗口，通过它可看到感兴
趣的数据；
· 视图可从一个或多个实际表中获得；
· 视图的定义存在数据库中，而数据并没再存一份在数
据库中，通过视图看到的数据存放在基本表中；
· 对视图的操作同其它表一样，通过视图修改数据时，
实际是修改基本表中的数据，相反，基本表数据的改
变也会自动反映在由基本表产生的视图中。
3.5 视 图
二、视图的作用
1． 简单性
——看到的就是用户需要的
不仅可简化用户对数据的理解，也可简化它们的操 作。经常使用的查询可以被定义为视图。
3.5 视 图
2． 安全性
通过视图用户只能查询和修改他们能见到的数据， 数据库其它数据则既看不到也取不到。
数据库授权命令可是用户对数据库的检索限制到特 定的数据库对象上，但不能授权到数据库特定的行 、列上。
视图可防止未授权用户查看特定的行/列
3． 逻辑数据独立性
3.5 视 图
一、 定义视图
具体见萨师煊等主编《数据库系统概论》P121-124
二、 查询视图
具体见萨师煊等主编《数据库系统概论》P125
三、 更新视图
具体见萨师煊等主编《数据库系统概论》P126
3.6 数据控制
SQL数据控制功能对数据库中数据的安全控制提供保护，主要表现在对数据使用的授权(GRANT)和收回授权(REVOKE)。
每个用户对自己拥有的资源可以由任意的操作权限，同时也可以把其中的一部分权限授予他人。
（具体见萨师煊等主编《数据库系统概论》P130）
3.6 数据控制
一、授权
3.6 数据控制
二、收回权限
注：授权(GRANT)和收回授权(REVOKE)并不是数据库的全部控制功能，只是其中的一小部分，其它功能如安全性、完整性、并发控制和恢复在7、8、9、10章介绍。
3.7 嵌入式SQL
前面几节介绍的SQL,，是作为独立的数据语言直接由用户在交互环境下使用的。此外，SQL还可以作为子语言嵌入在宿主语言（PASCAL、C等）中使用。
SQL作为子语言嵌入在宿主语言中使用必须要解决以下三方面问题：
1．嵌入识别问题
宿主语言的编译程序不能识别SQL语句，所以首要问题要解决如何区分宿主语言的语句和SQL语句。
3.7 嵌入式SQL
2． 宿主语言与SQL语言的数据通信问题
DBMS将SQL语句的查询结果或执行状态必须交给宿主语言/应用程序处理（通过SQLCA）；运行时，宿主语言的数据通过变量（称为主变量）也要能够交给SQL使用。
3． 宿主语言的单记录与SQL的多记录的问题
宿主语言一般一次处理一条记录；SQL语言常常处理的是记录（元组）的集合，其查询结果通常是含多个记录的一张表。——“阻抗不匹配”
本节将围绕如何解决这三个问题来介绍。
3.7 嵌入式SQL
一、 嵌入识别与预编译
解决方法：为SQL语句加一个特殊的前缀。
在用宿主语言的编译系统编译源程序之前，首先由预编译系统将SQL语句转换为宿主语言的合法函数调用。
3.7 嵌入式SQL
3.7 嵌入式SQL
一、 数据通信区与主变量
1．数据通信区SQLCA
——SQL Communication Area
在嵌入SQL语句的程序中，一般在程序的前部 都要有一条语句：
EXEC SQL INCLUDE SQLCA
这里SQLCA即是SQL与宿主语言的通信区，它 类似于结构变量，各个变量分别反映SQL语句 的各种执行状态。
3.7 嵌入式SQL
DBMS：数据库厂商标识
0：成功
例如：SQL Anywhere 中SQLCA有16个属性：
SQLCode (long): 存放执行SQL后返回的代码—
100：SELECT找不到符合条件的记录
-1：SQL操作错误
DataBase
Userid
DBPass
SQLErrText：错误代码
SQLDBCode：错误信息
…
…
3.7 嵌入式SQL
SQL被执行时，DBMS将产生的各类系统信息（如执行状态信息）写入系统通信区，应用程序在调用SQL后，可通过读取数据通信区中信息来确定语句执行情况。
应用通过SQLCA与数据库通信
应用
SQLCA
DBMS
连接参数
状态信息
3.7 嵌入式SQL
输出主变量：SQL对其赋值或设置状态信息，返回给应 用程序。
利用它可得到SQL语句的结果数据和状态。
输入主变量：由应用程序赋值，SQL引用。
可用于：插入数据、修改值、制定条件 （WHERE）
2． 主变量
SQL语句使用宿主语言的变量来输入/输出数据
主变量（Host Variable）
主变量根据作用不同分为：
3.7 嵌入式SQL
Note：所有变量要在
BEGIN DECLARE SECTION
…
END DECLARE SECTION
之间说明。
3.7 嵌入式SQL
三、 游标（Cursor）
当查询结果超过一个元组时，不能一次性将结果值赋给宿主语言的变量，因为主变量仅能保存一个数据，而不是一组数据。为此，引进一个特殊的数据结构——游标（Cursor）。
游标是系统为用户开设的一个数据缓冲区，存放SQL的执行结果。可将其理解为一个指示器，指向数据库中满足条件的元组。
游标包含两部分内容：
结果集：游标内SELECT语句执行后产生的集合；
游标位置：游标指针的当前位置。
3.7 嵌入式SQL
游标的定义和使用分为下面几步：
● 声明游标
不可执行的指令，仅定义游标，SELECT语句没有执行
（类似于变量说明）
● 打开游标
执行SELECT语句，将结果放入结果集中。
● 推进游标
移动指针，该变结果集的当前记录。
● 通过游标更新数据
● 关闭游标
程序实例（具体见萨师煊等主编《数据库系统概论》 P136-146）
第四章 关系系统及查询优化
具体见萨师煊等主编《数据库系统概论》P151-167
4.1.3 全关系系统的12条基本准则
4.1 关系系统
4.1.1 关系系统的定义
4.1.2 关系系统的分类
4.2 关系数据库系统的查询优化
4.2.1 关系系统及其查询优化
4.2.6 优化的一般步骤
4.2.5 关系代数表达式的优化算法
4.2.4 关系代数等价变换规则
4.2.3 查询优化的一般准则
4.2.2 一个实例
第五章 关系数据理论
数据库设计的一个最基本的问题是如何建立一个好的数据库模式。
即给出一组数据，如何构造一个适合于它们的数据模式，使数据库系统无论是在数据存储方面，还是在数据操纵方面都有较好的性能。
E-R模型方法讨论了实体与实体之间的数据联系，现在来讨论实体内部属性与属性之间的数据关联，目标是要设计一个“好”的数据库模型。
5.1 问题的提出
1．关系模型定义——复习
2．在解决如何设计一个好的数据库模式之前，先看一 看什么是“不好”的数据库设计（关系数据库模式可 能出现的异常）。
例：建立一个关系数据库来描述学生的一些情况， 该数据库只包含一个关系模式： 学生（学号，姓 名，系名，系主任，课程，成绩）
3. 例：具体见萨师煊等主编《数据库系统概论》P171 页
5.1 问题的提出
（1）存在的问题：
i. 数据冗余：姓名，系名，系==〉重复出现。
ii. 更新异常：某一元组修改系主任，其他不变==〉 同一系，系主任不同，造成了数据潜在的不一致 性。
iii. 插入异常：系刚成立，尚未招收学生，主关键字 为空，则系主任、选的课都无法存入数据库，未 选课的学生信息也无法存入。
删除异常：一个系的学生毕业了，删除这些学生的记录，则系主任等信息也删除掉了。
5.1 问题的提出
（2）产生异常的原因：
这些异常的产生主要是因为关系模式的结构，即关系模式中的属性之间存在过多的数据依赖关系，与现实世界不符合。
注：数据依赖关系——最重要的一类是函数依赖。
· 主关键字（学号+课程）一定，元组就确定了， 元组分量也就确定了，即所有其它属性都依赖于 “学号”和“课程”。
· 但实际：学号→姓名，不需选课。
系名→系主任。
5.1 问题的提出
（3）解决：
分解为三个新的关系模式：
学生（学号，姓名，系名）
成绩（学号，课程，成绩）
系（系名，系主任）
这样上面提到的问题不存在了，将学生、成绩和系三个相对独立的实体划分开来，使之更符合现实世界的实际。
5.2 规范化（Normalization）
5.2.1 函数依赖(Functional Dependency)
回顾：函数——熟悉的概念。
Y=f(x)：x和Y之间数量上的对应关系。给定x值，Y值
与之对应。称x函数决定Y，或Y函数依赖于x。
在关系数据库中讨论函数或函数依赖注重的是语义上
的关系。
如：省=f(城市)
5.2.1 函数依赖(Functional Dependency)
定义⒈ 函数依赖（具体见萨师煊等主编《数据库系统概论》172页）
说明：
· t1[x]=t2[x]==〉t1[r]=t2[r]成立，就有x→Y。
·只有当t1[x]=t2[x]为真，而t1[Y]=t2[Y]为假时 ，x→Y。
·当t1[x]=t2[x]为假时，不管t1[Y]=t2[Y]为T/F， 都有x→Y。
比如：当x为关键字属性时，t1[x]=t2[x]肯定为F ，但x→Y成立。
5.2.1 函数依赖(Functional Dependency)
术语和记号：
⑴．非平凡的函数依赖(Nontrivial Functional Dependency)
——通常讨论。
x→Y，但Y≤x(Y不包含于x),则x→Y称为非平凡 的函数依赖。
若Y≤x, 显然x→Y成立。（称为平凡的函数依赖 。Trivial Functional Dependency）
5.2.1 函数依赖(Functional Dependency)
⑵ 决定因素（Determinant）
若x→Y，则x称为决定因素（决定方）。
⑶ x→Y,Y→x则记作x←→Y。 如：学号←→姓名。
⑷ 若Y不函数依赖于x，记作x→Y。
5.2.1 函数依赖(Functional Dependency)
定义⒉ 完全函数依赖（Full Functional Dependency）：
若x→Y，并且对x的任何一个真子集x',都有x’→Y, 则称Y完全函数依赖x,记作x →Y.
部分函数依赖（Partial Functional Dependency）：
若x’→Y成立，则称Y部分函数依赖于x.记作x→Y 。（与书上定义比较）
例：5.1 模式中，（学号，课程）→系名
f
p
p
5.2.1 函数依赖(Functional Dependency)
定义⒊传递函数依赖（Transitive Functional Dependency）:
若x→Y，（非平凡函数依赖，且Y→x），Y→Z, 则称Z传递函数依赖于x。
∵若Y→x，则x←→Y，x—→Z。
直接
5.2.1 函数依赖(Functional Dependency)
例：·教室（课程，班级，时间，教室）——完全函数依赖
（课程，班级，时间）→教室
·教师（姓名，职务，职务工资）——传递函数依赖
姓名→职务
职务→职务工资 则姓名→职务工资
·前面例子： 三个新的学生关系模式中：——非平凡 函数依赖
学号→姓名
学号→系
系→系主任
（学号，课程）→成绩
f
5.2.2 码
现实世界的每一实体集合，都有一关键字（码），即唯一确定各个实体的一组属性。同样，关系上最重要的约束是关系的关键字约束，即关键字/码唯一确定关系的元组。
⒈ 候选码（Candidate Key）与主码（Primary Key）
⒉ 外部码（Foreign Key）
例： 学生选课（学号，课号，成绩）
F
学生（学号，姓名，年龄）
P
注：主码与外码（主关键字与外关键字）提供了一个表示关系间联系的手段。
5.2.3 范式
在关系数据模式设计中，为了避免由依赖引起的数据的冗余和更新异常问题，必须进行关系数据模式的规范化。
自1971年，E.F.Codd提出关系规范化理论以来，人们对规范化问题进行了长期的研究，并已经有了很大进展。
范式(Normal Form)的概念最早是由E.F.Codd提出的，1971～1972年，先后提出了1NF,2NF,3NF(根据关系模式满足的不同性质和规范化的程度划分)。1974年，又和Boyce共同提出了BCNF（Boyce-Codd Normal Form）。1976年，Fagin提出了4NF，后又有人提出5NF。最重要的是3NF和BCNF。这是进行规范化的主要目标。
5.2.3 范式
（具体见萨师煊等主编《数据库系统概论》P 174页，图5-2）
1. 第一范式（1NF）：
（具体见萨师煊等主编《数据库系统概论》P170）
——每个关系模式都应满足的最低要求。
即关系的所有分量都必须是不可分的最小数据项。
系名称 高级职称人数
教授 副教授
5.2.3 范式
2. 第二范式（2NF）：
（具体见萨师煊等主编《数据库系统概论》P174）
㈠ 定义：若R∈1NF，且每一非主属性完全函数依赖
于码，则R∈2NF。
· 所有单属性关键字都是2NF关系。
· 复合关键字（多属性构成），且存在非主属性
对关键字的部分依赖，则否。
5.2.3 范式
㈡ 反例：
例：库存（仓库号，设备号，数量，地点）
1NF，但非2NF。
非主属性数量完全依赖于关键字。
非主属性地点部分依赖于关键字。
即有仓库号→地点。
（仓库号，设备号）→地点。
p
5.2.3 范式
㈢ 出现的问题：
一个仓库若只有一种设备，则删除设备→删除仓库。
·学生关系：
学生（学号，姓名，系名）
不是2NF。
只有成绩完全函数依赖于码，姓名、系名、系 主任对码部分依赖，因为它们由学号可决定。
5.2.3 范式
㈣ 解决办法——投影分解
· 将部分函数依赖关系洪的决定方和非主属性从关系 模式中提出，单独构成一个关系模式。
· 将余下属性加上码（仍要保留部分函数依赖的决定 方属性，起分解出来的新关系之间的关联作用）构 成另一关系模式。
5.2.3 范式
例：⑴库存（仓库号，设备号，数量）
仓库（仓库号，地点）
⑵学生记录（学号，姓名，系名，系主任）
r(学生记录)=Π（学号，姓名，系名，系主任） （r’(学生)）
成绩（学号，课程，成绩）
r(成绩)=Π<学号，课程，成绩>（r’(学生)）
5.2.3 范式
1. 第三范式（3NF）：
㈠定义：（具体见萨师煊等主编《数据库系统概论》P176）
若R∈2NF，并且所有非主属性都不传递依赖于关键字，则R∈3NF。
·若存在非主属性对关键字的传递依赖，则不是3NF。
5.2.3 范式
㈡ 反例：
例：仓库（仓库号，所在省，仓库面积，所在城市）
仓库号→所在城市，所在城市→所在省。
∴仓库号→所在省。 ↓非3NF
㈢ 问题：插入异常：
如插入（“WH30”，“湖北”，400，“邯郸”）
（“WH22”，“河北”，240，“ ”）
再如：在山东济南要设一个仓库，想先存入有关所
在城市信息，但无仓库号，则不能。
5.2.3 范式
㈣ 解决——投影分解：（将传递依赖的属性分解出来
——自己总结的）
仓库（仓库号，仓库面积，所在城市）
城市（省，城市）
再例：
学生记录（学号，姓名，系，系主任）不是3NF
∵学号→系， 系→系主任， ∴学号→系主任
系主任对码（学号）的传递依赖。
分解：学生档案（学号，姓名，系名）
系（系名，系主任）
5.2.3 范式
4. BCNF范式：
由于3NF仍存在一些操作异常，......
㈠ 定义：（具体见萨师煊等主编《数据库系统概论》
P176）
——即若R
键字/码（或所有的决定因素 都是关键字）
，则R
5.2.3 范式
——或：若R
——一个满足BCNF的关系模式一定是非主属性对 码完全函数依赖;
主属性对不包含它的码也是完全函数依赖；
设有属性完全函数依赖于码以外的属性组。
5.2.3 范式
㈡ 举例及讨论：
例：⑴.管理（仓库号，设备号，职工号） 3NF，非
BCNF。
语义：①.一个仓库可有多个职工；
②.一名职工仅在一个仓库工作；
③.在每个仓库，一种设备仅由一名职工保管
（但每名职工可以保管多种设备）。
根据语义有依赖：职工号→仓库号；
（仓库号，设备号）→职工号；
问题：·新职工分到一仓库，尚未负责设备，则不能
插入。
·插入异常：同一设备，两个职工，无法防止
这样插入，与③违背。
5.2.3 范式
例：⑵.学生（学号，姓名，专业，宿舍）
·假定无重名，则码为学号或姓名，非主属性
对这两个码不存在部分函数依赖和传递函数
依赖，∴是3NF。
而同时除{学号}和{姓名}以外没有其他决定
因素，∴也是BCNF。
5.2.3 范式
例： ⑶.通讯（城市，街道，邮编）
↓完全依赖于码，且无传递依赖，∴是3NF。
·但邮编→城市，它是决定因素，它不是码，也不 包含在码中，∴非BCNF。
·非BCNF分解→BCNF，会破坏函数依赖。
Solution: 保持3NF，警惕主属性对非主属性的函数依赖带 来的操作异常现象。
5.2.3 范式
5. 多值依赖与第四范式：
㈠. 多值依赖(Multivalent Dependency):
定义5.9(具体见萨师煊等主编《数据库系统概论》
P178)
例：⑴(P178)
①增加一名教师，要插入多个（三个）元组；
②去掉一本参考书，要删除多个（两个）元组
∴数据冗余明显，增加、删除不方便，日积
月累可能出现数据错误 。
5.2.3 范式
原因：关系上存在着一种多值依赖。
·对于（物理，光学物理）有一组值{李勇，王
C Z Y
军}——T与之对应。
这组值决定于课程上的值，与参考书的值无关。
↓即另一个（物理，普通物理学）对应的一组
值仍为 T。
∴ T多值依赖于C，即 C→→T 。
5.2.3 范式
例：⑵P180
(W1,C1)有一组值{S1,S2}与之对应，与无关。
(W1,C2)有一组值{S1,S2}与之对应，与无关。
... ...
对W的每一个值Wi，S有一完整的集合与之对应,
而与C无关.
∴W→→S, 同样W→→C。
5.2.3 范式
㈡ 多值依赖的性质：
（具体见萨师煊等主编《数据库系统概论》P181）
· 对称性：若x→→Y，则x→→Z.
· 函数依赖是多值依赖的特例（即函数依赖的一定是
多值依赖），多值依赖是函数依赖的概括（即存在
多值依赖的关系，不一定存在函数依赖关系。）：
若x→Y，则x→→Y.
· 平凡的多值依赖：若x→→Y，而Z=φ时。
· 若x→→Y，Z≤（包含于）Y，W→Z，且Y∩W=φ
，则x→W。
Notes：关系模式中至少有三个属性，才有可能存在
多值依赖。
5.2.3 范式
㈢ 多值依赖与函数依赖的区别：
· x→Y的有效性仅决定于x,Y这两个属性集的值，即仅
在 ∏xY(R)上成立即可；
而x→→Y的有效性与属性集的范围有关，需在U(整个
属性集)上成立。 R(U)
· x→Y在R(U)上成立，则对于∨Y’＜Y，有x→Y’成立；
而x→→Y在R(U)上成立，不能判定对∨Y’＜Y，有
x→→Y’成立。
5.2.3 范式
㈣4NF：
定义（具体见萨师煊等主编《数据库系统概论》P181）
一个关系模式若属于4NF，则必然属于BCNF，反之不一定；4NF关系消除了BCNF关系中不理想之处，因此比BCNF先进。
· 函数依赖只考虑关系模式的静态逻辑结构。
而多值依赖受关系模式取值的动态变化的影响，即当
在关系模式中删除一些元组时，多值依赖关系可能被
破坏。
5.2.3 范式
关于函数依赖
函数依赖——通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。
一个函数依赖成立就意味着关系在任意时刻的实例都满足函数依赖的条件。
要确定函数依赖成立，需弄清楚数据的语义（语义：是实现世界的反映，不是主观臆断或仅由关系的当前实例所决定。）
5.2.3 范式
多值依赖：（至少三个属性，才有可能存在多值依赖）
例: Transport(Cname,Caddr,Item,Sname,Saddr)
Item→→(Cname,Caddr)
一种商品可以有多位顾客订购，与由哪些供 应商供应无关。
Item→→(Sname,Saddr)
5.2.3 范式
多值依赖与函数依赖的区别：
·X→Y的有效性仅决定于X,Y这两个属性集的值，即
仅在 ∏xY(R)上成立可；
而X→→Y的有效性与属性集的范围有关，需在U(整
个属性集)上成立。 R(U)
·X→Y在R(U)上成立，则对于所有Y中的Y’,有x→Y’
成立；
而X→→Y在R(U)上成立，不能判定对所有Y’＜Y,
有x→→Y’成立。
·函数依赖只考虑关系模式的静态逻辑结构；
而多值依赖受关系模式取值的动态变化的影响，即当在
关系模式中删除一些元组时，多值依赖关系可能被破坏.
5.3 数据依赖的公有系统
——Armstrong公理
※ Armstrong公理：模式分解算法的理论基础。
已知R满足一组函数依赖F，如何知道R中还有哪些FD(函数依赖)？或由F还能推导出哪些FD？
——需要一套形式化的推理规则。
5.3 数据依赖的公有系统
一．Armstrong公理的内容及正确性。
（具体见萨师煊等主编《数据库系统概论》P183）
★ R(U,F)，X≤u，Y≤U，Z≤U。推导规则如下：
① 自反律（Reflexivity）：
若Y≤X，则x→Y。（平凡FD）
② 增广律（Augmentation）：
若X→Y，则x∪Z→Y∪Z。记为：XZ→YZ。
③传递律（Transitivity）：
若x→Y，Y→Z，则x→Z。
5.3 数据依赖的公有系统
★ 正确性：
·增广：若①t[XZ]=S[XZ]，则t[x]=S[x]， t[Z]=S[Z]；
②又由x→Y，有t[Y]=S[Y]；
由①和②得：t[YZ]=S[YZ]。
· 传递：s[x]=t[x]
↓x→Y
推出：s[Y]=t[Y]
↓Y→Z
推出：s[Z]=t[Z]。
5.3 数据依赖的公有系统
二．Armstrong公理的推论：(P184)
· 合并规则：若X→Y，X→Z，则X→YZ。
· 分解规则：若X→Y，Z≤Y，则X→Z。
·伪传递规则：若x→Y，YW→Z，XW→Z。
① ∵X→Y，X→Z（增广）；
∴X→XY，XY→YZ（传递）；
∴X→YZ。
② ∵x→Y，YW→Z（增广）；
∴xW→YW（传递）；
∴xW→Z。
5.3 数据依赖的公有系统
根据合并规则和分解规则得到结论：
引理1：（具体见萨师煊等主编《数据库系统概论》
P184）
x→A1A2A3...An←→ X→Ak成立（k=1,2,...n）
5.3 数据依赖的公有系统
三．逻辑蕴涵和闭包：
有时需要根据给定的一组函数依赖来判断另一些 FD是否成立，这是函数依赖逻辑蕴涵要研究的内 容。
例如：R(U,F),U{A,B,C},F={A→B,B→C}，问 A→C成立？
根据传递律∴A→C成立
这时说F逻辑蕴涵A→C。
5.3 数据依赖的公有系统
定义1. 逻辑蕴涵：（具体见萨师煊等主编《数据 库系统概论》P183定义5.11）
设有关系模式R(U,F),X≤U,Y≤U，如果 从F中的函数依赖能推导出x→Y，则称F 逻辑蕴涵x→Y。
5.3 数据依赖的公有系统
定义2. 闭包：（具体见萨师煊等主编《数据库系统概论》 P184，定义5.12）
在关系模式R(U,F)中，被F所逻辑蕴涵的函数依 赖的全体称作F的闭包，记为F+。
求闭包F+是理论上可计算而实际上不可计算的问 题。（麻烦）
如：从F={x→A1A2A3...An}出发，至少推导出2 的n次幂个不同的函数依赖。F+很大。
如：F={ x→Y，Y→Z }；
F+={x→x,x→Xy,xZ→xY,x→xYZ,xZ→xYZ...} 。
5.3 数据依赖的公有系统
定义3. 设F——函数依赖，X≤U,
XF+={A X→A能由F根据Armstrong公理导出}，
所有用Armstrong公理从F导出的函数依赖X→Ai 中Ai的属性集合,称为属性集X关于F的闭包.
例：R(U,F),U{A,B,C},F={A→B,B→C}，
若X={A}，则XF+={A,B,C}
X={B}，则XF+={B,C}
X={C}，则XF+={C}
5.3 数据依赖的公有系统
四．公理的完备性
定理：Armstrong公理系统是有效的，完备的。
有效性：对于关系模式R(U,F)，只要F中的函数 依赖为真，则用公理根据F推导出的函 数依赖也一定为T。
完备性：用公理能否推导出所有的FD 即F+中 所有的FD是否都能用公理推导出来？
若F+中有FD不能用公理推出，说明公 理不够用、不完全，就必须补充新的公 理。
5.3 数据依赖的公有系统
五．闭包的计算
★ XF+的计算可以间接解决F+计算的问题，即 可以帮助判定X→F是否属于F+。
算法：求属性集X关于U上的函数依赖集F的闭 包XF+（P185）.
例：（P185）设有R(U,F),U={A,B,C,D,E}
F={AB→C,B→D,C→E,EC→B,AC→B}
求：(AB) F+
(AB) F+={ABCED}
5.3 数据依赖的公有系统
附：关系规范化的基本原则
Normalization：一个低级范式的关系模式经投影分解→多个高一级范式的关系Scheme的集合。
主要思想：逐步消除数据依赖中不合适的部分，使各关系模式达到一定程度的分离——“一事一地”的模式设计原则。
即：让一个关系描述一个概念/一个实体/实体间的一种联系。
5.3 数据依赖的公有系统
规范化的程度越高→数据的冗余和更新异常就相对减少。
但连接运算费时→查询花时间多。
∴根据具体情况，权衡利弊。
数据变动不频繁，规范化程度可低一些。实际工作中，一般达到3NF。
5.3 数据依赖的公有系统
原则：⑴关系模式进行无损连接分解（且保持FD）， 分解过程中，数据不能丢失或增加。把全局 关系模式中的所有数据无损的分解到各个子 关系模式中。以保证数据的完整性。（P189）
例：S(SNO,SDEPT,MN) 注：MN为负责人
正确的结果：S(SNO,SDEPT)
D(SDEPT,MN)
未解决插入删除异常：S(SNO,SDEPT)
D(SNO,MN)
∵SDEPT→ MN 无
5.3 数据依赖的公有系统
⑵合理选择规范化程度：
① 若考虑存取效率——低级范式冗余大，浪费空间， 影响一致性。∴希望属性越少越好， 取高级范式。
② 若考虑查询效率——低级范式比高级范式好。 ∵连接运算代价较少
∴根据情况，合理选择规范化程度。
①和②是一对矛盾。
5.3 数据依赖的公有系统
⑶正确性与可实现性原则
举例：
学号 姓名 性别 专业 年级 课程成绩
课号 课名 学时 学分 教师 工资号 成绩
5.3 数据依赖的公有系统
基本函数依赖集：
F1={学号→（姓名，性别，专业，年级），
课号→（课名，学时，学分，工资号，教师），
（学号，课程）→成绩，
工资号→教师}
1NF：学生（学号，姓名，性别，专业，年级， 课号，课名，学时，学分，教师， 工资号，成绩）
↓消除部分函数依赖
5.3 数据依赖的公有系统
2NF：·学生（学号,姓名,性别,专业,年级）；
课程（课号,课名,学时,学分,教师,工资号）；
·成绩（学号,课号,成绩）。
↓消除传递函数依赖
3NF： ·课程（课号，课名，学时，学分，工资号）
课号→工资号
·教师（工资号，教师）
工资号→教师
也是BCNF。
5.3 数据依赖的公有系统
补充：Normalization在实际数据库设计中的应用
前面介绍的Normalizationd的过程：（理论上）
定先用某种方法得到一个关系模式R
↓
分析并确定R上的FD和MVD
↓
用机械的方法进行模式分解，消除不适当的数 据依赖关系，从而规范化。
5.3 数据依赖的公有系统
实际应用并非这样：
⒈ 找出所有数据依赖关系不是一件简单的事。
若遗漏/出错，则得不到理论上认为好的DB。
⒉ 就算正确找出，机械分解，而不考虑具体情况，全 规范化到同样程度，也不适当。（是否常更新）
⒊ 数据库设计一般先：E-R图
而E-R图实体集合分解较细（包含属性较小）
∴为了以后DB查询的方便，更多的情况是合并模式 ，而非分解。
5.3 数据依赖的公有系统
★ 在实际应用中，为得到好的DB设计，要视具体
情况对数据库处理，既可合并，也可能分解。
但Normalizationd理论仍起指导作用。
第六章 数据库设计
6.1 数据库设计概述
6.1.1结构化生命周期法
——基于软件工程思想的一种信息系统设计方法
⒈ 可行性分析（系统调查）
⑴经济可行性分析：资金投入
⑵技术可行性分析：相应技术
⑶使用可行性分析：系统被用户接受、使用。
⑴⑵⑶都是整个项目立项与否的重要阶段，∴高层 决策者参与讨论决定。
6.1.1结构化生命周期法
⒉ 需求分析（系统分析）
其方法在P210，过程在P211。
系统开发中最重要的一步。
∵认识现实世界，了解企业需求是设计数据库的基础 ，否则，即使有先进的技术、高超的水平，也不可 能设计出用户所需的系统。
目标：详细调查要处理的对象，了解原系统（年工/以 前计算机系统）情况，确定新系统功能、目标。
虽然“技术含量不高”，但非常重要，是系统成功与否的关键。并且强调用户参与，离开用户将寸步难行。
6.1.1结构化生命周期法
⒊ 总体设计（概念结构设计）
把用户的信息要求统一到一个整体的逻辑结构或概念
模式中，独立于任何硬件和数据库管理系统。
应用程序：完成于系统划分、功能模块划分。
数据库角度：概念模型设计。
⒋ 详细设计（逻辑结构设计）
应用程序：给出功能模块说明，考虑实施方法，设计
存储过程。
数据库角度：根据具体的DBMS设计DataBase、设计关
系，考虑数据的完整性、考虑数据的安全和备份策略。
6.1.1结构化生命周期法
⒌编程
根据上一步设计结果进行具体实施。
建立数据库并装入原始数据，建立存储过程。
编程，调用应用程序代码。
⒍调试与试运行
前一阶段作了局部测试，现在：各子系统、各模块要
联合调试和测试，并试运行（试运行：听取用户意见
）。
6.1.1结构化生命周期法
⒎系统运行，评价与维护（运行）
最后一步将系统交给用户使用。
使用过程中，可能还会出现新的问题，甚至提出新要求，∴不断对系统评价，维护。
数据库系统的维护不是一朝一夕的事。只要DataBase System存在，就要不断的评价、调试、修改，直至数据库生命周期结束、或完全重新设计为止。
6.1.1结构化生命周期法
要求开发过程严格按阶段进行，前一阶段完成，才开
始下一阶段，没一阶段都要有严格的文档资料。
优点：每一步目标明确，易于管理。
缺点：用户只参与了需求分析阶段工作，对即将建立 的新系统没有直观的预见，很可能开发方开发 的系统不是用户所需要的。
6.1.2快速原型方法（Rapid Prototyping Approach）
——为克服前述方法的缺陷应运而生
⒈基本思想
根据原型进行快速开发，对存在的问题反复修正，直至形成用户满意的系统。
6.1.2快速原型方法（Rapid Prototyping Approach）
⒉ 原型
——“企业作业原型”、“软件功能原型”
反映了最终系统的基本功能黑本特征，依此可快速开发一个可以演示的系统，用户在这个原型系统中得到启发，发现存在的问题，提出新的要求，并和开发人员一起修正和发展原型，如此反复，最后形成用户满意的原型。
用户参与了开发的全过程；
整个过程用户看得见；
因系统离自己的目标越来越近而兴奋。
6.1.2快速原型方法（Rapid Prototyping Approach）
⒊ 优点
提高系统开发质量，降低开发成本，缩短开发周期，
最大程度的满足用户需求。
注：①采用该方法要有快速开发工具的支持；
②靠原始手工作坊式一条条编程不行；
③要求开发人员熟练掌握快速开发工具，对用户
的修改意见课作出快速的反应。
6.1.2快速原型方法（Rapid Prototyping Approach）
其它方法：
l 面向对象法；
l DADM演示与讨论；
l 生长与原型法；
l 软件复用技术。
6.2 需求分析
一、需求分析的任务
见萨师煊等主编《数据库系统概论》P209
二、需求分析的方法
见萨师煊等主编《数据库系统概论》P210
6.2 需求分析
三、数据流图（DFD）与数据字典
1．定义：
—— 系统的逻辑模型，不依赖于硬件，软件和 DataStructure
—— 便于用户理解的数据流程的图形表示
—— 分析元与用户之间非常好的通信工具，进一 步系统设计的出发点
6.2 需求分析
2．DFD的组成元素：
· 数据流（→）：用名字标记的→ 表示数据流。
将DFD中其它元素连接起来。
· 处理/加工（○）：对数据进行的操作。
把流入的数据流转化为流出的数据流。
注：每个处理应有一个名字表示它的含义，并分配一 个编号，以便标识它在层次结构中的位置。
· 存储：暂时存储数据的工具。
磁带，磁盘，文件，表
· 数据源点和终点：（□）系统的输入/输出；
系统之外的人员/组织；
系统数据的发送者/接受者；
6.3 概念结构设计
概念结构设计：在需求基础上，用数据模型表示数据
及其联系。
需求分析包括了：功能需求分析；
数据需求分析（数据库设计的基础）。
概念模型：不依赖于任何DBMS；
从现实世界角度对数据的抽象、描述；
容易为用户所理解。
6.3 概念结构设计
一．设计局部E-R图
概念结构设计依据是需求分析阶段的DFD/DD。
在DFD中选择适当层次的DFD，作为设计局部E-R图的出发点。 中层 允许有一定的重叠↓
⒈ 确定实体集合
第一步（关键一步）
数据流 / 数据源 / 目的 / 数据存储
↓根据具体情况决定 ↓常作为实体集合
6.3 概念结构设计
⒉ 联系
标明：1:1，1:N，N:M。
原则上：与处理框相关的输入流（数据流）， 输出流（数据目的地），输入或输出 的工作之间的可能存在的联系。
6.3 概念结构设计
⒊ 属性
属性名尽量和数据流中数据项名相同。
数据流实体的属性——数据流包括的数据项。
数据存储
数据源
数据目标
为简化E-R图，属性可仅在DFD中描述。
· 准则（P219）
实体属性——进/出该实体集的 某个数据流中
6.3 概念结构设计
⒋ 主关键字
属性中标明作为PK的属性集合。
⒌ 其它
建E-R图，要完善DD(DD：包括实体集，联系，属 性的描述)
某些情况：描述产生频率（每年/月/季），是否长 期保存，变化快慢，保密级别，存在的约束。
6.3 概念结构设计
二．集成局部E-R图
在设计局部E-R图的基础上，将局部E-R图集成为全 局E-R图。
集成时要解决的问题：
⒈消除冲突
⑴命名冲突：（P225）
同名异义
异名同义
实体 联系 属性
6.3 概念结构设计
⑵结构冲突：
l 同一概念在不同E-R图中意义、作用不同：实 体 属性 联系
l 同一实体在不同E-R图中包括属性组不同——
常见：∵局部应用关心侧重不同
↓Solution
并集→调整次序
l 同一联系在不同E-R图中类型不同。
6.3 概念结构设计
⑶属性冲突（P225）
⑷约束E-R图：同一数据项在不同的E-R图中有不同 的约束条件和访问权限。
具体集成时的原则：最后形成的模型和所有局部 模型一致。
若做不到：或许局部E-R图有错→修改
或许本来就是不同概念→不应视作一个
6.3 概念结构设计
⒉ 消除冗余
冗余：破坏DB完整性，维护起来困难
冗余数据：由基本数据导出的数据。
冗余联系：由基本联系导出的联系。
方法：⑴分析方法：以DFD、DD为依据，根据 逻辑关系消除
⑵规范化理论
6.3 概念结构设计
⒊ 合并局部E-R图
合并局部E-R图中相同部分
保留特殊部分
尽可能的
删除冗余部分
用累加的方式一次集成两个局部E-R图
6.3 概念结构设计
三．优化全局E-R图
必要时应对全局E-R图进行修改，重构和优化
→得到最佳的全局E-R图方案
规范化理论：
如：·根据需求分析收集的信息，确定FD
·使实体的属性都只依赖于PK
·部分FD或传递FD，判断是否分解出新的实体
6.4 逻辑结构设计
掌握E-R图向关系模型的转换原则。
（见萨师煊等主编《数据库系统概论》P230）
6.5 数据库的物理设计
DB特点——高效存取大量数据的能力。（依靠各类加 速存取DB的物理存储技术）
6.5.1 物理数据模型
一、记录和文件
关系在物理级表示为文件
——具有相同格式的记录集合。纪录：存储元组， 由一个或多个字段（字段：存储元组的含量） 组成（初等Data Type）。
流式文件：只能实现顺序存取
记录是文件：多种方法存取
在物理级，DB是一组文件（存储文件）；
文件是纪录的集合；
记录由字段组成。
区别：
6.5.1 物理数据模型
二、永久存储和分块
数据库运行时，外部存储器和主存之间要频繁地进行数据交换，每次交换的数据量称为一个数据块。在内存中开辟的缓冲区的大小至少要等于一个数据块的大小。数据块越大，一次能调进调出的记录数就越多。这种情况对顺序处理能减少访问磁盘的次数，提高了处理速度，但是对于以随机处理为主的应用系统就不一定合适了。因为数据块包含的记录数越多，同本次处理无关的记录可能传送的就越多，这样造成有效的数据传送降低，并且占用了更多的内存。所以，数据块的大小是考虑多方面因素后由厂家而非用户确定的。
6.5.1 物理数据模型
数据块的长度不一定恰好等于记录的整数倍，通常有两种组织方式：
不跨块方式：即一个数据块只包含若干完整的记录，不 足以容纳一个记录的零头空间放弃不用；
跨块方式：允许一个记录跨在不同的数据块，这种组 织方式可节省空间，但由于实现较困难， 故很少使用。
6.5.1 物理数据模型
上面提到的缓冲区数目和大小，数据块的大小及组织方式，是由DBMS设计者安排和实现的，不同系统设置都不一样，这些细节对数据库用户而言是透明的。
除了大的数据对象，多数记录的长度＜快的大小
因此：多个记录存于一个快中
∵运算代价同内存，外存之间传输块的个数有关
∴存储文件时，要考虑如何在块中安排记录的占用较
少的块
6.5.1 物理数据模型
三、数据库存取代价
数据库存取代价=物理块存取代价+计算代价
可忽略
物理块存取次数×每块存取代价
——用块的存取次数来描述DB的存取代价
6.5.2 DB文件的存取组织方法
一．索引存取方法
索引文件
l 是DBS常采用的数据文件结构，按关键字存取文 件，效率较高。
l 索引表，有序的逻辑文件。
l 只反映与索引项有关的数据的存放位置而不是数 据本身
l 不能离开被索引的数据文件（主文件）而独立 存在
6.5.2 DB文件的存取组织方法
建立索引的方式多种多样：
①主索引（Primary Index）：以记录的主关键 字建索引。
②次索引（Secondary Index）：用非主关键字 建索引。
③倒排文件（Inverted File）：在所有属性上都 建索引。
6.5.2 DB文件的存取组织方法
④ 稠密文件（Dense Index）：索引文件中对每一个 索引项值都有一个索引记录。
⑤ 稀疏索引（Sparse Index）：索引文件中对一组 索引项值才有一个索引记录。
⑥ 聚集索引（Clustering Index）：将索引项值相同 的记录在物理上集中存储在同一块或相邻块。
⑦ 多级索引（Multilevel Index）：在索引文件的基 础上再建索引。
6.5.2 DB文件的存取组织方法
常用的较好的折中的办法
∵处理DB主要开销：把块从磁盘上取
到主存中所需时间，扫描整个块的
时间可忽略。
更快的定位一个记录
权衡
注：稠密索引
索引文件较大
插入/删除，维护开销小
空间开销
——决定于具体应用
稀疏索引
占用空间小
访问时间
6.5.2 DB文件的存取组织方法
注：索引本身有时也会变得非常大，而难于有效处理。
例：一个文件由100000（10万）个记录，一块存 10个记录，有一个索引记录。
∴索引有10000个记录，索引记录比数据记录小，
设一个块能容纳100个索引记录→索引占100个块
读取出块数高达log2(100)7=7次，读块7次
6.5.2 DB文件的存取组织方法
主索引上构造一个稀疏索引：
搜索一个记录，在外层索引上用二分法找到不大于所需索码值的最大搜索码值对应的记录，指针指向一个内层索引块，对这一块作扫描，直到找到不大于所需搜索码值的最大搜索码值对应的记录。
这样，如果外层索引一在主存中，那么使用两级索引时，只需读一次索引块。
6.5.2 DB文件的存取组织方法
B+树索引文件：
前面几种索引文件都是静态索引（静态索引适用于相对比较稳定的文件），即索引结构和级别都是固定不复的，但随着主文件记录的变动，索引文件也要变化，需要增加维护开销。而且，随着主文件的变化，索引文件的性能会逐渐下降，到一定时候要进行重组织。∴对变化较大的文件，用动态索引。主文件较大时，多级索引可提高速度，但文件内容不多，不必要，反而降低效率。
6.5.2 DB文件的存取组织方法
二、聚簇
Clustered Index：数据（以升序）物理的存放在页上，索引页中的值的顺序也升序。
很多RDBS将各个关系存储在一个个独立的文件中（很多DBMS在文件管理方面不直接依赖于下层OS，而让OS分配给DBS一个大的操作系统文件，所有关系都在这个文件中，其管理用DBS进行）——利用OS的文件管理。
这种实现关系数据库的简单方法在DB规模大时不合适。
6.5.2 DB文件的存取组织方法
例：（理解一个文件中存储多个关系的好处）
图
Select account_ number, customer_ name, street, city
From depositor, customer
Where .......
必须找到具有相同customer_ name的customer元
组（可用索引）
对depositor中的每个元组
但要从磁盘传到主存中
最快情况：每个记录在一个块，每个记录执行一次
块操作。
6.5.2 DB文件的存取组织方法
聚簇文件结构：
将两个关系的元组混合在一起，读customer一个元组时，包含该元组的整个块从磁盘到主存。∵相应depositor元组存储在靠近customer元组的磁盘上∴该块也包含了处理查询所需的关系depositor的元组，顾客账户太多，则存在临近块中。
6.5.3 存取方法
——数据库文件的组织方法
一．堆文件组织
· 记录无任何次序的状如块中，块之间无特殊的组 织，块间由指针联系。
· 一条记录可以放在文件中的任何地方，只有那个 地方有时间存放，记录无顺序，一个关系就是一 个单独的文件。
· 文本文件，数据文件等串行处理文件以堆文件组 织。
6.5.3 存取方法
二． 顺序文件组织
·为了快速的按搜索码获取记录，我们通过指针把记 录链起来，每个记录的指针指向在搜索码顺序上的 下一个记录。
·为了减少顺序文件处理中的块访问的次数，在物理 上按搜索码顺序存储起来。
三． 散列文件组织（HASH）
·通过计算所需记录搜索码上的一个函数直接获得包 含该记录的磁盘块地址。
桶——存储一条/多条记录的存储单位
第七章 数据库恢复技术
数据库是一种共享资源，因此，在数据库的使用过程中，保证数据的安全可靠，、正确可用就成为非常重要的问题，它是有效使用数据库的前提。
数据库被破坏的原因可归纳为：
⒈软硬件故障，造成数据被破坏。
⒉数据库的并发操作引起数据的不一致性。
⒊自然或人为地破坏，如失火、失窃、病毒和为 授权人的有意纂改数据。
⒋对数据库数据的更新操作有误，如操作时输入 错误的数据或存取数据库的程序有错等等。
第七章 数据库恢复技术
针对这四类问题，一般DBMS提供了相应的功能：
⒈数据库恢复：即系统失效后的数据库恢复，配合定时备份数据库，使数据不丢失数据。
⒉并发控制：即保证多用户能共享数据库，并维护数据的一致性。
⒊安全性保护：防止对数据库的非法使用，以避免数据泄漏、纂改、破坏。
⒋完整性保护：保证数据的正确性和一致性。
从系统的角度看，数据库保护主要是指控制哪类用户可用什么方式存取哪类数据对象，以及对各类数据对象有那些完整性约束等问题。
7.1 事务的基本概念
一． 事务（Transaction）：
事务——是一种机制，它确保多个SQL语句被当作 单个工作单元来处理。
二、四个特性
——ACID准则
7.1 事务的基本概念
⑴ 原子性（Atomicity）
· 即事务执行的原子性，事务“要么不做，要么全做”
，如果事务因故障没有完成，则该事务已做的操作
认为是无效的，在恢复时必须取消该事务对数据库
的影响。
· 保证原子性的思路：对于要执行写操作的数据项，
在磁盘上记录其旧值，若事务没能完成执行，旧值
将被恢复，好像事务从未执行。
· 保证原子性是 DBMS本身的责任，由“事务管理
部件”处理。
7.1 事务的基本概念
⑵ 一致性（Consistency）
· 事务作用于数据库过程中，数据应始终满 足完整性约束。
· 一个事务的执行是把DB从一个一致的状态 阿转换成另一个一致的状态。
· 确保单个事务的一致性是对该事务编码的 应用，程序元的责任，完整性给这项工作 带来了便利。
7.1 事务的基本概念
⑶ 隔离性（Isolation）
· 即事务并发执行的相对独立性，这是事务并发控 制的目标。使事务并发执行的结果和某一串行执 行的结果相同。
· 即使每个事务都能确保C、A，但如几个事务并 发执行，它们的操作会以人们不希望的某种发 式交叉执行，也会导致不一致状态。
· 一种解决方法：串行执行事务（一个接一个）。
· 隔离性保证—→事务并发执行的结果和某一串行 执行的结果相同。
7.1 事务的基本概念
⑷ 持久性（Durability）
· DBMS中“恢复管理部件”的责任。
· 完成了的事务对数据库的影响应是持久的 ，即使数据库因故障而受到破坏，DBMS 也应该能够正确的恢复数据。
7.2 数据库恢复概述
数据库恢复：即系统失效后的数据库恢复，配合定时备份数据库，使数据不丢失数据。
7.3 故障的种类
一、事务内部的故障
二、系统故障
三、介质故障
四、计算机病毒
7.4 恢复的实现技术
一、数据转储（备份）
二、登记日志文件
备份是定期的，而不是实时的，所以利用备份并不能完全恢复数据库，只能将数据库恢复制作备份的那一时刻。
日志是对备份的补充，它可以看作是一个值班日记，它将记录下所有对数据库的更新操作。日志文件是实时的。
当磁盘发生故障造成DB损坏时，先利用备份恢复大部分数据库，然后运行数据库日志，将备份后所做的更新操作在重做一遍，从而使DB完全恢复。
7.4 恢复的实现技术
为保证日志的安全，应该将日志和主数据库安排在不同的存储设备上，否则日志和DB可能会同时遭破坏，日志也就失去了本来的作用。
日志记录有几种，“更新日志记录”描述一次数据库写操作，它有如下几个字段：
· 事务标识：执行写操作的事务的唯一标识。
· 数据项标识：所写的数据项的唯一标识，通常 是数据项在磁盘上的位置。
· 旧值：数据项的写前值。
· 新指：数据项的写后值。
7.4 恢复的实现技术
其它特殊的日志记录用于记录事务处理过程中的重要事
件，如事务的开始，以及事务的提交或中止。
将各种类型的日志记录记为：
数据项 前 后
每次事务执行写之前，必须在DB修改前生成该次写操作的日志记录。一旦日志记录已创建，就可以根据需要对DB做修改，并且，能利用日志记录中的旧值消除已做的修改。
7.5 具有检查点的恢复技术
系统故障，检查日志，决定哪些事务需要(redo , undo)
原则上——搜索整个日志来决定该信息
问题：⑴ 搜索过程耗时
⑵ 根据提供的算法，大多数需要的事物都将其更 新写入了DB
⒈ 为降低开销——引入检查点
日志文件中的一类记录：检查点记录
⒉“重新开始文件”——记录各检查点，记录在日志文 件中的地址。
7.5 具有检查点的恢复技术
⒊ 恢复子系统在登陆日志文件期间动态的维护日志：
· 缓冲中日志记录——写入磁盘的日志文件
· 在日志文件中写一个检查点
· 缓冲中的数据记录——写入磁盘
· 检查点记录在日志文件中的地址——重新开始文件
建立检查点 预定时间间隔：
按某种规则：如日志写满一半
检查点前提交的事务对DB的修改一定已写入 DB.∴不用对”T”REDO
例：P258
7.6 数据库镜像
镜像的实质也是备份，在同一时刻保存数据的两个或多个副本。
镜像与转储本质不同：
转储：定期或不定期的、间断、非实时
镜像一般是OS的功能——硬盘级的
但DBMS为了防止介质出现故障而丢失数据 也提供了镜像功能
如果条件许可，尽量使用OS级的硬盘级的镜像
7.6 数据库镜像
SQL Server：镜像连续、实时的将一个 SQL Server设备上的信息复制到另一个设备上。
对该设备操作的所有事件都复制到它的副本镜像设备上。如果两个设备中的一个损坏了，另一个设备由于保存了所有事件轨迹的最新拷贝，所以系统会完成自动切换，并保存系统连读工作。
第八章 并发控制
8.1 并发控制概述
并发控制：保证多用户能共享数据库，并维护数据的一致 性。
不一致状态：由于系统的故障，系统的状态不再反映DB应 当描述的现实世界的真实状态，系统必然会 在某一时刻处于不一致状态，最终应该被一 致态所代替。
数据库是一个共享资源，不同的用户可能要同时操作一个数据库，同时操作一个基本表，甚至同时操作一条记录。
8.1 并发控制概述
那么这些用户会不会发生冲突呢？
不同用户同时实施的更新操作会不会矛盾呢
如果控制不当的确会发生这些问题，本节讨论这方面的问题。
并发存取可能出现的异常
事务的并发执行可以显著提高系统的资源利用率，提高系统的效率，但当多个事务对数据库进行并发操作时，如不加任何控制，可能会引起数据库数据的不一致性。
8.1 并发控制概述
⒈ 丢失修改（例P265）
⒉ 不能重复读：如果在一个事务要对一个项连续读两次 ，以进行项的校验，而在此之间，插入 另一个事务读对该项的值进行修改，则 可能造成事务对同一项两次读出来的结 果不一样。
8.1 并发控制概述
⒊ “脏”读（Dirty Read）：当一个事务T1在对数据库中 的某些项做了修改以后,因某 种原因而中途取消，则它对数 据库的修改是无效的，这些被 修改过的项称为“脏”数据。在 T1取消前，可能有其它事务已 经读过这些“脏”数据,如果根 据此数据计算出新数据并写回 数据库，则数据库中数据出错.
8.1 并发控制概述
以上是典型的“脏”读的例子，异常不可能一一列举完。
所以只要有适当的并发控制技术控制并发的事务正确的执行，互不干扰，以避免造成数据库中的数据不一致性。
要在数据库系统保证数据的一致性，系统是会有代价的，为了减少开销，有时允许一些数据不一致性的存在，只要对数据库影响不大。
项（Item）：数据库操作的基本数据单位，也是并发控 制的基本单位，可以是数据库/关系/元组/ 字段......(由系统设计人员选择)
8.2 封锁（Locking）
基本思想：当一个用户对一个表或记录进行更新时，封锁改表或记录，是其他用户不能在同一时刻更新相同的表或记录，迫使其它用户在更新后的基础上再实施另外的更新操作。
一、封/加锁的类型
⒈ X锁
最简单的加锁方式，只有一种X锁，即排它锁（Exclusive Locks），该锁既用于项的写操作，也用于项的读操作。
注：事务T一旦对某项R加了X锁，则其它事务不能在对该项加锁，直至T释放X锁。
8.2 封锁（Locking）
⒉ S,X锁
S锁（Share Locks）共享锁，用 于项的读操作。
设有两种锁
X锁 共享锁，用于项的写操作。
允许多个事务并发的读同一项，但对项的写操作必须排它。
（S，X）锁单独采用X锁提高了并发程度，但可能产生活锁（Live Lock），即由于不断有事务对某项加S锁，而使一些想对该项加X锁的事务长期等待，对系统性能有不良影响。
8.2 封锁（Locking）
⒊ S，U，X锁
增加了U锁（Update Lock）——更新锁，事务在更新一个项时，首先对该项加U锁，此时允许其它事务在该项加S锁，待事务读出并修改项后，再将加在该锁上的U锁升级为X锁，然后写入修改后的项。由于不必在事务执行的全过程加X锁，因此进一步提高了并发程度，仍也可能→ 活锁。
8.2 封锁（Locking）
二、调度的可串行性
在并行执行事务时，我们会发现，由于事务交叉执行顺序不同，可能会得到不同的结果，必须有一个准则来判断那个正确。假设事务执行的正确结果是在没有别的事务并发执行时执行它得到的结果。由于事务可以一个接一个的串行执行，所以下面的假设正确：
几个事务并发执行是正确的
←→其结果同以某种次序串行执行这些事务得到的结果相同
8.3 活锁和死锁
系统对数据项加锁不能太随意，否则可能引起死锁。
⒈ 活锁：当若干事务要对同一数据项加锁时，造成一 些事务的永久等待。例：P270
避免活锁的简单方法：采用先来先服务策略。
即让系统按请求加锁的先后次序对事务排队， 数据项上的锁一旦释放，就批准申请队列中第 一个事务获得加锁。
8.3 活锁和死锁
⒉ 死锁：指两个以上事务集合中的每个事务都在等待加 锁当前已被另一事务加锁的数据项，从而造成 相互等待的现象。
DB中解决死锁的方法：
⑴ 一次封锁法：
要求每个事务一次将所有要使用的数据全部加锁 ，否则就不能执行。
8.3 活锁和死锁
⑵ 采用按序加锁法：
预先规定一个对数据项加锁的顺序，要求所有事 务按照这个次序申请加锁，锁管理也按顺序批准 加锁。
⑶ 不采取任何措施预防死锁，而是周期性的检查 系统中是否有死锁，若发现，就设法解除。
选择一个需花费代价最小的方法处理死锁。
如：事务T撤销，释放被加的锁，使其它事务 继续运行下去
8.4 并发调度的可串行性
事务处理系统允许多个事务并发执行
多个事务并发更新数据→异常
如果串行执行，就OK
一次执行一个事务，每个事务仅当前一个事务执行 完毕才开始，但如下理由促使我们考虑并发。
u 一个事务由多个步骤组成
u 一些步骤涉及I/O活动
u 一些步骤涉及CPU活动
8.4 并发调度的可串行性
∴ 多个事务可并行执行，一个事务在磁盘上读写时，另一个可在CPU上运行，可增加系统的“吞吐量”——给定时间内执行的事务数增加，相应磁盘与CPU利用率提高，空闲时间较少。
· 系统中可能运行着各种各样的事务，一些较短，一些较长，若串行执行，短事务可能得等待她前面的长事务完成→难以预测的延时。如果各事务是针对DB的不同部分进行操作，事务并发执行会更好。
8.4 并发调度的可串行性
减少“平均响应时间”——一个事务从开始到完成所需的平均时间
DB中并发执行本质上与OS中使用多道程序的动机一样。
△ 多个事务并发执行时，即使每个事务都正确执行，数据库的一致性也可能被破坏。
∴ 讲述“调度”
可用于确定那些可以保证一致性的执行序列
执行顺序：指令在系统中执行的时间顺序。
8.4 并发调度的可串行性
串行调度：由类自各事务的指令序列组成
属于同一事务的指令在调度中紧挨在一起。
N个事务，由n！个有效的串行调度
例：P273,图8-5(a)(b)
并发执行时，调度不必是串行的，若有两个并发执行的事务，OS可能先选其中的一个事务执行以小段时间，然后执行第二个事务一段时间，接着又切换道第一个......所有事务共享CPU时间。
8.4 并发调度的可串行性
执行顺序有多种，可能的调度总数要比n！大得多。
如果并发执行的控制完全由OS负责，许多调度都是可能的，包括使DB处于不一致状态的调度，保证任何调度执行后DB总处于一致状态是DBMS中“并发控制部件”的责任。
“两段锁协议”可保证并发调度的可串行性（之一）。
8.5 两段锁协议
两段锁协议要求每个事务分两个阶段提出加锁和解锁申请。
⒈ 扩展阶段（Growing Phase）：事务可以获得锁，但不能释放锁。
⒉ 收缩阶段（Shrinking Phase）：事务可以释放锁，但不能获得锁。
一开始，事物处于扩展阶段，事务根据需要获得锁，一旦该事务释放了锁，它就进入了收缩阶段。
· 事务遵守两段锁协议是可串行化调度的充分条件（如前例：P273）
· 两阶段两段锁协议并不保证不会发生死锁。
8.6 封锁的粒度
⒈ 封锁粒度（Granularity）
——封锁对象的大小
逻辑单元 物理单元
属性值（集）；元组； 页（索引/数据页），块等
关系；索引；DB
8.6 封锁的粒度
⒉ 封锁粒度与并发度的关系
粒度越大→封锁的数据单元越少→并发读越小→系统开销 也越小
粒度越小→封锁的数据单元越多→并发读越大→系统开销 也越大
例：P276
∴需要一种允许系统定义多级粒度的级制
⒊ 多粒度封锁（Multiple Granularity Locking）
一个系统中同时支持多种封锁粒度以供不同的事务选择。
第九章 数据库安全性
安全性保护：防止对数据库的非法使用，以避免数据 泄漏、纂改、破坏。
9.1 安全性控制的一般方法
一． 用户标识和鉴定
安全系统的核心问题是身份识别：
⒈ 用户名（User）
⒉ 口令（Password）
⒊ 随机数
9.1 安全性控制的一般方法
需要有一定的方法验证用户的身份，防止他人假冒，辨别用户的最普通的方案是要求用户提供只有用户本人和系统知道的口令，由于口令一般不能太复杂，否则用户自己也会忘记，这就使得口令不够安全，容易被想非法进入数据库系统的人破译。解决这个问题的方法是要求用户经常更换口令，而更安全的办法是在网络上以加密方式传输口令，此外，口令最好不要太简单，也不要用生日之类，易被他人猜出的口令。另外，辨别用户的方法还有磁卡，签名，指纹，声音内容等。
9.1 安全性控制的一般
同课章节目录