数据库知识点总结

最新推荐文章于 2024-07-28 19:10:22 发布

jasony_sam

最新推荐文章于 2024-07-28 19:10:22 发布

阅读量547

点赞数 12

文章标签：数据库

本文链接：https://blog.csdn.net/jasony_sam/article/details/139890162

版权

数据库知识点总结

第一章绪论

1.1 数据库系统概述

四个基本概念

数据：数据库存储的基本单位，是描述事物的符号记录，数据与其语义是不可分的

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

数据库管理系统：数据管理软件，有以下主要功能：

数据定义功能：定义数据对象
数据操纵功能：实现对数据库的基本操作（查询，插入，删除和修改）
数据库的运行管理：保证数据的安全性、完整性、多用户对数据的并发使用、发生故障后的系统恢复
数据库的建立和维护功能

数据库系统：在计算机系统中引入数据库后的系统，由数据库、数据库管理系统(及其开发工具)、应用系统、数据库管理员和用户构成

数据管理技术：经历了人工管理，文件系统，数据库系统三个阶段

数据库系统的特点：

数据的结构化
数据的共享性高，冗余度低，易扩充
数据的独立性高
由DBMS统一管理和控制

1.2 数据模型

数据模型就是现实世界的模拟

数据模型的分类：主要包括网状模型、层次模型、关系模型等

客观对象->概念模型->数据模型

数据模型的组成要素：

数据结构：所研究对象类型的集合，对系统静态特性的描述
数据操作：对数据库中各种对象(型)的实例(值)允许执行的操作及有关的操作规则对系统动态特性的描述
数据的约束条件组完整性规则的集合

信息：在数据库技术中，反映现实世界中事物的存在方式或运动状态

概念模型：用于信息世界的建模

信息世界中的基本概念：

实体：客观存在并可相互区别的事物称为实体
属性：实体的特性
码：唯一标识实体的属性集
域：属性的取值范围
联系：现实世界中事物内部以及事物之间的联系在信息世界中反映为实体内部的联系和实体之间的联系

概念模型的表示方法：实体－联系方法(E-R方法)，也称E-R模型

E-R模型的组成要素：

实体型：用矩形表示，矩形框内写明实体名；实体的属性用椭圆形表示，以无向边将其与相应的实体连接起来
联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型(1:1、1:n、m:n)，联系的属性也要用无向边与该联系连接。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

最常用数据模型：

层次模型
网状模型
关系模型
面向对象模型

其中层次模型和网状模型统称为非关系模型，它们的数据结构是以基本层次联系为基本单位，基本层次联系是两个记录及其一对多的联系；关系模型的数据结构是表；面向对象模型的数据结构是对象

层次模型

数据结构：有且只有一个结点没有双亲结点，这个结点称为根结点；根以外的其它结点有且只有一个双亲结点
多对多联系在层次模型中的表示：利用冗余结点或虚拟结点将多对多联系分解成一对多联系
数据操纵与完整性约束：数据操纵包括查询、插入、删除、更新；完整性约束包括无相应的双亲结点值就不能插入子女结点值；如果删除双亲结点值，则相应的子女结点值也被同时删除；更新操作时，应更新所有相应记录，以保证数据的一致性
存储结构：邻接法（物理相邻），链接法（逻辑相邻）
优点：
1. 模型简单易理解
2. 性能优于关系模型，不低于网状模型
3. 提供了良好的完整性支持
缺点：
1. 多对多联系表示不自然。
2. 对插入和删除操作的限制多。
3. 查询子女结点必须通过双亲结点。
4. 层次命令趋于程序化。

网状模型

数据结构：允许一个以上的结点无双亲，一个结点可以有多于一个的双亲
数据操纵与完整性约束：数据操纵包括查询、插入、删除、更新，但网状模型对数据操纵加了一些限制，提供了一定的完整性约束
支持记录码的概念，码是唯一标识记录的数据项的集合
支持双亲记录和子女记录之间某些约束条件，如允许插入尚未确定双亲结点值的子女结点值，允许只删除双亲结点值
存储结构：使用单向链接、双向链接、环状链接、向首链接等链接法实现记录之间的联系
优点：
1. 更直接地描述现实世界
2. 具有良好性能
缺点：
1. 结构复杂，不利于用户掌握
2. 加重了编程的负担

关系模型

数据结构：逻辑结构是一张二维表，由行和列组成
术语：
1. 关系：一个关系对应一个二维表
2. 元组：一行为一个元组
3. 属性：一列为一个属性
4. 主码：某个属性组，可以唯一确定一个元组
5. 域：属性的取值范围
6. 分量：元组中的一个变量值
7. 关系模式：一般形式为关系名(属性1,属性2,…,属性n)。如学生(学号,姓名,年龄,性别,系别,年级)。相当于概念模型中的实体型
关系模型中实体及实体间的联系都是用关系来表示的
关系必须是规范化的，满足一定的规范条件。最基本的规范条件是关系的每一个分量必须是一个不可分的数据项

反例：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

数据操纵与完整性约束：数据操纵包括查询、插入、删除、更新，这些操作是集合操作，操作对象和操作结果都是关系，即若干元组的集合。完整性约束有实体完整性、参照完整性和用户定义的完整性三大类。
存储结构：表以文件形式存储
优点：建立在严格的数学概念的基础上；概念单一，实体和联系都用关系表示，数据操作结果为关系；存取路径对用户透明
缺点：存取路径对用户透明导致查询效率往往不如非关系数据模型。为提高性能，必须对用户的查询请求进行优化，增加了开发数据库管理系统的难度

1.3 数据库系统结构

1.3.1 三级模式

数据库系统模式的概念

型：对某一类数据的结构和属性的说明
值：对型的具体赋值

模式：数据库系统中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图，综合了所有用户的需求，一个数据库只有一个模式。模式是数据库系统模式结构的中间层，与数据的物理存储细节和硬件环境无关，与具体的应用程序、开发工具及高级程序设计语言无关。
外模式：也称子模式或用户模式，是数据库用户使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。外模式通常是模式的子集
内模式：也称存储模式，是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式，一个数据库只有一个内模式

1.3.2 二级映象

三级模式是对数据的三个抽象级别，二级映象是在DBMS内部实现这三个抽象层次的联系和转换

外模式／模式映象：定义了外模式与模式之间的对应关系，每一个外模式都对应一个外模式／模式映象，该映象定义通常包含在各自外模式的描述中

外模式／模式映象保证了数据的逻辑独立性
模式／内模式映象：定义了数据全局逻辑结构与存储结构之间的对应关系，如说明逻辑记录和字段在内部是如何表示的。数据库中模式／内模式映象是唯一的，该映象定义通常包含在模式描述中

模式／内模式映象保证了数据的物理独立性

1.4 数据库系统的组成

硬件平台及数据库：足够大的内存存放操作系统、DBMS的核心模块、数据缓冲区和应用程序，足够大的外存存放数据库及其备份

软件：包括DBMS、操作系统、与数据库接口的高级语言及其编译系统、以DBMS为核心的应用开发工具、为特定应用环境开发的数据库应用系统

人员：

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

系统分析员：负责应用系统的需求分析和规范说明、与用户及DBA协商，确定系统硬软件配置、参与数据库系统的概要设计

数据库设计人员：参加用户需求调查和系统分析、确定数据库中的数据、设计数据库各级模式

应用程序员：设计和编写应用系统程序模块、进行调试和安装

用户：

偶然用户：企业高中级管理人员

简单用户

复杂用户：工程师等

1.5 数据库技术的研究领域

数据库管理系统软件的研制：包括研制DBMS本身及以DBMS为核心的一组相互联系的软件系统(包括工具软件和中间件)。

数据库设计：包括数据库设计方法、设计工具、设计理论、数据模型和数据建模。

数据库理论：集中于关系的规范化理论、关系数据理论等

第二章关系数据库

2.1 关系模型概述

关系数据库系统是支持关系模型的数据库系统。关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成

单一的数据结构：实体以及实体间的各种联系均用关系来表示，从用户角度，关系模型中数据的逻辑结构是一张二维表
关系操作：包括选择、投影、连接、除、并、交、差等查询操作和插入、删除、修改等更新操作两大类

关系操作的特点是集合操作方式

关系数据语言分为关系代数语言(用对关系的运算来表达查询)和关系演算语言(用谓词来表达查询)
关系的三类完整性约束：
1. 实体完整性：由关系系统自动支持。
2. 参照完整性：早期系统不支持，目前关系系统能自动支持。
3. 用户定义的完整性：反映应用领域需要遵循的约束条件，体现了具体领域中的语义约束，用户定义后由系统支持
  
  其中前两者是关系模型必须满足的完整性约束性条件

2.2 关系数据结构及形式化定义

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

笛卡尔积：给定一组域D1,D2,…,Dn，这些域可以相同，D1,D2,…,Dn的笛卡尔积为：D1×D2×…×Dn=｛(d1,d2,…,dn)｜di?Di,i=1,2,…,n

元组：笛卡尔积中每一个元素(d1,d2,…,dn)

分量：笛卡尔积元素(d1,d2,…,dn)中的每个值 $d_i$

基数：若 $D_i(i=1,2,...,n)$ 为有限集，其基数为 $m_i$ ，则 $D_1\times D_2\times ...\times D_n$ 的基数M为：
$M=\prod^n_{i=1}m_i$
关系：D1×D2×…×Dn的子集称为域D1,D2,…,Dn上的关系，表示为R(D1,D2,…,Dn)，其中R为关系名，n是关系的目或度(Degree)。当n=1时为单元关系，n=2时为二元关系。关系中的每个元素是关系中的元组，通常用t表示。

其他术语：

属性：关系中不同列可以对应相同的域，为了区分，必须对每列起一个名字，称为属性，n目关系必有n个属性

候选码：若关系中某一属性组的值能唯一地标识一个元组，则称该属性组为候选码。若候选码包含了关系模式的所有属性，则称该候选码为全码(All-key)

主码：若一个关系有多个候选码，则选定其中的一个就称为主码，主码的诸属性称为主属性，不包含在任何侯选码中的属性称为非主属性。在任一候选码中的属性都是主属性

三类关系：

基本关系
查询表
视图表（虚表）

关系模式：是对关系的描述

关系模式是型，而关系是值
定义关系模式：
1. 元组集合的结构包括属性构成、属性来自的域、属性与域之间的映象关系
2. 元组语义以及完整性约束条件
3. 属性间的数据依赖关系集合
关系模式的形式化表示：R(U,D,dom,F)

R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间的数据依赖关系集合

dom(Postgraduate-Person)=Person
关系模式通常可以简记为R (U)或R (A1,A2,…,An)

关系数据库：在一个给定的应用领域中，所有实体及实体之间联系的关系的集合构成一个关系数据库

关系数据库的型：称为关系数据库模式，是对关系数据库的描述，包括若干域的定义及在这些域上定义的若干关系模式。
关系数据库的值：是这些关系模式在某一时刻对应的关系的集合，通常简称为关系数据库。

2.3 关系的完整性

关系的完整性规则：是对关系的某种约束条件。关系模型中包括实体完整性、参照完整性和用户定义的完整性三类完整性约束

2.3.1 实体完整性

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

因为现实中的实体及其联系都是可以区分的，具有唯一性标识

2.3.2 参照完整性

关系间的引用：在关系模型中实体及实体间的联系都是用关系来描述的，因此可能存在着关系与关系间的引用

外码：设F是关系R的一个或一组属性，但不是关系R的码。如果F与关系S的主码Ks相对应，则称F是关系R的外码，关系R称为参照关系，关系S称为被参照关系或目标关系。

关系R和S不一定是不同的关系

参照完整性规则：若属性(或属性组)F是基本关系R的外码，它与基本关系S的主码Ks相对应，则对于R中每个元组在F上的值必须：或者取空值(F的每个属性值均为空值)，或者等于S中某个元组的主码值

2.3.3 用户定义的完整性

是针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求。关系模型应提供定义和检验这类完整性的机制，以便用统一的系统的方法处理它们，而不要由应用程序承担这一功能

如：关系课程(课程号,课程名,学分)中课程名必须取唯一值，课程名不能取空值，学分只能取值{1,2,3,4}

2.4 关系代数

概述

关系代数是一种抽象的查询语言，用对关系的运算来表达查询。运算对象、运算结果和运算符是关系代数运算的三大要素。

常用的关系运算符：

集合运算符：将关系看成元组的集合，运算是从关系的“水平”方向即行的角度来进行，有并、差、交、广义笛卡尔积四种运算符
专门的关系运算符：不仅涉及行而且涉及列，有选择、投影、连接、除四种运算符
算术比较符：辅助专门的关系运算符进行操作，有等于、不等于、大于、小于、不大于、不小于六种运算符
逻辑运算符：辅助专门的关系运算符进行操作，有逻辑与、非、或三种

传统的集合运算

专门的关系运算

常用符号

选择：是从行的角度进行的运算，在关系R中选择满足给定条件的诸元组，记为 $σ_F(R) = \{t|t\in R∧F(t)= '真'\}$ ，其中F是选择运算符，是一个逻辑表达式

投影：从R中选择出若干属性列组成新的关系，记为 $π_A(R) = \{ t[A] | t \in R \}$ ，其中A是R中的属性列。投影操作主要是从列的角度进行运算，但投影之后不仅取消了原关系中的某些列，而且还可能取消某些元组(避免重复行)

例如

连接：

例子：

除：

例：

2.5 关系演算

关系演算是以数理逻辑中的谓词演算为基础。按谓词变元不同分类，关系演算可分为元组关系演算和域关系演算

元组关系演算

检索操作GET

GET 工作空间名 (定额)(表达式1) :(操作条件)[排序表达式2]
其中：定额规定检索的元组个数；表达式1指定语句的操作对象，它可以是关系名或属性名；操作条件将操作结果限定在满足条件的元组中；表达式2指定排序方式

简单检索

查询所有被选修的课程号码

GET W (SC.Cno)
限定检索

查询信息系(IS)中年龄小于20岁的学生的学号和年龄

GET W (Student.Sno，Student.Sage)
:Student.Sdept='IS’∧ Student.Sage<20
排序检索

查询计算机系(CS)学生的学号、年龄，结果按年龄降序排序

GET W (Student.Sno，Student.Sage)
:Student.Sdept='CS‘ DOWN Student.Sage
定额检索

查询信息系年龄最大的三个学生的学号及年龄，按年龄降序

GET W (3) (Student.Sno，Student.Sage)
:Student.Sdept=‘IS’ DOWN Student.Sage
用元组变量的检索

查询信息系学生的名字(一个关系可以设多个元组变量)

RANGE Student X
GET W (Student.Sname):X.Sdept=‘IS’
有多个关系的表达式的检索

查询成绩为90分以上的学生名字与课程名字

RANGE SC SCX
GET W (Student.Sname，Course.Cname):\any SCX (SCX.Grade≥90
∧SCX.Sno=Student.Sno∧Course.Cno=SCX.Cno)
查询选修了全部课程的学生姓名

RANGE Course CX, SC SCX GET W (Student.Sname)
CX?SCX (SCX.Sno=Student.Sno ∧ SCX.Cno= CX.Cno)
用蕴含的检索

查询最少选修了95002学生所选课程的学生学号

RANGE Couse CX, SC SCX,SC SCY GET W (Student.Sno)
:CX(\any SCX (SCX.Sno='95002’∧SCX.Cno=CX.Cno)to
\any SCY(SCY.Sno=Student.Sno∧SCY.Cno= CX.Cno))
集函数

查询信息系学生的平均年龄

GET W (AVG(Student.Sage): Student.Sdept='IS’)

更新操作

修改操作
插入操作
删除操作

域关系运算

QBE

第三章关系数据库规划和设计

3.3.3 并发控制

3.3.3.1 并发控制概述

并发操作：多个用户同时对某个数据库对象进行的操作。若对并发操作不加控制就可能存取不正确数据，破坏数据库的一致性。所以DBMS必须提供并发控制机制，对并发操作进行正确调度、保证事务的隔离性、保证数据库的一致性，它是衡量一个DBMS性能的重要标志之一

并发操作可能引起的三类数据不一致问题：

丢失修改：指两个事务T1和T2从数据库中读入同一数据并修改，T2的提交结果破坏了T1提交的结果，导致T1的修改被丢失
不可重复读：不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果
读“脏”数据：事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤消，这时事务1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据称为“脏”数据

3.3.3.2 封锁

封锁：任何事务T在对某数据操作之前，先向系统发出请求对其加锁。加锁后事务T就对该数据拥有了一定的控制权，在事务T释放锁之前其它事务不能更新该数据。

排它锁(X锁,写锁)：若事务T对数据A加X锁，则只允许T读取和修改A，其他事务不能再对A加任何锁，直到T释放A上的X锁。它保证了在T释放A上X锁之前其他事务不能再读取和修改A
共享锁(S锁,读锁)：若事务T对数据A加S锁，则事务T只可读A，但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。它保证了在T释放A上S锁之前其它事务可以读A，但不能修改A。

3.3.3.3 封锁协议

封锁协议：事务对数据封锁时，何时申请X锁或S锁、持锁时间、何时释放等有关封锁的规则。

一级封锁协议：事务T在修改数据A之前必须先对其加X锁，直到该事务结束才释放X锁。 (防丢失修改）

二级封锁协议：一级封锁协议加上事务T在读取数据A前必须先对其加S锁，读完后立即释放S锁（防丢失修改，防读“脏”数据）。

三级封锁协议：一级封锁协议加上事务T在读取数据A前必须先对其加S锁，直到该事务结束才释放S锁（防丢失修改，防读“脏”数据，防不可重复读）

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

3.3.3.4 活锁与死锁

活锁：某个事务永远处于等待封锁的状态

死锁：多个事务同时处于等待状态，每个事务都在等待其它事务释放锁使其能够继续执行，从而出现多个事务互相等待的僵局，每个事务永远不能结束

3.3.3.5 并发调度的可串行性

可串行化调度：若多个事务并发调度的结果与任一串行调度的结果相同，则该并发调度是可串行化调度，两段锁协议是保证并发调度可串行性的封锁协议

对于一个给定的并发调度，当且仅当它是可串行化的，才认为是正确的调度

3.3.3.6 两段锁协议（2PL）

事务在对任何数据进行读、写之前，首先要申请并获得该数据上的封锁。

在释放一个封锁之后，事务不再申请和获得任何其他封锁

两段的含义

扩展阶段：只获得锁，不释放锁。
收缩阶段：只释放锁，不获得锁。

遵守2PL协议是可串行化调度的充分条件，但不是必要条件

3.3.3.7 封锁的粒度

3.3.3.8 SQL Server的并发控制技术

3.3.4 数据库恢复

3.3.4.1 事务的概念

数据库系统中的数据是由DBMS统一管理和控制的，为了适应数据共享的环境，DBMS必须提供数据保护能力，以保证数据库中数据的安全可靠和正确有效。数据库保护包括数据库恢复、安全性、完整性和并发控制四大技术

事务：用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序。事务不同于程序，一个程序通常包含多个事务。事务是数据库恢复和并发控制的基本单位。

事务的开始与结束可以由用户显式控制，如果没有显式地定义事务，则由DBMS按缺省规定自动地划分事务。显式定义为：

Begin Transction
...
Commit

Begin Transction
...
RollBack
//RollBack为事务回滚，即告诉事务管理器事务执行时发生故障，所有已完成的操作必须全部撤销，滚回到事务开始的状态

事务的性质：事务具有ACID特性

原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做，要么全不做
一致性：事务的执行必须保证数据库从一个一致性状态转到另一个一致性状态
隔离性：一个事务的执行不能被其他事务干扰，并发执行的各个事务间应互相独立
持久性：事务一旦提交，它对数据库中数据的改变应是永久的

3.3.4.2 数据库恢复概述

事务故障：某个事务在运行过程中由于种种原因未运行至正常结束点就夭折了，造成数据库可能处于不正确状态

事务故障的原因：违反了某些完整性限制、输入数据有误、运算溢出、并行事务发生死锁等
事务故障的分类
1. 可预期的：应用程序可以发现的故障，如违反了某些完整性限制、输入数据有误等，可由应用程序处理。
2. 不可预期的：应用程序无法发现的故障，如运算溢出、发生死锁等，应用程序无法处理此类故障，由系统进行处理
事务故障的恢复：发生事务故障时夭折的事务可能已将对数据库的部分修改写回磁盘，恢复子系统一般采用回滚(RollBack)，强行撤销(UNDO)该事务对数据库的所有修改，使得这个事务象根本没有启动过一样

系统故(软故障)：指造成系统停止运转的任何事件，使得系统要重新启动。这类故障影响所有正在运行的事务，但不破坏整个数据库。这时内存数据丢失，所有运行事务都异常终止

系统故障的原因：特定类型的硬件错误(如CPU故障)、操作系统故障、DBMS代码错误、突然停电等。
系统故障的恢复：
1. 一方面，发生系统故障时，一些尚未完成的事务可能已将部分更新操作写回数据库，使数据库处于不正确状态，所以恢复子系统在系统重启时必须让所有非正常终止的事务回滚，强行撤销(UNDO)所有未完成事务。
2. 另一方面，发生系统故障时，有些已完成事务可能部分甚至全部留在缓冲区，尚未写回磁盘，系统故障使得这些事务对数据库的修改部分或全部丢失，数据库处于不一致状态，因此恢复子系统在系统重启时，还必须重做(REDO)所有已提交事务

介质故障(硬故障)：使存储在外存中的数据部分丢失或全部丢失。介质故障发生的可能性较小，但破坏性大，破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。

介质故障的原因：磁盘损坏、磁头碰撞、瞬时强磁场干扰等。
介质故障的恢复：装入介质故障前某个时刻的数据副本，重做自此时开始的所有成功事务，将这些事务已提交的结果重新记入数据库

3.3.4.3 恢复的实现技术

数据转储：指DBA将整个数据库复制到磁带或另一磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本

静态转储：系统中无运行事务时进行转储，即转储开始时数据库处于一致性状态，而转储期间不允许对数据库的任何存取、修改操作。优点是实现简单；缺点是转储必须等用户事务结束，新的事务必须等转储结束，降低了数据库的可用性
动态转储：转储期间允许对数据库进行存取或修改，即转储操作与用户事务可以并发进行。优点是不用等待正在运行的用户事务结束，不会影响新事务的运行；缺点是不能保证副本中的数据正确有效，如转储期间的某个时刻Tc系统将数据A=100转储，而在下一时刻Td某一事务将A改为200，转储结束后，后备副本上A的值已经过时

为此，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件，利用后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态
海量转储：转储全部数据。
增量转储：每次只转储自上一次转储后更新过的数据。
从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便。但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

登记日志文件(Logging)：日志文件(log)是用来记录事务对数据库更新操作的文件。

日志文件的格式：有以记录为单位的日志文件和以数据块为单位的日志文件两种格式。
日志文件的内容：每个事务的开始标记(BEGIN TRANSACTION)、结束标记(COMMIT或ROLLBACK)和每个更新操作均可作为日志文件中的一个日志记录 (log record)。
登记日志文件的原则：为保证数据库可恢复，登记日志文件时必须遵循两条原则
1. 登记的次序严格按照并行事务执行的时间次序。
2. 必须先写日志文件，后写数据库写日志文件操作

3.3.4.4 恢复策略

事务故障的恢复：事务故障指事务在运行至正常终止点前被中止，这时恢复子系统应利用日志文件撤消(UNDO)此事务已对数据库进行的修改。事务故障的恢复由系统自动完成，对用户是透明的

系统故障的恢复：系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新已写入数据库，二是一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库。因此恢复操作要UNDO故障发生时未完成的事务，REDO已完成的事务。系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

介质故障的恢复：发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障。恢复方法是重装数据，然后重做已完成的事务

3.3.4.5 具有检查点的恢复技术

具有检查点的恢复技术：在日志文件中增加检查点checkpoint记录 (记载了检查点时刻所有正在执行的事务清单和这些事务最近一个日志记录的地址)，增加一个重新开始文件(记载了各个检查点记录在日志中的地址)，并让恢复子系统在登录日志文件期间动态地维护日志

3.3.4.6 数据库镜像

根据DBA的要求，DBMS自动把整个数据库或关键数据复制到另一个磁盘上。当主数据库更新时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。出现介质故障时，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本；没有出现故障时，数据库镜像还可用于并发操作，即当一个用户对数据加排他锁修改数据时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁

3.3.4.7 SQL Server的恢复技术

第五章关系数据理论

5.1 概述

关系数据理论(关系规范化理论)是数据库逻辑设计的理论指南

规范化理论研究的是关系模式中各属性之间的数据依赖关系及其对关系模式性能的影响，探讨“好”的关系模式应该具备的性质，以及达到“好”的关系模式的设计算法

5.2 关系模式可能存在的问题

插入异常

删除异常

更新异常

数据冗余

5.3 数据依赖——函数依赖

定义：

函数依赖的分类

平凡的函数依赖与非平凡的函数依赖
完全函数依赖与部分函数依赖
传递函数依赖与直接函数依赖

函数依赖的逻辑蕴含

定义：

例：

函数依赖的公理系统

为了从一组函数依赖求得蕴含的函数依赖，为了确定一个关系模式的码，就需要一套推理规则

Armstrong公理系统：
三个有用的推理规则：

由函数依赖定义的码

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.4 范式及其规范化

定义：

范式是对关系的不同数据依赖程度的要求。各种不同的范式都是以对关系模式的属性间允许的数据依赖加以限制的形式表示的
若R(U，F)符合x范式的要求，则称R为x范式，记作： $R\in xNF$
通过模式分解将一个低级范式转换为若干个高级范式的过程称作规范化

1NF

定义：关系中每一分量不可再分。即不能以集合、序列等作为属性值

2NF

定义：若 $R\in 1NF$ ，且每个非主属性完全依赖于码，则称 $R\in 2NF$ .
即2NF就是不允许有非主属性对码的部分依赖。
若R中有非主属性对码的部分依赖，则 $R\notin2NF$ 。

消除非主属性对码的部分依赖—模式分解

改造：

非主属性有两种，一种完全依赖于码，一种部分依赖于码。将SDC分解为：
$SC(SNO,CNAME,G)\in 2NF\\ SDM(SNO,DEPT,MNAME)\in 2NF$
解决了部分插入异常和更新异常，删除异常还存在

3NF

定义：

消除非主属性对码的传递依赖

改造：

BCNF

定义：

多值依赖

定义：

性质：

多值依赖与函数依赖的区别

4NF

定义：

范式之间的关系

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.5 关系模式分解

结论：

第六章数据库设计

6.1 数据库设计概述

概念：数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统

6.1.1 数据库和信息系统

信息系统是提供信息、辅助人们对环境进行控制和决策的系统
数据库是信息系统的核心和基础。它把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的功能，使信息系统可方便、及时、准确地从数据库中获得所需的信息

数据库设计的特点

数据库建设是硬件、软件和干件的结合（技术与管理的界面称之为干件）
数据库设计过程是结构设计和行为设计的密切结合

数据库设计方法简述

手工试凑法
规范设计法
新奥尔良方法：将数据库设计分为需求分析、概念设计、逻辑设计和物理设计四个阶段
S.B.Yao方法

数据库设计的基本步骤

数据库设计的准备工作
数据库设计的过程：

数据库各级模式的形成过程

需求分析阶段：综合各个用户的应用需求
概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)
逻辑设计阶段：首先将E-R图转换成具体DBMS支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式
物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

6.2 需求分析

6.2.1 需求分析的任务

需求分析的任务：通过详细调查现实世界要处理的对象(组织、部门、企业等)，充分了解原系统的工作概况，明确用户的各种需求，在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计

6.2.2 需求分析的方法

需求分析的方法：调查用户的实际需求并进行初步分析，与用户达成共识，然后分析与表达这些需求

分析和表达用户需求的SA (Structured Analysis) 方法：自顶向下的结构化分析方法，从最上层系统组织机构入手，采用逐层分解的方式分析系统，并用数据流图和数据字典描述系统

根据调查分析，得到如下所示的系统高层抽象图：
分解处理功能和数据：将处理功能的具体内容分解为若干子功能，再将每个子功能继续分解，直到把系统的工作过程表达清楚为止；在处理功能逐步分解的同时，其所用的数据也要逐级分解，形成若干层次的数据流图，数据流图表达了数据和处理过程的关系；处理过程用判定表或判定树来描述，数据用数据字典来描述
将分析结果再次提交给用户，征得用户的认可

数据字典：是各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要结果。数据字典在数据库设计中占有很重要的地位

数据项
数据结构
数据流
数据存储
处理过程

6.3 概念结构设计

6.3.1 概念结构

概念结构：需求分析阶段描述的用户应用需求是现实世界的具体需求，将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。概念结构设计是整个数据库设计的关键

概念结构设计的特点：

能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求，是现实世界的一个真实模型。
易于理解，可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库设计成功的关键。
易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
易于向关系、网状、层次等各种数据模型转换。
描述概念模型的工具是E-R模型。

概念结构设计的方法：

设计概念结构的四类方法：
1. 自顶向下：先定义全局概念结构的框架，再逐步细化。
2. 自底向上：先定义各局部应用的概念结构，再将它们集成起来，得到全局概念结构。
3. 逐步扩张：先定义最重要的核心概念结构，再向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。
4. 混合策略：将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
  
  常用策略：自顶向下地进行需求分析、自底向上地设计概念结构。自底向上设计概念结构的步骤是先抽象数据并设计局部视图，再集成局部视图，得到全局概念结构

6.3.2 数据抽象与局部视图设计

数据抽象：概念结构是对现实世界的一种抽象。所谓抽象是从实际的人、物、事和概念中抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型

三种常用抽象：

分类：定义某一类概念作为现实世界中一组对象的类型。这些对象具有某些共同的特性和行为，它抽象了对象值和型之间的“is member of”的语义，如张英是学生中的一员。在E-R模型中，实体型就是这种抽象
聚集：定义某一类型的组成成分。它抽象了对象内部类型和成分之间“is part of”的语义。在E-R模型中若干属性的聚集组成了实体型，就是这种抽象。如学号、姓名、专业、等属性的聚集组成学生实体型
概括：定义类型之间的一种子集联系。它抽象了类型之间的“is subset of”的语义。如学生是实体型，本科生、研究生也是实体型，本科生、研究生是学生的子集，称学生为超类，本科生、研究生为子类。概括具有继承性：子类继承超类上定义的所有抽象。 E-R模型中用双竖边的矩形框表示子类，用直线加小圆圈表示超类-子类的联系

概念设计的第一步就是利用上面的抽象机制对需求分析阶段收集到的数据进行分类、聚集，形成实体及其属性，标识实体的码，确定实体之间的联系类型(1:1,1:n,m:n)

局部视图设计：设计分E-R图的步骤

选择局部应用：需求分析阶段已用多层数据流图和数据字典描述了整个系统。设计分E-R图首先需要根据系统的具体情况，在多层数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点，让这组图中每一部分对应一个局部应用
逐一设计分E-R图：将各局部应用涉及的数据分别从数据字典中抽取出来，参照数据流图，标定各局部应用中的实体、实体的属性，标识实体的码，确定实体之间的联系及其类型

6.3.3 视图集成

视图的集成：各个局部视图即分E-R图建立好后，需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图

两种方法：1.一次集成 2.逐步累积

集成流程：

合并分E-R图，生成初步E-R图：由于各个局部应用所面向的问题不同，且由不同的设计人员进行设计，这就导致了各个分E-R图之间必定存在冲突。合并分E-R图的主要工作与关键所在就是合理消除各分E-R图的冲突。

冲突分三类：
1. 属性冲突
2. 命名冲突
3. 结构冲突
消除不必要的冗余，设计生成基本E-R图：在初步E-R图中，可能存在冗余数据和冗余实体间联系。冗余数据是指可由基本数据导出的数据，冗余联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难。消除不必要冗余后的初步E-R图称为基本E-R图
1. 消除冗余的规范化理论法：
  1. 确定分E-R图实体之间的数据依赖FL 。实体之间各种联系可以用实体码之间的函数依赖来表示。如部门和职工之间一对多的联系为职工号→部门号；部门和产品之间多对多的联系为(职工号,产品号) →工作天数。于是有函数依赖集FL
  2. 求FL的最小覆盖GL ，差集为D = FL-GL。逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉

6.4 逻辑结构设计

逻辑结构设计的任务：概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。从理论上讲，设计逻辑结构应该选择最适于相应概念结构的数据模型，然后对支持这种数据模型的各种DBMS进行比较，从中选出最合适的DBMS。但实际情况往往是已给定了某种DBMS，设计人员没有选择的余地

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

E-R图向关系模型的转换

转换要解决的问题：如何将实体和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。关系模型的逻辑结构是一组关系模式的集合，而E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的，所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式
转换应遵循的原则
1. 一个实体型转换为一个关系模式
2. 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并：若转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均是关系的属性，每个实体的码均是关系的候选码；若与某一端实体对应的关系模式合并，则需在该关系模式中加入另一个关系模式的码和联系本身的属性。
3. 如(职工与产品间的)负责联系为1:1联系转换方法有三种：
  1. 转换为一个独立的关系模式：负责(职工号,产品号) 或负责(职工号,产品号)
  2. 与职工关系模式合并，则只需在职工关系中加入产品关系的码部门号：职工(职工号,姓名,年龄,职称,产品号)
  3. 与产品关系模式合并，则只需在产品关系中加入职工关系的码职工号：产品(产品号,产品名, 职工号)
    
    注意：从理论上讲，1:1联系可以与任意一端对应的关系模式合并。但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。例如，如果经常要查询负责某个产品的职工姓名，则将负责联系与职工关系合并更好些
4. 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并：若转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均为关系的属性，关系的码为n端实体的码；若与n端对应的关系模式合并，则合并后关系的属性是在n端关系中加入1端关系的码和联系本身的属性，合并后关系的码不变。第二种方法可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。如(部门与职工间的)属于联系为1:n联系，将其转换为关系模式有两种方法：
  1. 转换为一个独立的关系模式：属于(职工号,部门号)
  2. 与职工关系模式合并：职工(职工号,姓名,年龄,职称,部门号)
5. 一个m:n联系转换为一个关系模式：与该联系相连的各实体的码以及联系本身的属性均是关系的属性，各实体码的组合为关系的码。如(仓库与零件间的)库存联系是一个m:n联系，可以将它转换为关系模式：库存(仓库号,零件号,库存量)
6. 三个或三个以上实体间的一个多元联系转换为一个关系模式：与该多元联系相连的各实体的码以及联系本身的属性均是关系的属性，各实体码的组合是关系的码。如(供应商、产品与零件间的)供应联系是一个三元联系，可以将它转换为如下关系模式：供应(供应商号,产品号,零件号)

数据模型的优化：数据库逻辑设计的结果不是唯一的，得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导

确定数据依赖：按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。
对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。如分析可知课程关系模式属于BC范式。
按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。常用的分解方法是：
1. 水平分解
2. 垂直分解

jasony_sam

关注

12
点赞
踩
23

收藏

觉得还不错? 一键收藏
0
评论
数据库知识点总结

关系数据库系统是支持关系模型的数据库系统。关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成单一的数据结构：实体以及实体间的各种联系均用关系来表示，从用户角度，关系模型中数据的逻辑结构是一张二维表关系操作：包括选择、投影、连接、除、并、交、差等查询操作和插入、删除、修改等更新操作两大类关系操作的特点是集合操作方式关系数据语言分为关系代数语言(用对关系的运算来表达查询)和关系演算语言(用谓词来表达查询)关系的三类完整性约束：实体完整性：由关系系统自动支持。
复制链接

扫一扫