《数据库系统概念（第六版）》读书笔记

本科由于各种原因没有选修过专门讲数据库的课程，对数据库也一直是处于会用即可的状态。想想还是应该对数据库有一个相对系统的学习，于是就先从这本《数据库系统概念》看起吧。

第一章 引 言

• 数据库的总体设计称为数据库模式（scheme）。
• 特定时刻存储在数据库中的信息的集合称作数据库的一个实例（instance）。

第二章 关系模型介绍

• 在关系模型中，关系（relation）用来指代表，元组（tuple）用来指代行，属性（attribute）指代的是表中的列。
• 数据库模式（database scheme）是数据库的逻辑设计，数据库实例（database instance）是给定时刻数据库中数据的一个快照。
• 超码（superkey） 是一个或多个属性的集合，这些属性的组合可以在一个关系中唯一地表示一个元组。
• 如果一个superkey的任意真子集都不能成为superkey，则我们称这样的最小superkey为候选码（candidate key）。
• 主码（primary key） 代表被数据库设计者选中的，主要用来在一个关系中区分不同元组的候选码。
• 一个关系模式（如$r_1$）可能在它的属性中包括另一个关系模式（如$r_2$）的primary key，这个属性在$r_1$上称作参照$r_2$的外码（foreign key）。这时，$r_1$称为外码依赖的参照关系，而$r_2$叫做外码的被参照关系。
• 参照完整性约束要求在参照关系中任意元组在特定属性上的取值必然等于被参照关系中某个元组在特定属性上的取值。
• 查询语言是用户用来从数据库请求获取信息的语言。在过程化语言中，用户指导系统对数据库执行一系列操作以计算出所需结果。在非过程化语言中，用户只需描述所需信息，而不用给出获取该信息的具体过程。
• 本书中主要涉及到的一些关系代数的操作及其含义：
  

第 3 章 SQL

• 当多个属性一起组成primary key时，只要这些属性中有一个不同就可以视作两个不同的primary key。
• 一个SQL查询可以包括三种类型的子句，select子句，from子句和where子句 。
• select子句用于列出查询结果中所需要的属性。
• from子句是一个查询求值中需要访问的关系列表。
• where子句是一个作用在from子句中关系的属性上的谓词。
• 别名运算 as。集合运算交，并，差。聚集函数avg，min，max，sum，count。
• 嵌套子查询，子查询是嵌套在另一个查询中select-from-where表达式。
• 书中有很多详细的说明SQL功能的SQL语句例子，这里就不一一列举了。

第 4 章 中级SQL

• 外连接（outer join） 通过在结果中创建包含空值元组的方式，保留了那些在连接中丢失的元组。（也就是说，如果两个关系$R_1$,$R_2$连接，如果$R_1$中的某个元组$t_1$在$R_2$中找不到匹配项，使用连接则在结果中不会包含$t_1$，而使用外连接则会包含$t_1$。）
• 外连接包括了三种形式，左外连接，右外连接，全外连接。
• 左外连接（left outer join） 只保留出现在左外连接运算之前（左边）的关系中的元组。
• 右外连接（right outer join） 只保留出现在右外连接运算之后（右边）的关系中的元组。
• 全外连接（full outer join） 保留出现在两个关系中的元组。
• 为了与外连接运算区别，此前提到的不保留未匹配元组的连接运算称作内连接（inner join） 运算。
• on和where在外连接中表现是不同的。其原因是外连接只为那些对相应内连接结果没有贡献的元组补上空值并加入结果。on条件是外连接声明的 一部分，但where子句却不是。
• SQL允许通过查询来定义“虚关系”，它在概念上包含查询的结果。虚关系并不预先计算并存储，而是在使用虚关系的时候才通过执行查询被计算出来。
• 任何像这种不是逻辑模型的一部分，但作为虚关系对用户可见的关系称为视图（view）。在任何给定的实际关系集合上能够支持大量的视图。
• 创建视图的命令格式为：create view v as ;
• 创建是视图以后，视图名可以出现在关系名可以出现的任何地方。
• 特定数据库允许存储视图关系，但是他们保证：如果用于定义视图的实际关系改变，视图也跟着修改。这样的视图被称为物化视图（materialized view）。
• 保持物化视图一直在最新状态的过程称为物化视图维护，或者通常简称视图维护。
• 频繁使用视图的应用将会从视图的物化中获益。物化视图查询所带来的好处需要与存储代价和增加的更新开销相权衡。
• 除了一些有限的情况之外，一般不允许对视图关系进行修改。不同的数据库指定了不同的条件以允许更新视图关系。具体的规则参考数据库系统手册。
• 在create table时允许指定的完整性约束包括：not null; unique; check(<谓词>)。
• 我们常常希望保证在一个关系中给定属性集上的取值也在另一关系的特定属性集的取值中出现。这种情况称之为参照完整性。
• 默认情况下，完整性约束会在每条SQL语句后检查。但在事务中有可能会暂时违反完整性约束。SQL标准允许将initially deferred子句加入到约束声明中，这样完整性约束不是在事务的中间步骤上检查，而是在事务结束的时候检查。
• 在关系的属性上所创建的索引（index） 是一种数据结构。它允许数据库系统高效地找到关系中那些在索引属性上取给定值的元组，而不用扫描关系中的所有元组。
• 当代数据库系统提供了三层结构的关系命名机制。最顶层由目录（catalog） 构成，每个目录都可以包含模式（scheme）。诸如关系和视图那样的SQL对象都包含在模式中。
• 授权相关的内容感觉平时用到的比较少，而且和Linux权限有较多的相似之处，所以这里就省略了。

第 5 章 高级SQL

• 这一章讲解了SQL的一些高级用法，但我感觉在平时中很少会有用到，于是就快速的过了一下，没有细看，因而相应的内容就省略了。

第 6 章 形式化关系查询语言

• 选择（select）运算选出满足给定谓词的元组。我们用小写希腊字母σ来表示选择，而将谓词写作σ的下标，参数关系在σ后的括号中。
• 投影（project）运算返回作为参数的关系，但把某些属性排除在外。投影用大写字母$\Pi$表示，列举所有我们希望在结果中出现的属性作为$\Pi$的下标，作为参数的关系跟随在$\Pi$后的括号中。
• 更名（rename）运算用于给关系代数表达式赋予名字。更名用ρ表示，关系代数表达式的名字作为ρ的下标，关系代数表达式位于ρ后的括号中。
• 元组关系演算（tuple relational calculus） 和域关系演算（domain relational calculus） 是非过程化的语言，代表了关系查询语言所需的基本能力。基本关系代数是一种过程化的语言，在能力上等价于被限制在安全表达式范围内的关系演算的这两种形式。

第 7 章 数据库设计和E-R模型

• E-R（Entity-Relationship）模型主要用于数据库设计过程。它的发展是为了帮助数据库设计，这是通过允许定义企业模式（enterprise schema） 实现的。这种企业模式代表数据库的全局逻辑结构，该全局结构可以用E-R图图形化表示。
• 实体（entity） 是现实世界中可区别于所有其他对象的一个“事物”或“对象”。实体通过一组属性来表示。每个属性都有一个可取值的集合，称为该属性的域（domain），或者值集（value set）。
• 实体集（entity set） 是相同类型即具有相同性质（或属性）的一个实体集合。
• 联系（relationship） 是指多个实体间的相互关联。
• 联系集（relationship set） 是相同类型联系的集合。
• 实体集之间的关联称为参与；也就是说，实体集XXX参与联系集XXX。
• 映射基数（mapping cardinality），或基数比率，表示一个实体通过一个联系集能关联的实体的个数。
• 对于实体集A和B之间的二元联系集来说，映射基数必然是以下情况之一：一对一，一对多，多对一，多对多。
• 如果实体集E中每个实体都参与到联系集R的至少一个联系中，实体集E在联系集R中的参与称为全部（total） 的。如果E中只有部分实体参与R，则E到R的参与称为部分（partial） 的。
• E-R图的画法省略，有需要自行查阅书本7.5章。

第 8 章 关系数据库设计

• 一个域是原子的（atomic），如果该域的元素被认为是不可分的单元。
• 我们称一个关系模式R属于第一范式（First Normal Form，1NF），如果R的所有属性的域都是原子的。
• 关于某个域是不是原子的，取决于实际情况，要在实际的场景中进行分析。
• 函数依赖：
  
  简单的理解就是，在关系r中，属性集α可以唯一的确定属性集β。
• 使用函数依赖这一概念，如果函数依赖K --> R在r上成立，则K是r的一个超码。
• 一个函数依赖称为平凡的（trivial），如果它在所有关系中都满足。一般地，如果$\beta \subseteq \alpha$，则形如α–>β地函数依赖是平凡地。
• Boyce-Codd 范式（Boyce-Codd Normal Form，BCNF）：
  
• 分解不属于BCNF的模式的一般规则：
  
• 第三范式（Third Normal Form，3NF）：
  
• 3NF实际是对BCNF的放宽，即增加了第三个条件。
• 接下来有许多数学上的定义和推导之类，略过。。。
• 多值依赖（multivalued dependency）：
  
• 第四范式（Fourth Normal Form，4NF）：
  
• 4NF比BCNF更严格。
• 更多的范式：
  

第 9 章 应用设计和开发

• 当服务器启动或者服务器接收到远程的HTTP请求执行某个特定servlet时，servlet的代码被加载到Web服务器中。servlet的任务就是处理这种可能涉及访问数据库获取必要信息，并动态生成HTML页面返回给客户端l浏览器的请求。
• servlet通常用于对HTTP请求动态生成响应。它可以访问HTML表单提供的输入，执行业务逻辑以决定给出什么样的响应，然后生成HTML输出并发送回浏览器。
• servlet生命周期：
  
• 服务器端脚本（server-side scripting）：脚本语言提供了可嵌入HTML页面内容中的脚本。在服务器端脚本中，服务器会在传送Web页面之前执行嵌入在HTML页面内容中的脚本。每段脚本在执行时会生成加入到页面中的文本（或可能甚至从页面中删除内容）。脚本的源代码将从页面中删除，因为客户端可能根本没察觉页面原先含有任何代码。如PHP就属于服务器端脚本。
• 后面的内容之前基本都接触过，因而省略。

第 10 章 存储和文件结构

• 磁盘
  
• 扇区是从磁盘读出和写入数据的最小单位。
• 通过反转磁性物质磁化的方向，读写头将信息磁化存储到扇区中。
• 因为所有盘片上的读写头一起移动，所以当某一个盘片的读写头在第i条磁道上时，所有其他盘片的读写头也都在各自盘片的第i条磁道上。因此，所有盘片的第i条磁道合在一起称为第i个柱面。
• RAID：Redundant Array of Independent Disk
  
• 一个文件可以由多个块组成。通常。每个关系的记录用一个单独的文件存储。但是在多表聚簇文件组织中，几个不同关系的记录存储在同一个文件中。
• 在文件中组织记录的几种可能的方法（也就是数据行怎么存储）。堆文件组织，顺序文件组织，散列文件组织。
• 堆文件组织：一条记录可以放在文件中的任何地方。只要那个地方有空间放这条记录。记录是没有顺序的。
• 顺序文件组织：记录根据其“搜索码”的值顺序存储。搜索码是任何一个属性或者属性的集合。搜索码无需是primary key，甚至也无需是super key。
• 散列文件组织：在每条记录的某些属性上计算一个散列函数。散列函数的结果确定了记录应该放到文件的哪个位置。
• 关于关系的关系模式和其他元数据存储在称为数据字典或系统目录的结构中。
• block是文件系统的概念，一个block映射到磁盘上可能对应多个扇区。而page是内存的概念，一个page也可能包含多个block。文件在文件系统中是由多个block组成的。

第 11 章 索引与散列

• 两种基本的索引类型：顺序索引与散列索引。
• 应从以下几个角度考察一个索引技术：能有效支持的访问类型；访问时间；插入时间；删除时间；空间开销。
• 用于在文件中查找记录的属性或属性集称为搜索码（search key）。
• --------顺序索引--------
• 如果包含记录的文件按照某个搜索码指定的顺序排序，那么该搜索码对应的索引称为聚集索引（或称为主索引 ）。注意这个搜索码并不一定必须是主码，尽管常常是主码。
• 搜索码指定的顺序与文件中记录的物理顺序不同的索引称为非聚集索引（或辅助索引）。
• 索引项或索引记录由一个搜索码值和指向具有该搜素码值的一条或多条记录的指针构成。
• 顺序索引包括稠密索引和稀疏索引。
• 在稠密索引中，文件中的每个搜索码值都有一个索引项。
• 在稀疏索引中，只为搜索码的某些值建立索引项。只有当关系按搜索码顺序排列存储时才能使用稀疏索引。也就是说，只有当索引是聚焦索引时才能使用稀疏索引。这很好理解，只有是有序的才能只用一部分搜索码来定位，相当于为一系列连续区间的开始建立索引。
• 如果索引本身很大（比如超出了内存大小很多），我们可以建立索引的索引来加速查找索引的过程。而索引本身是有序的，可以采用稀疏索引。
• 利用多级索引与二分查找，可以有效减少I/O操作。
• 辅助索引必须是稠密索引。
• 辅助索引能够提高使用聚集索引搜索码以外的码的查询性能。但是，辅助索引显著增加了数据库的更新开销。
• B+树是很常用的一个索引结构。但实际上属于数据结构的内容，所以和B+树相关的内容这里就不列出来了。（其实B+树也就是多级索引嘛。）通常可以把一个block作为一个节点，由于B+树又胖又矮，查询的时候不用访问几个block的。
• --------散列索引--------
• 顺序文件结构的一个缺点是我们必须访问索引结构来定位数据，或者必须使用二分法搜索，这将导致过多的I/O操作。基于散列技术的文件组织使我们能够避免访问索引结果。
• 散列索引比较简单，就是在搜索码上进行hash，然后定位到存储索引项的地方，再根据索引项找到记录。
• hash涉及到一个问题是hash桶数目的选择，选太小，很容易不够用；选太大，会造成空间的浪费。因而，有很多动态散列技术，允许散列函数动态改变，以适应数据库增大或缩小的需要。
• 可扩充散列是一种动态散列技术。核心思想就是一开始不把所有桶建立出来，按需建桶。hash的结果是一个b位的二进制数，一开始并不使用b位，而只使用i (< b)位，然后随着数据库越来越大，再使用越来越多的位，也就会建越来越多的桶。比如一开始用最高两位，可以定位4个桶（00，01，10，11）。后来数据变多，用最高三位，这样每个桶会分裂成两个桶，就成了八个桶。数据变少也可以把桶合并。当前时刻用几位是由一个桶地址表来维护的，他会把hash值映射到桶（所以这里其实增加了一次查询，会降低一些性能）。
• 使用顺序索引还是散列 索引要视具体情况而定。比如，很多查询是key=value这种，散列索引可能要好一些；而如果很多查询时key>=value or key<=value这种，可能顺序索引会合适一些。

第 12 章 查询处理

• 查询处理的步骤图：
  
• 加了如何执行注释的关系代数运算称为计算原语。用于执行一个查询的计算原语操作序列称为查询执行计划（或查询计算计划）。
• 查询执行引擎接受一个查询执行计划，执行该计划并把结果返回给查询。
• 对于一个查询，查询优化的第一个步是要能估计每个操作的代价。
• 文中以磁盘磁盘存取代价来度量查询执行计划的代价。因为磁盘通常最慢。
• 文中给出了对各个操作的分析过程，比较细节，这里就不一一列出了，具体内容参照原文。

第 13 章 查询优化

• 查询执行计划的产生有三步：（1）产生逻辑上与给定表达式等价的表达式；（2）对所产生的表达式以不同的方式做注释，产生不同的查询计划；（3）估计每个执行计划的代价，选择估计代价最小的一个。
• 13.2节罗列了很多的等价表达式，其可用于上述步骤（1）。
• 13.3节介绍了如何估计表达式的代价大小。估计的过程需要依赖于统计数据。
• 在优化的过程中，对于复杂的查询，搜索整个可能的计划空间代价太高，因而许多优化器采用启发式方法来降低查询优化的代价。

第 14 章 事务

• 事务：构成单一逻辑工作单元的操作集合。
• 原子性：属于一个事务的全部操作要么全部执行，要么全部不执行。
• 隔离性：确保事务正常执行而不被来自并发执行的数据库语句所干扰。
• 持久性：事务的操作一旦被提交，他对数据库造成的影响就是永久存在的，即使系统发生故障。
• 一致性：如果一个事务作为原子从一个一致的数据库状态开始独立的运行，则事务结束时数据库也必须再次是一致的。
• 确保单个事务的一致性是编写该事务的应用程序员的责任（如确保转账前后用户A、B金额总和不变）。很多业务层面的一致性约束是数据库没法理解的，所以需要依靠程序员。而一些预先定义的约束，比如用户的余额不能少于0等，是可以通过数据库自动检测的。检测不通过事务就会失败。关于一致性的理解，可以参照知乎上关于一致性的讨论。
• 原子性，隔离性，一致性都是由数据库保证的，从而减轻了开发人员的负担。
• 事务的隔离性确保事务并发执行后的系统状态与这些事务以某种次序一个接一个地执行后的状态是等价的。
• 可串行化调度：当多个事务并发执行时，调度应该在某种意义上等价于一个串行调度。这种调度就称为可串行化调度。
• 假设一个调度中存在两条连续的指令I和J，且I和J是不同事务在同一数据项上的操作，并且其中至少有一个是写操作时，I和J是冲突的。
• 如果调度S可以通过一系列非冲突指令交换转换成S’，则称S和S’是冲突等价的。
• 若一个调度S与一个串行调度冲突等价，则称调度S是冲突可串行化的。
• 可以通过构建图的形式来判断一个调度是否是冲突可串行化的。具体方法见书364页。
• 有可能存在两个调度，它们产生相同的结果，但他们不是冲突等价的。
• 可恢复调度应满足：对于每对事务T(i)和 T(j)，如果T(j)读取了之前由T(i)所写的数据项，则T(i)先于T(j)提交。
• 无级联调度应满足：对于每对事务T(i)和T(j)，如果T(j)读取了先前由T(i)所写的数据项，则T(i)必须在T(j)这一读操作前提交。
• SQL标准规定的四种隔离级别：可串行化；可重复读；已提交读；未提交读。强度逐渐减弱。

第 15 章 并发控制

• 待续…