数据库知识点整合（已完结）

数据库系统概论

第一章 绪论

数据库的概念，数据模型的概念，三个要素，两种数据模型，三级模式，二级独立性

1.1 数据库的四个基本概念

1. 数据 Data

   定义：①数据库存储的基本对象 ②描述事物的符号记录

   种类：数字、文字、图形、音频、视频等记录

   数据的含义称为数据的语义，数据与其语义是不可分的

2. 数据库 Database

   定义：是长期存储在计算机内、有组织的、可共享的大量数据的集合

   基本特征：

   • 数据按一定的数据模型组织、描述和存储
   • 可为各种用户共享
   • 冗余度较小
   • 数据独立性较高
   • 易扩展

   基本特点：

   1. 永久存储
   2. 有组织
   3. 可共享

3. 数据库管理系统 DBMS

   定义：①位于用户和操作系统之间的一层数据管理软件 ②是基础软件 ③是一个大型复杂的软件系统

   用途（主要六大功能）：

   • 科学地组织和存储数据、高效地获取和维护数据（书上没有写）

     

   • 数据定义功能

     • 提供数据定义语言（DDL）
     • 定义数据库中的数据对象

   • 数据组织、存储和管理

     • 分类组织、存储和管理各种数据
     • 确定组织数据的文件结构和存取方式
     • 实现数据之间的联系
     • 提供多种存取方式提高存取效率

   • 数据操纵功能

     • 提供数据操纵语言（DML）
     • 实现对数据库的基本操作（查询、插入、删除和修改）

   • 数据库的事务管理和运行管理

     • 数据库在建立、运行和维护时由数据库管理系统统一管理和控制
     • 保证数据的安全性、完整性、多用户对数据的并发使用
     • 发生故障后的系统恢复

   • 数据库建立和维护功能

     • 数据库初始数据的装载和转换
     • 数据库转储、恢复功能
     • 数据库的重组织
     • 性能监视、分析等

   • 其它功能

     • 数据库管理系统与网络中其它软件系统的通信
     • 数据库管理系统系统之间的数据转换
     • 异构数据库之间的互访和互操作

4. 数据库系统 DBS

   定义：是由数据库、数据库管理系统、应用程序和数据库管理员组成的存储、管理、处理和维护数据的系统

   

   特点：

   1. 数据结构化
   2. 数据的共享性高，冗余度低且易扩充
   3. 数据独立性高（物理独立、逻辑独立）
   4. 数据由数据库管理系统统一管理和控制（安全性、完整性保护，并发控制，数据库恢复）

数据库概念小结

数据库是长期存储在计算机内有组织的大量的共享的数据集合。

可以供各种用户共享，具有最小冗余度和较高的数据独立性。

数据库管理系统在数据库建立、运用和维护时对数据库进行统一控制，以保证数据的完整性、安全性，并在多用户同时使用数据库时进行并发控制，在发生故障后对数据库进行恢复。

1.2 数据模型

1.2.1 概念

数据模型是对现实世界数据特征的抽象，是用来描述数据、组织数据和对数据进行操作的。

数据模型是数据库系统的核心和基础

1.2.2 组成要素

1. 数据结构：描述系统的静态特性→描述数据库的组成对象以及对象之间的联系
2. 数据操作：描述系统的动态特性→是对数据库中各种对象的实例所允许的操作的集合, 其类型有查询和更新(增、删、改)
3. 数据的完整性约束条件：用以限定符合数据模型的数据库状态以及状态的变化,以保证数据的正确、有效与相 容 , 完整性约束条件是一组完整性规则的集合

1.2.3 两类数据模型

数据模型应该包含三方面的要求：

1. 能比较真实的模拟现实世界 2.容易被别人理解 3.便于在计算机上实现

第一类：

概念模型（信息模型）：安装用户的观点对数据和信息进行建模，主要用于数据库设计。

• 是现实世界到机器世界的一个中间层次。

• 信息世界中的基本概念

  • 实体：客观存在并可互相区别的事物

    // 指具体的人、事、物。

    // 比如，一个学生，一个部门，一门课，一次选课，部门的一次订货

  • 属性：实体所具有的某一特性

    // 例如：学生的属性可以是学号、性别、出生年月等。

  • 码：唯一标识实体的属性集

    // 例如学号就是学生的码，具有可替代意义

  • 实体型：用实体名及其属性名集合来抽象和刻画同类实体

    //例如：学生（学号、姓名、性别、出生年月）

  • 实体集：同一类型实体的集合

    // 例如：全体学生

  • 联系：

    ①实体内部的联系：组成实体的各属性之间的联系；

    ②实体之间的联系：不同实体集之间的联系

    • ​ 实体之间的联系有一对一、一对多和多对多等多种类型

• 表示方法：实体-联系方法，该方法用E-R图来描述现实世界的概念模型

第二类：

逻辑模型：是按计算机系统的观点对数据建模，主要用于数据库管理系统的实现。

主要包括层次模型、网状模型、关系模型、面向对象数据模型、对象关系数据模型、半结构化模型

• 层次模型和网状模型称为格式化模型。

  • 格式化模型中，实体用记录表示，实体的属性对应记录的数据项。实体之间的联系在格式化模型中转换成记录之间的两两联系。

  • 数据结构的单位是：基本层次联系 ——> 指两个记录以及它们之间一对多的联系。

  • 层次模型

    1. 是数据库系统中最早出现的数据模型

    2. 采用树形结构表示各类实体以及实体间的联系

  3. （类似二叉树结构）只有一个根节点，其它节点只有一个双亲节点

  4. 基本特点：任何一个给定的记录值只能按照其层次路径查看，没有一个子女记录值能够脱离双亲记录值而独立存在

  5. 优缺点：
  
   - 优点：
    1. 数据结构比较简单清晰
  
     		2. 查询效率较高
    	3. 提供了良好的完整性支持
  
    - 缺点：
    	     		1. 很多联系是非层次性的
    	  		2. 如果一个结点有多个双亲结点，使结构过于复杂
    		3. 查询子女结点必须提高双亲结点
    	  		3. 由于结构严密，层次命令趋于程序化
  

• 网状模型

  1. 允许一个以上的节点无双亲，一个结点可以有多于一个的双亲
     2. 网状数据模型的典型代表是DBTG系统

  2. 优缺点

     • 优点

     1. 更好直接描述现实世界

         2. 具有良好的性能，存取效率较高
        

     • 缺点

          1. 结构复杂
         		2. 网状模型的DDL、DML复杂，要嵌入某一种高级语言，用户不易掌握
        		3. 选择存取路径
       

  • 关系模型

    1. 数据结构

       • 关系：一个关系通常对应一张表

       • 元组：表中的一行

       • 属性：表中的一列即为一个属性，给每个属性起一个名称即属性名

       • 码（码键）：表中的某个属性组，可以唯一确定一个元组

       • 域：一组具有相同数据类型的值的集合。例如：大学生的年龄属性的域是（15~45岁）

       • 分量：元组中的一个属性值

       • 关系模式：对关系的描述，一般表示为：学生（学号，姓名，年龄）

         要求必须是规范化的，关系的每一个分量必须是一个不可分的数据项。（不能有表中表）

    2. 优缺点

       • 优点
         1. 关系模式与格式化模式不同，建立在严格的数学概念上的
         2. 概念单一
         3. 关系模式的存取路径对用户透明，从而具有更高的数据独立性、更好的安全性、简化开发工作。
       • 缺点
         1. 由于存取路径是隐蔽的，查询效率往往不如格式化模型
         2. 增加开发数据库管理系统的难度

物理模型：是对数据最底层的抽象，描述数据在系统内部的表示方法和存取方式，或在磁盘、磁带上的存储方式和存取方式。是面向计算机系统的。具体实现的是数据库管理系统的任务。

通常将现实世界抽象为信息世界，然后将信息世界转换为机器世界。

1.2.4 数据库系统的三级模式结构

模式的概念：

• 型（Type）
  对某一类数据的结构和属性的说明

• 值（Value）
  是型的一个具体赋值

  例如

  学生记录：
  （学号，姓名，性别，系别，年龄，籍贯）

  一个记录值：
  （201315130，李明，男，计算机系，19，江苏南京市）

模式（Schema）

• 数据库逻辑结构和特征的描述

• 是型的描述，不涉及具体值

• 反映的是数据的结构及其联系

• 模式是相对稳定的

实例（Instance）

• 模式的一个具体值
• 反映数据库某一时刻的状态
• 同一个模式可以有很多实例
• 实例随数据库中的数据的更新而变动

1. 模式（逻辑模式）

是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图

不涉及数据的物理存储细节和硬件环境也不设计应用程序层

一个数据库只有一个模式

//理解：就是一个整合包，获取数据处理传给外面。

2. 外模式（子模式/用户模式）

是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示

通常是模式的子集，一个数据库可以有多个外模式。

每个用户只能看见和访问所对应的外模式中的数据，数据库中的其余数据是不可见的。

// 理解：就是电视机反映的画面

3. 内模式（存储模式）

   一个数据库只有一个内模式

   是数据物理结构和存储方式的描述，是数据在数据库内部的组织方式。

   //理解：就是负责一些数据的存储方式，例如hash索引、加密等，就是电视机里面的硬件布线啥的

1.2.5 二级映像功能与数据独立性

三级模式是对数据的三个抽象级别

二级映象在数据库管理系统内部实现这三个抽象层次的联系和转换

1. 外模式/模式映像

   模式对应数据的全局逻辑结构，外模式对应的是数据的局部逻辑结构。

   同一个模式可以有多个外模式，每一个外模式数据库都有一个外模式/模式映像来定义外模式与模式之间的对应关系

   映像定义通常包含在各自外模式的描述中。

   保证了数据的逻辑独立性

   • 当模式改变时，数据库管理员对外模式／模式映象作相应改变，使外模式保持不变
   • 应用程序是依据数据的外模式编写的，应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性

2. 模式/内模式映像

   模式/内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。模式只有一个，内模式也只有一个，因此，模式/内模式映像是唯一的。

   保证数据的物理独立性

   • 当数据库的存储结构改变了（例如选用了另一种存储结构），数据库管理员修改模式／内模式映象，使模式保持不变。
   • 应用程序不受影响。保证了数据与程序的物理独立性，简称数据的物理独立性。

保证了数据库外模式的稳定性

从底层保证了应用程序的稳定性，除非应用需求本身发生变化，否则应用程序一般不需要修改

第二章 关系数据库

第二章
关系数据库，关系的完整性，关系代数（70页第6题会考一个类似的）

有关概念：

1. 域：是一组具有相同数据类型的值的集合

2. 笛卡尔积：给定一组域D1，D2，…，Dn，允许其中某些域是相同的。

   D1，D2，…，Dn的笛卡尔积为：

   D1×D2×…×Dn ＝
   ｛（d1，d2，…，dn）｜di∈Di，i＝1，2，…，n｝

3. 关系

   D1×D2×…×Dn的子集叫作在域D1，D2，…，Dn上的
   关系，表示为 R（D1，D2，…，Dn）

   R：关系名

   n：关系的目或度（Degree）

4. 码

   • 候选码：某一属性组的值能唯一标识一个元组，其它子集不能
   • 全码：关系的所有属性组是这个关系模式的候选码，则叫全码
   • 主码：若一个关系有多个候选码，则选定其中一个为主码
   • 主属性：候选码的属性为主属性，不包含在任何候选码中的属性称为非主属性或非码属性

5. 三类关系：基本关系，查询表，视图表

6. 任意两个元组的候选码不能相同

7. 关系的每一个分量必须取原子值（不可再分割）

2.1 关系数据库

在一个给定的应用领域中，所有关系的集合构成一个关系数据库。

• 关系数据库的型也称为关系数据库模式，是对关系数据库的描述
• 关系数据库的值是这些关系模式在某一时刻对应的关系的集合。

关系数据语言分类

• 关系代数语言
• 关系演算语言
  • 元组关系演算语言
  • 域关系演算语言
• 具有关系代数和关系演算双重特点的语言（SQL）

2.2 关系的完整性

实体完整性，参照完整性，用户定义完整性

实体完整性和参照完整性是关系模型必须满足的完整性约束条件==（关系的两个不变性）==

1. 实体完整性

   若属性A是基本关系R的主属性，则A不能取空值。

   （1）实体完整性规则是针对基本关系而言的。 一个基本表通常对应现实世界的一个实体集。

   （2）现实世界中的实体是可区分的，即它们具有某种唯一性标识。

   （3）关系模型中以主码作为唯一性标识。

   （4）主码中的属性即主属性不能取空值。

2. 参照完整性

   • 关系间的引用：在关系模型中实体及实体间的联系都是用关系来描述的，自然存在着关系与关系间的引用。

   • 外码：设F是基本关系R的一个或一组属性，但不是关系R的码。如果F与基本关系S的主码Ks相对应，则称F是R的外码。

     基本关系R称为参照关系

     基本关系S称为被参照关系或目标关系

     例子：学生关系R中，属性中专业号不是码，专业关系S中，属性专业号是码，因此专业号是R的外码，并且学生关系是参照关系，专业关系是被参照关系。

   • 参照完整性规则

     每一个外码必须为：

     • 取空值（外码每个属性值都是空值）
     • 等于被参照关系中的某个元组的主码值

3. 用户定义完整性

   针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求

2.3 关系代数

定义：是一种抽象的查询语言，它用对关系的运算来表达查询=-

​

2.3.1 传统的集合运算

1. 并∪

   S∪R：属于R或属于S的元组组成

2. 差 -

   R-S：属于R而不属于S的所有元组组成

3. 交∩

   R∩S：既属于R又属于S的元组组成

4. 笛卡尔积×

   R×S：

   

2.3.2 专门的关系运算

1. 选择 σ ：从关系R中选取使逻辑表达式F为真的元组，是从行的角度进行的运算

   

2. 投影π：选择出若干属性列组成新的关系

   

3. 连接[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IKUFMHce-1668003731819)
   一般的连接操作是从行的角度进行运算。

   

4. 除运算÷

   

第三章 关系数据库标准语言SQL

第三章
SQL语句、索引、视图等等都比较重要，会有一个大题。

SQL：结构化查询语言，是关系数据库的标准语言

一个数据库中可以建立多个模式

一个模式下通常包括多个表、视图和索引等数据库对象

定义功能包括模式定义，表定义，视图与索引定义。

3.1 数据定义

3.1.1 模式定义

• 创建

  create schema <模式名> authorization <用户名>
  

  

• 删除

  drop shema <模式名><cascade|restrict>
  // cascade 级联，表示在删除模式的同时把该模式中的所有的数据库对象全部删除
  // restrict 限制，表示如果该模式中以及定义了下属的数据库对象，则拒绝该删除语句的执行
  

  

3.1.2 基本表的定义

• 创建

  create table <表名>（）
  

• 修改

  alter table <表名> []
  

  
  

• 删除

  drop table <表名> [restrict|cascade]
  

3.1.3 索引定义

• 建立索引

  create [unique][cluster] index <索引名> on <表名>
  // unique 此索引的每一个索引值只对应唯一的数据记录
  //cluster 表示要建立的索引是聚簇索引
  

  

• 修改索引

  alter index <旧索引名> rename to <新索引名>
  

• 删除索引

  drop index <索引名>
  

3.2 数据查询

select <> from <> 
[where<>]
[group by <> [having<>]] 
[order by<>[asc|desc]]

// distinct——去掉表中的重复行
select distinct son from sc
// 字符匹配
[not] like '<匹配串>' [escape'<换码字符>']
// % 代表任意长度
// _ 代表单个字符

And 优先级高于 OR

order by：

聚集函数：

• 统计元组个数 COUNT(*)

• 统计一列中值的个数
  COUNT([DISTINCT|ALL] <列名>)

• 计算一列值的总和（此列必须为数值型）
  SUM([DISTINCT|ALL] <列名>)

• 计算一列值的平均值（此列必须为数值型）
  AVG([DISTINCT|ALL] <列名>)

• 求一列中的最大值和最小值
  ：

  MAX([DISTINCT|ALL] <列名>)

  MIN([DISTINCT|ALL] <列名>)

where作用于视图/基本表

having作用于组

3.3 表的连接

自身连接——需要给表起别名以是区别

外连接

select student.Son,Sname,Ssex,Sage,Sdept,Con,Grade From Student left out join SC on (Student.Son=SC.Sno);

3.4 集合查询

exists:带有exists谓语的子查询不返回任何数据，只产生逻辑真值“true”和逻辑假值“false”。

并操作UNION

交操作INTERSECT

差操作EXCEPT

• UNION：将多个查询结果合并起来，自动去掉重复组

  UNION ALL：保留重复元组

  

• intersect

3.5 数据更新

1. 插入数据

   insert into <表名>[] values()
   
   

2. 修改数据

   update <表名> set <列名>=<表达式> [where <条件>]
   
   

   

   

3. 删除数据

   delete from <表名> [where <条件>]
   
   

空值处理：

1. 有NOT NULL约束条件的不能取空值
2. 加了UNIQUE限制的属性不能取空值
3. 码属性不能取空值

3.6 视图

虚表，是从一个或几个基本表（或视图）导出的表

只存放视图的定义，不存放视图对应的数据

基表中的数据发生变化，从视图中查询出的数据也随之改变

1. 建立视图

   create view <视图名> as <子查询> [with check option]
   
   

   CREATE VIEW IS_Student
           AS 
           SELECT Sno,Sname,Sage
           FROM  Student
           WHERE  Sdept= 'IS'
           WITH CHECK OPTION;
   
   //定义IS_Student视图时加上了WITH CHECK OPTION子句，对该视图进行插入、修改和删除操作时，RDBMS会自动加上Sdept='IS'的条件。
   
   

2. 删除视图

   drop view <视图名>[cascade]
   
   

   //使用CASCADE级联删除语句，把该视图和由它导出的

第四章 数据库安全性

第四章
数据库的安全性 自主存取控制方法 授权 强制存取控制方法

数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏 。

数据库的不安全因素：

1. 非授权用户对数据库的恶意存取和破坏
2. 数据库中重要或敏感的数据被泄露
3. 安全环境的脆弱性

定义用户权限和合法权限检查一起组成了数据库管理系统的存取控制子系统

4.1 自主存取控制方法(C2)DAC——通过对数据的存取权限来进行安全控制，数据本身无安全性标记

• 用户对不同的数据对象有不同的存取权限
• 不同的用户对同一对象也有不同的权限
• 用户还可将其拥有的存取权限转授给其他用户

用户权限由两个因素组成：数据库对象和操作类型

定义存取权限就是授权。

在关系数据库中，存取控制的对象不仅有数据本身，还有数据库模式。

提高SQL的grant（授权）语句和revoke（收回权限）语句实现：

1. grant

   grant <权限> on <对象类型><对象名> to <用户>
   语义：将对指定操作对象的指定操作权限授予指定的用户
   
   

   //把查询Student表权限授给用户U1
         GRANT   SELECT 
         ON   TABLE   Student 
         TO   U1;
   //把对Student表和Course表的全部权限授予用户U2和U3
   
         GRANT ALL PRIVILIGES 
         ON TABLE Student,Course 
         TO U2,U3;
   //把对表SC的查询权限授予所有用户
   
        GRANT SELECT 
        ON TABLE SC 
   	  TO PUBLIC;
   //把查询Student表和修改学生学号的权限授给用户U4
   　 
   	  	GRANT UPDATE(Sno), SELECT 
   		ON TABLE Student 
   		TO U4;
   //把对表SC的INSERT权限授予U5用户，并允许他再将此权限授予其他用户
        
       GRANT INSERT 
       ON TABLE SC 
       TO U5
       WITH GRANT OPTION;
   
   

2. revoke

   revoke <权限> on <对象类型> <对象名> from <用户>
   
   

   //把用户U4修改学生学号的权限收回
   
   		REVOKE UPDATE(Sno)
   		ON TABLE Student 
   		FROM U4;
   
   
   

4.2强制存取控制方法(B1)MAC

• 每一个数据对象被标以一定的密级
• 每一个用户也被授予某一个级别的许可证
• 对于任意一个对象，只有具有合法许可证的用户才可以存取

数据库管理系统所管理的全部实体被分为主体和客体。

• 主体是系统中的活动实体

  数据库管理系统所管理的实际用户，代表用户的各进程。

  敏感度标记称为许可证级别

• 客体是系统中的被动实体，受主体操纵

  文件、基本表、索引、视图

  敏感度标记称为密级

强制存取控制规则：

1. 向下读取：主体的许可级别大于等于客体密级时，主体才能读取
2. 向上写入：主体的许可级别小于等于客体密级时，主体才能写入

强制存取控制（MAC）是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据。

实现强制存取控制时要首先实现自主存取控制

审计&数据加密

数据库安全审计系统提供了一种事后检查的安全机制

数据加密主要包括存储加密和传输加密

第五章 数据库完整性

第五章
实体完整性，参照完整性，用户定义的完整性

指数据的正确性和相容性。

• 正确性：是指数据是符合现实世界语义，反映了当前实际状况的
• 相容性：是指数据库同一对象在不同关系表中的数据是符合逻辑的

数据的完整性和安全性是两种不同的概念：

• 数据的完整性
  ：防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据
• 数据的安全性：
  保护数据库 防止恶意的破坏和非法的存取

维护数据库的完整性，数据库管理系统必须：

1. 提供定义完整性约束条件的机制
2. 提供完整性检查的方法（在事务提交时或提交够检查）
3. 违约处理（拒绝[no action] / 级连[cascade]）

5.1 实体完整性

1. 定义

   create table 中用primary key定义

   • 单属性构成的码：

     1. 定义为列级约束条件

        create table student(
        	son char(9) primary key,
            sname char(20) not null,
            sex char(2),
            sage smallint
        );
        
        

     2. 定义为表级约束条件

        create table student(
        	son char(9) primary key,
            sname char(20) not null,
            sex char(2),
            sage smallint,
            primary key(son)
        );
        
        

   • 多个属性构成的码：

     1. 定义只能为表级约束条件

        create table sc(
        	son char(9) primary key,
            sname char(20) not null,
            sex char(2),
            sage smallint,
            primary key(son,sname)
        )
        
        

2. 实体完整性检查和违约处理

   插入或对主码列进行更新操作时，关系数据库管理系统按照实体完整性规则自动进行检查。

   包括：

   • 检查主码值是否唯一，如果不唯一则拒绝插入或修改 方法：全表扫描（耗时）-> 添加索引
   • 检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改

5.2 参照完整性

1. 定义：

   在create table中用foreign key短语定义哪些为外码，用references短语指明这些外码参照哪些表的主码。

   例子：关系SC中（Sno，Cno）是主码。Sno，Cno分别参照Student表的主码和Course表的主码

   create table SC(
   	Son char(9) not null,
       Con char(4) not null,
       Grade int,
       
       /*在表级定义实体完整性*/
       primary key(Son,Con),
       
       /*在表级定义参照完整性*/
       foreign key(Son) references Student(Son),
       foreign key(Con) references Course(Con)
   )
   
   

2. 参照完整性检查和违约处理：

   一个参照完整性将两个表中的相应元组联系起来

   对被参照表和参照表进行增删改操作时有可能破坏参照完整性，必须进行检查

   

   违约处理：

   1. 拒接执行：默认操作
   2. 级联操作：当删除或修改被参照表（Student）的一个元组造成了与参照表（SC）的不一致，则删除或修改参照表中的所有造成不一致的元组
   3. 设置为空值

   对于参照完整性，除了应该定义外码，还应==定义外码列是否允许空值==

   CREATE TABLE SC(  
       Sno CHAR(9)  NOT NULL，
       Cno   CHAR(4)  NOT NULL，
       Grade  SMALLINT,
       PRIMARY KEY(Sno,Cno)， 			
       FOREIGN KEY (Sno) REFERENCES Student(Sno) 
   		ON DELETE CASCADE        /*级联删除SC表中相应的元组*/
       	ON UPDATE CASCADE,       /*级联更新SC表中相应的元组*/
       FOREIGN KEY (Cno) REFERENCES Course(Cno)	                    
       	ON DELETE NO ACTION   /*当删除course 表中的元组造成了与SC表不一致时拒绝删除*/
       	ON UPDATE CASCADE     /*当更新course表中的cno时，级联更新SC表中相应的元组*/
   );
   
   
   

5.3 用户定义完整性

针对某一具体应用的数据必须满足的语义要求

1. 属性上的约束条件

   CREATE TABLE时定义属性上的约束条件

   • 列值非空（NOT NULL）

     CREATE TABLE SC(  
         Sno CHAR(9)  NOT NULL,	
         Cno CHAR(4)  NOT NULL,	           
         Grade  SMALLINT NOT NULL,	           
         PRIMARY KEY (Sno, Cno),  
          … 
         /* 如果在表级定义实体完整性，隐含了Sno，Cno不允许取空值，则在  
         列级不允许取空值的定义 可以不写 */
     );
     
     
     

   • 列值唯一（UNIQUE）

     CREATE TABLE DEPT(   
         Deptno  NUMERIC(2),          
         Dname  CHAR(9)  UNIQUE NOT NULL，/*要求Dname列值唯一, 并且不能取空值*/
         Location  CHAR(10),           
         PRIMARY KEY (Deptno)        
     );
     
     
     

   • 检查列值是否满足一个条件表达式（CHECK）

     CREATE TABLE Student( 
         Sno  CHAR(9) PRIMARY KEY,         
         Sname CHAR(8) NOT NULL,                           
         Ssex  CHAR(2)  CHECK (Ssex IN ('男','女')),/*性别属性Ssex只允许取'男'或'女' */       
         Sage  SMALLINT,            
         Sdept  CHAR(20)          
     );
     
     

   • 约束条件检查和违约处理

     插入元组或修改属性的值时，关系数据库管理系统检查属性上的约束条件是否被满足

     如果不满足则操作被拒绝执行

2. 元组上的约束条件

   在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制

   同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件

   CREATE TABLE Student(  
       Sno CHAR(9), 
       Sname CHAR(8) NOT NULL，
       Ssex CHAR(2),
       Sage SMALLINT, 
       Sdept CHAR(20),
       PRIMARY KEY (Sno),
       CHECK (Ssex='女' OR Sname NOT LIKE 'Ms.%')/*定义了元组中Sname和 Ssex两个属性值之间的约束条件*/
   );
   
   /*性别是女性的元组都能通过该项检查，因为Ssex=‘女’成立;*/
   /*当性别是男性时，要通过检查则名字一定不能以Ms.打头*/
   
   
   

   • 约束条件检查和违约处理

     插入元组或修改属性的值时，关系数据库管理系统检查元组上的约束条件是否被满足

     如果不满足则操作被拒绝执行

5.4 完整性约束命名子句

CONSTRAINT <完整性约束条件名><完整性约束条件>

<完整性约束条件>包括NOT NULL、UNIQUE、PRIMARY KEY短语、FOREIGN KEY短语、CHECK短语等

CREATE TABLE Student(   
    Sno  NUMERIC(6)      
    CONSTRAINT C1 CHECK (Sno BETWEEN 90000 AND 99999),         
    Sname  CHAR(20)           
    CONSTRAINT C2 NOT NULL,       
    Sage  NUMERIC(3)     
    CONSTRAINT C3 CHECK (Sage < 30),    
    Ssex  CHAR(2)     
    CONSTRAINT C4 CHECK (Ssex IN ( ‘男’,'女')),   
    CONSTRAINT StudentKey PRIMARY KEY(Sno)   
);

/*在Student表上建立了5个约束条件，包括主码约束（命名为StudentKey）以及C1、C2、C3、C4四个列级约束。*/

/*修改表Student中的约束条件，要求学号改为在900000~999999之间，年龄由小于30改为小于40*/
/*可以先删除原来的约束条件，再增加新的约束条件*/
ALTER TABLE Student DROP CONSTRAINT C1;
ALTER TABLE Student ADD CONSTRAINT C1 CHECK (Sno BETWEEN 900000 AND 999999);
ALTER TABLE Student DROP CONSTRAINT C3;
ALTER TABLE Student ADD CONSTRAINT C3 CHECK(Sage < 40);

5.5 断言

可以使用 CREATE ASSERTION语句，通过声明性断言来指定更具一般性的约束。

可以定义涉及多个表的或聚集操作的比较复杂的完整性约束。

断言创建以后，任何对断言中所涉及的关系的操作都会触发关系数据库管理系统对断言的检查，任何使断言不为真值的操作都会被拒绝执行

CREATE ASSERTION<断言名>

/*限制数据库课程最多60名学生选修*/
create assertion asse_sc_db_num 
check( 60 >=( select count(*) from Course,SC 
              Where SC.Con=Course.Con and Course.Cname = '数据库')
     );
     
/*限制每一门课程最多60名学生选修*/
CREATE ASSERTION ASSE_SC_CNUM1
CHECK(60 >= ALL (SELECT count(*) FROM SC 
                 GROUP by cno) 		  
     );
     
/*限制每个学期每一门课程最多60名学生选修*/
//首先需要修改SC表的模式，增加一个“学期（TERM）”属性
	 ALTER TABLE SC ADD TERM DATE;
//然后，定义断言：
     CREATE ASSERTION ASSE_SC_CNUM2
 	 CHECK(60 >= ALL(SELECT count(*) FROM SC
				    GROUP by cno,TERM)	   
          );

删除断言的语句格式为:DROP ASSERTION <断言名>

5.6 触发器

触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程。

• 触发器保存在数据库服务器中
• 任何用户对表的增、删、改操作均由服务器自动激活相应的触发器
• 触发器可以实施更为复杂的检查和操作，具有更精细和更强大的数据控制能力

1. 定义触发器

   触发器又叫事件-条件-动作规则

   当特定的系统事件发生时，对规则的条件进行检查，如果条件成立则执行规则中的动作，否则不执行该动作。规则中的动作体可以很复杂，通常是一段SQL存储过程。

   SQL使用create trigger命令建立触发器(表的拥有者才能创建)

   create trigger <触发器名>
   {BEFORE | AFTER} <触发事件> ON <表名>
   REFERENCING NEW|OLD ROW AS<变量>
   FOR EACH  {ROW | STATEMENT}
   [WHEN <触发条件>]<触发动作体>
   
   

   触发器名：

   • 触发器名可以包含模式名，也可以不包含模式名
   • 同一模式下，触发器名必须是唯一的
   • 触发器名和表名必须在同一模式下

   表名：

   • 触发器只能定义在基本表上，不能定义在视图上
   • 当基本表的数据发生变化时，将激活定义在该表上相应触发事件的触发器

   触发事件

   • 触发事件可以是INSERT、DELETE或UPDATE，也可以是这几个事件的组合

   • 还可以UPDATE OF<触发列，…>，即进一步指明修改哪些列时激活触发器

   • AFTER/BEFORE是触发的时机

     • AFTER表示在触发事件的操作执行之后激活触发器
     • BEFORE表示在触发事件的操作执行之前激活触发器

   行级触发器（FOR EACH ROW）：触发动作会有n行次

   语句级触发器（FOR EACH STATEMENT）：执行完该语句后，触发动作只发生一次

2. 激活触发器

   触发器的执行，是由触发事件激活的，并由数据库服务器自动执行

   一个数据表上可能定义了多个触发器，遵循如下的执行顺序:

   （1） 执行该表上的BEFORE触发器;

   （2） 激活触发器的SQL语句;

   （3） 执行该表上的AFTER触发器。

   谁先创建谁先执行

3. 删除触发器

   drop trigger <触发器名> on <表名>
   
   

   只能由具有相应权限的用户删除。

第六章 关系数据理论

第六章
函数依赖，主码，范式，规范化、2NF、3
NF（BCNF、4NF不考）

关系模式由五部分组成（五元组）

R(U,D,DOM,F)

关系名R是符号化的元组语义 STUDENT(U,D,dom,F)

U为一组属性 U{sno,name,age}

D为属性组U中的属性所来自的域 D{char,int}

DOM为属性到域的映射 dom{dom(sno)=dom(name)=char,dom(age)=int}

F为属性组U上的一组数据依赖 F{sno–>name,sno–>age}

当且仅当U上的一个关系r满足F时，r称为关系模式R的一个关系

作为二维表，关系要符合一个最基本的条件：每个分量必须是不可分开的数据项。（1NF）

数据依赖：

• 是一个关系内部属性与属性之间的一种约束关系。<通过属性间值的相等与否体现出来的数据间相互联系>
• 是现实世界属性间相互联系的抽象
• 是数据内在的性质
• 是语义的体现

主要类型：① 函数依赖 ② 多值依赖

6.1 函数依赖

1、设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r 中不可能存在两个元组在X上的属性值相等， 而在Y上的属性值不等， 则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。

• X→Y，但Y⊈X则称X→Y是非平凡的函数依赖
• X→Y，但Y⊆X 则称X→Y是平凡的函数依赖
• 若X→Y，则X称为这个函数依赖的决定因素
• 若X→Y，Y→X，则记作X←→Y
• 若Y不函数依赖于X，则记作X↛ Y

2、在R(U)中，如果X→Y，并且对于X的任何一个真子集X’, 都有 X’ ↛ Y, 则称Y对X完全函数依赖，记作

若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作
。

在R(U)中，如果X→Y(Y⊈X)，Y↛X，Y→Z，Z⊈Y, 则称Z对X传递函数依赖。记为：

​ 如果Y→X, 即X←→Y，则Z直接依赖于X，而不是传递函数依赖。

在关系中，包括在任何候选码中的属性称为主属性；不包括在任何候选码中的属性称为非主属性。

函数依赖只分析关系中的非主属性对主属性之间的依赖关系，并不分析主属性对主键(码)的依赖关系。

假设存在关系

R(学号，姓名，性别，班级，班主任，课程号，课程名，学时数，成绩)

主键：学号+课程号

主属性：{学号，课程号}

非主属性有：{姓名，性别，班级，班主任，课程名，学时数，成绩}

部分函数依赖：

姓名、性别和班级三个属性只依赖于主键中的学号，与“课程号”无关。

因此（学号，课程号）---->姓名是“部分函数依赖”

（学号，课程号）---->性别是“部分函数依赖”

（学号，课程号）----->班级是“部分函数依赖”

课程名和学时数只依赖于课程号，

因此（学号，课程号）----->课程名是“部分函数依赖”

完全函数依赖：

成绩依赖于学号和课程号两个字段的组合；但只知道学号无法确定成绩，同理只知道课程号也无法确定成绩；只有学号和课程号组合在一起才能标识哪个学生哪门课程的成绩；

因此（学号，课程号）---->成绩  是“完全函数依赖”。

传递函数依赖：

班主任依赖于班级，与学号无关，与课程号也无关

又因班级依赖于学号所以班主任间接依赖于学号

因此，（学号，课程号）----->班主任是“传递函数依赖”

6.2 码

1. 超码

   设K为R(U,F)的属性或属性组，其中U是关系R上的所有属性，若K->U，则称K为R的超码。

   就是属性K可以推出所有的属性U

2. 候选码

   设K为R(U,F)的超码，若K->U，则称K为R的候选码

   候选码就是最小超码

3. 主码

   若R(U,R)有多个候选码，则可以从中选定一个作为R的主码

4. 主属性

   包含在候选码中的属性，称为主属性

5. 全码

   关系模式的码由整个属性组构成

6. 外码

   关系模式 R中属性或属性组X 并非 R的码，但 X 是另一个关系模式的码，则称 X 是R 的外部码（Foreign key）也称外码。

6.3 范式

范式是符合某一种级别的关系模式的集合。

关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。

1. 1NF 列不能再分

   在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

   所谓第一范式（1NF）是指数据库表的每一列(即每个属性)都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

   简而言之，第一范式就是无重复的列。

2. 2NF 消除部分依赖

   第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。
   、

   第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。

   简而言之，第二范式就是非主属性依赖于主关键字。

   • 找出数据表中所有的码
   • 找出主属性和非主属性
   • 查看是否存在非主属性对码的部分函数依赖。
   • 将表拆分使每一个非主属性都完全函数依赖于候选码

3. 3NF 消除传递依赖

   满足第三范式（3NF）必须先满足第二范式（2NF）。在满足第二范式的基础上，切不存在传递函数依赖，那么就是第三范式。

   简而言之，第三范式就是属性不依赖于其它非主属性。

4. BCNF 消除主属性对于码的部分与传递函数依赖（不考）

   • 所有非主属性对每一个码都是完全函数依赖
   • 所有的主属性对每一个不包含它的码,也是完全函数依赖
   • 没有任何属性完全函数依赖于非码的任何一组属性

   例子：

   某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；

   一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

   那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？

   答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量

   码：（管理员，物品名），（仓库名，物品名）

   主属性：仓库名、管理员、物品名非主属性：数量

   ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。

   ∴ 此关系模式属于3NF。
   基于此关系模式的关系（具体的数据）可能如图所示：

   

   我们来看以下几种操作：

   先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。

   某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。

   如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。

   从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。

   造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

   解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

   仓库（仓库名，管理员）
   库存（仓库名，物品名，数量）
   这样，之前的插入异常，修改异常与删除异常的问题就被解决了。

6.4 规范化

一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化

基本思想：逐步消除数据依赖中不合适的地方

“一事一地”的模式设计原则。

实质上是概念的单一化。

第七章 数据库设计

第七章
数据库设计的基本步骤，E-R图，P241 第7，8题这种必考。必有一个大题20分。

数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。

7.1 数据库设计的基本步骤

1. 需求分析
2. 概念结构设计
3. 逻辑结构设计
4. 物理结构设计
5. 数据库实施
6. 数据库运行和维护

7.2 E-R图==（重点）==

7.2.1 概念模型

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计

描述概念模型的工具：E-R模型

7.2.2 E-R

包括：实体、属性、实体之间的联系

1. 实体之间的联系

   • 两个实体型之间的联系：

     ① 一对一联系（1∶1）//一个班一个班长

     ②一对多联系（1∶n）//一个班n个学生

     ③多对多联系（m∶n）//一个学生多门课程，一门课程多个学生

   • 两个以上的实体型之间的联系

     一般地，两个以上的实体型之间也存在着一对一、一对多、多对多联系。

     

   • 单个实体型内的联系

     同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。

     

2. E-R图

   E-R图提供了表示实体型、属性和联系的方法：

   • 实体型：用矩形表示，矩形框内写明实体名。
   • 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。
   • 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1∶1，1∶n或m∶n）
   • 联系可以具有属性

   

   各子系统的E-R图之间的冲突主要有三类：属性冲突、命名冲突、结构冲突

7.2.3 逻辑结构设计

E-R图由实体型、实体的属性和实体型之间的联系三个要素组成

关系模型的逻辑结构是一组关系模式的集合

将E-R图转换为关系模型：将实体型、实体的属性和实体型之间的联系转化为关系模式

转换原则：

1. 一个实体型转换为一个关系模式
   • 关系的属性：实体的属性
   • 关系的码：实体的码
2. 实体型间的联系有以下不同情况
   • 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
   • 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
   • 一个m:n联系转换为一个关系模式
   • 三个或三个以上实体间的一个多元联系转换为一个关系模式。
   • 具有相同码的关系模式可合并

第十章 数据库恢复技术

第十章
事务的概念，事务的特性。

1. 事务是==用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割==的工作单位。（重点）

2. 事务是==恢复和并发控制==的基本单位

3. 事务通常是以BEGIN TRANSACTION开始，以COMMIT或ROLLBACK结束

   • COMMIT

     事务正常结束
     提交事务的所有操作（读+更新）

     事务中所有对数据库的更新写回到磁盘上的物理数据库中

   • ROLLBACK

     事务异常终止

     事务运行的过程中发生了故障，不能继续执行

     系统将事务中对数据库的所有已完成的操作全部撤销

     事务滚回到开始时的状态

4. 事务的ACID特性：原子性，一致性，隔离性，持续性 （重点）

5. 事务故障仅指这类非预期的故障

6. 事务内部更多的故障是非预期的，是不能由应用程序处理的

7. 系统故障是指造成系统停止运转的任何事件，使得系统要重新启动

8. 事务故障的恢复：事务撤消

9. 类故障，对数据库的影响有两种可能性： 一是数据库本身被破坏
   二是数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。

10. 恢复操作的基本原理：冗余

11. 恢复的实现技术：复杂

12. 建立冗余数据最常用的技术是**数据转储**和==登记日志文件==

13. 转储是指数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程

    备用的数据文本称为**后备副本(backup)或后援副本**

14. 重装后备副本只能将数据库恢复到转储时的状态

15. 转储可分为静态转储和动态转储

16. 数据转储方法可以分为：动态海量转储、动态增量转储、静态海量转储、静态增量转储

17. 日志文件是用来记录事务对数据库的更新操作的文件

18. 日志文件中需要登记的内容包括：

    • 各个事务的开始
    • 各个事务的结束
    • 各个事务的所有更新操作

19. 每个日志记录的内容主要包括：

    • 事务标识
    • 操作的类型
    • 操作的对象
    • 更新前数据的旧值
    • 更新后数据的新值

20. 登记日志文件的两条规则：

    • 登记的次序严格按并发事务执行的时间次序
    • 必须先写日志文件，后写数据库

21. 保证数据一致性是对数据库的最基本的要求

书上小结：

第十一章 并发控制

第十一章
并发控制的基本方法 可串行化调度 两段锁协议 封锁的粒度

1. 事务是并发控制的基本单位，并发控制保证事务的隔离性和一致性

2. 并发操作带来的数据不一致性包括丢失修改、不可重复读和读“脏”数据

3. 并发控制的主要技术由 封锁、时间时间戳、乐观控制法、多版本并发控制（重点）

4. 封锁由两种类型：排他锁、读锁

5. 封锁协议：

   • 一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放

     一级封锁协议可防止丢失修改，并保证事务T是可恢复的。

   • 二级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。

     二级封锁协议可以防止丢失修改和读“脏”数据。

   • 三级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。

     三级封锁协议可防止丢失修改、读脏数据和不可重复读。

6. 避免活锁的简单方法就是采用先来先服务的策略

7. 诊断死锁的方法与操作系统类似，一般使用超时法或事务等待图法

8. 可串行化(Serializable)调度
   多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同重点

9. 可串行性(Serializability)
   是并发事务正确调度的准则 重点

10. 冲突可串行化调度是可串行化调度的充分条件 重点

11. 两段锁协议指所有事务必须分两个阶段对数据项加锁和解锁 重点

    • 第一阶段是获得封锁，也称为扩展阶段
    • 第二阶段是释放封锁，也称为收缩阶段

12. 事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。重点

    • 若并发事务都遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的
    • 若并发事务的一个调度是可串行化的，不一定所有事务都符合两段锁协议

13. 封锁对象的大小称为封锁粒度(Granularity) 重点

14. 封锁的对象:逻辑单元，物理单元 重点

15. 封锁粒度与系统的并发度和并发控制的开销密切相关。 重点

    • 封锁的粒度越大，数据库所能够封锁的数据单元就越少，并发度就越小，系统开销也越小；
    • 封锁的粒度越小，并发度较高，但系统开销也就越大

16. 在多粒度封锁中一个数据对象可能以两种方式封锁：显式封锁和隐式封锁

17. 引进意向锁目的： 提高对某个数据对象加锁时系统的检查效率

    • 如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁
    • 对任一结点加基本锁，必须先对它的上层结点加意向锁
    • 例如，对任一元组加锁时，必须先对它所在的数据库和关系加意向锁

上小结：