Database System Concepts Note

Database System Concepts Notes

Chapter 1 Introduction

1.1 数据、数据库、数据库系统、数据库管理系统

• 数据：一条条记录
• 数据库：The collection of data, usually referred to as the database.
  • 数据库按照某种结构，有序的组织数据
  • 数据量大，有关联，有结构，可共享
• 数据库系统：开发的应用系统（包含一组由关联的数据和一组处理数据的程序）
  • 注：后台有数据库支持的网站或者应用都可称为数据库系统
  • 系统的演化：记录（若干个属性）$\to$ 一个表 $\to$ 一个数据库 $\to$ DBMS（Mysql）$\to$ Java访问 $\to$ 系统
• 数据库管理系统：A database-management system (DBMS) is a collection of interrelated data and a set of programs to access those data.
  • Oracle、MySql、MongoDB

1.2 使用数据库系统的目的

1.2.1 关系型数据库的共同特点

基于关系模型

e.g. 所有关系型数据库都基于 SQL 国际标准

但是，非关系型数据库没有共同的理论基础

1.2.2 使用文件存储和使用数据库存储的对比

如果使用 Excel、txt 文件存储数据

优点：方便

缺点：不安全、并发访问差、查询不方便、文件和文件之间没有关联

e.g. 大学的数据如果使用 txt 存储，假设有学生基本信息、学生学习成绩、学生的活动三个 txt 文件。但这三个文件是有关联的，使用 txt，excel 都难以体现文件之间的关联。

1.2.3 使用文件系统的不足

1. 数据的冗余和不一致

冗余：同一数据的重复存储 $\to$ 在修改时造成数据的不一致，浪费了存储空间

e.g. 学生的手机号存储在5个文件中，在学生手机号更换时，造成了数据错误。

• 在经典的关系模型理论中，一定要消除冗余
• 在当前的一些应用中，为了加快响应速度，反而有意的保留一些冗余

2. 不易存取
3. 孤立
4. 数据的完整性得不到保障

• DBMS 会使用一些约束机制，保证数据的正确性和完整性

5. 并发异常

6. 安全问题

*1.3 View of Data

1.3.1 Data Abstraction 数据抽象

物理层抽象：生成的物理文件，真正的数据

逻辑层抽象：数据之间的关系，在软件中的表现方式

视图层：数据的局部，有好多个视图层

如果将数据抽象比作一头大象

• 物理层（内模式）是一个大象实体 （10个表）

• 逻辑层（概念模式）是百科全书中的大象 （10个表）

• 视图层（外模式）是大象的局部 （ $\le$ 10 个表）

使用视图层的目的

• 为了安全
  • 为了数据库的安全考虑，在实际开发时通常只给开发人员展示视图层的部分，甚至对表名、字段名做模糊处理
  • 在一般的开发中，数据库的结构严格保密
• 简化数据库结构

1.3.2 Instances and Schemas 实例与模式

模式和实例对应面向对象中的类和实例

模式：数据库的结构

实例：在某一时刻，数据库的状态，是经常变化的

1.3.3 Data Models 数据模型

• 一组软件工具集合，用以描述：数据、数据之间的联系、数据语义、数据约束

！数据模型的三要素

• 数据结构：去组织数据
  • $CH-2$ 关系模型的数据结构
• 操作数据：定义一组命令去操作数据 $CRUD$
  • $CH-6$ 关系代数，理论上操作
  • $CH-3\sim CH-5$ SQL 实际上的操作，SQL 语句
• 一组规则（约束）：保证数据的完整性和正确性

Chapter 2 Intro to the Relational Model

The relational model is today the primary data model for commercial data processing applications.

2.1 Structure of Relational Databases

• 数据结构：一张二维表
  • 表对应的每一列：属性/ 字段 (attribute)
  • 表的每一行的值：元组 (tuple) / 记录 (record)

2.1.1 属性的特点

• 每一个属性有允许的取值范围
• 每一个属性具有原子性，不可分
• 可以有 null 空值
  • Definition: The null value is a special value that signifies that the value is unknown or does not exist.
  • null 会影响查询效率，通常在实际操作时使用默认值代替 null

2.1.2 关系模型的优点

优点

• 有严谨的数学基础 $\to$ 集合论
• 简单清晰

缺点

• 只能存适合用二维表描述的结构化数据，应用场景受限

对关系的形式化定义

11/100 ch2

2.3 Keys 码/关键字

码 (Key) 具有唯一性，由一个或者多个属性构成，能够唯一的标识某一条记录，在数据库查询时，通过码来加快查询速度

• 查询优化 $\to$ 索引文件 （对于每一个主码属性，系统会自动的创建索引文件）

2.3.1 码的类型

• superkey 超码：任意属性集合，可以用来区别元组
  • 可能会有多余（冗余）的属性
  • 不是最小化的一个属性集合
• candidate key 候选码：候选码的任意子集不是超码
  • 对超码进行了最小化，去除了冗余的属性
  • 在一个关系里，候选码可以有多个
  • 建表时选一个候选码作为主码使用
  • e.g. 在一个学生关系中，学生的身份证号和学号都是候选码，但是 { s t u d e n t I d , i d } \{studentId,id\} {studentId,id} 不是一个候选码
• primary key 主码：在多个候选码中挑选一个候选码供当前关系使用
  • 插入一条新记录的时候，主码的值一定要唯一
  • 修改一条记录的主码时，修改的主码值也要唯一
  • 主码值不能为空，必须要有值
  • DBMS 根据主码上创建搜索索引
  • 一般在实际操作中，使用 DBMS 系统自动生成主码
  • 实体完整性约束：对主码属性取值的约束
    • 一般情况下的主码选用：属性本身是唯一的，属性本身较少变化
• foreign key 外码：针对两个表，体现两个表之间的一种关系，这两个表可以是同一个表（自连接）
  • 可以同名，可以不同名，但是数据类型必须一致
  • 例如，有学生表和课程表，课程表 $r_2$ 和学生表 $r_1$ 都有属性 $id$ ， $id$ 在 $r_2$ 中做主码，在 $r_1$ 中不做主码，则这个属性就是 $r_1$ 的外码
    • $r_1$ 参照关系 (referencing relation)
    • $r_2$ 被参照关系 (referenced relation)
  • 外码在本表中不能做主码
  • 参照完整性：外码一旦建立，就会自动检测相关联的表是否符合要求，外码的取值要参考参考表。A referential integrity constraint requires that the values appearing in specified attributes of any tuple in the referencing relation also appear in specified attributes of at least one tuple in the referenced relation.
    • 取空值、 $r_2$ 中某个元组的主码值
    • 例如，在学生的选课课程表中要约束外码取值 $id$ ，这个外码一定要在关联的学生表中存在。同时，也不能在参照关系中删除已经在被参照关系中包含的元组

PS：对于关系型的 DBMS ，自动支持了实体完整性和参照完整性约束。对于 DBA 只要定义主码和外码，DBMS 会自动检查实体完整性和参照完整性约束。

2.3.2 关于码的一些实际例子

e.g.1 学生实体、专业实体

学生（学号，姓名，性别，专业号，年龄）

专业（专业号，专业名）

e.g.2 学生、课程、学生与课程之间的联系

学生（学号，姓名，性别，专业号，年龄）

课程（课程号，课程名，学分）

选修（学号，课程号，成绩）

• 复合属性主码：如果只用一个属性做主码，不能唯一的区分每一个元组

• 此表中有两个外码：在选修表中，单独的学号是外码（对于学生表），单独的课程号是外码（对于课程）

• 在选修表中，学号和课程号同时收到了实体完整性（主码约束）和参照完整型约束（参考参考关系中的值）。也就是说

  • 选修主码：学号，课程号
  • 外码 1 ：学号，在学生表中存在，且不能为空（它是一个主码）
  • 外码 2 ：课程号，在课程表中存在，且不能为空（它是一个主码）

Chapter 3 Introduction to SQL

3.1 Overview of the SQL Query Language

关系代数：理论

SQL ： 实践

3.1.1 当前使用 SQL 语言的两种方式

• DBA $\to$ SQL $\to$ 管理 DBMS
• 开发人员 $\to$ SQL 嵌入到编程语言中 $\to$ 访问 DBMS 中的某一个数据库 （CRUD）

3.1.2 数据库服务器

登陆前的准备：通过计算机 $\to$ 管理 $\to$ 服务 $\to$ MySQL 查看服务是否启动

1. 成功登陆 登录信息（连接字符出）

• 用户名

• 密码

• 端口号 3306（default）

• 数据库服务器的地址（本机 127.0.0.1）或者计算机名（localhost）

2. 客户端：DBA 命令行/可视化工具

3. 访问和操作数据库

3.1.3 数据库类型

• 系统数据库
  • information_schema
    • 存储数据库对象信息（如用户表信息，列信息等），不能修改
  • performance_schema
    • 存储数据库服务器性能参数信息，不能修改
  • sys
    • 以视图形式显示更易理解的系统元信息
  • mysql
    • 存储 Mysql 配置信息，用户权限信息等
• 用户数据库
  • 用户创建的数据库
• 学习数据库
  • sakila 和 world，可删除

3.1.4 创建数据库

• 输入数据库名称：要求唯一，一般小写，英文名称且有意义，不要太长
• 选择字符集：一般使用 utf8
• 数据库排序规则：一般使用 utf8_general_ci

3.2 SQL (Structure Query Language)

3.2.1 SQL的基本结构 查询

• 关系代数是 SQL 查询的理论基础

• select 最终的结果投影

	select 字段1，字段2，....字段n

• from

from 表1，表2，...n

• where 选择运算

where 筛选条件

• group by 分组+聚集函数

group by 分组字段

• order by
  • 排序的时候参考 UTF8 来排序

order by 排序字段

• 重命名：as 可以省略，表进行自连接的时候，一定要对表重命名
• like 模糊查询
  • % 匹配任意多个字符
  • _ 匹配一个字符
  • * 选出所有

3.2.2 SQL语句的注意点

1. 大小写敏感，一般数据库名，表名，字段名都是小写
2. 一条 SQL 命令以分号结束
3. 所有的符号都要在半角下输入
4. -- 为单行注释 /**/ 为多行注释
5. 保留字不要给数据库名，表名，字段名命名
6. 分行写每一个关系
7. select * 表示要显示表中的所有字段

• 在学习，实验中可以用
• 在实际开发中不要用

8. salary / 12 广义投影
9. 多表查询 $\to$ 关系代数（笛卡尔积）
10. 有些 DBMS 不支持自然连接，所以在开发中不使用，避免换库时的麻烦

3.5 Set Operations ans Null Values

3.5.1 关系代数的并交差

• 前提条件
  • 两个查询结果中的字段的个数要相同
  • 相对应的属性的域要相同

3.5.2 Union

• union 去重复
• union all 不去重复

3.5.3 Intersect

• mySQL 不支持交运算，使用嵌套的 select 实现

3.5.4 Except

• mySQL 不支持差运算，使用嵌套的 select 实现

3.5.5 Null

• 查询空值不可以使用等号

3.7 Aggregate Function 聚集函数

• 分组 + 聚集函数

  • 使用 group by 加上字段：根据指定的字段进行分组

    • 如果没有使用 group by 对

  • select

    • 被分组后的可以加到 select 子句中
    • 小组类型的数据

  • having : 对分组后的记录进行筛选

    • 一定和 group by 搭配使用 having + 筛选条件

    select
    from
    where + 筛选条件 -- 针对所有的记录
    group by -- 分组
    having + 筛选条件 -- 针对分组后的记录再做筛选
    

  • 配合相应的聚集函数进行运算

    • sum()
    • avg()
    • count()
    • max()
    • min()

3.8 Nested Subqueries 嵌套子查询

• 定义: 一个 select 语句嵌套在另一个 select 语句中

• 不同的 DBMS 嵌套的方式不同

• 出现的位置

select t1, t2 = select子句
from r1, r2 = select子句
where 字段1 in/=/>= select子句

• 目的: 分步查询, 降低查询难度

3.8.1 集合成员

• in 测试元组是否是集合中的成员
• not in 测试元组是否不是集合中的成员
• in/not in 的执行顺序: 从最里层的查询开始执行
• in/not in 等价于 连接查询/and/or

3.8.2 集合的比较

• 至少比某一个要大：使用 > some 表示

• 比所有的都大: 使用 > all 表示

注意

• = some 等价于 in
• < > some 不等价于 not in
• < > all 等价于 not in
• = all 不等价于 in

3.8.3 空关系测试

• exists 结构在作为参数的子查询非空时返回 true (i.e. 判断子查询的查询结果中有没有记录)
  • exists
    • 有记录 true
    • 没有记录 false
  • not exist
    • 有记录 false
    • 没有记录 true

通常写法 select * exists

• 相关子查询：子查询不能独立执行，要依赖于父查询
  • 谓词 exists 的查询是外层的查询先执行, 再做到内层, 多重循环
• 不相关子查询：子查询可以独立执行，给父查询提供信息

PS：除法：一个集合是否包含另一个集合中的所有数据，只能通过 not exist 间接实现

e.g. 查询2009年秋季学期和2010年春季学期同时开课的课程

SELECT *
FROM
    section AS S
WHERE
      semester = 'Fall'
  AND year = 2009
  AND EXISTS
          (
              SELECT *
              FROM
                  section AS T
              WHERE
                    semester = 'Spring'
                AND year = 2010
                AND S.course_id = T.course_id
          );

注意到，来自外层查询的一个相关名称可以用在 where 子句的查询中

使用了外层查询相关名称的子查询称为相关子查询

3.8.4 重复元组存在性测试

如果作为参数的子查询结果中没有重复的元组, unique 结构将返回 true 值

e.g. 找出所有在2009年最多开设过一次的课程

select T.course_id
 from course as T
 where unique(select R.couse_id
              from section as R
              where T.course_id=R.course_id and 
              R.year=2009);

SELECT
    T.course_id
FROM
    course AS T
WHERE
        1 >= ( -- 1代表什么
        SELECT
            COUNT(R.course_id)
        FROM
            section AS R
        WHERE
              T.course_id = R.course_id
          AND R.year = 2009
    )

3.8.5 from子句中的子查询

任何 select-from-where 返回的结果都是关系, 因而可以被插入到另一个 select-from-where 中任何关系可以出现的位置

3.8.6 with子句中的子查询

with子句提供定义临时关系的方法,这个定义只对包含with的子句的查询有效

-- 工资总额大于所有系平均工资总额的系

WITH
    dept_total(dept_name, value) AS
        (SELECT
             dept_name,
             SUM(salary)
         FROM
             instructor
         GROUP BY
             dept_name
        ),
    dept_total_avg(value) AS
        (SELECT
             AVG(value)
         FROM
             dept_total
        )
SELECT
    dept_name
FROM
    dept_total,
    dept_total_avg
WHERE
    dept_total.value >= dept_total_avg.value

3.8.7 select子句中的子查询

• 也被称为标量子查询

select 子句中可以嵌套 select-from-where , 当且仅当 select 的结果作为一个属性

3.9 数据库的修改

3.9.1 删除

• 只能删除整个元组,不能删除某些属性上的值

delete from r
where P;

其中, $P$ 代表一个谓词, $r$ 代表一个关系. delete 语句首先从 $r$ 中找出所有使得 $P(t)$ 为真的元组 $t$, 然后把他们从 $r$ 中删除. 如果省略 where 子句, 则 $r$ 中的所有元组都将被删除

3.9.2 插入

语法

insert into course
	values('CS-437', 'Database Systems', 'Comp. Sci.', 4);

或者

insert into course(course_id, title, dept_name,credits)
	values('CS-437', 'Database Systems', 'Comp. Sci.', 4);

在查询结果的基础上插入元组

e.g. 让Music系的每个修满144学分的学生成为教师, 其工资为18000美元

INSERT INTO
    instructor
SELECT -- 将id, name, dept_name, 18000 作为四个项插入instructor
    ID,
    name,
    dept_name,
    18000
FROM
    student
WHERE
      dept_name = 'Music'
  AND tot_cred > 144;

注意: 应该在执行插入操作之前执行完 select 语句, 应该避免执行会导致无限循环的 insert-select 操作

insert into student
	select *
	from student

3.9.3 更新

在不改变整个元组的情况下改变其部分属性的值

语法

update instructor
set salary = salary * 1.05

update instructor
set salary = salary * 1.05
where salary < 70000

当要对不同的群体进行操作时, update 的顺序十分重要

e.g. 对工资超过100000美元的教室涨3%工资,其余涨5%

update instructor
set salary = salary * 1.03
where salary > 100000

update instructor
set salary = salary * 1.05
where salary <= 100000

注意: 上面两个 update 语句的顺序十分重要, 如果改变这两个语句的顺序, 那些工资略低于100000的教师将会涨8%的工资

使用Case确定更新顺序

update instructor 
set salary = case
		when salary <= 100000 then salary * 1.05
		else salary * 1.03
	end

标量子查询在update中的应用

UPDATE student
SET
    tot_cred=(
        SELECT
            SUM(credits)
        FROM
            takes,
            course
        WHERE
              takes.course_id = course.course_id
          AND student.ID = takes.ID
          AND takes.grade <> 'F'
          AND takes.grade IS NOT NULL);


SELECT *
FROM
    instructor
LIMIT 3,5;

Appendix MySQL 补充语法

• limit n：只显示查询结果中的 $n$ 条记录

SELECT dept_name,AVG(salary) AS avg_salary 
FROM instructor
GROUP BY dept_name
ORDER BY avg_salary DESC
LIMIT 2;

• limit 分页查询

SELECT *
FROM
    instructor
LIMIT 3(开始查询的位置),5(结束查询的位置);

分页查询公式：
查询第 pageIndex 页，每页显示 pageSize 条：

Select * from student LIMIT (pageIndex -1) * pageSize,pageSize;

• with rollup ：求小计

group by + with rollup：表示在进行分组统计的基础上再次对每一小组进行汇总统计

SELECT
    country.`Code`,
    SUM(city.`Population`)
FROM
    country,
    city
WHERE
    country.`Code` = city.`CountryCode`
GROUP BY
    country.`Code`; -- 只根据 code 分组
    
SELECT
    country.`Code`,
    city.`ID`,
    SUM(city.`Population`)
FROM
    country,
    city
WHERE
    country.`Code` = city.`CountryCode`
GROUP BY
    country.`Code`, city.`ID`; -- 根据 code 和 id 分组

SELECT
    country.`Code`,
    city.`ID`,
    SUM(city.`Population`)
FROM
    country,
    city
WHERE
    country.`Code` = city.`CountryCode`
GROUP BY
    country.`Code`, city.`ID`
WITH
    ROLLUP;
-- 根据 code 和 id 分组,再对每个 code 中的 id 进行汇总

#Chapter 4 Intermediate SQL

4.1 Join 连接查询

4.1.1 INNER JOIN

/*4.1.1 inner join*/
/*1.查询学生的选课情况，使用内连接*/
SELECT *
FROM
    student
        JOIN takes ON student.ID = takes.ID
;

-- 这是内连接,也可写成 inner join
SELECT *
FROM
    student
        INNER JOIN takes ON student.ID = takes.ID
;

-- 也可以用多表连接的方式完成
SELECT *
FROM
    student,
    takes
WHERE
    student.ID = takes.ID;
-- 笛卡尔积后再等值连接查询

4.1.2 OUTER JOIN

/*4.1.2 OUTER JOIN 外连接*/
/*1. 查询出所有学生的选课情况,包括没有选课的学生,使用左外连接 */

SELECT *
FROM
    student
        LEFT OUTER JOIN takes ON student.ID = takes.ID;


/*2. 找出没有选修课程的学生*/
SELECT *
FROM
    student
        LEFT OUTER JOIN takes ON student.ID = takes.ID
WHERE
    course_id IS NULL;

/*3. 查询出所有学生的选课情况,包括没有选课的学生,使用右外连接*/
SELECT *
FROM
    takes
        RIGHT OUTER JOIN student ON student.ID = takes.ID
;

/*4. 显示Comp.Sci.系的所有学生以及他们在2009年春季选修的所有课程段的列表.*/
/*mysql 不支持以下代码。*/
/*
SELECT *
FROM
    (SELECT
         id,
         name
     FROM
         student
     WHERE
         dept_name = 'Comp. Sci.') full OUTER JOIN
 (SELECT id
 FROM takes
 WHERE semester='Spring' AND YEAR=2009)
ON student.id= takes.id;
 */
/*由于 Mysql 不支持全外连接，所以只能用左外连接并上右外连接*/
SELECT *
FROM
    (SELECT
         id,
         name
     FROM
         student
     WHERE
         dept_name = 'Comp. Sci.')
        AS Cstudent1 (id, name)
        LEFT OUTER JOIN
        (SELECT
             id
         FROM
             takes
         WHERE
               semester = 'Spring'
           AND year = 2009)
            AS Cspring1 (id)
        ON Cstudent1.id = Cspring1.id
UNION
SELECT *
FROM
    (SELECT
         id,
         name
     FROM
         student
     WHERE
         dept_name = 'Comp. Sci.')
        AS Cstudent2 (id, name)
        RIGHT OUTER JOIN
        (SELECT
             id
         FROM
             takes
         WHERE
               semester = 'Spring'
           AND year = 2009)
            AS Cspring2 (id)
        ON Cstudent2.id = Cspring2.id;

4.2 视图的创建和使用

• 视图的作用
  • 安全性：隐藏基本数据，可使用权限机制控制用户的访问，
  • 查询性能提高：可直接基于视图查询
  • 提高了数据的独立性

4.2.1 创建视图

-- 4.2.1 创建视图
/*1. 为 instructor 创建职员视图 faculty*/
CREATE VIEW faculty
AS
(
SELECT
    id,
    name,
    dept_name
FROM
    instructor
    );
    
    
/*2. 创建视图,列出Physics系在2009年秋季学期开设的所有课程段,以及每个
课程段在哪栋建筑的哪个房间授课*/
CREATE VIEW physics_fall_2009
AS
SELECT
    course.course_id,
    sec_id,
    building,
    room_number
FROM
    course,
    section
WHERE
      course.course_id = section.course_id
  AND course.dept_name = 'Physics'
  AND section.semester = 'Fall'
  AND section.year = 2009
;

4.2.2 使用视图

/*4.2.2 使用视图*/
/*1.使用视图 physics_fall_2009,找到所有在 2009 年秋季学期在 Watson 大楼
开设的 Physics 课程*/
SELECT
    course_id
FROM
    physics_fall_2009
WHERE
    building = 'Watson'
;


/*2.在视图 physics_fall_2009 的基础上,定义视图 physics_fall_2009_Waston */
CREATE VIEW physics_fall_2009_watson
AS
SELECT
    course_id,
    room_number
FROM
    physics_fall_2009
WHERE
    building='Watson'
;

4.2.3 视图的更新

• 最终会反映到基本表中
• 视图是不实际存储数据的虚表。因此对视图的更新，最终要转换为对基本表的更新。因为有些视图的更新不能唯一有意义地的装换成对应基本表的更新
• 不可更新的视图举例
  • 若视图是由两个以上基本表导出的，则此视图不允许更新
  • 若视图的字段来自字段表达式或常数，则不允许对此视图执行INSERT和UPDATE操作，但允许执行DELETE
  • 若视图字段来自聚集函数，则此视图不允许更新
  • 若视图定义中含有GROUP BY 子句，则此视图不允许更新
  • 若视图中含有DISTINCT语句，则此视图不允许更新
  • 若视图定义中含有嵌套查询，并且内层查询的FROM子句涉及的表也是导出该视图的基本表，则此视图不允许更新
  • 一个不允许更新的视图上定义的视图也不允许更新

-- 4.2.3 视图的更新
# 最终会反映到基本表中
/*1.往视图 faculty 中插入一条记录,实际变化反映在表 instructors 中*/
INSERT INTO faculty
VALUES ('30675','Green','Music');

/*2.创建视图 instructor_info,然后插入一条记录,提示不能成功执行*/
CREATE VIEW instructor_info
AS
SELECT
    id,
    name,
    building
FROM
    instructor,
    department
WHERE instructor.dept_name=department.dept_name
;

INSERT INTO instructor_info
VALUES ('69987','White','Taylor');
/*

4.2.4 WITH CHECK OPTION

/*
4.2.5 with check option 命令的作用
 (1)不使用 with check option
创建一个 History 系的教师视图，不使用 with check option
 */
CREATE VIEW history_instructors
AS
    SELECT *
    FROM instructor
    WHERE dept_name = 'history';
    
-- 通过该视图可以插入一条 Biology 系的教师记录
INSERT INTO history_instructors
VALUES ('25566','Brown','Biology',100000);

-- 然后对该视图进行查询，却查找不到刚才插入的这条记录
SELECT *
FROM history_instructors;

但是实际应用中，希望通过哪个视图插入进去的记录，应该也可以通过该 视图查询出来；即某个特定的视图只负责满足特定条件的记录的更新和查询， 不满足特定条件的记录是不能通过该视图更新到基本表的。这时就可以使用 WITH CHECK OPTION 命令

# (2)使用 with check option
# 创建一个 History 系的教师视图
CREATE VIEW history_instructors AS
SELECT *
FROM
    instructor
WHERE
    dept_name = 'History'
WITH CHECK OPTION;

# 通过该视图插入一条 Biology 系的教师记录
INSERT INTO
    history_instructors
VALUES
    ('25566', 'Brown', 'Biology', 100000)

• 系统提示错误,因为要插入的记录不满足 where dept_name= 'History' 的条件;

• 所以：定义视图时加上了 WITH CHECK OPTION 子句，对该视图进行插入、修改和删除操作时，DBMS 会自动加上 dept_name= 'History' 的条件

4.4 权限管理

• 数据安全管理 $\to$ 安全认证的一个重要指标 (D1, D2, C2, B1,A1)

1. 用户/密码 $\to$ 合法用户 $\to$ 登录到数据库服务器
2. 能访问到哪一个数据对象 (服务器, 数据库, 数据表, 字段)
3. 能做什么操作 CRUD

• 实现步骤

1. 创建一个用户账号, 密码 (有创建用户权限的账号, 才能发出命令)

   • mysql 系统管理员账号: root (PS: sqlserver sa)

   • 默认情况下, root 账号不允许远程登陆

   • 命令格式：

     Create user ‘用户名’@‘主机名’identified by ‘密码’; 
     
     -- e.g. 
     -- mysql 8.0
     create user 's1'@'localhost' identified by 's1';
     或
     Create user 's1'@'localhost' identified with mysql_native_password by ‘123’; 
     -- mysql8.0
     
     flush privilege; -- 刷新权限
     

2. 授权: 指定用户能对哪些数据对象做什么样的操作

注意: 此功能已经在实际开发中外移到程序实现

• 权限管理的框架 RBAC (java shiro)

Chapter 5 Advanced SQL

5.1 函数和存储过程

• 函数：事先定义，完成一定功能，调用
• 存储过程：事先定义，完成一定功能，调用

区别

• 函数一定要有返回值，存储过程不用
• 函数只能在 DBMS 调用，存储过程可以在 DBMS 和应用程序中调用存储过程名(java)
  • 早期：将重要的业务逻辑用存储过程的方式实现（传输的数据小，并且更加安全）

5.2 触发器

• 不会作为系统实现的主要方式
• DBMS主动的去执行一些任务
• 维护数据库的数据完整性
  • 实体，参照，用户自定义（本表，两个表）
  • 整个数据库中，几个表之间更加复杂的数据完整性委会
  • e.g. A表更新操作 $\to$ B 表更新操作 $\to$ C表更新操作

Chapter 6 Formal Relational Query Languages

理论上研究：关系模型要素（数据操作）

要掌握的内容

• 关系代数的运算特点
  • 运算对象和运算结果都是关系表（一个集合）
• 关系代数的6个基本运算
  • 每种运算的特点、作用和命令格式
• 关系代数的附加运算和扩展运算
  • 每种运算的特点、作用和命令格式

6.1 Relational Algebra

6.1.1 Six fundamental operators

6.1.1.1 The Select Operation

select $\sigma$

Define as
σ p ( r ) = { t ∣ t ∈ r   a n d   p ( t ) } \sigma_{p}(r)=\{t|t\in r\ and \ p(t) \} σp​(r)={t∣t∈r and p(t)}

其中，$p(t)$ 是谓词，表示属性名，是一个筛选条件

$e.g.{\sigma }_{dept\_name}="Physics"$

• 是一元运算
• 从行/元组中的角度进行运算

6.1.1.2 The Project Operation

project $\prod$

投影操作，取出几列属性

注意：

• 在关系代数中，如果查询结果出现重复记录，去重复
• 在 DBMS 中，去重的代价太高，不会自动去重
• 是一元运算

6.1.1.3 The Union Operation

union $\cup$

• 把两个表的记录合并为一个表
• 合并的两个表必须要相容
  • 两个合并的表的属性要相同
  • 两个合并的表的数据类型（域）要相同
• 实际的查询和复杂，分步先实现查询子句，再通过并运算合并查询
• 在关系代数中：并操作需要去重
• 是二元运算

6.1.1.4 The Set-Difference Operation

set difference $r-s$

Define as
r − s = { t ∣   t ∈ r   a n d   t ∉ s } r-s=\{t|\ t\in r \ and \ t \notin s \} r−s={t∣ t∈r and t∈/​s}

• 差运算也需要满足相容规则

6.1.1.5 The Cartesian-Product Operation

caetesian product $\times$

Define as
r × s = { t , q ∣   t ∈ r   a n d   q ∈ s } r\times s =\{t,q|\ t\in r\ and \ q \in s \} r×s={t,q∣ t∈r and q∈s}

• 产生一个大表，属性是两表相加，记录个数是两表相乘
• 笛卡尔积运算的意义
  • 将分布在多个表中的数据连接起来，做成一个表（多表查询、连接查询）
    • e.g. 查询需求分布在两个表中，所以要先构造一个包含两个表信息的新表，再根据筛选条件筛选信息
  • 一定要对结果进行进一步的做运算，这样才能获得正确的数据
• 如果有相同的属性，前面加上表名
• 进行笛卡尔积运算的两个表，可以是相同的表，也可以是不同的表，但是属性个数不一定要相等

e.g. 如果两个表中都有 id 这个属性，他们笛卡尔积的属性如下

teacher.id
course.id

6.1.1.7 The Rename Operation

• 给一个表重命名：简化表名、表和表自连接时，需要对表重命名给一个属性重命名：简化属性名

• 对一个属性进行了函数/运算后起名

• 属性英文名 $\to$ 改为中文名

6.1.3 Additional Relational-Algebra Operations

6.1.3.1 The Set-Intersection Operation

$$r\cap s=r-(r-s)$$

6.1.3.2 The Natural-Join Operation

$${\Pi }_{\text{name, course-id }}\text{ (instructor }\bowtie \text{ teaches) }$$

• 自动去除相同的属性，直接提取出正确的记录

• 包含三种运算：笛卡尔积运算、选择运算、投影

• 自然连接是可交换和可结合的

• 如果做自然连接，一定要存在同名且相同数据类型的属性（相同的至少一列字段）

6.1.3.3 The Assignment Operation

赋值运算的定义：当查询和复杂时，分步完成时得到了一些中间结果，再通过赋值运算，用临时表的形式保存下来（复杂的查询任务）

e.g.

$temp1\leftarrow R\times S$
$temp2\leftarrow \sigma .A_1=s.A_1\wedge r.A_2=s.A_2\wedge ...\wedge r.A_n=s.A_n(temp1)$
$result={\prod }_{R\cup S}(temp2)$

6.1.3.4 Outer join Operations

e.g. 此图产生了空值，表示有些老师没有上课信息

PS：如果做自然连接，就不包含没有上课的老师的信息（不匹配）

• 左外连接：全部显示左表数据
• 右外连接：全部显示右表数据
• 如果匹配显示匹配值，不匹配显示 $null$

6.1.3.5 Generalized Projection

6.1.3.5 Aggregation

聚集函数，返回的是一个值
$$G_{p(x)(key)}(table)$$
$P(x)$ 有以下几种

• count 查询结果中记录的个数
• avg
• max 和 min
• sum

分组和聚集函数常常搭配使用
$$ke{y}_1{G}_{p(x)(ke{y}_2)}$$
对坐标进行以下命令得到右表
$$dept\_name{G}_{avg(salary)}(instructor)$$

Chapter 7 Database Design and the E-R Model

1. 设计目的：消除一切冗余

2. 设计三要素

• 确定实体集
• 辨别实体集之间的联系
• 确定联系的类型
• 确定实体集和联系的属性
• 确定属性的类型

7.3 Constraints

7.3.1 Mapping Cardinalities 映射的势(基数)

描述一个实体通过联系集对应另一个实体的个数

联系的类型

• 1对1（大学 $\to$ 校长）

• 1对多 （宿舍 $\to$ 学生）

• 多对多 （学生 $\to$ 选课）

7.3.2 Participation Constraints 参与约束

• 实体集参与到联系里时是全部参与还是部分参与
  • 全部参与 $\to$ 外码字段不能为空
  • 部分参与 $\to$ 外码字段可以为空
  • 帮助我们判断两个实体集之间的联系是否合适（如果出现大量空值，则定义的联系不合适）
• 一个表的记录是否完全参与到另一个表中
• 间接联系（具有传递性的联系）可以不用写

For example, we expect every student entity to be related to at least one instructor through the advisor relationship. Therefore the participation of student in the relationship set advisor is total. In contrast, an instructor need not advise any students. Hence, it is possible that only some of the instructor entities are related to the student entity set through the advisor relationship, and the participation of instructor in the advisor relationship set is therefore partial.

7.3.3 Keys

主码约束：对每一个实体集都要确定一个主码

7.6 Reduction to Relational Schemas

7.6.1 Representation of Strong Entity Sets with Simple Attributes 简单属性的强实体集转换

简单属性的强实体集转换

简单属性：只有一个值

强实体集：有主码

7.6.2 Representation of Strong Entity Sets with Complex Attributes 复杂属性的强实体集转换

复杂属性的强实体集转换

• 复杂属性
  • 复合属性：有多个子属性的属性
    • 在转换时候拉平，写出所有属性
    • $e.gname\to name.fisrt\_name,name.last\_name$
  • 多值属性
    • 通过主码映射构建新表，单独生成新表
    • $e.g.inst(id,salary,...),inst\_phone(id,phone\_number)$
  • 派生属性
    • 派生字段：由计算得出，可以删除也可以保留
    • 删除：消除冗余
    • 保留：提高查询速度，便于建立索引（因为对表做算数处理之后索引失效）
    • $e.g.stu(id,birth,age)age$ 就是 $birth$ 的派生属性

强实体集：有主码

7.6.3 Representation of Weak Entity Sets 弱实体集转换

一般较少出现，依赖于强实体集，借依赖的强实体集的主码和自己的属性

$e.g.section(course\_id,sec\_id,semester,year)$

7.6.4 Representation of Relationship Sets 联系集转换

• 关系模式：联系集本身
• 属性：参与联系的实体集的主码

1:1 联系的主码

• 涉及到联系集的两端的主码属性和联系集本身的属性
• 用任一方的实体集的主码

1:n 联系的主码

• 使用最精确的做主码

m:n 联系的主码

• 使用联系集的两端的主码同时做主码

7.6.4.1 Redundancy of Schemas

• 合并主码相同的表（1对1，1对多）
  • 注意：多对多的表不可合并

7.7 Entity-Relationship Design Issues

1. 数据库设计三要素

• 实体集
• 联系集
• 属性

2. 建立信息模型 $\to$ ER 模型

• 三要素在 ER 图中全部都要体现出来

3. ER 模型 $\to$ 数据模型转换(关系模型，对象模型，非关系型数据库模型)

注意：ER 图的所有要素都要转换成关系模式

• 实体集 $\to$ 关系模式

7.7.1 Basic Structure

• 矩形：实体集
• 菱形：表示联系，在联系中心写联系的名字
• 菱形加虚线矩形：联系的属性
• 两个实体集之间用
  • 箭头连接：一
  • 不用箭头连接：多（有箭头的那方）
• 全部参与：双线
• 对于较复杂的符合属性：使用缩进
• 多值属性：使用大括号 phone_number
• 派生属性：使用括号 age()
• 双菱形加虚下划线：不具有主码的实体集为弱实体集，强实体集：有主码
  • 一个弱实体集不能独立存在，要依赖于强实体集存在

7.9 Alternative Notations for Modeling Data

7.9.1 Symbols used in the E-R notation

Chapter 8 Relational Database Design

8.1 Features of Good Relational Designs

• 使用规范化理论，衡量或者评估或改进工具进行数据库优化

  • 通过对关系模式的分解解决不合适的数据依赖（通过对低级别范式的优化，表的分解，在规范化的过程中，一个表会被优化为多个表）
  • 范式：normal form （NF）
  • 多级范式：第一到第三范式（ $1\sim 3$ NF），BC 范式 （BCNF），第四到五范式（$4\sim 5$ NF）
    • 范式级别越低，表示约束的标准越低，越宽松，级别太低的表是不可用的，需要提高其范式
    • 一个关系模式的范式定义为：$R\in nNF\ \ e.g.student\in 3NF $
    • 在设计数据库时，范式级别往往呗指定为数据库工程的验收标准

• 前提：系统分析 $\to$ ER 模型能够比较好的贴近现实问题 $\to$ 转换关系表 $\to$ 表的质量较好（紧密围绕某一个主题去确定属性）

• 纯粹从理论上提出的一套规范化的方法 （有些方法在现实中无法使用）

  • 基本前提：泛关系假设（假设开始设计数据库的时候，一个数据库中的多个表的属性是合在一个表中的）
    • 大表的质量肯定比较差 $\to$ 对这个大表使用规范化理论进行优化
    • 构成大表的原因是实体集找的不好，但是如果全部确认了比较好的实体集，这章屁用没有，常会出现的错误是实体集的属性找的不好

• 优化的目的：消除冗余

• 把多个主题的属性合并到一个表中

  • 优点：方便查询
  • 缺点
    • 浪费存储空间，数据冗余情况严重
    • 更新数据的操作要更新所有相关数据，导致更新操作相对困难
    • 扩展了主码，需要更加详细的字段信息
  • 产生问题的原因：数据之间的依赖关系

8.2 Atomic Domains and First Normal Form （1NF）

• 所有字段是原子（不可分解的），不存在复合属性
• 级别最低，对关系表的要求最低
• 避免：有一些看着是原子，但是实际上可以分割的字段，需要消除，不要使用程序解读

8.3 Decomposition Using Functional Dependencies （3NF & BCNF）

8.3.1 Functional Dependencies

• 函数依赖（FD）：研究两组属性集之间的依赖关系（两个属性谁决定谁、唯一决定）
  • 简明定义： x → f ( x ) = { d 1 , d 2 , . . . , d n } x\to f(x)=\{d_1,d_2,...,d_n\} x→f(x)={d1​,d2​,...,dn​}，例如 f ( i d ) = { n a m e , d e p t _ n a m e , s a l a r y } f(id)=\{name,dept\_name,salary\} f(id)={name,dept_name,salary}
  • 严谨定义：Consider a relation schema $r(R)$, and let $\alpha \subseteq R$ and $\beta \subseteq R$
    • Given an instance of $r(R)$, we say that the instance satisfies the functional dependency $\alpha \to \beta$ if for all pairs of tuples $t_1$ and $t_2$ in the instance such that $t_1[\alpha ]=t_2[\alpha ]$, it is also the case that $t_1[\beta ]=t_2[\beta ]$
    • We say that the functional dependency $\alpha \to \beta$ holds on schema $r(R)$ if, in every legal instance of $r(R)$ it satisfies the functional dependency.
    • $[\alpha ]$ 表示在 $\alpha$ 上的取值
  • 从函数依赖的角度可以定义码
    • $K$ is a superkey of $r(R)$ if the functional dependency $K\to R$ holds on $r(R).$
    • $K$ is a candidate key for $R$ if and only if $K\to R$ and for no $a\subseteq K,K\to R$
  • 关系表中的属性类型
    • 主码属性
    • 非主码属性
    • 候选码属性
• 函数依赖的集合：$F$ 表示若干个在 $R$ 上成立的 FD 的集合
• 刻画一个关系模式 $R$
  • 属性：$R(A_1,A_2,...A_n)$
  • 函数依赖关系： F = { A 1 → A 2 . . . } F=\{A_1\to A_2...\} F={A1​→A2​...}
• 函数依赖的类型
  • 平凡的函数依赖
    • a functional dependency of the form $\alpha \to \beta$ is trivial if $\beta \subseteq \alpha$
    • 自己决定自己，在任何 $R$ 上，任何属性上都成立
    • 例如，$AB\to A$ 就是一个平凡的函数依赖，因为 { A } ⊆ { A B } \{A\} \subseteq \{AB\} {A}⊆{AB}
    • 表明了属性和属性自己是有关系的
  • 传递函数依赖（不好的）
    • $A\to B,B\to C$
  • 完全函数依赖（好的）
    • 一个完全函数依赖成立，当且仅当 $X_1,X_2\to Y$ 成立，且 $X_1\to Y,X_2\to Y$ 不成立
    • 也就是说，$Y$ 要完全依赖于 $X_1,X_2$ 的值，没有多余的属性
  • 部分函数依赖（不好的）
    • 一个部分函数依赖成立，当且仅当 $X_1,X_2\to Y$ 成立，且 $X_1\to Y,X_2\to Y$ 也成立
    • 也就是说，$Y$ 部分依赖于 $X_1,X_2$ 的值，只要 $X_1,X_2$ 的一部分知道，$Y$ 就成立
• 函数依赖的闭包
  • $R$ 上成立的所有的 FD 的集合
• 堆到规则

8.3.2 Boyce-Codd Normal Form ！！

• 定义（重点）：A relation schema $R$ is in BCNF with respect to a set $F$ of functional dependencies if, for all functional dependencies in $F^{+}$ of the form $\alpha \to \beta$, where $\alpha \subseteq R$ and $\beta \subseteq R$, at least one of the following holds:
  • $\alpha \to \beta$ is a trivial functional dependency (that is, $\beta \subseteq \alpha )$.
  • $\alpha$ is a superkey for schema $R$.

这个定义是一个判断标准

• 对于 $F^{+}$ 中所有形如 $\alpha \to \beta$ 的函数依赖（也就是所有的函数依赖，如 { a → b , b → c , a b → d e } \{a\to b, b\to c, ab\to de\} {a→b,b→c,ab→de}），如果满足其中其中之一的条件，则为 BCNF
  • 判断 $\alpha \to \beta$ 是不是平凡的 FD
  • 判断 $\alpha \to \beta$ 中 $\alpha$ 是不是超码

总结：在 $R$ 上，能够存在的函数依赖，要么是平凡的函数依赖，要么 $\alpha$ （决定因素）是超码，则 $R\subseteq$ BCNF. 也就是说发出箭头的除平凡外就是超码

8.3.3 BCNF and Dependency Preservation

如果一个关系 $R$ not in BCNF $\to$ 优化（模式分解）$\to$ 成为许多小的关系模式 { R 1 , R 2 , . . . , R n } \{R_1,R_2,...,R_n\} {R1​,R2​,...,Rn​}

把一个 $R$ 分解为若干个子关系模式时，达到 BCNF 要求时，有可能会丢失一些函数依赖（不保持函数依赖）

分解需要满足两个前提条件

• 分解之后要保持函数依赖

8.3.4 Third Normal Form

A relation schema $R$ is in third normal form with respect to a set $F$ of functional dependencies if, for all functional dependencies in $F^{+}$ of the form $\alpha \to \beta$, where $\alpha \subseteq R$ and $\beta \subseteq R$, at least one of the following holds:

• $\alpha \to \beta$ is a trivial functional dependency.
• $\alpha$ is a superkey for $R$.
• Each attribute $A$ in $\beta -\alpha$ is contained in a candidate key for $R$.
  • $\beta -\alpha$：它们的差
  • $A$ ：主属性（构成候选码的属性）
  • 是不是由主属性构成的

Note that the third condition above does not say that a single candidate key must contain all the attributes in $\beta -\alpha ;$ each attribute $A$ in $\beta -\alpha$ may be contained in a different candidate key.

8.3.5 Second Normal Form

如果关系 $R\in$ 1NF，并且 $R$ 中的每一个非主属性完全依赖于主关键字

8.4 Functional-Dependency Theory

• 函数依赖在当前这个表上对不对
• 候选码的确认

8.4.1 Closure of a Set of Functional Dependencies

• logically implied：Given a set $F$ of functional dependencies on a schema, wecan prove that certain other functional dependencies also hold on the schema. We say that such functional dependencies are “logically implied” by $F$.

已知： R ( A 1 , A 2 , A 3 , A 4 ) , F = { A 1 → A 2 ， A 1 → A 3 } R(A_1,A_2,A_3,A_4), F=\{A_1\to A_2，A_1\to A_3\} R(A1​,A2​,A3​,A4​),F={A1​→A2​，A1​→A3​}

问：在 $R$ 上，还有没有一些未知的 FD 能够基于已知的 $F$ 推导出来，如何证明？

• Armstrong’s axioms：作为工具来回答以上问题

  • 三条公理

    • Reflexivity rule. If $\alpha$ is a set of attributes and $\beta \subseteq \alpha$, then $\alpha \to \beta$ holds.
    • Augmentation rule. If $\alpha \to \beta$ holds and $\gamma$ is a set of attributes, then $\gamma \alpha \to \gamma \beta$ holds.
    • Transitivity rule. If $\alpha \to \beta$ holds and $\beta \to \gamma$ holds, then $\alpha \to \gamma$ holds.

  • 三条公理的性质

    • 正确性：基于这三个推导规则推导出的结果
    • 完备性：利用此三个推导规则，能够把所有的函数依赖都能证明

  • 三条派生规则

    • Union rule. If $\alpha \to \beta$ holds and $\alpha \to \gamma$ holds, then $\alpha \to \beta \gamma$ holds.
    • Decomposition rule. If $\alpha \to \beta \gamma$ holds, then $\alpha \to \beta$ holds and $\alpha \to \gamma$ holds.
    • Pseudotransitivity rule. If $\alpha \to \beta$ holds and $\gamma \beta \to \delta$ holds, then $\alpha \gamma \to \delta$ holds.

  • 六个推导规则的作用

    • 求给定关系模式的码 $K\to R$
    • 计算 $F^{+}$ （有一些算法）
    • 求一组函数依赖中蕴含的函数依赖

  • 求一组函数依赖中蕴含的函数依赖

    • 利用 Armstrong 公理系统直接证明（困难）

    • 计算 $F^{+}$ 看当前的函数依赖是否处于闭包中（困难）

    • 求出 $\alpha$ 属性集闭包，判断 $\alpha \to \beta$ （容易：属性的个数是有限的）

      属性集闭包：$\alpha$ 能决定的所有属性

      如，判断 $\alpha \to {\beta }_1$ 在 $F$ 上成立，求出 $\alpha$ 属性集闭包 $({\beta }_1,{\beta }_2,{\beta }_3)$

• 属性集闭包的作用

  • 判断 PD 的逻辑蕴含关系
  • 判断一个属性集是否为超码：一个属性集的闭包等于所有的属性，它就是超码
  • 判断一个属性集是否为候选码（超码的最小化）：首先为超码，并且作为超码有没有多余属性
    • A+=R​ $A$ 自己就可以决定所有的属性，$A$ 就是候选码，$B$ 是多余的
    • A+= ACB​ 且 B+=AGCD $(R=ABCDG)$ $\to$ $AB$ 没有多余的属性，$AB$是候选码
    • 在经典的数据库设计中，不能随意添加 ID 字段，但是在现在的实际应用中，经常认为添加 ID 属性

8.4.2 Canonical Cover 正则覆盖/最小覆盖

已知一个 $F$ （函数依赖），将 $F$ 最小化，得到 $F_c/F_{min}$ （正则覆盖）

• 正则覆盖的作用

  • 在进行模式分解时，消除多余的函数依赖，使得最终建表精简
  • 在 DBMS 中真正建立数据表的时候，FD ，约束表现

• $F$ 最小化：消除冗余的 FD

  • 在 $F$ 中，有相同的 FD 去除

  • 在 $F$ 中，有一些 FD 可以被其他的 FD 直接推导 （传递，自反，合并，分解）

  • 复合属性（extraneous attributes）：有没有多余属性

    • 左边为复合属性： $e.g.AB\to C$，$AB$ 中是否有多余属性

      Attribute $A$ is extraneous in $\beta$ if $A\in \beta$, and the set of functional dependencies ( F − { α → β } ) ∪ { α → ( β − A ) } (F-\{\alpha \rightarrow \beta\}) \cup\{\alpha \rightarrow(\beta-A)\} (F−{α→β})∪{α→(β−A)} logically implies $F.$

      假设 $A$ 是多余的，去掉旧的 FD （含有 $A$），加上新的 FD （去掉了 $A$），得到新的 $F^{\prime }$

    • 右边为复合属性： $e.g.A\to BC$，$BC$ 中是否有多余属性

      Attribute $A$ is extraneous in $\alpha$ if $A\in \alpha$, and $F$ logically implies ( F − { α → β } ) ∪ { ( α − A ) → β } . (F-\{\alpha \rightarrow\beta\}) \cup\{(\alpha-A) \rightarrow \beta\} . (F−{α→β})∪{(α−A)→β}.

    • 需要证明

  • 正则覆盖Notice

    • 判断左边的复合属性，直接在原本的依赖集中求闭包
      比如有 $AB\to C$ ，如果想去掉 $A$ 或者 $B$，就看看函数依赖集中的 $A^{+}$ （ $A$ 的闭包） 或者 $B^{+}$ 中有没有 $C$ 即可，因为如果 $B$ 能够从它单独的自己出发推出 $C$ 那么 $A$ 在这个关系中就是无用的
    • 判断右边的复合属性，才需要把函数依赖中的元素删掉再放回原函数依赖集

8.4.3 候选码的确定

关系 $R(U,F)$ 中，假定 $F$ 已经是最小覆盖

• 准则 $1$：如果属性 $A$ 只在 $F$ 中各函数依赖的左端出现或根本没有出现过，则 $A$ 一定是候选码中的属性
• 准则 $2$：如果属性 $A$ 只在 $F$ 中各函数依赖的右端出现，则 $A$ 一定不是候选码中的属性

确定候选码的步骤是
(1) 对于关系模式 $R(U,F)$，求 $F$ 的最小覆盖，仍用 $F$ 表示
(2) 根据准则 $1$，确定候选码中必须有的属性集(设为 $M$)
(3) 根据准则 $2$，去掉候选码中没有的属性集(设为 $G$)
(4) 确定余下的属性集(设为 $W$)。
(5) 从 $M$ 开始，令 $K＝M$，如果 $K_F^{+}=U$ （ $U$ 为全集），$K$ 就是候选码。否则从 $W$ 选择属性加入到 $K$ 中，直到 $K_F^{+}=U$，$K$ 就是候选码
(6) 注意：可能有多个候选码

8.4.4 无损连接和保持函数依赖

• 对于 $\mathrm{R}(\mathrm{U},\mathrm{F})$ 的一个分解 ρ = { R 1 , R 2 } \rho=\left\{R_{1}, R_{2}\right\} ρ={R1​,R2​} ，如果 $R_1\cap R_2\to R_1\in F^{+}$ 或 $R_1\cap R_2\to R_2\in F^{+}$, 则该分解具有无损连接性
• 若 $F^{+}={\left({\bigcup }_{i=1}^k{F}_i\right)}^{+}$, 则 $\mathrm{R}(\mathrm{U},\mathrm{F})$ 的分解 ρ = { R 1 < U 1 , F 1 > , ⋯   , R k < U k , F k > } \rho=\left\{R_{1}<U_{1}, F_{1}>, \cdots, R_{k}<U_{k}, F_{k}>\right\} ρ={R1​<U1​,F1​>,⋯,Rk​<Uk​,Fk​>} 保持函数依赖

8.4.5 关系模式 $R$ 的优化 模式分解

• $F$ 的最小集要求出来

• 候选码要求出来

• 判断 $R$ 的范式级别

• 模式分解：分解的两个前提条件

  • 无损分解（第一要保证，一定要保证）：数据的正确性，记录数要等于分解之后子表连接运算的记录数
  • 保持函数依赖（第二要保证）：分解后所有的函数依赖的并等于原函数依赖

• BCNF 分解算法（满足无损分解）

  • 至少有一个函数依赖不满足 BCNF 的要求时就执行优化

• 3NF 分解算法（满足无损分解和保持函数依赖）
  • 先算最小覆盖 $F_c$
  • 找出候选码
  • 根据 $F_c$ 中的函数依赖分解
    • 一个函数依赖就生成一个子表 T n = { . . . } T_n=\{...\} Tn​={...}
    • $Count(T_n)=Count(F_c)$
  • 检查候选码 $K$ 是否包含在某个子表中
    • 包含： T n = { . . . } T_n=\{...\} Tn​={...} 就是结果，$Count(T_n)=Count(F_c)$
    • 不包含：将候选码 $K$ 生成一个子表，$Count(T_n)=Count(F_c)+1$

Chapter11 Indexing and Hashing

SQL 查询语句十分重要

• 构造 SQL: 怎么样写出质量高的 SQL 语句
• 运行期间: 查询语句 $\to$ 执行慢 $\to$ 观察分析 SQL

11.1 索引 Index

提高查询速度的有效办法

是帮助 MySQL 高效获取数据的数据结构（有序）。即在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以 某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引

• 索引的作用：快速查找数据

当表中有大量记录时，若要对表进行查询，第一种搜索信息方式是全表搜索， 是将所有记录一一取出，和查询条件进行一一对比，然后返回满足条件的记录，这样做会消耗大量数据库系统时间，并造成大量磁盘 I/O 操作；第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中 的 ROWID（相当于页码）快速找到表中对应的记录

• 索引的缺点
  • 要占用额外的存储空间
  • 降低更新表的速度：更新表时，MySQL 不仅要保存数据，还有可能要维护索引文件

11.1.1 索引的分类

• 聚簇索引
  • 索引中键值的逻辑顺序决定了表中相应记录的物理顺序
  • 主键索引（等价于基本表）：在主码字段上建立的索引
• 非聚簇索引
  • 单列索引：一个索引只包含单个列，一个表可以有多个单列索引
  • 唯一索引：索引列的值必须唯一，但允许有空值
  • 复合索引：一个索引包括多个列
  • 全文索引：在 MyISAM 引擎支持，只能在 CHAR,VARCHAR,TEXT 类型字段上使用

11.1.2 索引的创建和删除

• 主键索引：DBMS 自动创建 (在表上定义了主键时，会自动创建一个主键索引)

• 单列属性索引：一个表可以有多个单列索引

CREATE INDEX name_index ON student(NAME); 

此外，在表上定义一个外键时，会自动创建一个普通索引

• 唯一索引：相应属性的值不能重复

CREATE UNIQUE INDEX title_index ON course(title);

• 复合索引：多个属性一起构成的索引

CREATE INDEX dept_name_index ON student(dept_name,name); 

11.1.3 索引的维护

• 删除索引：DROP INDEX 索引名 ON 表名;

DROP INDEX name_index ON tb;

• 查询表上建立的索引：SHOW INDEX FROM 表名;

SHOW INDEX FROM student; 

11.1.4 索引的选择

使用索引也是有代价的，因为索引本身要占用存储空间，同时索引会加重更新记录时的负担，因此所引并不是越多越好

• 适合创建索引的字段

  • 主码和外码字段
  • Where 子句中的常用到的查询条件的字段
  • 查询中与其他表关联的字段，
  • 排序的字段，统计或分组的字段创建索引

• 不适合创建索引的字段

  • 频繁更新的字段不适合建立索引
  • Where 条件用不到的字段，不创建索引
  • 表中记录较少时，不需要建立索引
  • 经常增删改的表不要建立索引
  • 重复值多的字段不要建立索引

  计算字段不重复的比例

  SELECT
      COUNT(DISTINCT (dept_name)) / COUNT(*) AS Selectivity
  FROM
      instructor;
  

11.1.5 InnoDB 中的主键索引

MySQL InnoDB 数据存储结构 (hellopz.com)

InnoDB 的页结构

InnoDB 存储引擎将数据划分为若干个页，以页作为磁盘和内存之间交互的 基本单位，页的大小一般为 16KB。因此，InnoDB 一次最少从磁盘中读取 16KB 的内容到内存中；一次最少把内存中的 16KB 内容刷新到磁盘中

• 每一条记录不能跨页，设计表的时候，字段的数据类型和长度不能

名称	中文名	占用空间大小	简单描述
File Header	文件头部	38字节	页的一些通用信息
Page Header	页面头部	56字节	数据页专有的一些信息
Infimum + Supremum	最小记录和最大记录	26字节	两个虚拟的行记录
User Records	用户记录	不确定	实际存储的行记录内容
Free Space	空闲空间	不确定	页中尚未使用的空间
Page Directory	页面目录	不确定	页中的某些记录的相对位置
File Trailer	文件尾部	8字节	校验页是否完整

• 插入数据时，数据页的变化如下

• 多个页之间采用双向链表连接

InnoDB 的记录（行）结构

Mysql 中记录的格式类型包括：Compact、redundant、dynamic、compressed 四种，默认是 compact 行类型

（1）变长字段：

• 列长度 < 255 字节，用 1 字节表示
• 列长度 > 255 字节，用 2 字节表示
• 长度最大不能超过 2 个字节，因为 MySQL 数据库中 VARCHAR 的最大长度限制为 65535

（2）NUll 标志位：

• 记录该行数据是否有 NULL 值，有就用 1 表示，占 1 个字节；
• 如果这个行数据有 NULL，则不占任何空间；

（3）记录头信息：

• 固定占 5 个字节，即 40 位，具体记录头信息见下图

（4）实际的每列的数据

（5）每行数据除了用户定义的列之外，还有两个隐藏列

名称	大小（单位：bit）	描述
预留位1	1	没有使用
预留位2	1	没有使用
delete_mask	1	标记该记录是否被删除
min_rec_mask	1	B+树的每层非叶子节点中的最小记录都会添加该标记
n_owned	4	表示当前记录拥有的记录数
heap_no	13	表示当前记录在记录堆的位置信息
record_type	3	表示当前记录的类型，0表示普通记录，1表示B+树非叶子节点记录，2表示最小记录，3表示最大记录
next_record	16	表示下一条记录的相对位置

当对记录进行增删改操作，InnoDB 始终会维护一条记录间的单链表，链表 中的各个节点是按照主键值由小到大的顺序连接起来的

11.1.6 避免索引失效方法

1. 防止复合索引失效

• 不要跨列或无序使用（遵循最佳左前缀原则）
• 尽量使用全索引匹配
• 不能使用不等于（!= <>）或 is null (is not null)，否则自身以及右侧所有索引全部失效

2. 不要在索引上进行任何操作（计算、函数、类型转换），否则索引失效

如假设 A.x 是索引

不要写成：SELECT ..WHERE A.x*3 = .. ;

3. like 尽量以“常量”开头，不要以'%'开头，否则索引失效

• tname 索引失效

EXPLAIN
SELECT *
FROM
    student
WHERE
    name LIKE '%x%'; 

• 不以’%'开头，name 索引不失效

EXPLAIN
SELECT *
FROM
    student
WHERE
    name LIKE 'x%';

• 如果必须使用 like '%x%'进行模糊查询，可以将索引列放在 select 后面，使用索引覆盖挽救一部分

EXPLAIN
SELECT
    name
FROM
    student
WHERE
    name LIKE '%x%';

11.2 SQL 语句命令执行分析

查询优化器 $\to$ SQL 语句进行编译 $\to$ 生成查询计划（使用的表，索引文件）

11.2.1 EXPLAIN 命令

查看 SQL 的执行计划，模拟 SQL 优化器执行 SQL 语句，可以让开发人员分析 SQL 执行的状况

EXPLAIN 命令可以查看 SQL 语句的执行计划。当 EXPLAIN 与SQL语句一起使用时，Mysql将显示来自优化器的有关语句执行计划的信息。也就是说，Mysql解释了它将如何处理语句，包括有关如何联接表以及以何种顺序联接表的信息

• EXPLAIN 的作用
  • 分析出表的读取顺序
  • 数据读取操作的操作类型
  • 哪些索引可以使用
  • 哪些索引被实际使用
  • 表之间的引用
  • 每张表有多少行被优化器查询

参数	描述
id	执行select子句或操作表的顺序
select_type	查询的类型，如SIMPLE、PRIMARY、SUBQUERY、DERIVED、UNION等
table	当前行使用的表名
partitions	匹配的分区
type	连接类型，如system、const、eq_ref、ref、range、index、all等
possible_keys	可能使用的索引
key	实际使用的索引，NULL表示未使用索引
key_len	查询中使用的索引长度
ref	列与索引的比较
rows	扫描的行数
filtered	选取的行数占扫描的行数的百分比，理想的结果是100
extra	其它额外信息

参数解析

1. id : 编号

• id 值相同：表示从上往下顺序执行。表的执行顺序因记录数的改变而改变，记录数少的表优先查询
• id 值不同：id 值越大越优先查询。如在嵌套子查询时，先查内层再查外层

2. select_type ：查询类型

• PRIMARY：表示包含子查询 SQL 中的主查询（外层）；
• SUBQUERY：表示包含子查询 SQL 中的子查询 （非最外层）；
• SIMPLE：表示简单查询，不包含子查询、union 查询；
• DERIVED：表示衍生查询，使用到了临时表；

3. type：查询时用到的索引类型

主要类型：$system>const>eq\_ref>ref>range>index>all$，越往左边性能越高

要对 type 进行优化的前提是要有索引 (system、const 只是理想情况，实际能达到 ref 和 range 类型)

• system：只有一条数据的系统表或衍生表只有一条数据的主查询

• const：仅仅能查到一条数据的 SQL ，用于 primary key 或 unique 索引

• eq_ref：唯一性索引，对于每个索引键的查询，返回匹配唯一行数据（有且只有 1 个）

• ref：非唯一性索引，对于每个索引键的查询，返回匹配的所有行

• range：只检索给定范围的行，使用一个索引来选择行

• index：使用全文索引

• ALL：全表扫描

4. possible_keys ：系统预测可能用到的索引

如果 possible_key/key 为 NULL，则说明该查询没用到索引

5. key ：实际查询时使用到的索引

如果 key 为 NULL，则说明该查询没用到索引

6. key_len ：使用的索引长度

可用于判断复合索引中的属性是否被完全使用

注意：

• utf8：1 个字符 3 个字节
• gbk：1 个字符 2 个字节
• latin：1 个字符 1 个字节
• 如果索引字段可以为 NULL，则会使用 1 个字节用于标识
• Varchar：用 2 个字节标识可变长度

7. ref

注意与 type 中的 ref 值区分

作用：指明当前表所参照的字段

8. rows: 记录个数

9. extra：额外信息

using filesort：表示该 SQL 语句性能消耗大，需要“额外”的一次排序（查询），常见于 order by 语句中，如：

• 对于单索引

  • 如果排序和查找是同一个字段，则不会出现 using filesort

  • 如果排序和查找不是同一个字段，则会出现 using filesort

  • 避免方法：where 子句中出现哪些字段，order by 子句中就用哪些字段

    EXPLAIN
    SELECT *
    FROM
        instructor
    WHERE
        salary > 60000
    ORDER BY
        dept_name
    

• 对于复合索引

  • 查询各子句中出现的字段最好不要跨列，保持和复合索引字段一样的顺序

  • 注意：where 和 order by 按照复合索引的顺序使用，不要跨列或无序使用

    EXPLAIN
    SELECT *
    FROM
        student
    WHERE
        name = 'Zhang'
    ORDER BY
        dept_name
    

    student 表中的复合索引为(dept_name,name)，但是该查询语句中，先出现 name 字段，后出现 dept_name 字段，和复合索引中字段的顺序不一致，导致复合索引失效，查询时没有使用该复合索引

using temporary：表示该 SQL 语句性能损耗大，用到了临时表

• 一般出现在 group by 语句中
• 避免方法：查询哪些列，就在 group by 子句中使用这些列

using index ：该信息表示 SQL 语句性能提升，实现了索引覆盖

• 表示不读取原文件，只从索引文件中获取数据，不需要回表查询

using where：该信息表示 SQL 语句性能损耗大，需要回表查询

假设 age 是索引列，但查询语句为：

SELECT
    age,
    name
FROM
    ...
WHERE
    age = ...

此语句中必须回原表查寻 name 字段的值，因此会显示 using where.

如执行以下命令：

EXPLAIN
SELECT *
FROM
    instructor
WHERE
    salary > 60000
GROUP BY
    dept_name

该查询中 dept_name 为索引字段，但是要显示所有字段，必须要回原表查询，因此会显示 using where

Chapter14 Transactions

14.1 Transaction Concept

• 事务：是关系型数据库和非关系型数据库的一个显著区别
  • A transaction is a unit of program execution that accesses and possibly updates various data items.
  • 是用户定义的语句群，要么全部都执行，要么全部都不执行，不能执行一部分
  • 企业的实际应用：关系型数据库（重要的数据）+ 非关系型数据库（不太重要的数据）
• 定义事务

显式定义

BEGIN TRANSACTION
SQL 1
SQL 2
COMMIT # 写到磁盘中

BEGIN TRANSACTION
ROLLBACK # 撤销之前的更新结果

隐式定义

当用户没有显式的定义事务的时候，DBMS 按缺省规则自动划分事务

• ACID

  • 原子：一个事务要么执行要么不执行
  • 隔离：一个事务的执行不能被其他事务干扰
  • 持久：一旦一个事务被成功提交之后，它对数据库中的数据的改变就是永久性的
  • 一致：事务的执行结果必须使得数据库从一个一致性状态变到另一个一致性状态
  • 如何实现：并发控制、恢复机制

14.2 并发控制/调度

• 并发控制/调度：某一时刻，多个用户对同一个数据对象的访问
  • 并发调度不当产生的问题
    • 丢失修改：两个事务同时读了一个数据并且修改，先修改的修改丢失
    • 不可重复读：事务1读取数据后，事务2执行更新操作，事务1两次读同一个数据但是却得到不同的结果
    • 读脏数据：事务1在对数据做修改的时候，事务2读取了这个数据，但是事务1回滚了，事务2读的数据就是脏数据
  • 设计合适的并发调度策略

14.2.1 悲观法

基本方法 $\to$ 基于锁的机制：对要访问的数据对象上加锁

• 排他锁：写锁，更新数据，能读能写

• 共享锁：读锁，查询数据，能读

• 关于锁上加锁：只能加多个共享锁，共享锁不能加排他锁。如果第一个锁是排他锁，其他的锁就不能继续往上添加

• 问题：死锁现象——两阶段封锁协议

  • 如，T1：A, B, C

    在生长阶段（申请锁阶段）：ABC 数据对象上的锁全部都要加上

    对ABC进行数据处理

    收缩阶段（释放锁阶段）：ABC数据对象上的锁全部都释放

• 可以对不同层次的数据对象加锁

  • 服务器级别的锁，让服务器变为只读（恢复）
  • 数据库级别的锁（数据库备份）
  • 数据表级别（并发控制）
  • 记录级别（细化的并发控制）
  • 字段级别（细化的并发控制）

• 锁的使用：数据对象的级别，锁的类型，申请锁的时间，持有锁的时间（释放锁的时间）

  • 自己研究比较困难，容易造成死锁，不要亲自在开发的时候使用锁机制进行并发控制，使用事务的隔离级别来控制

• 隔离级别：实际开发中使用的并发控制

  • Serializable：可串行化，所有事务顺序执行，代价最高，但是最可靠，保证所有的数据不一致情况都不会发生
  • Repeatable read：可重复读，并发度好，可以防止脏读，不可重复读，但会可能出现幻读，默认情况下锁定所有已经读取的行
  • Read committed ：已提交读，一个事务不能读取其他数据未提交的数据，可以避免脏读，可能出现不可重复读，幻读
  • Read uncommitted：未提交读，允许其他事务读取一个事务正在读取的数据，以上问题都会出现

14.2.2 乐观的并发调度

查询数据是主要业务的应用场景
不使用锁机制，不强调先要占有某个数据对象，方法有

每个事务都可以对某个数据对象进行操作和更新

• 时间戳
• 版本控制

14.3 恢复机制——事务的持久性

• 数据库的数据出现故障是不可避免的
• 做备份（冗余数据）
• 主数据文件做备份——基本数据——DBA——先写日志，再写数据库
• 日志文件做备份——DBMS自动维护：记录对表的更新操作
  日志记录——写入日志文件

事务开始标记
	insert
	值
事务结束标记

一旦发生故障，DBMS检查日志文件，有一些日志记录是否完整：事务开始和结束标记
还有一些日志记录不完整：只有事务开始但是没有结束标记

MySQL单机备份
主从备份

Appendix A 编程语言访问数据库

A.1 基本访问流程

DBMS DBA $\to$ 直接操作 $\to$ DBMS （人数少）

开发人员：间接操作 $\to$ 编程语言 $\to$ DBMS（人数多）

java 访问 MySQL 的步骤：开发人员 $\to$ 框架工具 $\to$ SSM

1. 找到合适的 API：加装驱动（类、属性、方法）
   • java：JDBC
   • ODBC：开放数据库互连
   • C#：ADO.NET
   • PHP

java：语言生态环境好，第三方工具包（已实现功能，类库、jar、war）

系统开发：广泛的利用第三方工具包

e.g. JDBC $\to$ jar $\to$ 类

2. 连接到数据库，建立连接：conncetion
   • 连接类 $\to$ 编写连接字符串信息（数据库服务器IP、登陆账号密码、端口号、访问的数据库）
   • 使用 open() 方法打开，以建立连接
3. 编写SQL字符串：CRUD
4. 执行命令：命令类
   • command, statement, SQL命令
   • 属性，方法，CRUD，查询
5. 接收 SQL 返回结果
   • 查询 $\to$ 结果集（10记录$\to$ 遍历 $\to$ 页面显示）
   • 更新 $\to$ 返回一个整数（几行受到了影响）
6. 关闭连接对象
7. 定义一个事务
8. try-catc

A.2 SQL注入攻击

因为 SQL 语句是多个字符串拼凑而成，通过一些特殊字符的编写，可以对传入的 SQL 语句进行修改，达到获取高级权限的目的

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

public class TestSQL_Injection {

    public static void main(String[] args) {
        Connection conn = null;
        try {
            // 1.加载驱动mysql8版本
            Class.forName("com.mysql.cj.jdbc.Driver");

            // 2.建立连接
            conn = DriverManager.getConnection("jdbc:mysql:///myschool? useSSL=false & serverTimezone=Hongkong", "root", "root");

            // 3.编写非法的SQL语句
		    /*SELECT * FROM users
			  WHERE id=666
			        AND username='xxx' OR '1'='1';*/

            String selectUser = "SELECT * FROM users "
                    + "WHERE id=666 "
                    + "AND username='xxx' OR '1'='1';";

            // 4.创建命令对象
            Statement stmt = conn.createStatement();

            // 5.执行并接收查询结果
            ResultSet rest = stmt.executeQuery(selectUser);
            // 循环读出数据
            while (rest.next()) {
                int id = rest.getInt("id");
                String username = rest.getString("username");
                System.out.println(id + " " + username);
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try {
                // 关闭连接
                assert conn != null;
                conn.close();
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
    }
}

A.3 参数化的SQL语句

将要执行的 SQL 语句参数化，填入字符串中，以达到防止 SQL 注入攻击的目的

注意：在 select 操作中,如果参数是 sql标识符或者列名，不可以使用 setString 参数化编写(SQL限制)

https://stackoverflow.com/questions/36192242/java-preparedstatement-sql-syntax-error

A.4 预编译的SQL语言

Appendix B 数据库恢复技术

单机

B.1 故障的种类

1. 事务内部的故障(DBMS自动恢复 日志文件)

2. 系统故障(DBMS自动恢复 日志文件)

3. 介质故障(DBA恢复 备份数据+日志文件)

4. 计算机病毒(DBA恢复 备份数据+日志文件)

B.1.1 事务内部的故障

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

• 运算溢出
• 并发事务发生死锁而被选中撤销该事务
• 违反了某些完整性限制而被终止等

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

• 事务故障意味着

  • 事务没有达到预期的终点( COMMIT 或者显式的 ROLLBACK )
  • 数据库可能处于不正确状态。

• 事务故障的恢复：事务撤消（UNDO）

  • 强行回滚（ROLLBACK）该事务
  • 撤销该事务已经作出的任何对数据库的修改，使得该事务象根本没有启动一样

B.1.2 系统故障

• 系统故障
  • 称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动。

B.1.3 介质故障

B.1.4 计算机病毒

B.2 恢复

• 恢复操作的基本原理：冗余
  • 利用存储在系统别处的冗余数据来重建数据库中已被破坏或不正确的那部分数据
• 恢复的实现技术：复杂
  • 一个大型数据库产品，恢复子系统的代码要占全部代码的10%以上

恢复机制涉及的关键问题

1. 如何建立冗余数据

• 数据转储/备份（backup）：对主数据库文件进行备份
• 登记日志文件（logging）：.log

2. 如何利用这些冗余数据实施数据库恢复

静态转储

• 在系统中无运行事务时进行的转储操作
• 转储开始时数据库处于一致性状态
• 转储期间不允许对数据库的任何存取、修改活动
• 得到的一定是一个数据一致性的副本
• 优点：实现简单
• 缺点：降低了数据库的可用性
  • 转储必须等待正运行的用户事务结束
  • 新的事务必须等转储结束

动态转储

• 转储操作与用户事务并发进行

• 转储期间允许对数据库进行存取或修改

• 优点

  • 不用等待正在运行的用户事务结束
  • 不会影响新事务的运行

• 缺点

  • 不能保证副本中的数据正确有效
  • 例：在转储期间的某时刻 $T_c$，系统把数据 $A=100$ 转储到磁带上，而在下一时刻 $T_d$，某一事务将 $A$ 改为 $200$。后备副本上的 $A$ 过时了

• 海量转储（全备份）: 每次转储全部数据库（一般是第一次备份数据库时）

• 增量转储: 只转储上次转储后更新过的数据 （后面的备份）

• 海量转储与增量转储比较

  • 从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
  • 如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

• 登记日志文件

  • DBMS 自动完成
  • 只记录修改类操作
  • 以数据块为单位

• 必须先写日志文件，后写数据库（因为写日志文件的操作比写数据库快的多）

  • 写日志文件操作：把表示这个修改的日志记录写到日志文件中
  • 写数据库操作：把对数据的修改写到数据库中

在恢复数据库的时候，可能有一段无法恢复，需要日志文件

B.3 检查点技术

• 具有检查点（checkpoint）的恢复技术
  • 在日志文件中增加检查点记录（checkpoint）
  • 增加重新开始文件
  • 恢复子系统在登录日志文件期间动态地维护日志

数据库集群

主从备份（主服务器处理用户请求）

多台从服务器：自动对主服务器的数据进行同步的更新——利用日志文件