《第讲数据库基础自学版》由会员分享，可在线阅读，更多相关《第讲数据库基础自学版（253页珍藏版）》请在金锄头文库上搜索。
1、数据库应用第第3 3讲讲 数据库原理数据库原理 n参考文献：萨师煊等主编数据库系统概论n数据库是数据管理的工具。数据管理经历了从手工管理阶段、文件管理阶段到数据库管理阶段的变迁。n几个重要概念： n数据n数据库n数据库管理系统n数据库系统存放数据的仓库（顾名思义/不准确的含义）信息的载体/表示尽管数据库技术已发展成熟，但还没有一个普遍接受的、严格的定义。数据库(Data Base)数据库应具备的特征数据库应具备的特征/定义：定义：（1 1）数据库是相互关联的数据的集合数据库是相互关联的数据的集合数据库中的数据不是孤立的，数据与数据之间是相互关联的，在数据库中不仅要能够表示数据本身，还要能够表示
2、数据与数据之间的联系。如：学籍管理学生、课程两类数据。 （2 2）用综合的方法组织数据用综合的方法组织数据顺序、索引、聚簇Cluster数据库例：人事部门有一个职工文件：职工基本情况有关人事管理的数据教育部门也有一个职工文件：职工基本情况有关教育培训的数据其中，“职工基本情况”重复存储，浪费空间。可共享存储类似这样的共同数据，以降低数据的冗余度。（3 3）具有较小的数据冗余，可供多个用户共享具有较小的数据冗余，可供多个用户共享低冗余与数据共享：在数据库技术之前，数据文件都是独立的，任何数据文件都必须含有满足某一应用的全部数据。数据库（4 4）具有较高的数据独立性具有较高的数据独立性数据独立性：
3、（包括物理独立性、逻辑独立性。）指数据的组织和存储方法与应用程序互不依赖，彼此独立的特性。可降低应用程序的开发代价和维护代价。数据库在数据库技术之前，数据文件的组织方式和应用程序是密切相关的。数据结构改变，相应的应用程序也必须随之修改=开发/维护代价数据库（5 5）具有安全控制机制，能够保证数据的安全、可靠具有安全控制机制，能够保证数据的安全、可靠数据库要有一套安全机制，以便有效地防止数据库中的数据被非法使用/修改；数据库还要有一套备份/恢复机制，以保证当数据遭到破坏时将数据立刻完全恢复=继续、可靠地运行。（6 6）允许并发地使用数据库，能有效、及时地处理数据，允许并发地使用数据库，能有效、及
4、时地处理数据，并能保证数据的一致性和完整性并能保证数据的一致性和完整性一致性：数据库中的数据是共享的，并且允许多个用户同时使用相同的数据。这就要求数据库能够协议一致，保证各个用户之间对数据的操作不发生矛盾和冲突。正确性、完整性：保证数据正确的特性数据完整性可通过建立一些约束条件保证数据库中的数据是正确的。如：学生年龄20（2或100则错误）数据库数据库管理系统（DataBaseManagementSystem，DBMS）数据库的功能/特性不是数据库中的数据固有的，是靠管理或支持数据库的系统软件DBMS提供的。DBMSDBMS任务：任务：对数据资源进行管理，使之能为多个用户共享。保证数据的安全性
5、/可靠性/完整性/一致性/独立性数据库管理系统数据库管理系统 2 2数据库操纵功能数据库操纵功能 完成对数据库中数据的操作：插入、删除、修改； 重新组织数据库的存储结构； 完成对数据库的备份/恢复等.DBMSDBMS功能：功能： 1 1数据库定义功能数据库定义功能 定义数据库结构和存储结构； 定义数据库中数据之间的联系； 定义数据完整性约束条件和保证完整性的触发机制等.3 3数据库查询功能数据库查询功能以各种方式提供灵活的查询功能，以便方便使用数据.4 4数据库控制功能数据库控制功能完成对数据库的安全性控制/完整性控制/并发控制5 5数据库通信功能数据库通信功能在分布式数据库或提供网络操作功能
6、的数据库中还必须提供通信功能。数据库管理系统1 1数据库系统数据库系统 (DataBase System，DBS)基于数据库的计算机应用系统，包括：以数据为主体的数据库管理数据库的系统软件DBMS支持数据库系统的计算机硬件环境和操作系统环境管理和使用数据库系统的人，特别是DBA方便使用和管理系统的技术说明书和使用说明书数据库系统和数据库管理员数据库系统和数据库管理员数据库管理员数据库管理员 (DataBase Administrator，DBA)从事数据库管理工作的人员，负责数据库的全面管理工作（维护、设计）数据库的使用会改变企事业单位的管理方式，但因为要把众多部门或用户的数据放在同一数据库中
7、，会带来一些问题，如：数据冲突；越权使用数据；重要数据丢失因此需要管理部门：负责和数据管理有关的工作。数据库系统和数据库管理员注注: DBA: DBA工作繁重、重要、关键：工作繁重、重要、关键：除了要掌握一定的数据处理、数据库技术之外，还应有处理好人际关系的素质、能力。在一个企事业中，特别是一个规模较大的数据库，不能指望一两个人来完成管理工作，所以DBA常指数据库管理部门。开发DBS时，一开始就应设置DBA的职位或相应的机构，以明确DBA职责、权限。数据处理是计算机应用领域中最大的一类应用用计算机实现数据管理经历了三个发展阶段：1 1人工管理阶段人工管理阶段数据库管理的初级阶段。在50年代中期
8、以前，计算机采用的是批处理方式，主要用于科学计算。1.1.2数据管理技术的产生和发展2 2文件系统阶段（文件系统阶段（5050年代后期年代后期6060年代中期）年代中期）特点：特点： 计算机技术有了很大的发展，开始广泛应用于信息处理 存储设备有了磁盘、磁鼓等可直接存取的设备 计算机有了操作系统，包括文件管理系统，用户可将数 据组织成文件体交给系统进行自动管理。 数据可长期保存在磁盘等存储设备上 程序和数据有了一定的独立性，且文件有多种形式的组 织结构：顺序、链接、索引、直接1.1.2数据管理技术的产生和发展缺点：缺点：（1）数据冗余较大每个文件都是为特定的用途设计的，同样数据在多个文件中重复存
9、储进能提供以文件为单位的数据共享。（2）程序和数据之间的独立性较差应用程序依赖于文件的存储结构，修改文件存储结构就要修改程序1.1.2数据管理技术的产生和发展（3）对数据的表示和处理能力较差 文件的结构和操作比较单一，不够丰富。（4）数据不一致 由（1）造成，更新时会造成同一数据在不同文件中的不一致。（5）数据联系弱文件与文件之间是独立的，文件之间的联系必须通过程序来构造。 尽管如此，文件系统在数据管理技术的发展中仍起着很重要的作用。1.1.2数据管理技术的产生和发展1.1.2数据管理技术的产生和发展3.3.数据库系统阶段数据库系统阶段从60年代后期开始，计算机用于信息处理的规模越来越大，对数
10、据管理的技术提出了更高的要求，此时开始提出计算机网络系统和分布式系统，出现了大容量的磁盘，文件系统已不再能胜任多用户环境下的数据共享和处理。一个新的数据库管理技术DBMS由此而形成，它对所有用户数据实行统一的、集中的管理、操作和维护。按照数据模型的进展情况，数据库系统的发展可划分为三代：第一代：层次数据库系统和网状数据库系统 主要支持层次和网状数据模型第二代：关系数据库系统 支持关系数据模型，该模型有严格的理论基础，概念简单、清晰，易于用户理解和使用。因此一经提出便迅速发展，成为实力性最强的产品。1.1.2数据管理技术的产生和发展第三代：新一代数据库系统面向对象数据库系统 基于扩展的关系数据模
11、型或面向对象数据模型的尚未完全成熟的一代数据库系统 。特点：支持包括数据、对象和知识的管理 在保持和继承第二代技术的基础上引进新技术(如OO) 对其他系统开放，具有良好的可移植性、可连结性、 可扩充性、互操作性。 1.1.2数据管理技术的产生和发展1.2数据模型数据模型 模型模型对客观事物、现象、过程或系统的简化描述所有的数据库系统都为它所要描述的世界建立了模型：数据建模：描述了组织数据的框架结构。如：楼房住户-数据；房间规格-数据模型数据建模最后发展成为数据的存储方式（数据字典中的定义）业务功能建模：用户的最终需求。业务功能建模最后发展成为应用程序产生高效的应用程序的前提是良好的数据模型。（
12、正如10平米的房间无法成为会议厅一样，一个糟糕的数据模型也无法产生高质量的应用。1.2数据模型数据模型为什么要建立数据模型（DataModel）： 象盖大楼的设计图一样，DM可使所有的项目参与者都有一个共同的数据标准 避免出现问题再解决（边干便改的方式） 可及早发现问题 加快应用开发速度1.2.1数据模型的三要素 1数据结构描述数据的静态特征，包括对数据结构和数据建联系的描述。通常按照数据结构的类型来命名数据模型：层次结构层次模型网状结构网状模型关系结构关系模型2数据操作描述数据的动态特征：一组定义在数据上的操作（包括操作的含义、操作符、运算规则及其语言等）主要操作：检索与更新（插入、删除、修
13、改）1.2.1数据模型的三要素 33.数据的约束条件完整性规则的集合，数据库中的数据必须满足这组规则。约束条件的主要目的是使数据库与它所描述的现实系统相符合。设计时：时数据模型正确、真实、有效地反映现实 运行时：保证数据库中的数据值真实地体现现实世 界的状态 1.2.2常见数据模型根据数据模型应用目的不同，数据模型有以下几种：概念（数据）模型（概念（数据）模型（ConceptualDataModel）面向现实世界建模主要用来描述现实世界的概念化结构，与具体的DBMS无关；-现实世界的事物经过人脑的抽象加工，提取出对用 户有用的信息，经过组织整理加工形成结余现实世 界和计算机世界之间的中间模型；
14、-CDM只关心现实世界中的事物、事务特征、联系， 完全没有与具体及其相关的任何概念；1.2.2常见数据模型-CDM是系统分析员、程序设计员、维护人员、用户 之间相互理解的共同语言；-CDM能时数据库的设计人员在设计的初始阶段摆脱 计算机系统及DBMS的具体技术问题，集中精力分析 数据、数据之间的联系；-概念模型必须转换成逻辑模型，才能在DBMS中实现；-最常用的概念模型是E-R模型1.2.2常见数据模型逻辑（数据）模型（逻辑（数据）模型（LogicalDataModel）面向用户建模用户从数据库所看到的数据模型； - 是具体的DBMS所支持的数据模型（网状/层次/关系/面向对象）；-既要面向用
15、户，也要面向系统；-LDM表示数据建联系的方法-一般的DBMS支持一种LDM（特殊的DBMS支持多种LDM）1.2.2常见数据模型常见数据模型 物理（数据）模型（物理（数据）模型（PhysicalDataModel）面向具体的DBMS，面向机器描述数据在存储介质上的组织结构-PDM不仅与具体的DBMS有关，还与操作系统 和硬件有关-每一种逻辑模型在实现时都有其对应的物理模型-PDM加入了概念模型中为考虑的因素：触发器、 存储过程、主键、外键、索引等-DBMS为保证其独立性和可以执行，大部分PDM的实现工作由系统自动完成，而设计者只设计索引、聚簇等特殊结构1.2.3概念模型概念模型 实体实体-联
16、系（联系（Entity-Relationship）概念模型概念模型首先介绍E-R模型中常用的几个重要概念，利用它们可构造出现实世界的数据的抽象描述。1实体、实体型、实体集实体、实体型、实体集实体（实体（Entity）客观存在并能相互区分的事物如：人；数据库课程；正是用的计算机；一场足球赛不能严格地定义实体，正如几何中“点”，“线”一样。关键之处：一个实体能和别的实体区分开。1.2.3概念模型概念模型实体型（EntityType）用实体名及属性名集合来抽象刻画同类实体实体集（EntitySet）同型的实体组成的集合。2属性（属性（Attribute）指实体所具有的某一方面的特性，一个实体可 由若
17、干个属性来刻划。-属性取值在一定的范围，称为该属性的值域/域（Domain）-唯一标识实体的属性集称为码(Key)1.2.3概念模型概念模型3联系（联系（Relationship）实体集合间存在的相互关系为了建立现实世界的完整模型，常常需要对联系分类，根据一个实体集合的实体可以和多少个另一类实体集合的实体相联系，可将联系分为如下几种：(1)一对一联系（1：1）系系主任(2)一对多联系（1：n）班级学生(3)多对多联系（m：n）课程学生1.2.3概念模型概念模型4实体实体-联系图联系图（1）确定所有实体集合用矩形方框表示实体集合，方框内标明实体集合名 称；（2）选择实体集应包含的属性用椭圆框表示
18、属性，通过无向边连接到实体集。只有一个属性的实体集可用属性代替，附加到它参加的联系上；（3）确定实体集之间的联系用菱形框表示，框内标明联系的名称，通过无向边（或有向边）连接到参加联系的每个实体集合；1.2.3概念模型概念模型（4）确定实体集的关键字用下划线在属性上标明关键字的属性集合；（5）确定联系的类型在用无向边连接联系到实体集时，在边上注明1或n（多）来知名联系的类型。（在用有向边连接联系到实体集时，让边的箭头指向1的实体集的 一方，多对多因为都是多方，故无箭头）1.2.4三种主要的逻辑数据模型三种主要的逻辑数据模型 上节讨论的概念数据模型是“概念上”的，是抽象的，它与具体的数据库管理系统
19、无关。这节要讨论的数据模型将与具体的DBMS有关，与DBMS支持的数据和联系的表示或存储有关。前面提到过，数据库中不仅要存放数据本身，还要存放数据间的联系，可用不同的方法表示数据与数据之间的联系。把表示数据与数据之间联系的方法称为逻辑（数据）模型。1.2.4三种主要的逻辑数据模型三种主要的逻辑数据模型一、一、层次模型（层次模型（HierarchicalModel）用树型结构来表示实体之间联系的模型。支持层次模型的典型系统诞生于1970年前后，是IBM公司的IMS（InformationManagementSystem）系统。优点：结构简单缺点：插入、删除限制多 1.2.4三种主要的逻辑数据模型
20、三种主要的逻辑数据模型二、二、网状模型（网状模型（NetworkModel）典型代表：DBTG（DataBaseTaskGroup）数据库任务组1网状模型的数据结构2网状模型的数据操纵与完整性约束3网状模型的存储结构4网状模型的优缺点优点：更能直接描述世界缺点：结构复杂1.2.4三种主要的逻辑数据模型三种主要的逻辑数据模型三、三、关系模型（关系模型（RelationalModel）1970，IBM，E.F.Codd关系模型源于数学，它把数据看成是二维表（关系） 中的元素。（其严格定义下一章给出）用关系表示（不需用指针）实体和实体之间联系的模 型称为关系模型。对于用户，关系方法应该是很简单的，但
21、RDBMS很复杂，因为将大量工作都转嫁给了RDBMS。1.2.4三种主要的逻辑数据模型三种主要的逻辑数据模型RDBMS的设想在层次、网状数据库诞生的同时产生的，但研制开发RDBMS却花费了比人们想象的要长得多的时间。所以成为商品并投入使用比层次、网状数据库晚了十几年。但一投入使用就显示了旺盛的活力，并逐步取代层次、网状数据库。1.3数据库系统的结构数据库系统的结构1.3.1数据库系统模式的概念数据库系统模式的概念 当设计数据库时，对数据库的结构感兴趣；即模式（模式（Schema）：）：数据库中数据的逻辑结构和特征的描述当应用数据库时，关心的是数据库中存在的数据实例（Instance）。数据库中
22、的数据经常变化，而数据库的结构在一定时间范围内不会改变。数据库中结构的定义可以在多个抽象级别进行，形成多个级别的数据库模式。1.3.2数据库系统的三级模式结构数据库系统的三级模式结构数据库系统的三级模式不仅可以使数据具有独立性，而且还可以使数据达到共享，使同一数据满足更多用户的不同要求。一、内模式（InternalSchema）存储模式是数据在数据库系统的内部表示，即对数据的物 理结构/存储方式的描述，是低级描述，一般由DBMS提供的语言或工具完成；1.3.2数据库系统的三级模式结构数据库系统的三级模式结构要修改存储数据库的结构（例如，用倒排文件代替多 链表），那么仅仅需要把这些修改反映在存储
23、模式中；通常我们不关心内模式的具体技术实现，而是从一般组 织的观点（即概念模式）或用户的观点（外模式）来讨 论数据库的描述。但我们必须意识到基本的内模式和存 储数据库的存在。1.3.2数据库系统的三级模式结构数据库系统的三级模式结构二、模式（Schema）逻辑模式是数据库中全体数据的逻辑结构和特性的描述， 是所有用户的公共数据视图；DBMS提供数据定义语言DDL来描述逻辑模式，严格定义数据的名称、特征、相互关系、约束等。1.3.2数据库系统的三级模式结构数据库系统的三级模式结构三、外模式（ExternalSchema）用户模式（视图）是模式的子集或变形，是与某一应用有关的数据的逻辑表示；不同用
24、户需求不同，看待数据的方式也可以不同 ，对数据保密的要求也可以不同，使用的程序设计语言也可以不同，因此不同用户的外模式的描述可以使不同的。1.3.2数据库系统的三级模式结构数据库系统的三级模式结构举例：民航售票系统包括处理航班程序和处理旅客程序。-程序的使用人员不必知道关于人事档案、丢失的行李、飞行员的航行分配等信息；-调度员可能需要知道关于航班、飞机和人事档案等 信息（如那些飞行员有资格驾驶747），但不必知道雇员的工资、旅客等信息。所以可以为订票部门建立一个数据库视图，为调度部门建立另一个完全不同的部门。1.3.2数据库系统的三级模式结构数据库系统的三级模式结构Note：视图处理的数据并不
25、实际存储在数据库中，而仅可以从逻辑数据库中构造出来。视图比（逻辑）模式的抽象级别更高。举例：“年龄”在人事部门数据库中，但（逻辑）模式重金包含出生年月。当用户希望通过访问视图得到年龄时，DBMS翻译这个要求，在从物理数据库上取出的数据完成计算。注：一个数据库只有一个模式，一个内模式，但可注：一个数据库只有一个模式，一个内模式，但可以有多个外模式。以有多个外模式。1.3.3数据库的二级映象数据库的二级映象 在三级模式中提供了两级映象，保证了数据库系统的数据独立性，既物理独立性与逻辑独立性。一、外模式/模式映象数据库系统投入使用后，可能有必要修改模式（如增加新关系、属性、改变类型），这时：重新定义
26、外模式/模式映象=现存外模式不变=应用程序不变1.3.3数据库的二级映象数据库的二级映象二、模式/内模式映象当内模式发生变化时：重新定义模式/内模式映象=模式保持不变=外模式保持不变=建立在外模式上的应用程序保持不变1.5数据库技术的研究领域1数据库管理系统软件的开发2数据库设计3数据库理论第二章第二章关系数据库关系数据库1关系操作 查询操作：选择/ 投影/ 连接/ 除/ 并/ 交/ 差2.1关系模型概述关系模型概述从数据模型的三要素加以介绍一、一、数据结构数据结构关系二、二、关系操作关系操作增加、删除、修改2.1关系模型概述元组关系演算：谓词变元的基本对象是元组变量域关系演算：谓词变元的基本
27、对象是域变量Note：关系代数和关系演算是抽象的查询语言，与具体关系代数和关系演算是抽象的查询语言，与具体的的DBMS中实际语言不一样，但彼此等价，是从抽象的中实际语言不一样，但彼此等价，是从抽象的观点出发学习数据库查询的问题。观点出发学习数据库查询的问题。3关系数据语言2关系操作的表示方法：关系代数：用对关系的运算表达查询要求关系演算：用谓词表达查询要求2.1关系模型概述实体完整性关系模型必须满足的完整性约束条件参照完整性三、关系的完整性约束条件关系的完整性约束条件用户定义的完整性：针对某一具体数据库的约束条件反映某一具体应用所设计的数据必须满足的语义要求。（关系系统自动支持）2.2关系数据
28、结构及形式化定义关系数据结构及形式化定义 2.2.1关系关系一、基本概念1域（Domain）2笛卡尔积（Cartesian Product）元组（Tuple）3关系（Relation）分量（Component）候选码CandidateKey 非码属性Non-keyattribute 主码 Primark Key全码 All-key主属性Prime attribute2.2关系数据结构及形式化定义关系数据结构及形式化定义二、关系的三种类型 基本关系（基本表）：实际存在的表，是实际存储数据的逻辑表示查询表：查询结果对应的表视图表 ：由基本表或其它视图标导出的表，虚表，不对应实际存储的数据2.2.2
29、关系模式关系模式 值（Value）：是型的一个具体赋值关系是值 型（Type）：对某一类数据的结构和属性的说明关系模式是型（关系模式是对关 系的描述）2.3关系的完整性关系的完整性（具体见萨师煊等主编数据库系统概论P52-55）2.4关系代数（关系代数（RelationalAlgebra） 关系代数是对关系运算的总和，关系运算分两类:2.4.1传统的集合运算传统的集合运算并交差积（按行） 2.4.2专门的关系运算专门的关系运算 选择/ 投影/ 连接/ 除（按行、列）一、几个记号和概念元组，分量属性列域，剩余属性组元组的连接象集关系运算定义第三章第三章关系数据库标准语言关系数据库标准语言SQL
30、关系代数和关系演算是形式化查询语言，商业DBMS使用SQL（Structured Query Language）。1974 年 由 IBM 的 San Jose研 究 室 提 出 ， 最 初 叫SEQUEL（Structured English Query Language）关系数据库系统通过SQL对数据库进行查询和更新目前有许多不同版本的SQL语言,有两个不同的主要标准:ANSI(AmericanNationalStandardsInstitute)1986ISO(InternationalStandardsOrganization)：SQL-89,SQL-92,SQL2,正在制定SQL33
31、.1SQL语言概貌及特点语言概貌及特点 一、一、SQL特点特点1一体化一体化SQL是一种一体化的语言，它包括了数据定义、查询、更新、控制四方面功能。可以完成数据库活动中的全部工作以前的非关系模型的数据语言一般包括：内模式描述语言、模式描述语言、外模式描述语言、数据操纵语言等。内容多，操作起来不像SQL那样简单。3.1SQL语言概貌及特点语言概貌及特点2高度非过程化高度非过程化没有必要一步步地告诉计算机“如何”去做，只需描述清楚用户要“做什么”，SQL就可以将要求交给系统，自动完成全部工作。3面向集合的操作方式面向集合的操作方式操作对象、查询结果是元组的集合；插入、删除、更新操作的对象也可以是元
32、组的集合。 3.1SQL语言概貌及特点语言概貌及特点4两种使用形式，统一的语法结构两种使用形式，统一的语法结构自含式：将SQL作为操作命令独立使用现在许多数据库开发工具都将SQL直接融入到自身的语言中。 宿主式：将SQL嵌入到高级语言中使用3.1SQL语言概貌及特点语言概貌及特点5语言简洁语言简洁SQL虽然功能强且使用两种方式，但只有为数不多的几条命令，另外语法也非常简单，接近自然语言，易掌握、学习。除了以上特点之外，SQL语言还支持数据库的三级模式结构。3.1SQL语言概貌及特点语言概貌及特点二、二、SQL语言组成语言组成SQL同一般的程序设计语言一样,由以下几个部分组成：1常量：文本常量（
33、字符串）、整型常量、数值常量2数据类型：以IBM DB2 SQL为例，具体见萨师煊等主编数据库系统概论P893空值：NULL3.1SQL语言概貌及特点语言概貌及特点集合运算符：、-算术运算符：+，-，*，/5.函数SQL提供了非常丰富的内部函数聚集函数（详见萨师煊等主编数据库系统概论P100）4.运算符字符串运算符：| （连接）比较运算符：6个逻辑运算符：NOT，AND，OR3.1SQL语言概貌及特点语言概貌及特点6谓词SQL为了具有强大的查询能力，提供了一系列的谓词：BETWEENAND/NOTBETWEENAND介于两者之间 /介于两者之外IN/NOTIN在其中/不在其中LIKE匹配ISN
34、ULL/ISNOTNULLEXISTS/NOTEXISTS存在/不存在量词ANY任意一个存在量词ALL全程量词3.1SQL语言概貌及特点语言概貌及特点7表达式8条件由一个或多个含有比较运算符的表达试及逻辑运算符组合而成。9.命令（具体见萨师煊等主编数据库系统概论P86表3.1） 3.2数据定义数据定义 存储过程定义基本表定义定义功能数据库的定义：和物理数据有关，以后介绍视图定义索引定义规则定义与数据完整性有关，以后介绍 3.2.1定义、删除与修改基本表 (具体见萨师煊等主编数据库系统概论P88)3.2.2建立与删除索引建立与删除索引(具体见萨师煊等主编数据库系统概论P90)在使用关系数据库系统
35、时，用户所看到和操作的数据好像在简单的二维表中，而实际上数据在磁盘上是如何存储的用户可能不知道。然而数据的物理存储如何却使数据库主要性能的主要因素。索引时最常见的改善数据库性能的技术。nCREATE TABLE 表名（列名数据类型列级完整性约束条件，表级完整性约束条件n例：CREATE TABLE Student (Sno CHAR(5) NOT NULL UNIQUE,SNAME CHAR(20) UNIQUE,SSEX CHAR(1),SAGE INT,SDEPT CHAR(15);修改基本表nALTER TABLE 表名ADD新列名数据类型完整性约束nDROP完整性约束名nALTER 列
36、名数据类型；n例：向学生表增加“入学时间”日期型nALTER TABLE STUDENT ADD Scome date;n修改年龄为半字长整数nALTER TABLE STUDENT ALTER SAGE SMALLINTn删除学生姓名必须取唯一值的约束。nDROP TABLE Student DROP UNIQUE Tag SnamenDROP TABLE 3.2.2建立与删除索引关于索引关于索引索引的建立和删除由DBA或建表的人负责，用户不必也不能在存取数据是选择索引；作为一般规则，不应该在一个表上建立太多的索引（2-3个）。索引能改善查询效果，但也耗费了磁盘空间。降低了更新操作的性能。因
37、为系统必须花时间来维护这些索引；表中数据越多，索引的优越性才越明显。3.3.1单表查询单表查询 指定列消除重复行选择表中若干列全部列经计算的列选择表中若干元组查询满足条件的元组对查询结果排序对查询结果分组3.3.2连接查询连接查询 等值/非等值连接自身连接外连接复合条件连接3.3.3嵌套查询嵌套查询 带有IN谓词的查询带有比较运算符的查询带有ANY或ALL谓词的子查询带有EXISTS谓词的查询3.3.4集合查询具体见萨师煊等主编数据库系统概论P1143.3.5SELECT语句的一般格式语句的一般格式具体见萨师煊等主编数据库系统概论P115 3.4数据更新数据更新 插入、修改、删除数据（具体见萨
38、师煊等主编数据库系统概论P117）一、插入数据1插入单个元组2插入子查询结果3.4数据更新数据更新二、修改数据1修改一个元组的值2修改多个元组的值3带子查询的修改语句3.4数据更新数据更新三、删除数据1删除一个元组的值2删除多个元组的值3带子查询的删除语句4更新操作与数据库的一致性3.5视视图图 一、关于视图：视图是原始数据库数据的一种变换，是查看表中数据的另外一种方式；可将视图看成是一个移动的窗口，通过它可看到感兴趣的数据；视图可从一个或多个实际表中获得；视图的定义存在数据库中，而数据并没再存一份在数据库中，通过视图看到的数据存放在基本表中；对视图的操作同其它表一样，通过视图修改数据时，实际
39、是修改基本表中的数据，相反，基本表数据的改变也会自动反映在由基本表产生的视图中。3.5视视图图二、视图的作用1简单性看到的就是用户需要的不仅可简化用户对数据的理解，也可简化它们的操 作。经常使用的查询可以被定义为视图。3.5视视图图2安全性通过视图用户只能查询和修改他们能见到的数据，数据库其它数据则既看不到也取不到。数据库授权命令可是用户对数据库的检索限制到特定的数据库对象上，但不能授权到数据库特定的行、列上。视图可防止未授权用户查看特定的行/列3逻辑数据独立性3.5视视图图一、定义视图具体见萨师煊等主编数据库系统概论P121-124二、查询视图具体见萨师煊等主编数据库系统概论P125三、更新
40、视图具体见萨师煊等主编数据库系统概论P1263.6数据控制数据控制 SQL数据控制功能对数据库中数据的安全控制提供保护，主要表现在对数据使用的授权(GRANT)和收回授权(REVOKE)。每个用户对自己拥有的资源可以由任意的操作权限，同时也可以把其中的一部分权限授予他人。（具体见萨师煊等主编数据库系统概论P130） 3.6数据控制数据控制一、授权3.6数据控制数据控制二、收回权限注：授权(GRANT)和收回授权(REVOKE)并不是数据库的全部控制功能，只是其中的一小部分，其它功能如安全性、完整性、并发控制和恢复在7、8、9、10章介绍。 3.7嵌入式嵌入式SQL 前面几节介绍的SQL,，是作
41、为独立的数据语言直接由用户在交互环境下使用的。此外，SQL还可以作为子语言嵌入在宿主语言（PASCAL、C等）中使用。SQL作为子语言嵌入在宿主语言中使用必须要解决以下三方面问题：1嵌入识别问题宿主语言的编译程序不能识别SQL语句，所以首要问题要解决如何区分宿主语言的语句和SQL语句。3.7嵌入式嵌入式SQL2宿主语言与SQL语言的数据通信问题DBMS将SQL语句的查询结果或执行状态必须交给宿主语言/应用程序处理（通过SQLCA）；运行时，宿主语言的数据通过变量（称为主变量）也要能够交给SQL使用。3宿主语言的单记录与SQL的多记录的问题宿主语言一般一次处理一条记录；SQL语言常常处理的是记录
42、（元组）的集合，其查询结果通常是含多个记录的一张表。“阻抗不匹配”本节将围绕如何解决这三个问题来介绍。3.7嵌入式嵌入式SQL一、一、嵌入识别与预编译嵌入识别与预编译解决方法：为SQL语句加一个特殊的前缀。在用宿主语言的编译系统编译源程序之前，首先由预编译系统将SQL语句转换为宿主语言的合法函数调用。 3.7嵌入式嵌入式SQL3.7嵌入式嵌入式SQL一、一、数据通信区与主变量数据通信区与主变量1数据通信区SQLCASQL Communication Area在嵌入SQL语句的程序中，一般在程序的前部都要有一条语句：EXECSQLINCLUDESQLCA这里SQLCA即是SQL与宿主语言的通信区
43、，它类似于结构变量，各个变量分别反映SQL语句的各种执行状态。 3.7嵌入式嵌入式SQLDBMS：数据库厂商标识 0：成功例如：SQL Anywhere 中SQLCA有16个属性：SQLCode(long):存放执行SQL后返回的代码100：SELECT找不到符合条件的记录-1：SQL操作错误DataBaseUseridDBPassSQLErrText：错误代码SQLDBCode：错误信息3.7嵌入式嵌入式SQLSQL被执行时，DBMS将产生的各类系统信息（如执行状态信息）写入系统通信区，应用程序在调用SQL后，可通过读取数据通信区中信息来确定语句执行情况。 应用通过SQLCA与数据库通信 应
44、用SQLCADBMS连接参数状态信息 3.7嵌入式嵌入式SQL输出主变量：SQL对其赋值或设置状态信息，返回给应用程序。利用它可得到SQL语句的结果数据和状态。输入主变量：由应用程序赋值，SQL引用。可用于：插入数据、修改值、制定条件（WHERE）2主变量主变量SQL语句使用宿主语言的变量来输入/输出数据主变量（Host Variable）主变量根据作用不同分为：3.7嵌入式嵌入式SQLNote：所有变量要在BEGINDECLARESECTIONENDDECLARESECTION之间说明。 3.7嵌入式嵌入式SQL三、游标（Cursor）当查询结果超过一个元组时，不能一次性将结果值赋给宿主语言
45、的变量，因为主变量仅能保存一个数据，而不是一组数据。为此，引进一个特殊的数据结构游标（Cursor）。游标是系统为用户开设的一个数据缓冲区，存放SQL的执行结果。可将其理解为一个指示器，指向数据库中满足条件的元组。游标包含两部分内容：结果集：游标内SELECT语句执行后产生的集合；游标位置：游标指针的当前位置。3.7嵌入式嵌入式SQL游标的定义和使用分为下面几步：声明游标不可执行的指令，仅定义游标，SELECT语句没有执行（类似于变量说明）打开游标执行SELECT语句，将结果放入结果集中。推进游标 移动指针，该变结果集的当前记录。通过游标更新数据 关闭游标 程序实例（具体见萨师煊等主编数据库系
46、统概论P136-146） 第四章第四章关系系统及查询优化关系系统及查询优化 具体见萨师煊等主编数据库系统概论P151-1674.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一个实例第五章第五章关系数据理论关系数据理论 数据库设计的一个最基本的问题是如何建立一个好的数据库模式。即给出一组数据，如何构造一个适合于它们的数据模式，使数据库系统无论是在数据存
47、储方面，还是在数据操纵方面都有较好的性能。E-R模型方法讨论了实体与实体之间的数据联系，现在来讨论实体内部属性与属性之间的数据关联，目标是要设计一个“好”的数据库模型。 5.1问题的提出问题的提出 1关系模型定义复习2在解决如何设计一个好的数据库模式之前，先看一 看什么是“不好”的数据库设计（关系数据库模式可 能出现的异常）。 例：建立一个关系数据库来描述学生的一些情况，该数据库只包含一个关系模式： 学生（学号，姓名，系名，系主任，课程，成绩）3.例：具体见萨师煊等主编数据库系统概论P171页 5.1问题的提出问题的提出（1）存在的问题：）存在的问题：i.i.数据冗余：姓名，系名，系=重复出现
48、。ii.ii.更新异常：某一元组修改系主任，其他不变=同一系，系主任不同，造成了数据潜在的不一致性。iii.iii.插入异常：系刚成立，尚未招收学生，主关键字为空，则系主任、选的课都无法存入数据库，未 选课的学生信息也无法存入。iv.删除异常：一个系的学生毕业了，删除这些学生的记录，则系主任等信息也删除掉了。 5.1问题的提出问题的提出（2）产生异常的原因：）产生异常的原因：这些异常的产生主要是因为关系模式的结构，即关系模式中的属性之间存在过多的数据依赖关系，与现实世界不符合。注：数据依赖关系最重要的一类是函数依赖。主关键字（学号+课程）一定，元组就确定了，元组分量也就确定了，即所有其它属性都
49、依赖于“学号”和“课程”。但实际：学号姓名，不需选课。系名系主任。5.1问题的提出问题的提出（3）解决：）解决：分解为三个新的关系模式：学生（学号，姓名，系名）成绩（学号，课程，成绩）系（系名，系主任）这样上面提到的问题不存在了，将学生、成绩和系三个相对独立的实体划分开来，使之更符合现实世界的实际。 5.2规范化（规范化（Normalization） 5.2.1函数依赖(FunctionalDependency) 回顾：函数熟悉的概念。Y=f(x)：x和Y之间数量上的对应关系。给定x值，Y值与之对应。称x函数决定Y，或Y函数依赖于x。在关系数据库中讨论函数或函数依赖注重的是语义上的关系。如：省
50、=f(城市)5.2.1函数依赖函数依赖(FunctionalDependency)定定义义 函函数数依依赖赖（具体见萨师煊等主编数据库系统概论172页）页）说明：t1x=t2x=t1r=t2r成立，就有xY。只有当t1x=t2x为真，而t1Y=t2Y为假时，xY。当t1x=t2x为假时，不管t1Y=t2Y为T/F， 都有xY。比如：当x为关键字属性时，t1x=t2x肯定为F，但xY成立。5.2.1函数依赖函数依赖(FunctionalDependency)术语和记号：术语和记号：非平凡的函数依赖非平凡的函数依赖(NontrivialFunctionalDependency)通常讨论。xY，但Y
51、x(Y不包含于x),则xY称为非平凡的函数依赖。若Yx x,显然xY成立。（称为平凡的函数依赖。TrivialFunctionalDependency）5.2.1函数依赖函数依赖(FunctionalDependency)决定因素（决定因素（Determinant）若xY，则x称为决定因素（决定方）。xY,Yx则记作xY。如：学号姓名。若Y不函数依赖于x，记作xY。5.2.1函数依赖函数依赖(FunctionalDependency)定定 义义 完完 全全 函函 数数 依依 赖赖 （ FullFunctionalDependency）：）：若xY，并且对x的任何一个真子集x,都有xY,则称Y完
52、全函数依赖完全函数依赖x,记作xY.部分函数依赖（部分函数依赖（PartialFunctionalDependency）：）：若xY成立，则称Y部分函数依赖于x.记作xY。（与书上定义比较）例：5.1模式中，（学号，课程）系名fpp5.2.1函数依赖函数依赖(FunctionalDependency)定义定义传递函数依赖（传递函数依赖（TransitiveFunctionalDependency）:若xY，（非平凡函数依赖，且Yx），YZ,则称Z传递函数依赖于x。若Yx，则xY，xZ。直接5.2.1函数依赖函数依赖(FunctionalDependency)例：教室（课程，班级，时间，教室）完
53、全函数依赖（课程，班级，时间）教室教师（姓名，职务，职务工资）传递函数依赖姓名职务职务职务工资则姓名职务工资前面例子：三个新的学生关系模式中：非平凡函数依赖学号姓名学号系系系主任（学号，课程）成绩f5.2.2码码 现实世界的每一实体集合，都有一关键字（码），即唯一确定各个实体的一组属性。同样，关系上最重要的约束是关系的关键字约束，即关键字/码唯一确定关系的元组。候选码（CandidateKey）与主码（PrimaryKey）外部码（ForeignKey）例：学生选课（学号，课号，成绩）F学生（学号，姓名，年龄）P注：主码与外码（主关键字与外关键字）提供了一个注：主码与外码（主关键字与外关键字）
54、提供了一个表示关系间联系的手段。表示关系间联系的手段。5.2.3范式范式 在关系数据模式设计中，为了避免由依赖引起的数据的冗余和更新异常问题，必须进行关系数据模式的规范化关系数据模式的规范化。自1971年，E.F.Codd提出关系规范化理论以来，人们对规范化问题进行了长期的研究，并已经有了很大进展。范式(NormalForm)的概念最早是由E.F.Codd提出的，19711972年，先后提出了1NF,2NF,3NF(根据关系模式满足的不同性质和规范化的程度划分)。1974年，又和Boyce共同提出了BCNF（Boyce-CoddNormalForm）。1976年，Fagin提出了4NF，后又有
55、人提出5NF。最重要的是3NF和BCNF。这是进行规范化的主要目标。5.2.3范式范式（具体见萨师煊等主编数据库系统概论P 174页，图5-2）1.第一范式（第一范式（1NF）：）：（具体见萨师煊等主编数据库系统概论P170）每个关系模式都应满足的最低要求。即关系的所有分量都必须是不可分的最小数据项。系名称高级职称人数教授副教授5.2.3范式范式2.第二范式（第二范式（2NF）：）：（具体见萨师煊等主编数据库系统概论P174）定义：若R1NF，且每一非主属性完全函数依赖于码，则R2NF。所有单属性关键字都是2NF关系。复合关键字（多属性构成），且存在非主属性对关键字的部分依赖，则否。5.2.3
56、范式范式反例：例：库存（仓库号，设备号，数量，地点）1NF，但非但非2NF。非主属性数量完全依赖于关键字。非主属性地点部分依赖于关键字。即有仓库号地点。（仓库号，设备号）地点。p5.2.3范式范式出现的问题：一个仓库若只有一种设备，则删除设备删除仓库。学生关系：学生（学号，姓名，系名）不是2NF。只有成绩完全函数依赖于码，姓名、系名、系主任对码部分依赖，因为它们由学号可决定。5.2.3范式范式解决办法投影分解将部分函数依赖关系洪的决定方和非主属性从关系模式中提出，单独构成一个关系模式。将余下属性加上码（仍要保留部分函数依赖的决定方属性，起分解出来的新关系之间的关联作用）构成另一关系模式。5.2
57、.3范式范式例：库存（仓库号，设备号，数量）仓库（仓库号，地点）学生记录（学号，姓名，系名，系主任）r(学生记录)=（学号，姓名，系名，系主任）（r(学生)）成绩（学号，课程，成绩）r(成绩)=（r(学生)）5.2.3范式范式1.第三范式（第三范式（3NF）：）：定义：（具体见萨师煊等主编数据库系统概论P176）若R2NF，并且所有非主属性都不传递依赖于关键字，则R3NF。若存在非主属性对关键字的传递依赖，则不是3NF。5.2.3范式范式反例：例：仓库（仓库号，所在省，仓库面积，所在城市）仓库号所在城市，所在城市所在省。仓库号所在省。非3NF问题：插入异常：如插入（“WH30”，“湖北”，40
58、0，“邯郸”）（“WH22”，“河北”，240，“”）再如：在山东济南要设一个仓库，想先存入有关所在城市信息，但无仓库号，则不能。5.2.3范式范式解决投影分解：（将传递依赖的属性分解出来自己总结的）仓库（仓库号，仓库面积，所在城市）城市（省，城市）再例：学生记录（学号，姓名，系，系主任）不是3NF学号系，系系主任，学号系主任系主任对码（学号）的传递依赖。分解：学生档案（学号，姓名，系名）系（系名，系主任）5.2.3范式范式4.BCNF范式：范式：由于3NF仍存在一些操作异常，.定义：（具体见萨师煊等主编数据库系统概论P176）即若R中的每个函数依赖的左部都是关键字/码（或所有的决定因素 都是
59、关键字），则RBCNF。5.2.3范式范式或：若R3NF，并且不存在主属性对非主属性的函数依赖，则RBCNF。一个满足BCNF的关系模式一定是非主属性对码完全函数依赖;主属性对不包含它的码也是完全函数依赖；设有属性完全函数依赖于码以外的属性组。5.2.3范式范式举例及讨论：例：.管理（仓库号，设备号，职工号）3NF，非非BCNF。语义：.一个仓库可有多个职工；.一名职工仅在一个仓库工作；.在每个仓库，一种设备仅由一名职工保管（但每名职工可以保管多种设备）。根据语义有依赖：职工号仓库号；（仓库号，设备号）职工号；问题：新职工分到一仓库，尚未负责设备，则不能插入。插入异常：同一设备，两个职工，无法
60、防止这样插入，与违背。5.2.3范式范式例：.学生（学号，姓名，专业，宿舍）假定无重名，则码为学号或姓名，非主属性对这两个码不存在部分函数依赖和传递函数依赖，是3NF。而同时除学号和姓名以外没有其他决定因素，也是BCNF。5.2.3范式范式例：.通讯（城市，街道，邮编）完全依赖于码，且无传递依赖，是3NF。但邮编城市，它是决定因素，它不是码，也不包含在码中，非BCNF。非BCNF分解BCNF，会破坏函数依赖。Solution:保持3NF，警惕主属性对非主属性的函数依赖带来的操作异常现象。5.2.3范式范式5.多值依赖与第四范式：多值依赖与第四范式：.多值依赖多值依赖(MultivalentDe
61、pendency):定定义义5.9(具体见萨师煊等主编数据库系统概论P178)例：(P178)增加一名教师，要插入多个（三个）元组；去掉一本参考书，要删除多个（两个）元组数据冗余明显，增加、删除不方便，日积月累可能出现数据错误。5.2.3范式范式原因：关系上存在着一种多值依赖。对于（物理，光学物理）有一组值李勇，王CZY军T与之对应。这组值决定于课程上的值，与参考书的值无关。即另一个（物理，普通物理学）对应的一组值仍为T。T多值依赖于C，即CT。5.2.3范式范式例：P180(W1,C1)有一组值S1,S2与之对应，与无关。(W1,C2)有一组值S1,S2与之对应，与无关。.对W的每一个值Wi
62、，S有一完整的集合与之对应,而与C无关.WS,同样WC。5.2.3范式范式多值依赖的性质：多值依赖的性质：（具体见萨师煊等主编数据库系统概论P181）对称性：若xY，则xZ.函数依赖是多值依赖的特例（即函数依赖的一定是多值依赖），多值依赖是函数依赖的概括（即存在多值依赖的关系，不一定存在函数依赖关系。）：若xY，则xY.平凡的多值依赖：若xY，而Z=时。 若xY，Z（包含于）Y，WZ，且YW=，则xW。Notes：关系模式中至少有三个属性，才有可关系模式中至少有三个属性，才有可能存在能存在多值依赖。多值依赖。5.2.3范式范式多值依赖与函数依赖的区别：多值依赖与函数依赖的区别：xY的有效性仅决
63、定于x,Y这两个属性集的值，即仅在xY(R)上成立即可；而xY的有效性与属性集的范围有关，需在U(整个属性集)上成立。R(U)xY在R(U)上成立，则对于YY，有xY成立；而xY在R(U)上成立，不能判定对YY，有xY成立。5.2.3范式范式4NF：定义（具体见萨师煊等主编数据库系统概论P181）一个关系模式若属于4NF，则必然属于BCNF，反之不一定；4NF关系消除了BCNF关系中不理想之处，因此比BCNF先进。函数依赖只考虑关系模式的静态逻辑结构。而多值依赖受关系模式取值的动态变化的影响，即当在关系模式中删除一些元组时，多值依赖关系可能被破坏。5.2.3范式范式关于关于函数依赖函数依赖函数
64、依赖通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。一个函数依赖成立就意味着关系在任意时刻的实例都满足函数依赖的条件。要确定函数依赖成立，需弄清楚数据的语义（语义：是实现世界的反映，不是主观臆断或仅由关系的当前实例所决定。）5.2.3范式范式多值依赖：（至少三个属性，才有可能存在多值依赖）例:Transport(Cname,Caddr,Item,Sname,Saddr)Item(Cname,Caddr)一种商品可以有多位顾客订购，与由哪些供应商供应无关。Item(Sname,Saddr)5.2.3范式范式多值依赖与函数依赖的区别：XY的有效性仅决定于X,Y这两个属性集的值，即仅在x
65、Y(R)上成立可；而XY的有效性与属性集的范围有关，需在U(整个属性集)上成立。R(U)XY在R(U)上成立，则对于所有Y中的Y,有xY成立；而XY在R(U)上成立，不能判定对所有YY,有xY成立。函数依赖只考虑关系模式的静态逻辑结构；而多值依赖受关系模式取值的动态变化的影响，即当在关系模式中删除一些元组时，多值依赖关系可能被破坏.5.3数据依赖的公有系统数据依赖的公有系统 Armstrong公理Armstrong公理：模式分解算法的理论基础。已知R满足一组函数依赖F，如何知道R中还有哪些FD(函数依赖)？或由F还能推导出哪些FD？需要一套形式化的推理规则。5.3数据依赖的公有系统数据依赖的公
66、有系统一Armstrong公理的内容及正确性。（具体见萨师煊等主编数据库系统概论P183）R(U,F)，Xu，YU，ZU。推导规则如下：自反律（Reflexivity）：若YX，则xY。（平凡FD）增广律（Augmentation）：若XY，则xZYZ。记为：XZYZ。传递律（Transitivity）：若xY，YZ，则xZ。 5.3数据依赖的公有系统数据依赖的公有系统正确性： 增广：若 tXZ=SXZ，则 tx=Sx，tZ=SZ；又由xY，有tY=SY；由和得：tYZ=SYZ。传递：sx=txxY推出：sY=tYYZ推出：sZ=tZ。 5.3数据依赖的公有系统数据依赖的公有系统二Armstr
67、ong公理的推论：(P184)合并规则：若XY，XZ，则XYZ。分解规则：若XY，ZY，则XZ。伪传递规则：若xY，YWZ，XWZ。XY，XZ（增广）；XXY，XYYZ（传递）；XYZ。xY，YWZ（增广）；xWYW（传递）；xWZ。5.3数据依赖的公有系统数据依赖的公有系统根据合并规则和分解规则得到结论：引理1：（具体见萨师煊等主编数据库系统概论P184）xA1A2A3.AnXAk成立（k=1,2,.n）5.3数据依赖的公有系统数据依赖的公有系统三三逻辑蕴涵和闭包：逻辑蕴涵和闭包：有时需要根据给定的一组函数依赖来判断另一些FD是否成立，这是函数依赖逻辑蕴涵要研究的内容。例如： R(U,F),
68、UA,B,C,F=AB,BC， 问AC成立？根据传递律AC成立这时说F逻辑蕴涵AC。5.3数据依赖的公有系统数据依赖的公有系统定定义义1.逻逻辑辑蕴蕴涵涵：（具体见萨师煊等主编数据库系统概论P183定义定义5.11）设有关系模式R(U,F),XU,YU，如果从F中的函数依赖能推导出xY，则称F 逻辑蕴涵xY。5.3数据依赖的公有系统数据依赖的公有系统定定义义2.闭闭包包：（具体见萨师煊等主编数据库系统概论P184，定义定义5.12）在关系模式R(U,F)中，被F所逻辑蕴涵的函数依赖的全体称作F的闭包，记为F+。 求闭包F+是理论上可计算而实际上不可计算的问题。（麻烦）如：从F=xA1A2A3.
69、An出发，至少推导出2的n次幂个不同的函数依赖。F+很大。如：F=xY，YZ；F+=xx,xXy,xZxY,xxYZ,xZxYZ.。5.3数据依赖的公有系统数据依赖的公有系统定义定义3.设F函数依赖，XU,XF+=AXA能由F根据Armstrong公理导出，所有用Armstrong公理从F导出的函数依赖XAi 中Ai的属性集合,称为属性集属性集X关于关于F的闭包的闭包.例：R(U,F),UA,B,C,F=AB,BC，若X=A，则XF+=A,B,CX=B，则XF+=B,CX=C，则XF+=C5.3数据依赖的公有系统数据依赖的公有系统四四公理的完备性公理的完备性定理：Armstrong公理系统是有
70、效的，完备的。有效性：对于关系模式R(U,F)，只要F中的函数依赖为真，则用公理根据F推导出的函数依赖也一定为T。完备性：用公理能否推导出所有的FD?即F+中所有的FD是否都能用公理推导出来？若F+中有FD不能用公理推出，说明公理不够用、不完全，就必须补充新的公理。5.3数据依赖的公有系统数据依赖的公有系统五五闭包的计算闭包的计算XF+的计算可以间接解决F+计算的问题，即可以帮助判定XF是否属于F+。算法：求属性集X关于U上的函数依赖集F的闭包XF+（P185）.例：（P185）设有R(U,F),U=A,B,C,D,EF=ABC,BD,CE,ECB,ACB求：(AB)F+(AB)F+=ABCE
71、D5.3数据依赖的公有系统数据依赖的公有系统附：关系规范化的基本原则附：关系规范化的基本原则Normalization：一个低级范式的关系模式经投影分解多个高一级范式的关系Scheme的集合。主要思想：逐步消除数据依赖中不合适的部分，使各关系模式达到一定程度的分离“一事一地”的模式设计原则。即：让一个关系描述一个概念/一个实体/实体间的一种联系。5.3数据依赖的公有系统数据依赖的公有系统规范化的程度越高数据的冗余和更新异常就相对减少。但连接运算费时查询花时间多。根据具体情况，权衡利弊。数据变动不频繁，规范化程度可低一些。实际工作中，一般达到3NF。 5.3数据依赖的公有系统数据依赖的公有系统原
72、则：关系模式进行无损连接分解（且保持FD），分解过程中，数据不能丢失或增加。把全局关系模式中的所有数据无损的分解到各个子关系模式中。以保证数据的完整性。（P189）例：S(SNO,SDEPT,MN)注：MN为负责人正确的结果：S(SNO,SDEPT)D(SDEPT,MN)未解决插入删除异常：S(SNO,SDEPT)D(SNO,MN)SDEPTMN无5.3数据依赖的公有系统数据依赖的公有系统合理选择规范化程度：若考虑存取效率低级范式冗余大，浪费空间，影响一致性。希望属性越少越好， 取高级范式。若 考 虑 查 询 效 率 低 级 范 式 比 高 级 范 式 好 。 连接运算代价较少根据情况，合理选
73、择规范化程度。和是一对矛盾。 5.3数据依赖的公有系统数据依赖的公有系统正确性与可实现性原则举例：学号姓名性别专业年级课程成绩 课号课名学时学分教师工资号成绩5.3数据依赖的公有系统数据依赖的公有系统基本函数依赖集：F1=学号（姓名，性别，专业，年级），课号（课名，学时，学分，工资号，教师），（学号，课程）成绩，工资号教师 1NF：学生（学号，姓名，性别，专业，年级，课号，课名，学时，学分，教师，工资号，成绩）消除部分函数依赖5.3数据依赖的公有系统数据依赖的公有系统2NF：学生（学号,姓名,性别,专业,年级）；课程（课号,课名,学时,学分,教师,工资号）；成绩（学号,课号,成绩）。消除传递函
74、数依赖 3NF： 课程（课号，课名，学时，学分，工资号）课号工资号教师（工资号，教师）工资号教师 也是BCNF。5.3数据依赖的公有系统数据依赖的公有系统补补充充：Normalization在在实实际际数数据据库库设设计计中中的的应应用用前面介绍的Normalizationd的过程：（理论上）定先用某种方法得到一个关系模式R分析并确定R上的FD和MVD用机械的方法进行模式分解，消除不适当的数据依赖关系，从而规范化。5.3数据依赖的公有系统数据依赖的公有系统实际应用并非这样：找出所有数据依赖关系不是一件简单的事。若遗漏/出错，则得不到理论上认为好的DB。就算正确找出，机械分解，而不考虑具体情况，
75、全 规范化到同样程度，也不适当。（是否常更新）数据库设计一般先：E-R图而E-R图实体集合分解较细（包含属性较小）为了以后DB查询的方便，更多的情况是合并模式 ，而非分解。5.3数据依赖的公有系统数据依赖的公有系统在实际应用中，为得到好的DB设计，要视具体情况对数据库处理，既可合并，也可能分解。但Normalizationd理论仍起指导作用。 第六章第六章数据库设计数据库设计6.1数据库设计概述数据库设计概述6.1.1结构化生命周期法结构化生命周期法基于软件工程思想的一种信息系统设计方法基于软件工程思想的一种信息系统设计方法可行性分析（系统调查）经济可行性分析：资金投入技术可行性分析：相应技术
76、使用可行性分析：系统被用户接受、使用。都是整个项目立项与否的重要阶段，高层决策者参与讨论决定。6.1.1结构化生命周期法需求分析（系统分析）其方法在P210，过程在P211。系统开发中最重要的一步。认识现实世界，了解企业需求是设计数据库的基础，否则，即使有先进的技术、高超的水平，也不可能设计出用户所需的系统。目标：详细调查要处理的对象，了解原系统（年工/以前计算机系统）情况，确定新系统功能、目标。虽然“技术含量不高”，但非常重要，是系统成功与否的关键。并且强调用户参与，离开用户将寸步难行。6.1.1结构化生命周期法总体设计（概念结构设计）把用户的信息要求统一到一个整体的逻辑结构或概念模式中，独
77、立于任何硬件和数据库管理系统。应用程序：完成于系统划分、功能模块划分。数据库角度：概念模型设计。详细设计（逻辑结构设计）应用程序：给出功能模块说明，考虑实施方法，设计存储过程。数据库角度：根据具体的DBMS设计DataBase、设计关系，考虑数据的完整性、考虑数据的安全和备份策略。6.1.1结构化生命周期法编程根据上一步设计结果进行具体实施。建立数据库并装入原始数据，建立存储过程。编程，调用应用程序代码。调试与试运行前一阶段作了局部测试，现在：各子系统、各模块要联合调试和测试，并试运行（试运行：听取用户意见）。6.1.1结构化生命周期法系统运行，评价与维护（运行）最后一步将系统交给用户使用。使
78、用过程中，可能还会出现新的问题，甚至提出新要求，不断对系统评价，维护。数据库系统的维护不是一朝一夕的事。只要DataBaseSystem存在，就要不断的评价、调试、修改，直至数据库生命周期结束、或完全重新设计为止。6.1.1结构化生命周期法要求开发过程严格按阶段进行，前一阶段完成，才开始下一阶段，没一阶段都要有严格的文档资料。优点：每一步目标明确，易于管理。缺点：用户只参与了需求分析阶段工作，对即将建立的新系统没有直观的预见，很可能开发方开发的系统不是用户所需要的。6.1.2快速原型方法（快速原型方法（RapidPrototypingApproach） 为克服前述方法的缺陷应运而生为克服前述方
79、法的缺陷应运而生基本思想根据原型进行快速开发，对存在的问题反复修正，直至形成用户满意的系统。6.1.2快速原型方法（快速原型方法（RapidPrototypingApproach）原型“企业作业原型”、“软件功能原型”反映了最终系统的基本功能黑本特征，依此可快速开发一个可以演示的系统，用户在这个原型系统中得到启发，发现存在的问题，提出新的要求，并和开发人员一起修正和发展原型，如此反复，最后形成用户满意的原型。用户参与了开发的全过程；整个过程用户看得见；因系统离自己的目标越来越近而兴奋。6.1.2快速原型方法（快速原型方法（RapidPrototypingApproach）优点提高系统开发质量，
80、降低开发成本，缩短开发周期，最大程度的满足用户需求。注：采用该方法要有快速开发工具的支持；靠原始手工作坊式一条条编程不行；要求开发人员熟练掌握快速开发工具，对用户的修改意见课作出快速的反应。 6.1.2快速原型方法（快速原型方法（RapidPrototypingApproach）其它方法：l面向对象法；lDADM演示与讨论；l生长与原型法；l软件复用技术。6.2需求分析需求分析 一、需求分析的任务见萨师煊等主编数据库系统概论P209二、需求分析的方法见萨师煊等主编数据库系统概论P2106.2需求分析需求分析三、数据流图（DFD）与数据字典1定义： 系统的逻辑模型，不依赖于硬件，软件和DataS
81、tructure 便于用户理解的数据流程的图形表示分析元与用户之间非常好的通信工具，进一步系统设计的出发点 6.2需求分析需求分析2DFD的组成元素：数据流（）：用名字标记的 表示数据流。将DFD中其它元素连接起来。处理/加工（）：对数据进行的操作。把流入的数据流转化为流出的数据流。 注：每个处理应有一个名字表示它的含义，并分配一个编号，以便标识它在层次结构中的位置。 存储：暂时存储数据的工具。磁带，磁盘，文件，表数据源点和终点：（）系统的输入/输出；系统之外的人员/组织；系统数据的发送者/接受者； 6.3概念结构设计概念结构设计 概念结构设计：在需求基础上，用数据模型表示数据及其联系。需求分
82、析包括了：功能需求分析；数据需求分析（数据库设计的基础）。概念模型：不依赖于任何DBMS；从现实世界角度对数据的抽象、描述；容易为用户所理解。 6.3概念结构设计概念结构设计一设计局部E-R图概念结构设计依据是需求分析阶段的DFD/DD。在DFD中选择适当层次的DFD，作为设计局部E-R图的出发点。中层 允许有一定的重叠确定实体集合第一步（关键一步）数据流 / 数据源 / 目的 / 数据存储 根据具体情况决定常作为实体集合 6.3概念结构设计概念结构设计联系标明：1:1，1:N，N:M。原则上：与处理框相关的输入流（数据流），输出流（数据目的地），输入或输出的工作之间的可能存在的联系。 6.3
83、概念结构设计概念结构设计属性属性名尽量和数据流中数据项名相同。数据流实体的属性数据流包括的数据项。数据存储数据源数据目标为简化E-R图，属性可仅在DFD中描述。准则（P219） 实体属性进/出该实体集的某个数据流中6.3概念结构设计概念结构设计主关键字属性中标明作为PK的属性集合。其它建E-R图，要完善DD(DD：包括实体集，联系，属性的描述)某些情况：描述产生频率（每年/月/季），是否长期保存，变化快慢，保密级别，存在的约束。 6.3概念结构设计概念结构设计二集成局部E-R图在设计局部E-R图的基础上，将局部E-R图集成为全 局E-R图。集成时要解决的问题：消除冲突命名冲突：（P225）同名
84、异义异名同义 实体 联系 属性6.3概念结构设计概念结构设计结构冲突：l同一概念在不同E-R图中意义、作用不同：实体 属性 联系l同一实体在不同E-R图中包括属性组不同常见：局部应用关心侧重不同Solution并集调整次序l同一联系在不同E-R图中类型不同。6.3概念结构设计概念结构设计属性冲突（P225）约束E-R图：同一数据项在不同的E-R图中有不同的约束条件和访问权限。具体集成时的原则：最后形成的模型和所有局部模型一致。若做不到：或许局部E-R图有错修改或许本来就是不同概念不应视作一个 6.3概念结构设计概念结构设计 消除冗余冗余：破坏DB完整性，维护起来困难冗余数据：由基本数据导出的数
85、据。冗余联系：由基本联系导出的联系。方法：分析方法：以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数
86、据库的物理设计数据库的物理设计DB特点高效存取大量数据的能力。（依靠各类加速存取DB的物理存储技术） 6.5.1物理数据模型物理数据模型 一、记录和文件关系在物理级表示为文件 具有相同格式的记录集合。纪录：存储元组，由一个或多个字段（字段：存储元组的含量）组成（初等Data Type）。流式文件：只能实现顺序存取记录是文件：多种方法存取在物理级，DB是一组文件（存储文件）；文件是纪录的集合；记录由字段组成。区别：6.5.1物理数据模型物理数据模型二、永久存储和分块数据库运行时，外部存储器和主存之间要频繁地进行数据交换，每次交换的数据量称为一个数据块。在内存中开辟的缓冲区的大小至少要等于一个数据
87、块的大小。数据块越大，一次能调进调出的记录数就越多。这种情况对顺序处理能减少访问磁盘的次数，提高了处理速度，但是对于以随机处理为主的应用系统就不一定合适了。因为数据块包含的记录数越多，同本次处理无关的记录可能传送的就越多，这样造成有效的数据传送降低，并且占用了更多的内存。所以，数据块的大小是考虑多方面因素后由厂家而非用户确定的。 6.5.1物理数据模型物理数据模型数据块的长度不一定恰好等于记录的整数倍，通常有两种组织方式： 不跨块方式：即一个数据块只包含若干完整的记录，不足以容纳一个记录的零头空间放弃不用； 跨块方式：允许一个记录跨在不同的数据块，这种组织方式可节省空间，但由于实现较困难，故很
88、少使用。6.5.1物理数据模型物理数据模型上面提到的缓冲区数目和大小，数据块的大小及组织方式，是由DBMS设计者安排和实现的，不同系统设置都不一样，这些细节对数据库用户而言是透明的。除了大的数据对象，多数记录的长度快的大小因此：多个记录存于一个快中运算代价同内存，外存之间传输块的个数有关存储文件时，要考虑如何在块中安排记录的占用较少的块6.5.1物理数据模型物理数据模型三、数据库存取代价数据库存取代价=物理块存取代价+计算代价可忽略物理块存取次数每块存取代价用块的存取次数来描述DB的存取代价6.5.2DB文件的存取组织方法文件的存取组织方法 一索引存取方法索引文件 l是DBS常采用的数据文件结
89、构，按关键字存取文件，效率较高。 l索引表，有序的逻辑文件。 l只反映与索引项有关的数据的存放位置而不是数 据本身l不能离开被索引的数据文件（主文件）而独立存在6.5.2DB文件的存取组织方法文件的存取组织方法建立索引的方式多种多样：主索引（Primary Index）：以记录的主关键字建索引。次索引（Secondary Index）：用非主关键字建索引。倒排文件（Inverted File）：在所有属性上都建索引。6.5.2DB文件的存取组织方法文件的存取组织方法稠密文件（Dense Index）：索引文件中对每一个索引项值都有一个索引记录。稀疏索引（Sparse Index）：索引文件中对
90、一组索引项值才有一个索引记录。聚集索引（Clustering Index）：将索引项值相同的记录在物理上集中存储在同一块或相邻块。多级索引（Multilevel Index）：在索引文件的基础上再建索引。6.5.2DB文件的存取组织方法文件的存取组织方法常用的较好的折中的办法 处理DB主要开销：把块从磁盘上取到主存中所需时间，扫描整个块的时间可忽略。更快的定位一个记录权衡注：稠密索引索引文件较大插入/删除，维护开销小空间开销决定于具体应用稀疏索引 占用空间小 访问时间6.5.2DB文件的存取组织方法文件的存取组织方法注：索引本身有时也会变得非常大，而难于有效处理。例：一个文件由100000（1
91、0万）个记录，一块存 10个记录，有一个索引记录。索引有10000个记录，索引记录比数据记录小，设一个块能容纳100个索引记录索引占100个块读取出块数高达log2(100)7=7次，读块7次6.5.2DB文件的存取组织方法文件的存取组织方法主索引上构造一个稀疏索引：搜索一个记录，在外层索引上用二分法找到不大于所需索码值的最大搜索码值对应的记录，指针指向一个内层索引块，对这一块作扫描，直到找到不大于所需搜索码值的最大搜索码值对应的记录。这样，如果外层索引一在主存中，那么使用两级索引时，只需读一次索引块。6.5.2DB文件的存取组织方法文件的存取组织方法B+树索引文件：前面几种索引文件都是静态索
92、引（静态索引适用于相对比较稳定的文件），即索引结构和级别都是固定不复的，但随着主文件记录的变动，索引文件也要变化，需要增加维护开销。而且，随着主文件的变化，索引文件的性能会逐渐下降，到一定时候要进行重组织。对变化较大的文件，用动态索引。主文件较大时，多级索引可提高速度，但文件内容不多，不必要，反而降低效率。6.5.2DB文件的存取组织方法文件的存取组织方法二、聚簇ClusteredIndex：数据（以升序）物理的存放在页上，索引页中的值的顺序也升序。很多RDBS将各个关系存储在一个个独立的文件中（很多DBMS在文件管理方面不直接依赖于下层OS，而让OS分配给DBS一个大的操作系统文件，所有关系
93、都在这个文件中，其管理用DBS进行）利用OS的文件管理。这种实现关系数据库的简单方法在DB规模大时不合适。6.5.2DB文件的存取组织方法文件的存取组织方法例：（理解一个文件中存储多个关系的好处）图Selectaccount_number,customer_name,street,cityFromdepositor,customerWhere.必须找到具有相同customer_ name的customer元组（可用索引）对depositor中的每个元组但要从磁盘传到主存中最快情况：每个记录在一个块，每个记录执行一次块操作。6.5.2DB文件的存取组织方法文件的存取组织方法聚簇文件结构：将两个关
94、系的元组混合在一起，读customer一个元组时，包含该元组的整个块从磁盘到主存。相应depositor元组存储在靠近customer元组的磁盘上该块也包含了处理查询所需的关系depositor的元组，顾客账户太多，则存在临近块中。 6.5.3存取方法存取方法 数据库文件的组织方法一堆文件组织记录无任何次序的状如块中，块之间无特殊的组 织，块间由指针联系。一条记录可以放在文件中的任何地方，只有那个地方有时间存放，记录无顺序，一个关系就是一 个单独的文件。文本文件，数据文件等串行处理文件以堆文件组织。6.5.3存取方法存取方法二顺序文件组织为了快速的按搜索码获取记录，我们通过指针把记 录链起来，
95、每个记录的指针指向在搜索码顺序上的下一个记录。为了减少顺序文件处理中的块访问的次数，在物理 上按搜索码顺序存储起来。三散列文件组织（HASH）通过计算所需记录搜索码上的一个函数直接获得包 含该记录的磁盘块地址。桶存储一条/多条记录的存储单位 第七章第七章数据库恢复技术数据库恢复技术 数据库是一种共享资源，因此，在数据库的使用过程中，保证数据的安全可靠，、正确可用就成为非常重要的问题，它是有效使用数据库的前提。数据库被破坏的原因可归纳为：软硬件故障，造成数据被破坏。数据库的并发操作引起数据的不一致性。自然或人为地破坏，如失火、失窃、病毒和为授权人的有意纂改数据。对数据库数据的更新操作有误，如操作
96、时输入错误的数据或存取数据库的程序有错等等。第七章第七章数据库恢复技术数据库恢复技术针对这四类问题，一般DBMS提供了相应的功能：数据库恢复：即系统失效后的数据库恢复，配合定时备份数据库，使数据不丢失数据。并发控制：即保证多用户能共享数据库，并维护数据的一致性。安全性保护：防止对数据库的非法使用，以避免数据泄漏、纂改、破坏。完整性保护：保证数据的正确性和一致性。从系统的角度看，数据库保护主要是指控制哪类用户可用什么方式存取哪类数据对象，以及对各类数据对象有那些完整性约束等问题。 7.1事务的基本概念事务的基本概念 一事务（Transaction）：事务是一种机制，它确保多个SQL语句被当作单个
97、工作单元来处理。二、四个特性ACID准则7.1事务的基本概念事务的基本概念 原子性（Atomicity）即事务执行的原子性，事务“要么不做，要么全做”，如果事务因故障没有完成，则该事务已做的操作认为是无效的，在恢复时必须取消该事务对数据库的影响。保证原子性的思路：对于要执行写操作的数据项，在磁盘上记录其旧值，若事务没能完成执行，旧值将被恢复，好像事务从未执行。保证原子性是DBMS本身的责任，由“事务管理部件”处理。7.1事务的基本概念事务的基本概念 一致性（Consistency）事务作用于数据库过程中，数据应始终满足完整性约束。一个事务的执行是把DB从一个一致的状态阿转换成另一个一致的状态。
98、确保单个事务的一致性是对该事务编码的应用，程序元的责任，完整性给这项工作带来了便利。7.1事务的基本概念事务的基本概念 隔离性（Isolation）即事务并发执行的相对独立性，这是事务并发控制的目标。使事务并发执行的结果和某一串行执行的结果相同。即使每个事务都能确保C、A，但如几个事务并发执行，它们的操作会以人们不希望的某种发式交叉执行，也会导致不一致状态。一种解决方法：串行执行事务（一个接一个）。隔离性保证事务并发执行的结果和某一串行执行的结果相同。7.1事务的基本概念事务的基本概念持久性（Durability）DBMS中“恢复管理部件”的责任。完成了的事务对数据库的影响应是持久的 ，即使数
99、据库因故障而受到破坏，DBMS也应该能够正确的恢复数据。 7.2数据库恢复概述数据库恢复概述 数据库恢复：即系统失效后的数据库恢复，配合定时备份数据库，使数据不丢失数据。7.3故障的种类故障的种类一、事务内部的故障二、系统故障三、介质故障四、计算机病毒7.4恢复的实现技术恢复的实现技术 一、数据转储（备份）二、登记日志文件备份是定期的，而不是实时的，所以利用备份并不能完全恢复数据库，只能将数据库恢复制作备份的那一时刻。日志是对备份的补充，它可以看作是一个值班日记，它将记录下所有对数据库的更新操作。日志文件是实时的。当磁盘发生故障造成DB损坏时，先利用备份恢复大部分数据库，然后运行数据库日志，将
100、备份后所做的更新操作在重做一遍，从而使DB完全恢复。 7.4恢复的实现技术恢复的实现技术 为保证日志的安全，应该将日志和主数据库安排在不同的存储设备上，否则日志和DB可能会同时遭破坏，日志也就失去了本来的作用。日志记录有几种，“更新日志记录”描述一次数据库写操作，它有如下几个字段：事务标识：执行写操作的事务的唯一标识。数据项标识：所写的数据项的唯一标识，通常是数据项在磁盘上的位置。 旧值：数据项的写前值。新指：数据项的写后值。7.4恢复的实现技术恢复的实现技术 其它特殊的日志记录用于记录事务处理过程中的重要事件，如事务的开始，以及事务的提交或中止。将各种类型的日志记录记为：事务Ti开始数据项
101、前 后提交中止每次事务执行写之前，必须在DB修改前生成该次写操作的日志记录。一旦日志记录已创建，就可以根据需要对DB做修改，并且，能利用日志记录中的旧值消除已做的修改。 7.5具有检查点的恢复技术具有检查点的恢复技术 系统故障，检查日志，决定哪些事务需要(redo,undo)原则上搜索整个日志来决定该信息问题：搜索过程耗时根据提供的算法，大多数需要的事物都将其更新写入了DB为降低开销引入检查点日志文件中的一类记录：检查点记录“重新开始文件”记录各检查点，记录在日志文件中的地址。7.5具有检查点的恢复技术具有检查点的恢复技术 恢复子系统在登陆日志文件期间动态的维护日志：缓冲中日志记录写入磁盘的日
102、志文件在日志文件中写一个检查点缓冲中的数据记录写入磁盘检查点记录在日志文件中的地址重新开始文件建立检查点预定时间间隔：按某种规则：如日志写满一半检查点前提交的事务对DB的修改一定已写入DB.不用对”T”REDO例：P2587.6数据库镜像数据库镜像 镜像的实质也是备份，在同一时刻保存数据的两个或多个副本。镜像与转储本质不同：转储：定期或不定期的、间断、非实时镜像一般是OS的功能硬盘级的但DBMS为了防止介质出现故障而丢失数据也提供了镜像功能如果条件许可，尽量使用OS级的硬盘级的镜像7.6数据库镜像数据库镜像SQLServer：镜像连续、实时的将一个SQLServer设备上的信息复制到另一个设备
103、上。对该设备操作的所有事件都复制到它的副本镜像设备上。如果两个设备中的一个损坏了，另一个设备由于保存了所有事件轨迹的最新拷贝，所以系统会完成自动切换，并保存系统连读工作。第八章第八章并发控制并发控制 8.1并发控制概述并发控制概述并发控制：保证多用户能共享数据库，并维护数据的一致性。不一致状态：由于系统的故障，系统的状态不再反映DB应当描述的现实世界的真实状态，系统必然会在某一时刻处于不一致状态，最终应该被一致态所代替。数据库是一个共享资源，不同的用户可能要同时操作一个数据库，同时操作一个基本表，甚至同时操作一条记录。8.1并发控制概述那么这些用户会不会发生冲突呢？不同用户同时实施的更新操作会
104、不会矛盾呢?如果控制不当的确会发生这些问题，本节讨论这方面的问题。并发存取可能出现的异常事务的并发执行可以显著提高系统的资源利用率，提高系统的效率，但当多个事务对数据库进行并发操作时，如不加任何控制，可能会引起数据库数据的不一致性。8.1并发控制概述 丢失修改（例P265） 不能重复读：如果在一个事务要对一个项连续读两次，以进行项的校验，而在此之间，插入另一个事务读对该项的值进行修改，则可能造成事务对同一项两次读出来的结果不一样。8.1并发控制概述“脏”读（DirtyRead）：当一个事务T1在对数据库中的某些项做了修改以后,因某种原因而中途取消，则它对数据库的修改是无效的，这些被修改过的项称
105、为“脏”数据。在T1取消前，可能有其它事务已经读过这些“脏”数据,如果根据此数据计算出新数据并写回数据库，则数据库中数据出错.8.1并发控制概述以上是典型的“脏”读的例子，异常不可能一一列举完。所以只要有适当的并发控制技术控制并发的事务正确的执行，互不干扰，以避免造成数据库中的数据不一致性。要在数据库系统保证数据的一致性，系统是会有代价的，为了减少开销，有时允许一些数据不一致性的存在，只要对数据库影响不大。项（Item）：数据库操作的基本数据单位，也是并发控制的基本单位，可以是数据库/关系/元组/字段.(由系统设计人员选择)8.2封锁（封锁（Locking） 基本思想：当一个用户对一个表或记录
106、进行更新时，封锁改表或记录，是其他用户不能在同一时刻更新相同的表或记录，迫使其它用户在更新后的基础上再实施另外的更新操作。一、封/加锁的类型X锁最简单的加锁方式，只有一种X锁，即排它锁（Exclusive Locks），该锁既用于项的写操作，也用于项的读操作。注：事务T一旦对某项R加了X锁，则其它事务不能在对该项加锁，直至T释放X锁。8.2封锁（封锁（Locking） S,X锁S锁（Share Locks）共享锁，用于项的读操作。设有两种锁X锁 共享锁，用于项的写操作。 允许多个事务并发的读同一项，但对项的写操作必须排它。（S，X）锁单独采用X锁提高了并发程度，但可能产生活锁（LiveLock
107、），即由于不断有事务对某项加S锁，而使一些想对该项加X锁的事务长期等待，对系统性能有不良影响。 8.2封锁（封锁（Locking） S，U，X锁增加了U锁（Update Lock）更新锁，事务在更新一个项时，首先对该项加U锁，此时允许其它事务在该项加S锁，待事务读出并修改项后，再将加在该锁上的U锁升级为X锁，然后写入修改后的项。由于不必在事务执行的全过程加X锁，因此进一步提高了并发程度，仍也可能 活锁。8.2封锁（封锁（Locking） 二、调度的可串行性在并行执行事务时，我们会发现，由于事务交叉执行顺序不同，可能会得到不同的结果，必须有一个准则来判断那个正确。假设事务执行的正确结果是在没有别
108、的事务并发执行时执行它得到的结果。由于事务可以一个接一个的串行执行，所以下面的假设正确：几个事务并发执行是正确的其结果同以某种次序串行执行这些事务得到的结果相同8.3活锁和死锁活锁和死锁系统对数据项加锁不能太随意，否则可能引起死锁。活锁：当若干事务要对同一数据项加锁时，造成一 些事务的永久等待。例：P270避免活锁的简单方法：采用先来先服务策略。即让系统按请求加锁的先后次序对事务排队，数据项上的锁一旦释放，就批准申请队列中第一个事务获得加锁。8.3活锁和死锁活锁和死锁 死锁：指两个以上事务集合中的每个事务都在等待加锁当前已被另一事务加锁的数据项，从而造成相互等待的现象。DB中解决死锁的方法：一
109、次封锁法：要求每个事务一次将所有要使用的数据全部加锁，否则就不能执行。 8.3活锁和死锁活锁和死锁 采用按序加锁法：预先规定一个对数据项加锁的顺序，要求所有事务按照这个次序申请加锁，锁管理也按顺序批准加锁。 不采取任何措施预防死锁，而是周期性的检查 系统中是否有死锁，若发现，就设法解除。选择一个需花费代价最小的方法处理死锁。如：事务T撤销，释放被加的锁，使其它事务 继续运行下去8.4并发调度的可串行性并发调度的可串行性事务处理系统允许多个事务并发执行多个事务并发更新数据异常如果串行执行，就OK一次执行一个事务，每个事务仅当前一个事务执行完毕才开始，但如下理由促使我们考虑并发。 u一个事务由多个
110、步骤组成 u一些步骤涉及I/O活动 u一些步骤涉及CPU活动 8.4并发调度的可串行性并发调度的可串行性 多个事务可并行执行，一个事务在磁盘上读写时，另一个可在CPU上运行，可增加系统的“吞吐量”给定时间内执行的事务数增加，相应磁盘与CPU利用率提高，空闲时间较少。系统中可能运行着各种各样的事务，一些较短，一些较长，若串行执行，短事务可能得等待她前面的长事务完成难以预测的延时。如果各事务是针对DB的不同部分进行操作，事务并发执行会更好。8.4并发调度的可串行性并发调度的可串行性减少“平均响应时间”一个事务从开始到完成所需的平均时间 DB中并发执行本质上与OS中使用多道程序的动机一样。多个事务并
111、发执行时，即使每个事务都正确执行，数据库的一致性也可能被破坏。讲述“调度”可用于确定那些可以保证一致性的执行序列执行顺序：指令在系统中执行的时间顺序。8.4并发调度的可串行性并发调度的可串行性串行调度：由类自各事务的指令序列组成属于同一事务的指令在调度中紧挨在一起。N个事务，由n！个有效的串行调度例：P273,图8-5(a)(b)并发执行时，调度不必是串行的，若有两个并发执行的事务，OS可能先选其中的一个事务执行以小段时间，然后执行第二个事务一段时间，接着又切换道第一个.所有事务共享CPU时间。8.4并发调度的可串行性并发调度的可串行性执行顺序有多种，可能的调度总数要比n！大得多。如果并发执行
112、的控制完全由OS负责，许多调度都是可能的，包括使DB处于不一致状态的调度，保证任何调度执行后DB总处于一致状态是DBMS中“并发控制部件”的责任。“两段锁协议”可保证并发调度的可串行性（之一）。 8.5两段锁协议两段锁协议 两段锁协议要求每个事务分两个阶段提出加锁和解锁申请。扩展阶段（Growing Phase）：事务可以获得锁，但不能释放锁。收缩阶段（Shrinking Phase）：事务可以释放锁，但不能获得锁。一开始，事物处于扩展阶段，事务根据需要获得锁，一旦该事务释放了锁，它就进入了收缩阶段。事务遵守两段锁协议是可串行化调度的充分条件（如前例：P273）两阶段两段锁协议并不保证不会发生
113、死锁。8.6封锁的粒度封锁的粒度 封锁粒度（Granularity）封锁对象的大小逻辑单元 物理单元属性值（集）；元组； 页（索引/数据页），块等关系；索引；DB8.6封锁的粒度封锁的粒度封锁粒度与并发度的关系粒度越大封锁的数据单元越少并发读越小系统开销也越小 粒度越小封锁的数据单元越多并发读越大系统开销也越大例：P276需要一种允许系统定义多级粒度的级制多粒度封锁（MultipleGranularityLocking）一个系统中同时支持多种封锁粒度以供不同的事务选择。 第九章第九章数据库安全性数据库安全性 安全性保护：防止对数据库的非法使用，以避免数据泄漏、纂改、破坏。9.1安全性控制的一般
114、方法安全性控制的一般方法一用户标识和鉴定安全系统的核心问题是身份识别：用户名（User）口令（Password）随机数9.1安全性控制的一般方法需要有一定的方法验证用户的身份，防止他人假冒，辨别用户的最普通的方案是要求用户提供只有用户本人和系统知道的口令，由于口令一般不能太复杂，否则用户自己也会忘记，这就使得口令不够安全，容易被想非法进入数据库系统的人破译。解决这个问题的方法是要求用户经常更换口令，而更安全的办法是在网络上以加密方式传输口令，此外，口令最好不要太简单，也不要用生日之类，易被他人猜出的口令。另外，辨别用户的方法还有磁卡，签名，指纹，声音内容等。9.1安全性控制的一般方法二存取控制
115、进行了对用户的识别，在DBMS中还应该有机器强制存取控制起作用，即严格按照授权控制对数据库的存取。由此，DBMS要维护一张用户权限表（用户权限表：指不同的用户对于不同的数据对象允许执行的操作权限。），每次用户存取数据库任何数据之前，都要查表确认存取是否合法。9.2商品化商品化DBMS数据安全措施实例数据安全措施实例 一SQL Server数据库中的对象，至少需要通过三层安全防线WindowsNTSQLServer数据库管理系统SQLServer中的数据库对象操作系统（如NT）是第一道安全防线，也C/S中，用户必须首先进入服务器的OS获得使用服务器资源的权限（如使用SQLServer的权限），才
116、可以进一步使用和访问在服务器上驻留的资源。9.2商品化商品化DBMS数据安全措施实例数据安全措施实例 SQL Server是另一道安全防线，只有注册到SQLServer，才有可能访问SQLServer中的数据对象。SQLServer有一套创建的管理各种级别，用户的机制，不同的用户在SQLServer中由不同的权限。注册到SQLServer的用户，并不意味着在SQLServer上拥有全部权限，不同的用户由不同的级别，不同的用户可以访问不同的数据库对象，不同的用户对数据库对象有不同的使用权限，不同的用户可以从DBA或数据库拥有者那里获得不同的授权。9.2商品化商品化DBMS数据安全措施实例数据安全
117、措施实例二Sybase的数据库安全措施用户管理： 在Sybase中，要登陆进入系统的用户，在系统要有一个账号，用户口令是系统确认账号的口令。 在系统建立账号 在数据库上建立用户 将用户和账号联系起来 只有提供了账号的口令才能进入该数据库。 这些工作由DBA完成。 9.2商品化商品化DBMS数据安全措施实例数据安全措施实例权限管理： Sybase中权限有两类： 对象权限：使用SELECT,UPDATE,INSERT,DELETE和 EXECUTE命令的权限。 指 Table, View和Column 命令权限：CREATE DATABASE / DEFAULT/ PROCEDURE/ RULE/
118、TABLE/VIEW DUMP DATABASE, DUMP TRANSACTION 只能由系统管理员或数据库所有者授予。9.2商品化商品化DBMS数据安全措施实例数据安全措施实例 Sybase把用户分为四类（按拥有权限的层次排列）：系统管理员（SA）：是超级用户，工作在系统的保护系统之外，任何以SA登陆的用户都可充当这一角色。数据库所有者（DBO）：DBO和SA可给其他用户授予命令权限。数据库中的对象所有者：指创建数据库中对象的用户。具有对对象操作所有权限（SELECT/./EXECUTE）。其他用户（包括数据库所有者）对此对象无任何权限，除非数据库中的对象所有者现实的授权。其它用户：前三级
119、用户可以给他们授予或收回权限。 9.2商品化商品化DBMS数据安全措施实例数据安全措施实例三Oracle的数据安全措施用户标识和鉴别 创建数据库用户时给口令，每次登陆进入数据库时要和对口令。授权机制 GRANT / REVOKE 9.2商品化商品化DBMS数据安全措施实例数据安全措施实例 审计 这是一种事后监视的措施，即跟踪数据库的访问活 动，以发现数据库的非法访问，达到安全防范的目 的。 DBMS可以将跟踪审计的结果存放在一个特殊文件（ 跟踪审计记录）中，主要记录的内容包括：n数据操作类型n终端标识和用户标识n操作时间n涉及的数据数据的新值和旧值等 第十章第十章 数据库完整性数据库完整性 数
120、据库的完整性指数据库的正确性、一致性、相容性数据库的完整性的破坏主要是由于一些无效数据写入了数据库，或不恰当的删除数据造成的。为了解决这个问题，DBMS应提供定义完整性约束的方法和相应的完整性检查机制，检查数据库更新后，数据是否满足完整性约束条件。数据语义的表达式由用户定义的 第十章第十章 数据库完整性数据库完整性一完整性约束的类型一般分两类： l属性的值的约束：对属性取值的类型、范围、精度等的限制，和属性的语义有关。 l 属性之间联系的约束：反映了数据之间存在的联系，在关系模型中，指多个属性或多个元组之间联系的约束，如属性间函数依赖，各值。 第十章第十章 数据库完整性数据库完整性根据约束加在
121、数据本身上，还是加在允许数据所作的改变上，又分为： u静态约束：数据库每一确定状态应满足的约束条件。 u动态约束：数据库从一种状态转变到另一种状态时应遵守的约束。根据DBMS进行完整性检查的时间，分为： l立即执行约束： l延迟执行约束： 第十章第十章 数据库完整性数据库完整性二表示完整性约束的方法 隐式约束方法最基本的方法，可实现大部分静态约束。是在定义数据库模式时定义数据的模型、范围、精度。定义Primary Key, F. Rule等 DB中最底层的约束 第十章第十章 数据库完整性数据库完整性 显式约束方法：可实现一些隐式约束方法无能为力的、更复杂的约束，根据不同DBMS的支持，可选择以
122、下几种方法： 采用断言说明语句：特殊的查询语句，能用断言的形式写出数据库完整性约束。 数据库层的约束。 第十章第十章 数据库完整性数据库完整性 CHECK或CONSTRAINT子句。 在 DB模 式 定 义 时 加 入 ， CHECK或CONSTRAINT子句说明数据有效的条件。和是与隐式类似的，说明数据库满足的条件，DBMS的任务。 数据库触发器：在数据操作满足触发条件时执行。 将完整性约束的说明和检查的任务交给应用程，在应用程序中增加一些存储过程。 和都是给出了检查约束条件的存储过程。 第十章第十章 数据库完整性数据库完整性注 ： 、，开发人员只须用说明性方法（语言）定义，其余的由DBMS完成。简单方便，但在C/S下，检查约束时间较晚，在用户事务交付后，才能发现违规作废，对用户来说发现error不及时。可克服和，在用户输入数据时可发现，及时提醒用户，但设计工作量大，且易出错或遗漏。 最好几种方法同时使用。
