第一章绪论

数据库的基本概念:

DBMS（数据库管理系统）中并发控制的基本单位是事务（Transaction）。事务是一系列操作，这些操作要么全部执行，要么全部不执行，它是一个不可分割的工作单位。数据库系统利用事务来保证即使在多个用户并发访问数据库时，也能保持数据的一致性和完整性。

...

为了管理并发事务，数据库系统实施了一系列并发控制机制，这些机制确保事务的隔离性，即事务的执行不会被其他事务的操作所干扰。隔离性是ACID原则中的一个重要组成部分，ACID代表原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），这是事务必须遵守的四个特性。

并发控制通常通过锁定机制（如共享锁和排它锁）、乐观并发控制、时间戳排序、多版本并发控制（MVCC）等技术来实现。这些机制可以防止并发事务之间发生冲突，例如更新丢失、脏读、不可重复读和幻读等问题。通过这些并发控制技术，DBMS能够在维护数据一致性的同时，提高系统的并发性能。

数据库的发展阶段

数据库的发展阶段以及独立性

独立性即用户应用程序与数据库的数据相互独立

数据模型

ER图

常见的数据模型+层次模型

网状模型

关系模型

关系、元组、属性、码、域、分量

数据库系统的结构

三级模式结构

第二章关系型数据库

关系模式

关系操作

关系语言的分类

(1)关系代数语言

交

并差

笛卡尔积

选择、象集、条件表达式

选择

投影

选择和投影的结合

连接:

分为

自然连接和悬浮元组

外连接、左外连接、右外连接(跟上面的自然连接比起来就是不再舍弃悬浮元组)

除 (很简单)

关系的完整性(实体完整性、参照完整性、用户定义完整性)

数据库的数据完整性是指数据的准确性和可靠性。它确保了数据库中的数据是正确的、一致的，并且符合定义的规则和约束。数据完整性是数据库管理的一个重要部分，它包括以下几个方面：

实体完整性：确保每个表都有一个唯一的主键，不允许有重复的记录，也不允许主键的值为空。
参照完整性：确保外键值的一致性，即表中的外键必须对应于另一表的主键，或者是完全为空，以维护不同表之间的数据一致性。
域完整性：确保表中的每个字段值都必须在一个特定的域（数据类型、数据范围）内，例如，一个年龄字段应该只包含正整数。
用户定义的完整性：指的是根据业务规则为数据库设置的特定的规则和约束，例如，一个员工的工资不应该低于最低工资标准。

通过强制执行这些完整性约束，数据库管理系统（DBMS）能够防止无效数据的输入，减少数据错误，并确保数据的质量。数据完整性对于保证信息系统的准确性和可信赖性至关重要。

第三章 SQL语言

基本概念

这个也考

数据定义语言DDL、数据查询语言DQL、数据操纵语言DML、数据控制语言DCL

SQL语言的特点

SQL的基本语法:

(1)变量类型

模式定义

模式定义+视图

模式删除

表的定义和删除、修改

索引的建立、删除和修改

查询

别名

(如下面是给username起了别名“姓名",这里as可以省略)

下面是给表user起别名u

结果去重(distinct)

如下面的查询语句查询的结果有重复的

可以加上distinct来去重

查询结果加条件where

可适用的查询条件

between and

(%表示前面可任意个字符、_表一个、

is null

多个附加条件 and or

聚集函数

count(*))

count(DISTINCT title)

分组查询(group by 和having)

注意group by后不能加where,如下面:

解决方式是加having

连接

两个表连接(笛卡尔积)

这样写是两张表直接笛卡尔积

以where做关键字

自身连接

外连接

左外连接

嵌套查询

带any all的子查询

带exists的子查询

集合的查询

并 union。交 intersect ,差except

差except

表的修改

插入

修改

删除

视图

创建视图

删除视图

查询视图

更新视图

注意:要先更新视图、再修改原表

游标

游标是SQL 的一种数据访问机制，游标是一种处理数据的方法。众所周知，使用SQL的select查询操作返回的结果是一个包含一行或者是多行的数据集，如果我们要对查询的结果再进行查询，比如（查看结果的第一行、下一行、最后一行、前十行等等操作）简单的通过select语句是无法完成的，因为这时候索要查询的结果不是数据表，而是已经查询出来的结果集。游标就是针对这种情况而出现的。

我们可以将“ 游标 ”简单的看成是结果集的一个指针，可以根据需要在结果集上面来回滚动，浏览我需要的数据。

声明游标—>打开游标—>读取数据—>关闭游标—>删除游标

声明游标

语法如下：

for

Slect查询的相关语句

上面的彩色字体表示的是，声明游标时的选项，不是必须提供的，每一个都代表游标的相关选项和特性

（1）LOCAL：对于在其中创建批处理、存储过程或触发器来说，该游标的作用域是局部的。GLOBAL：指定该游标的作用域是全局的

（2）FORWARD_ONLY:指定游标只能从第一行滚动到最后一行。否则默认为FORWARD_ONLY。SCROLL表示游标可以来回滚动

（3）STATIC：定义一个游标，以创建将又该游标使用的数据临时复本，对游标的所有请求都从tempdb中的这以临时表中不得到应答；因此，在对该游标进行提取操作时返回的数据中不反映对基表所做的修改，并且该游标不允许修改。

KEYSET:指定当游标打开时，游标重的行的成员身份和顺序已经固定。对行进行唯一标识的键值内置在tempdb内一个称为keyset的表中。

DYNAMIC:定义一个游标，以反映在滚动游标时对结果集内的各行所做的所有数据更改。行的数据值、顺序和成员身份在每次提取时都会更改，动态游标不支持ABSOLUTE提取选项。

FAST_FORWARD：指定启动了性能优化的FORWARD_ONLY、READ_ONLY游标。如果指定了SCROLL或FOR_UPDATE,则不能指定FAST_FORWARD。


SCROLL_LOCKS：指定通过游标进行的定位更新或删除一定会成功。将行读入游标时SQL Server将锁定这些行，以确保随后可对它们进行修改，如果还指定了FAST_FORWARD或STATIC，则不能指定SCROLL_LOCKS。

OPTIMISTIC：指定如果行自读入游标以来已得到更新，则通过游标进行的定位更新或定位删除不成功。当将行读入游标时，SQL Server不锁定行，它改用timestamp列值比较结果来确定行读入游标后是否发生了修改，如果表不包含timestamp列，它改用校验和值进行确定，如果以修改该行，则尝试进行的定位更新或删除将失败，如果还指定了FAST_FORWARD，则不能指定OPTIMISTIC。

TYPE_WARNING:指定游标从所请求的类型隐式转换为另一种类型时，向客户端发送警告消息。

2、打开游标——Open Cursorname

3、取出数据——Fetch.........From

Fetch [ NEXT | PRIOR | FIRST | LAST | ABSOLUTE { n | @nvar } | RELATIVE { n | @nvar }] FROM Cursorname

[ INTO @variable_name [ ,...n ] ]

NEXT:紧跟当前行返回结果行，并且当前行递增为返回行，如果FETCH NEXT为对游标的第一次提取操作，则返回结果集中的第一行。NEXT为默认的游标提取选项。

PRIOR：返回紧邻当前行前面的结果行，并且当前行递减为返回行，如果FETCH PRIOR为对游标的第一次提取操作，则没有行返回并且游标置于第一行之前。

FIRST：返回游标中的第一行并将其作为当前行。

LAST:返回游标中的最后一行并将其作为当前行。

ABSOLUTE { n | @nvar }：如果n或@nvar为正，则返回从游标头开始向后n行的第n行，并将返回行变成新的当前行。如果n或@nvar为负，则返回从游标末尾开始向前的n行的第n行，并将返回行变成新的当前行。如果n或@nvar为0，则不返回行。n必须是整数常量，并且@nvar的数据类型必须为int、tinyint或smallint.

RELATIVE { n | @nvar }：如果n或@nvar为正，则返回从当前行开始向后的第n行。如果n或@nvar为负，则返回从当前行开始向前的第n行。如果n或@nvar为0，则返回当前行,对游标第一次提取时，如果在将n或@nvar设置为负数或0的情况下指定FETCH RELATIVE,则不返回行，n必须是整数常量，@nvar的数据类型必须是int、tinyint或smallint.

GLOBAL：指定cursor_name是全局游标。

cursor_name：已声明的游标的名称。如果全局游标和局部游标都使用cursor_name作为其名称，那么如果指定了GLOBAL，则cursor_name指的是全局游标，否则cursor_name指的是局部游标。

@cursor_variable_name：游标变量名，引用要从中进行提取操作的打开的游标。

INTO @variable_name [ ,...n ]：允许将提取操作的列数据放到局部变量中。列表中的各个变量从左到右与游标结果集中的相应列相关联。各变量的数据类型必须与相应的结果集列的数据类型相匹配，或是结果集列数据类型所支持的隐士转换。变量的数目必须与游标选择列表中的列数一致。

4、关闭游标——Close Cursorname

5、删除游标——Deallocate Cursorname

第四章数据库的安全性

安全性控制

用户身份鉴别、存取控制、自主存取控制方法(重点)

主要的操作权限有下面:

上面的References表示是否允许创建外键权限

授权grant

回收权限revoke

这里的cascade表示子用户赋予的权限一并回收

数据库的角色

用于给一类人授权

视图机制

审计和数据加密(简单了解即可)

第五章数据库的完整性

正确性、相容性、维护完整性

三大完整性

实体完整性

主键定义使用primary key的两种方式

参照完整性

定义外键foreign key+references

用户定义完整性

断言

assertion

触发器

for each row

for each statement表示语句执行完了

删除触发器

数据库范式

1、数据库范式的作用

数据库范式主要是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的设计理念。简单来说，数据库范式可以避免数据冗余，减少数据库的存储空间，并且减轻维护数据完整性的成本。是关系数据库核心的技术之一，也是从事数据库开发人员必备知识。

2、数据库范式分类介绍

范式是评价数据库模式规范化程度从低到高主要有：1NF、2NF、3Nf、BCNF、4NF、5NF。

范式通常分为几个不同的级别，每个级别对应一组特定的规则，这些规则定义了表结构应该如何组织以避免不同类型的数据冗余和更新异常。以下是一些基本的数据库范式：

第一范式（1NF）：

** **表的每个列都是不可分割的基本数据项，同一列中的值都是同一类型的，每个列都有唯一的名称，且每个表中的每个记录都需要能够被唯一地识别（通常通过主键实现）。

第二范式（2NF）：

** **在第一范式的基础上，表必须没有部分依赖，即表中的非主属性必须完全依赖于主键。

第三范式（3NF）：

** **在第二范式的基础上，表中的所有非主属性不仅完全依赖于主键，而且还必须直接依赖于主键，没有传递依赖。

BCNF（Boyce-Codd Normal Form）：

** **是第三范式的加强版，要求表中的每个决定因素都是候选键。

第四范式（4NF）：

** **在BCNF的基础上，表必须没有多值依赖，即表中的一个属性不能依赖于另一个属性的多个值。

第五范式（5NF）：

** **在第四范式的基础上，表必须没有潜在的连接依赖，即表的任何非平凡的连接依赖都必须是由候选键推导出来的。

第六范式（6NF）：

** **是进一步的范式，通常涉及到复杂的时间相关的数据。

数据库设计者通常会根据实际需求，平衡范式化和性能之间的关系。过度范式化可能会导致查询性能下降，因为它可能需要多个表的连接操作。在实践中，设计者往往会在第三范式或BCNF停止，并在必要时对数据库模式进行适当的反范式化以优化性能。

2.1 1NF 第一范式

强调属性的原子性约束，要求属性具有原子性，不可再分解。

举例：

学生表(学号、姓名、年龄、性别、地址)。地址可以细分为国家、省份、城市、市区、街道，那么该模式就没有达到第一范式。

第一范式存在问题：冗余度大、会引起修改操作的不一致性、数据插入异常、数据删除异常。

2.2 2NF 第二范式

第二范式，强调记录的唯一性约束，数据表必须有一个主键，并且没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

举例：

版本表(版本编码，版本名称，产品编码，产品名称)，其中主键是(版本编码，产品编码)，这个场景中，数据库设计并不符合第二范式，因为产品名称只依赖于产品编码。存在部分依赖。所以，为了使其满足第二范式，可以改造成两个表：版本表(版本编码，产品编码)和产品表(产品编码，产品名称)

2.3 3NF 第三范式

第三范式，强调数据属性冗余性的约束，也就是非主键列必须直接依赖于主键。也就是消除了非主属性对码的传递函数依赖。

举例：

订单表(订单编码，顾客编码，顾客名称)，其中主键是(订单编码)，这个场景中，顾客编码、顾客名称都完全依赖于主键，因此符合第二范式，但顾客名称依赖于顾客编码，从而间接依赖于主键，所以不能满足第三范式。如果要满足第三范式，需要拆分为两个表：订单表(订单编码，顾客编码)和顾客表(顾客编码，顾客名称)。

说明：3NF的模式肯定满足2NF。产生冗余和异常的两个重要原因是部分依赖和传递依赖。3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，性能较好。1NF、2NF一般不适合作为数据库模式，通常需要转换为3NF或者更高级别的范式，这种变换过程称为关系模式规范化处理。

2.4 BCNF(Bovce Codd Normal Form 巴克斯范式)

属于修正的第三范式，是防止主键的某一列会依赖于主键的其他列。当3NF消除了主属性对码的部分函数依赖和传递函数依赖称为BCNF。

特性：

1、所有主属性对每一个码都是完全函数依赖

2、所有主属性对每一个不包含它的码，也是完全函数依赖

3、没有任何属性完全函数依赖与非码的任何一组属性

举例：库存表(仓库名，管理员名，商品名，数量)，主键为(仓库名，管理员名，商品名)，这是满足前面三个范式的，但是仓库名和管理员名之间存在依赖关系，因此删除某一个仓库，会导致管理员也被删除，这样就不满足BCNF。

2.5 4NF 第四范式

非主属性不应该有多值。如果有多值就违反了第四范式。4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。

举例：用户联系方式表(用户id，固定电话，移动电话)，其中用户id是主键，这个满足了BCNF,但是一个用户有可能会有多个固定电话或者多个移动电话，那么这种设计就不合理，应该改为(用户id，联系方式类型，电话号码)。

说明：如果只考虑函数依赖，关系模式规范化程度最高的范式是BCNF;如果考虑多值依赖则是4NF。

2.6 5NF 第五范式

第五范式属于最终范式，消除了4NF中的连接依赖，第五范式需要满足以下要求：

1、必须满足第四范式

2、表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。

一般实际应用中不必考虑第五范式。