数据库系统概论

普洱有点咸

于 2023-10-16 11:01:50 发布

阅读量446

点赞数

文章标签：数据库

本文链接：https://blog.csdn.net/zyx1234321/article/details/133854151

版权

一、数据库绪论

数据库的四个概念

数据（Data）：数据是数据库中存储的基本对象，它是描述事物的符号记录。
数据库（Database）：数据库是长期储存在计算机内、有组织的、可共享的大量数据的集合。
数据库管理系统（DBMS）：数据库管理系统是位于用户与操作系统之间的一层数据管理软件，它是一个大型复杂的软件系统，它主要用于科学地组织和存储数据、高效地获取和维护数据。
数据库系统（DBS）：数据库系统主要是由数据库、数据库管理系统（及其开发工具）、数据库管理员以及应用程序所构成的一套人机系统。

信息世界中的基本概念

实体（Entity）：客观存在并可相互区别的事物称为实体。
属性（Attribute）：实体所具有的某一特性称为属性。一个实体可以由若干个属性来刻画。例如学生实体可以由学号、姓名、性别、出生年份、系、入学时间等属性组成。（94002268，张山，男，1976，计算机系，1994）这些属性组合起来表征了一个学生。
码（Key）：唯一标识实体的属性集称为码。例如学号是学生实体的码。
域（Domain）：属性的取值范围称为该属性的域。例如，学号的域为8位整数，姓名的域为字符串集合，年龄的域为小于38的整数，性别的域为（男，女）。
实体型（Entity Type）：具有相同属性的实体必然具有共同的特征和性质。用实体名及其属性名集合来抽象和刻画同类实体，称为实体型。例如，学生（学号，姓名，性别，出生年份，系，入学时间）就是一个实体型。
实体集（Entity Set）：同型实体的集合称为实体集。例如，全体学生就是一个实体集。
联系（Relationship）：在现实世界中，事物内部以及事物之间是有联系的，这些联系在信息世界中反映为实体（型）内部的联系和实体（型）之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系。实体之间的联系通常是指不同实体集之间的联系。

两个实体型之间的联系

两个实体型之间的联系可以分为三类：

一对一联系（1 : 1）

如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1 : 1。例如，学校里面，一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。

一对多联系（1 : n）

如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1 : n。例如，一个班级中有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。

多对多联系（m : n）

如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m : n。

常见的数据模型

层次模型（Hierarchical Model）
网状模型（Network Model）
关系模型（Relational Model)）
面向对象数据模型（Object Oriented Data Model）
对象关系数据模型（Object Relational Data Model）
半结构化数据模型（Semistruture Data Model）

数据库系统结构

从数据库应用开发人员角度看，数据库系统通常采用三级模式结构，是数据库系统内部的系统结构。
从数据库最终用户角度看，数据库系统的结构分为：
- 单用户结构
- 主从式结构
- 分布式结构
- 客户-服务器结构
- 浏览器-应用服务器结构
- 数据库服务器多层结构

数据库系统的组成

数据库
数据库管理系统（及其开发工具）
数据库管理员
应用程序

数据库管理员职责

决定数据库中的信息内容和结构。
决定数据库的存储结构和存取策略。
定义数据的安全性要求和完整性约束条件。
监控数据库的使用和运行。
数据库的改进和重组。

二、关系型数据库

域（Domain）： 域是一组具有相同数据类型的值的集合。

笛卡尔积（Cartesian Product）： 给定一组域D1，D2，…，Dn，允许其中某些域是相同的。D1，D2，…，Dn的笛卡尔积为：
D1×D2×…×Dn ＝｛（d1，d2，…，dn）｜di∈Di，i＝1，2，…，n｝，笛卡尔积是所有域的所有取值的一个组合，它不能重复。

元组（Tuple）：笛卡尔积中每一个元素（d1，d2，…，dn）叫作一个n元组（n-tuple）或简称元组。
分量（Component）：笛卡尔积中每一个元素（d1，d2，…，dn）中的每一个值di叫作一个分量。
基数（Cardinal number）：若Di（i＝1，2，…，n）为有限集，其基数为mi（i＝1，2，…，n），则D1×D2×…×Dn的基数M为：

关系（Relation）： D1×D2×…×Dn的子集叫作在域D1，D2，…，Dn上的关系，表示为R（D1，D2，…，Dn），其中，R为关系名，n为关系的目或度（Degree）。

什么是关系模式？

关系模式是对关系的描述。如元组集合的结构，完整性约束条件。

关系操作

常用关系操作：

查询操作：选择、投影、连接、除、并、差、交、笛卡尔积（选择、投影、并、差、笛卡尔基是5种基本操作，交、连接、除，可以用5种基本运算来表达，引进它们并不增加语言的能力，但可以简化表达）
数据更新：插入、删除、修改

三、SQL语言

SQL的功能

SQL的结构

SQL支持关系数据库三级模式结构：

SQL的数据类型

四、数据库安全性

不安全的因素

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

用户身份鉴别

静态口令鉴别
动态口令鉴别
生物特征鉴别
智能卡鉴别

存取控制机制

常用存取控制方法：

自主存取控制（Discretionary Access Control ，简称DAC）
强制存取控制（Mandatory Access Control，简称 MAC）

权限授权回收

权限授权

语法格式：

GRANT < 权限 > [,< 权限 > ] ...
ON < 对象类型 > < 对象名 > [,< 对象类型 > < 对象名 > ] ...
TO < 用户 > [,< 用户 > ] ...
[ WITH GRANT OPTION ] ;

WITH GRANT OPTION子句：指定：可以再授予，没有指定：不能传播。

权限回收

语法格式：

REVOKE < 权限 > [, < 权限 > ] ...
ON < 对象类型 > < 对象名 > [,< 对象类型 > < 对象名 > ] ... 
FROM < 用户 > [,< 用户 > ] ... [ CASCADE | RESTRICT ] ;

五、数据库完整性

1、实体完整性

关系模型的实体完整性定义：CREATE TABLE中用PRIMARY KEY定义那些列为主码。

单属性构成的码有两种说明方法
- 定义为列级约束条件
- 定义为表级约束条件
多属性构成的码有一种说明方法
- 定义为表级约束条件

2、参照完整性

关系模型的参照完整性定义：在CREATE TABLE中用FOREIGN KEY定义哪些列为外码。

3、用户定义的完整性

用户定义的完整性是：针对某一具体应用的数据必须满足的语义要求。

关系数据库管理系统提供了定义和检验用户定义完整性的机制，不必由应用程序承担。

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

列值非空（NOT NULL）
列值唯一（UNIQUE）
检查列值是否满足一个条件表达式（CHECK）

4、触发器

触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程。触发器保存在数据库服务器中，任何用户对表的增、删、改操作均由服务器自动激活相应的触发器，触发器可以实施更为复杂的检查和操作，具有更精细和更强大的数据控制能力。

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

定义触发器
语法格式：

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

注意：不同的RDBMS产品触发器语法各不相同。表的拥有者才可以在表上创建触发器。

六、关系数据库理论

1、依赖

1.1、函数依赖

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

1.2、平凡函数依赖

专业定义：X→Y，但Y⊆X 则称X→Y是平凡的函数依赖。

1.3、非平凡函数依赖

专业定义：X→Y，但Y⊈X则称X→Y是非平凡的函数依赖。

1.4、完全函数依赖

专业定义：

1.5、部分函数依赖

专业定义：

1.6、传递函数依赖

专业定义：

2、码

3、范式

3.1、1NF

作为二维表，关系要符合一个最基本的条件：每个分量必须是不可分开的数据项。满足了这个条件的关系模式就属于第一范式（1NF）。

3.2、2NF

若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于任何一个候选码，则R∈2NF。

3.3、3NF

3.4、BCBF

BCNF（Boyce Codd Normal Form）由Boyce和Codd提出，比3NF更进了一步。通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。设关系模式R<U,F>∈1NF，若X →Y且Y ∉ X时，X必含有码，则R<U,F>∈BCNF。换言之，在关系模式R<U,F>中，如果每一个决定属性集都包含候选码，则R∈BCNF。

七、数据库恢复技术

1、事务

1.1、事务的概念

所谓事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做,是一个不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。事务和程序是两个概念。一般地讲，一个程序中包含多个事务。

1.2、事务的语句

在SQL语言中，定义事务的语句有三条：

begin transaction （或者 BEGIN TRANSACTION）
commit （或者 COMMIT）
rollback （或者 ROLLBACK）

事务通常是以BEGIN TRANSACTION开始，以COMMIT或ROLLBACK结束。COMMIT表示提交，即提交事务的所有操作。

1.3、事务的特性

事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这个四个特性也简称为ACID特性。

原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，（第一个操作是从账号A中减去一万元，第二个操作是向账号B中加入一万元。这两个操作要么全做，要么全不做）。
隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
持续性：持续性也称永久性（Permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

注：事务是恢复和并发控制的基本单位。

事务ACID特性可能遭到破坏的因素有：

多个事务并行运行时，不同事务的操作交叉执行
事务在运行过程中被强行停止

2、数据库恢复

尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。

3、故障的种类

事务内部的故障：事务内部的故障有的是可以通过事务程序本身发现的，有的是非预期的，不能由事务程序处理的。事务内部更多的故障是非预期的，是不能由应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制等。以后，事务故障仅指这类非预期的故障。事务故障意味着事务没有达到预期的终点（COMMIT或者显式的ROLLBACK），因此，数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚（ROLLBACK）该事务，即撤销该事务已经作出的任何对数据库的修改，使得该事务好像根本没有启动一样。
系统故障（俗称软故障）：系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误、突然停电等。这类故障影响正在运行的所有事务，但不破坏数据库。这时主存内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。
介质故障（俗称硬故障）：系统故障常称为软故障（Soft Crash），介质故障称为硬故障（Hard Crash）。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。

4、恢复的机制

恢复机制涉及的两个关键问题是：

第一，如何建立冗余数据；（最常用的技术是数据转储和登录日志文件）
第二，如何利用这些冗余数据实施数据库恢复。

5、恢复的策略

当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。

不同故障其恢复策略和方法也不一样。

八、数据库并发控制

1、并发控制概述

事务是并发控制的基本单位，并发控制机制的任务，对并发操作进行正确调度，保证事务的隔离性，保证数据库的一致性，并发操作带来的数据不一致性会导致以下问题：

丢失修改（Lost Update）
不可重复读（Non-repeatable Read）
读“脏”数据（Dirty Read）

为了充分利用系统资源发挥数据库共享资源的特点，应该允许多个事务并行地执行。

在单处理机系统中，事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行。这种并行执行方式称为交叉并发方式（Interleaved Concurrency）。虽然单处理机系统中的并行事务并没有真正地并行运行，但是减少了处理机的空闲时间，提高了系统的效率。

在多处理机系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行。这种并行执行方式称为同时并发方式（Simultaneous Concurrency）。本章讨论的数据库系统并发控制技术是以单处理机系统为基础的。这些理论可以推广到多处理机的情况。

当多个用户并发地存取数据库时就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会存取和存储不正确的数据，破坏数据库的一致性。所以数据库管理系统必须提供并发控制机制。并发控制机制是衡量一个数据库管理系统性能的重要标志之一。

2、封锁概述

封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。在事务T释放它的锁之前，其他的事务不能更新此数据对象。
确切的控制由封锁的类型决定。基本的封锁类型有两种: 排它锁(Exclusive Locks，简称X锁) 和共享锁(Share Locks，简称S锁)。

1.　排它锁又称为写锁（X）。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。
2.　共享锁又称为读锁（S）。若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

3、封锁协议

在运用X锁和S锁这两种基本封锁，对数据对象加锁时，还需要约定一些规则，例如何时申请X锁或S锁、持锁时间、何时释放等。称这些规则为封锁协议（Locking Protocol）。

一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。一级封锁协议可防止丢失修改，并保证事务T是可恢复的。在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读"脏"数据。
二级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。二级封锁协议除防止了丢失修改，还可进一步防止读"脏"数据。在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。
三级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。三级封锁协议除防止了丢失修改和不读"脏"数据外，还进一步防止了不可重复读。

上述三级协议的主要区别在于什么操作需要申请封锁，以及何时释放锁(即持锁时间)。

4、活锁和死锁

和操作系统一样，封锁的方法可能引起活锁和死锁。
活锁 **：**如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求……T2有可能永远等待，这就是活锁的情形。避免活锁的简单方法是采用先来先服务的策略
**死锁：**如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。

死锁的预防：

一次封锁法：要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行，一次封锁法虽然可以有效地防止死锁的发生，但也存在问题：
- 扩大了封锁的范围，从而降低了系统的并发度。
- 数据库中数据是不断变化的，原来不要求封锁的数据，在执行过程中可能会变成封锁对象，所以很难事先精确地确定每个事务所要封锁的数据对象，为此只能扩大封锁范围，将事务在执行过程中可能要封锁的数据对象全部加锁，这就进一步降低了并发度。
顺序封锁法：顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。例如在B树结构的索引中，可规定封锁的顺序必须是从根结点开始，然后是下一级的子女结点，逐级封锁。顺序封锁法可以有效地防止死锁，但也同样存在问题：
- 数据库系统中封锁的数据对象极多，并且随数据的插入、删除等操作而不断地变化，要维护这样的资源的封锁顺序非常困难，成本很高。
- 事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。

死锁的诊断：

超时法：如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。
等待图法：事务等待图是一个有向图G=(T，U)。T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2，则T1，T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地（比如每隔1 min）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。

5、并发调度的可串行性

多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行它们时的结果相同，我们称这种调度策略为可串行化（Serializable）的调度。可串行性（Serializability）是并发事务正确性的准则。按这个准则规定，一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度。为了保证并发操作的正确性，DBMS的并发控制机制必须提供一定的手段来保证调度是可串行化的。从理论上讲，在某一事务执行时禁止其他事务执行的调度策略一定是可串行化的调度，这也是最简单的调度策略，但这种方法实际上是不可取的，这使用户不能充分共享数据库资源。目前DBMS普遍采用封锁方法实现并发操作调度的可串行性，从而保证调度的正确性。两段锁（Two-Phase Locking，简称2PL）协议就是保证并发调度可串行性的封锁协议。除此之外还有其他一些方法，如时标方法、乐观方法等来保证调度的正确性。

参考资料：https://blog.csdn.net/qq_39183034/article/details/122771126

https://blog.csdn.net/qq_38490457/article/details/110132192