数据库系统概览-CSDN博客

本文链接：https://blog.csdn.net/qq_41338341/article/details/114321362

第一章绪论

1、试述数据、数据库、数据库管理系统、数据库系统的概念。

术语	概念
数据	描述事物的符号记录
数据库	是长期存储在计算机内、有组织的、可共享的大量数据的集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
数据库管理系统	是位于用户与操作系统之间的一层数据管理软件。在数据库建立、运行和维护时对数据库进行统一控制，以保证数据的完整性和安全性，并在多用户同时使用数据库时进行并发控制，在发生故障后对数据库进行恢复。
数据库系统	是由数据库、数据库管理系统（及其应用开发工具）、应用程序和数据库管理员组成的存储、管理、处理和维护数据的系统。

2、数据管理技术的三个阶段。

人工管理阶段
文件系统阶段
数据库系统阶段

3、数据库系统的特点。

（1）数据结构化；
（2）数据的共享性高、冗余度低且易扩充；
（3）数据独立性高；
（4）数据由数据库管理系统统一管理和控制。

4、数据模型

模型	特点
概念模型	也称信息模型，它是按照用户的观点来对数据和信息建模，主要用于数据库设计。
逻辑模型	主要包括层次模型、网状模型、关系模型、面向对象数据模型和对象关系数据模型、半结构化数据模型等。它是按照计算机系统的观点对数据建模，主要用于数据库管理系统的实现。
物理模型	它是对数据最底层的抽象，它描述数据在系统内部的表示方式和存取方法，或在磁盘或磁带上的存储方式和存取方法，是面向计算机系统的。

在这里插入图片描述

5、数据库系统的三级模式结构

术语	概念
模式	也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个模式。模式主要是定义两方面内容： 1. 定义数据的逻辑结构，例如数据记录是由哪些数据项构成，数据项的名字、类型、取值范围等。通俗来说，就是设计数据库的表。 2. 定义数据之间的联系，定义与数据有关的安全性、完整性要求。简单来说，就是设计表与表之间的关系。
外模式	也称子模式、用户模式，是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述。是数据库用户的数据视图，适于某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式，但是一个应用程序只能使用一个外模式。外模式是模式的子集，是局部逻辑结构，两者的区别的作用是为了区别权限。比如有些用户是看不到某些信息的，员工只能看到自己的工资却看不到公司的内部财务信息。举个例子：`SELECT NAME,SEX FROM student；`这个查询只是规定了名字和性别，所以这个视图是student表的子表。这些就叫做外模式。
内模式	也称存储模式。它是数据物理结构和存储方式的描述，是数据在数据库内部的组织方式。一个数据库只有一个内模式。例如，记录的存储方式是堆存储还是按照某个（些）属性值的升（降）序存储，或按照属性值聚簇存储；数据是否压缩存储、是否加密；索引按照什么方式组织，是B+树索引还是hash索引等等

6、数据库的二级映像功能与逻辑独立性、物理独立性

映像就是指相邻级模式之间的联系和交互。数据库管理系统在这三级模式之间提供了两层映像：

外模式/模式映像：当模式改变时（例如增加新的关系、新的属性、改变属性的数据类型等），由数据库管理员对各个外模式/模式的映像作相应改变，可以使外模式保持不变。应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。
模式/内模式映像：当数据库的存储结构改变时（例如选用了另一种存储结构），由数据库管理员对模式/内模式映像作相应改变，可以使模式保持不变，从而应用程序也不必改变。保证了数据与程序的物理独立性，简称数据的物理独立性。

第二章关系数据库

关系数据库系统是支持关系模型的数据库系统。关系模型的数据结构非常简单，只包含单一的数据结构——关系。在用户看来，关系模型中数据的逻辑结构是一张扁平的二维表。

1. 基本概念

域：一组具有相同数据类型和取值范围的值的集合。

笛卡尔积：域上的一种集合运算。

例如给出两个域：

$D_1 = 学生集合Student = \{小明，小红，小花\}$
$D_2 = 专业集合Profession = \{计算机专业，信息专业\}$

则 $D_1 、D_2$ 的笛卡尔积为

$\begin{aligned} D_1 × D_2 = \{ & \\ &（小明，计算机专业），（小明，信息专业），\\ &（小红，计算机专业），（小红，信息专业），\\ &（小花，计算机专业），（小花，信息专业）\\ & \} \end{aligned}$

关系： $D_1 × D_2 × ... ×D_n$ 的子集叫做在域 $D_1 ， D_2 ， ... ，D_n$ 上的关系，表示为 $R(D_1， D_2 ， ... ，D_n)$ 。这里 R 表示关系的名字，n 是关系的目或度。

也就是说，关系是笛卡尔积的的有限子集，可以简单理解为关系就是一张二维表。

关系可以有三种类型：

基本关系：也称基本表、基表，是实际存在的表，它是实际存储数据的逻辑表示。
查询表：查询结果对应的表。
视图表：是由基本表或其他视图表导出的表，是虚表，不对应实际存储的数据。

候选码：若关系中的某一属性组的值能唯一地标识一个元组，而其真子集不能，则称该属性组为候选码。

主码：从候选码中选定一个作为主码。

主属性（不能为空）：任一候选码的属性
非主属性（非码属性）：不包含在任何候选码中的属性

全码：若关系模式的所有属性都是这个关系模式的候选码，称为全码。

2. 关系的完整性

实体完整性：主属性不能取空值。
参照完整性：外码要么取空值，要么等于所引用的那种表相应的属性值。
用户定义的完整性

3. 关系代数与关系运算

关系代数是一种抽象的查询语言，它用对关系的运算来表达查询。
在这里插入图片描述

分类	说明
等值连接	从关系R与S的广义笛卡尔积中选取A、B属性值相等的那些元组，不消除重复
自然连接	类似等值连接，要求两个关系中进行比较的分量必须是同名的属性组，消除重复列
左外连接	自然连接之后，再保留左边的关系R中的悬浮元组，右边对应属性填NULL
右外连接	自然连接之后，再保留右边的关系R中的悬浮元组，右边对应属性填NULL
外连接	左右的悬浮元组都保留

第三章关系数据库标准语言SQL（待补充）

1、数据定义

关系数据库系统支持三级模式结构，其模式、外模式、内模式中的基本对象有模式、表、视图和索引等。因此SQL的数据定义功能包括模式定义、表定义、视图和索引的定义。如图所示：
在这里插入图片描述

1、定义模式

create schema <模式名> authorization <用户名>;

如果没有指定<模式名>，那么<模式名>隐含为<用户名>。
要创建模式，调用该命令的用户必须拥有数据库管理员权限，或者获得了数据库管理员授予的create schema 的权限。

用户在创建模式的同时在这个模式定义中进一步创建基本表、视图，定义授权。即

create schema <模式名> authorization <用户名> [<表定义子句> | <视图定义子句> | <授权定义子句>];

例如，为用户ZHANG创建一个模式TEST，并且在其中定义一个表TAB1。

create schema TEST authorization ZHANG 
create table TAB1 ( name char(20),
					age int
					address char(30)
					);

2、删除模式

drop schema <模式名> <cascade | restrict>;

其中，cascade 和 restrict 两者必选其一。

cascade （级联），表示在删除模式的同时把该模式中所有的数据库对象全部删除。
restrict （限制），表示如果该模式中已经定义了下属的数据库对象（如表、视图等），则拒绝该删除语句的执行。

3、基本表的定义、删除与修改

定义

create table <表名> (<列名> <数据类型> [列级完整性约束条件]
					[, <列名> <数据类型> [列级完整性约束条件] ]
					...
					[, [表级完整性约束条件] ]);

列级完整性约束条件：

primary key：主键
unique：唯一性
not null：非空

修改

alter table <表名>
[add [column] <新列名> <数据类型> [完整性约束]]
[add <表级完整性约束>]
[drop [column> <列名> [cascade | restrict]]
[drop constraint <完整性约束名> [restrict | cascade]]
[alter column <列名> <数据类型>];

删除

drop table <表名> [restrict | cascade];

4、索引的建立、修改与删除

当表的数据量比较大时，查询操作会比较耗时。建立索引是加快查询速度的有效手段。

数据库索引有多种类型，常见的有：

顺序文件上的索引
B+树索引
散列索引
位图索引

建立索引

create [unique] [cluster] index <索引名>
on <表名>(<列名> [<次序>] [, <列名> [<次序>]] ...);

表名：要建立索引的基本表的名字
索引可以建立在该表的一列或多列上，各列名之间用逗号分隔。
次序：可选 ASC（升序）或 DESC（降序），默认值是 ASC。
unique表明此索引的每一个索引值只对应唯一的数据记录。
cluster表示要建立的索引是聚簇索引。

例如：

create unique index ID on Student(StuID);

修改索引

alter index <旧索引名> rename to <新索引名>;

删除索引

drop index <索引名>;

2、数据查询

第四章数据库安全性

1、数据库安全标准

TCSEC/TDI 安全级别划分（从上之下，从高到低）

安全级别	定义
A1	验证设计（verify design）
B3	安全域（security domains）
B2	结构化保护（structural protection）
B1	标记安全保护（labeled security protection）
C2	受控的存取保护（controlled access protection）
C1	自主安全保护（discretionary security protection）
D	最小保护（minimal protection）

2、自主存取控制方法

用户权限是由两个要素组成的：数据库对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据库对象上进行哪些类型的操作。

对象类型	对象	操作类型
数据库模式	模式	create schema
	基本表	create table，alter table
	视图	create view
	索引	create index
数据	基本表和视图	select，insert，update，references，all privileges
数据	属性列	create index

2.1 授权GRANT

grant <权限> [,<权限>] ...
on <对象类型> <对象名> [,<对象类型> <对象名>]...
to <用户> [,<用户>]...
[with grant option];

如果指定了with grant option子句，则获得某种权限的用户还可以把这种权限再授予给其他用户。否则获得某种权限的用户只能使用该权限，不能传播该权限。

例如：

grant insert
on table Student
to User5
with grant option;

SQL标准允许具有with grant option的用户把相应权限或其子集传递授予给其他用户，但是不允许循环授予，即被授予者不能把权限再授回给授予者或其祖先，如图所示：

2.2 收回授权REVOKE

revoke <权限> [, <权限>]...
on <对象类型> <对象名> [, <对象类型> <对象名>]...
from <用户> [,<用户>] ... [cascade | restrict];

2.3 创建数据库模式的权限

GRANT和REVOKE语句向用户授予或收回对数据的操作权限。对创建数据库模式一类的数据库对象的授权则由数据库管理员在创建用户时实现。

create user <username> [with] [dba | resource | connect];

只有系统的超级用户才有权创建一个新的数据库用户；
新创建的数据库用户有三种权限：connect、resource和dba，默认是connect

dba	√	√	√	√
拥有的权限	可否执行的操作
拥有的权限	create user	create schema	create table	登陆数据库，执行数据查询和操纵
resource	×	×	√	√
connect	×	×	×	√，但是必须拥有相应权限

3、强制存取控制方法

在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类。

对于主体和客体，数据库管理系统为它们每个实例（值）指派一个敏感度标记。敏感度标记被分为若干个级别：绝密 >= 机密 >= 可信 >= 公开。

主体的敏感度标记称为许可证级别，客体的敏感度标记称为密级。

仅当主体的许可证级别 >= 客体的密级时，该主体才能读取相应的客体。
仅当主体的许可证级别 <= 客体的密级时，该主体才能写相应的客体。

4、审计

审计功能把用户对数据库的所有操作自动记录下来放入审计日志中。审计员可以利用审计日志监控数据库中的各种行为，重现导致数据库现有状况的一系列事件，找出非法存取数据的人、时间和内容等。

审计事件一般有多个类别，例如：

服务器事件
系统权限
语句事件
模式对象事件

AUDIT语句用来设置审计功能，NOAUDIT语句则取消审计功能。

比如，对修改SC表结构或修改SC表数据的操作进行审计。

audit alter,update
on SC;

取消对SC表的一切审计。

noaudit alter，update
on SC;

第五章数据库完整性

1. 实体完整性

（1）列级约束条件

create table Student
	(Sno char(9) primary key,   /*在列级定义主码*/
	 Sname char(20) not null,
	 Ssex char(2)
	 );

（2）表级约束条件

create table SC
	(Sno char(9) not null,
	 Cno char(4) not null,
	 Grade smallint,
	 primary key (Sno,Cno)   /*只能在表级定义主码*/
	);

2. 参照完整性

create table SC
	(Sno char(9) not null,
	 Cno char(4) not null,
	 Grade smallint,
	 primary key (Sno,Cno),   /*在表级定义实体完整性*/
	 foreign key (Sno) references Studnet(Sno), /*在表级定义参照完整性*/
	 foreign key (Cno) references Course(Cno)   /*在表级定义参照完整性*/
	);

在这里插入图片描述

拒绝：no action
级联：cascade

显示说明参照完整性的违约处理示例

create table SC
	(Sno char(9) not null,
	 Cno char(4) not null,
	 Grade smallint,
	 primary key (Sno,Cno), /*在表级定义实体完整性,Sno、Cno都不能取空值*/
	 foreign key (Sno) references Studnet(Sno)  /*在表级定义参照完整性*/
	 	on delete cascade   /*当删除Student表中的元组时，级联删除SC表中相应的元组*/
	 	on update cascade,
	 foreign key (Cno) references Course(Cno)   /*在表级定义参照完整性*/
	 	on delete no action /*当删除Course表中的元组造成与SC表不一致或时，拒绝删除*/
	 	on update cascade,
	);

3. 用户定义的完整性

（1）属性上约束条件的定义

- 列值非空（`not null`）
- 列值唯一（`unique`）
- 检查列值是否满足一个条件表达式（`check`短语）

create table Student
	(Sno char(9) primary key,
	 Sname char(8) not null,
	 Ssex char(2) check(Ssex in ('男','女'))
	 );

（2）元组上的约束条件的定义

create table Student
	(Sno char(9) primary key,
	 Sname char(8) not null,
	 Ssex char(2),
	 check(Ssex = '女')
	 );

性别是女性的元组都能通过该项check检查，因为 Ssex='女' 成立。

（3）违约处理

不满足约束条件则拒绝执行该操作。

4. 断言

任何使断言不为真值的操作都会被拒绝执行。

创建断言：

create assertion <断言名> <check子句>;

删除断言：

drop assertion <断言名>;

5. 触发器

触发器是用户定义在关系表上的一类由事件驱动的特殊过程。一旦定义，触发器将被保存在数据库服务器中。任何用户对表的增、删、改操作均由服务器自动激活相应的触发器，在关系数据库管理系统核心层进行集中的完整性控制。

触发器又叫事件 - 条件 - 动作规则。当特定的系统事件（比如增删查改）发生时，对规则的条件进行检查，如果条件成立时则执行规则中的动作。

定义触发器

create trigger <触发器名>
{before | after} <触发事件> on <表名>
referencing new|old row as <变量>
for each {row | statement }
[when <触发条件>] <触发动作体>;

激活触发器

同一个表上的多个触发器激活时遵循如下的执行顺序：

执行该表上的 before 触发器
激活触发器的 sql 语句
执行该表上的 after 触发器

对于同一个表上的多个 before（after）触发器，遵循 “谁先创建谁先执行” 的原则。

删除触发器

drop trigger <触发器名> on <表名>;

第六章关系数据理论

1. 概念

函数依赖与完全函数依赖、部分依赖

函数依赖：学号→姓名，学号相同，则姓名一定相同。
完全函数依赖：X→Y，但是X的任一真子集推不出Y。其中X、Y是指一个/组属性。
部分依赖：X→Y，但是 Y 不完全函数依赖于 X。

候选码、超码、主码、主属性、非主属性、全码

候选码：若关系中的某一属性组的值能唯一地标识一个元组，而其真子集不能，则称该属性组为候选码。
超码：能唯一标识一个元组，其真子集也有可能能唯一标识一个元组，即 Y部分函数依赖于 X。候选码一定是超码，超码不一定是候选码。
主码：从候选码中选定一个作为主码。
主属性（不能为空）：包含在任何一个候选码中的属性。
非主属性（非码属性）：不包含在任何候选码中的属性
全码：整个属性组都是码，称为全码。

决定因素

X→Y，称 X 为这个函数依赖的决定因素。

2. 范式

在这里插入图片描述

范式	含义
1NF	每一个分量必须是不可分的数据项。
2NF	R∈1NF，且每一个非主属性完全函数依赖于任何一个候选码，则R∈2NF
3NF	每一个非主属性既不传递依赖于码，也不部分依赖于码。
BCNF	每一个决定因素都包含码
4NF
5NF

在这里插入图片描述

3. 数据依赖的公理系统

在这里插入图片描述

属性集 X 关于函数依赖集 F 的闭包

极小函数依赖集（最小依赖集、最小覆盖）

4. 模式分解

无损连接分解

保持函数依赖分解

分解方法及判断方法

第七章数据库设计

1. 数据库设计的步骤

数据库设计：过程(六个阶段) :

需求分析阶段：准确了解与分析用户需求（包括数据与处理）是整个设计过程的基础，是最困难、最耗费时间的一步。
概念结构设计阶段：是整个数据库设计的关键通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
逻辑结构设计阶段：将概念结构转换为某个DBMS所支持的数据模型，对其进行优化。
数据库物理设计阶段：为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
数据库实施阶段：运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
数据库运行和维护阶段：数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。

2. 数据字典

3. E-R 模型及关系模型

第九章关系查询处理和查询优化

查询处理 4 个阶段：

查询分析
查询检查
查询优化
- 代数优化（关系代数语法树图）
- 物理优化
查询执行

第十章数据库恢复技术

1. 事务

概念：事务是用户定义的一个数据库序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位，是恢复和并发控制的基本单位。

例如，在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。

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

BEGIN TRANSACTION;
COMMIT;
ROLLBACK;

事务通常是以 BEGIN TRANSACTION 开始，以COMMIT 或 ROLLBACK 结束。COMMIT 表示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束。 ROLLBACK 表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。这里的操作指对数据库的更新操作。

事务的ACID特性：

原子性
一致性
隔离性
持续性

2. 数据库故障的类型

事务内部的故障
系统故障
介质故障
计算机病毒

3. 恢复的实现技术

数据转储
- 静态转储
- 动态转储
登陆日志文件

4. 恢复策略

事务故障的恢复
系统故障的恢复
介质故障的恢复

第十一章并发控制概述

1. 概述

并发操作可能存在的 3 类问题：

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

并发控制机制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其他事务的干扰，从而避免造成数据的不一致性。

并发控制的主要技术：

封锁
时间戳
乐观控制法
多版本并发控制

2. 封锁

所谓封锁就是事务 T 在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。

基本的封锁类型有两种：

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

3. 封锁协议

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

一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。（不丢失修改数据）
二级封锁协议：在一级封锁协议基础上增加事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。（不丢失修改数据、不读脏数据）
三级封锁协议：在一级封锁协议基础上增加事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。（不丢失修改数据、不读脏数据、可重复读）

4. 活锁和死锁

活锁

如果事务 $T_1$ 封锁了数据R，事务 $T_2$ 又请求封锁R，于是 $T_2$ 等待； $T_3$ 也请求封锁R，当 $T_1$ 释放了R上的封锁之后，系统首先批准了 $T_3$ 的请求， $T_2$ 仍然等待；然后 $T_4$ 又请求封锁R，当 $T_3$ 释放了R上的封锁之后，系统又批准了 $T_4$ 的请求… $T_2$ 有可能永远等待，这就是活锁的情形。

避免活锁的简单方法就是采用先来先服务的锁。

死锁

如果事务 $T_1$ 封锁了数据 $R_1$ ， $T_2$ 封锁了数据 $R_2$ 。然后 $T_1$ 又请求封锁 $R_2$ ，因 $T_2$ 已封锁了 $R_2$ ， $T_1$ 也只能等待 $T_2$ 释放 $R_2$ 上的锁。接着 $T_2$ 又申请封锁 $R_1$ ，因 $T_1$ 已封锁了 $R_1$ ， $T_2$ 也只能等待 $T_1$ 释放 $R_1$ 上的锁。这样就出现了 $T_1$ 在等待 $T_2$ ，而 $T_2$ 又在等待 $T_1$ 的局面， $T_1$ 和 $T_2$ 两个事务永远不能结束，形成死锁。

死锁的预防：

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

诊断死锁：