数据库系统概念笔记-引言

Posted 2020-07-11

 数据库管理系统（DBMS）由一个互相关联的数据的集合和一组用以访问这些数据的程序组成。这个数据集合通常称作数据库，其中包含了关于某个企业的信息。

  DBMS的主要目标是要提供一种可以方便、高效地存取数据库信息的途径。

1.1 数据视图

1.1.1 数据抽象

 一个可用的系统必须能高效地检索数据。这种高效性的需求促使设计者在数据库中使用了复杂的数据结构来表示数据，但是，有很多数据库用户不懂这些。为此，数据库的系统开发人员通过如下几个层次上的抽象来对用户屏蔽复杂性，以简化用户与系统的交互：

• 物理层  最低层次的抽象。描述数据实际上是怎样存储的，详细描述复杂的底层数据结构；
• 逻辑层  比物理层稍高的抽象，描述数据库中存储什么及这些数据间存在什么关系。逻辑层的用户不必知道物理层的复杂性，这称作物理数据独立性；
• 视图层  最高层次的抽象，只描述整个数据库的某个部分

 我们可以用程序设计语言的数据类型进行表达以上三层数据抽象：

type instructor = record
  ID:        char(5),
  name:      char(20),
  dept_name: char(20),
  salary:    numeric(8,2)
end;

 以上代码定义了一个具有4个字段的新记录instructor。每个字段有一个字段名和所属类型。对一个大学来说，可能包括几个这样的记录类型：

1. department，包含字段dept_name, building, budget
2. course，包含字段course_id, title, dept_name, credits
3. students，包含字段ID, name, dept_name, tot_cred

 在物理层，以上3个记录可能被描述为连续存储位置组成的存储块，不过，这些记录是怎样存储的复杂细节都被数据库的编译器屏蔽了，使用数据库的程序设计人员不需要理解这么复杂的东西。

 在逻辑层，只需要关心存储什么，开发人员先定义记录类型，以后就可以进行记录的增加、更新、删除、检索，开发人员不需要关心数据是如何存储的。

 在视图层，连记录的类型都被屏蔽了，数据库只向用户提供了某一部分数据。例如，大学注册办公室的职员只能看见数据库中关于学生的那部分信息，而不能访问涉及教师工资的信息。

1.1.2 实例和模式

 因为随着事件的推移，数据库会发生增删改，数据库会发生改变。特定时刻存储在数据库中的信息的集合就称作数据库的一个实例，而数据库的总体设计就称作数据库模式。这里要注意，数据库昨天的实例和今天的实例可能是不一样的。

 数据库系统还可以分为几种不同的模式：物理模式在物理层描述数据库的设计；逻辑模式则在逻辑层描述数据库设计；在视图层的模式可称为子模式。

 用类比来形象介绍实例和模式。在咱地球上，存在人这种类型，人又可以分为亚洲人、欧洲人、非洲人、美洲人等，其中亚洲人又可以分为中国人、日本人、越南人等，其中中国人又可以分为北京人、河北人、河南人等，以此类推，细分下去，还可以分出哪个乡村的人，比如小明的户籍是亚洲的某个某市某镇某县，我们还会发现童年时、成年时、老年时的小明又是大不一样的。类比起来，这里模式相当于类型，而实例相当于某个时刻具体的东西。比如，模式可相当于亚洲人，中国人，北京人，某个乡村的人，实例相当于某个时刻的小明，其实，实例也不仅仅是一个人，将中国人视作一个群体，则实例也可以相当于某个时刻的中国人。

1.1.3 数据模型

 数据库结构的基础是数据模型。数据模型是一个描述数据，数据联系，数据语义以及一致性约束的概念工具的集合。数据模型提供了一种描述物理层、逻辑层以及视图层的数据库设计方式。

 主要有4种数据模型：

• 关系模型
• 实体-联系模型
• 基于对象的数据模型
• 半结构化的数据模型

1.2 数据库语言

 最常见的数据库语言是SQL了，SQL语言可以分出数据定义语言（DDL）和数据操纵语言（DML），其中DDL用来定义数据库模式，DML用来表达数据库的查询和更新。

 1.2.1 数据操纵语言

 数据操纵语言（DML）是这样一种语言，它使得用户可以访问或操纵那些按照某种适当的数据模型组织起来的数据，有以下访问类型：

• query    对存储在数据库中的信息进行检索
• insert    向数据库中插入新的信息
• delete   从数据库中删除信息
• update  修改数据库中存储的信息

 其中查询是要求对信息进行检索的语句，DML中涉及信息检索的部分称作查询语言。

1.2.2 数据定义语言

 数据库模式是通过一系列定义来说明的，这些定义由一种数据定义语言（DDL）的特殊语言来表达。

 存储在数据库中的数据值必须满足某些一致性约束。例如，假设大学要求一个系的账户余额必须不能为负值。DDL语言提供了指定这种约束的工具。每当数据库被更新时，数据库系统都会检查这些约束。通常，约束可以是关于数据库的任意谓词。数据库系统实现可以以最小代价测试完整性约束。

• 域约束。就是范围检查，比如学生成绩的范围只能是0到100分。
• 参照完整性。比如，一个course记录中的dept_name值必须出现在department关系中的某个记录的dept_name属性中，我们不希望有人把course记录的dept_name随便改成一个不存在的值
• 断言。一个断言就是数据库需要时刻满足的某一条件。例如，“每一学期每一个系必须至少开设5门课程”，必须表达成一个断言。断言创建以后，系统会检测其有效性。如果断言有效，则以后只有不破坏断言的数据库更新才被允许。
• 授权。用户对数据库的操作权限有读权限、插入权限、删除权限、修改权限，有有些用户应该只拥有读权限，我们就可以只对其授权读权限。

 DDL以一些指令作为输入，生成一些输出。DDL的输出放在数据字典中，数据字段包含了元数据，元数据是关于数据的数据。可把数据字典看作一种特殊的表，这种表只能由数据库系统本身（不是常规的用户）来访问和修改。在读取和修改实际的数据前，数据库系统先要参考数据字典。

1.3 关系数据库

 关系数据库基于关系模型，使用一系列的表来表达数据以及这些数据之间的联系。

1.3.1 表

 每个表有多个列，每个列有唯一的名字，以下表格展示了一个关系数据库的示例。

第一个表是instructor表，例如，ID为22222的名叫Einstein的教师是物理系的成员，他的年薪为95 000美元。第二个表是department表，例如，生物系在Waston大楼，经费预算为90 000美元。

instructor表

ID	name	dept_name	salary
22222	Einstein	Physics	95000
12121	Wu	Finance	90000
32343	El Said	History	60000
45565	Katz	Comp. Sci.	75000

department表

dept_name	building	budget
Comp. Sci	Taylor	100000
Biology	Watson	90000
Elec. Eng.	Taylor	85000
Music	Packard	80000
Finance	Painter	120000
History	Painer	50000
Physics	Watson	70000

 

 

 

 

 

 

 

 

 关系模型是基于记录的模型的一个实例。基于记录的模型，之所有由此称谓，是因为数据库的结构是几种固定格式的记录。每个表包含一种特定类型的记录。每种定义固定数目的字段或属性。表的列对应记录的属性。

1.3.2 数据操纵语言

 下面是一个SQL查询的例子，它找出历史系的所有教员的名字：

SELECT instructor.name
FROM instructor
WHERE instructor.dept_name = "History";

 这个查询指定了从instructor表中要取回的是dept_name为History的那些行，并且这些行的name属性要显示出来。更具体点，执行本查询的结果就是一个表，它有一列name和若干行，每一行都是dept_name为History的一个教员的名字。

 查询还可以涉及来自不止一个表的信息。例如，下面的查询将找出与经费预算超过95 000美元的系相关联的所有教员的ID和系名：

SELECT instructor.ID, department.dept_name
FROM instructor, department
WHERE instructor.dept_name = department.dept_name AND
  department.budget > 95000;

 结果将是一张表，这个表有两列和若干行。

 1.3.3 数据定义语言

 通过DDL语言，我们可以定义表、完整性约束、断言，等等。

 例如，以下的SQL DDL语句定义了department表：

CREATE TABLE department
(
  dept_name char(20),
  building  char(15),
  budget    numeric(12,2)
);

 上面的DDL语句执行的结果就是创建了department表，该表有3个列：dept_name、building 和 budget，每个列有一个与之相关的数据类型。

1.4 数据库设计

 数据库系统被设计用来管理大量信息。数据库设计的主要内容是数据库模式的设计。

1.4.1 设计过程

 第一步，全面刻画预期的数据库用户的数据需求，制定出用户需求的规格文档；

 第二步，选择一个数据模型，并运用该选定的数据模型的概念，将那些需求转换成一个数据库的概念模型。在这个概念设计阶段开发出来的模式提供了企业的详细概述，重点是描述数据以及它们之间的联系，而不是指定的物理存储细节；

    从关系模型的角度来看，概念设计阶段涉及决定数据库应该包括哪些属性，以及如何将这些属性组织到多个表中。前者基本上是商业的决策，而后者主要是计算机科学的问题，解决这个问题主要有两种方法：一种是使用实体-联系模型，另一种是引入一套算法，这套算法将所有的属性集作为输入，生成一组关系表；

    一个开发完全的概念模式还将指出企业的功能需求。在功能需求说明中，用户描述数据之上的各种操作，例如更新数据、检索特定的数据、删除数据等。

 第三步，逻辑设计阶段，设计者将高层的概念模式映射到要使用的数据库系统的实现模型上；

 第四步，物理设计阶段，上一步设计者将得到的特定于系统的数据库模式用到本阶段中，此阶段指定数据库的物理特性，这些特性包括文件组织的形式以及内部的存储结构。

1.4.2 大学机构的数据库设计

 在需求分析阶段中的需求描述是制定数据库的概念结构的基础。以下是大学的主要特性：

• 大学分成多个系。每个系由自己的名字（dept_name）来标识，坐落在特定的建筑物（building）中，有它的经费预算（budget）；
• 每个系有一个开设课程列表。没门课程有课程号（course_id）、课程名（title）、系名（dept_name）和学分（credits），还可能有先修要求（prerequisites）；
• 教师由个人唯一的标识号（ID）来标识。每位教师有姓名（name），所在的系（dept_name）和工资（salary）；
• 学生由个人唯一的标识号（ID）来标识。每位学生有姓名（name）、主修的系（dept_name）和已修学分数（tot_cred）；
• 大学维护一个教室列表，详细说明楼名（building）、房间号（room_number）和容量（capacity）；
• 大学维护开设的所有课程（开课）的列表。每次开课由课程号（course_id）、开课号（sec_id）、年（year）和学期（semester）来标识，与之相关的有学期；（semester）、年（year）、楼名（building）、房间号（room_number）和时段号（time_slot_id，即上课的时间）；
• 系有一个教学任务列表，说明每位教师的授课情况；
• 大学有一个所有学生课程注册的列表，说明每位学生在哪些课程的哪次开课中注册了。

1.4.3 实体-联系模型

 实体-联系（E-R）数据模型使用一组称作实体的基本对象，以及这些对象间的联系。实体是现实世界中可区别于其他对象的一件“事情”或一个“物体”。例如，每个人是一个实体，每个银行账户也是一个实体。

 数据库中实体通过属性集合来描述。例如，属性dept_name、building 与 budget可以描述大学中的一个系，并且它们组成了 department 实体集的属性。

 联系是几个实体之间的关联。例如，member 联系将一位教师和她所在的系关联在一起。同一类型的所有实体的集合称作实体集，同一类型的所有联系的集合称作联系集。

 数据库的总体逻辑结构（模式）可以用实体-联系图进行图形化标识。最常用的画图方法是采用同一建模语言（UML）。在我们使用的基于UML符号中，E-R图如下表示：

• 实体集用矩形标识，实体名在头部，属性名列在下面；
• 联系集用连接一对相关的实体集的菱形表示，联系名放在菱形内部。

 除了实体和联系外，E-R模型还描绘了数据库必须遵守的对其内容的某些约束。一个重要的约束是映射基数，它标识通过某个联系集能与一实体进行关联的实体数目。例如，如果一位教师只能属于一个系，E-R模型就能表达出这种约束。

1.5 数据存储和查询

1.5.1 存储管理器

 存储管理器是数据库系统中负责在数据库中存储的低层数据与应用程序以及向系统提交的查询之间提供接口的部件。存储管理器负责与文件管理器进行交互。原始数据通过操作系统提供的文件系统存储在磁盘上。存储管理器将各种DML语句翻译成为底层文件系统命令。因此，存储管理器负责数据库中数据的存储、检索和更新。

 存储管理部件包括：

• 权限及完整性管理器，它检测是否满足完整性约束，并检查试图访问数据的用户的权限；
• 事务管理器，它保证即使发生了故障，数据库也保持在一致（正确）的状态，并保证并发事务的执行不发生冲突；
• 文件管理器，它管理磁盘存储空间的分配，管理用于标识磁盘上所存储信息的数据结构；
• 缓冲区管理器，它负责将数据从磁盘上取到内存中来，并决定哪些数据应被缓冲存储在内存中。

 存储管理器实现了几种数据结构，作为系统物理实现的一部分：

• 数据文件，存储数据库自身；
• 数据字典，存储关于数据库结构的元数据，尤其是数据库模式；
• 索引，提供对数据项的快速访问。

1.5.2 查询处理器

 查询处理器组件包括：

• DDL解释器，它解释DDL语句并将这些定义记录在数据字典中；
• DML编译器，将查询语言中的DML语句翻译为一个执行方案，包括一系列查询执行引擎能理解的低级指令
• 查询执行引擎，执行由DML编译器产生的低级指令。

1.6 事务管理

 通常，对数据库的几个操作合起来就可以形成一个逻辑单元，称作事务。比如资金转账，其中一个系（A系）的账户进行取出操作，而另一个系（B系）的账户进行存入操作。显然，这两个操作必须保证要么都发生要么都不发生。这种要么都发生要么都不发生的要求称为原子性。除此之外，资金转账还必须保持数据库的一致性。也就是说，A和B的余额之和应该是保持不变的。这种正确性的要求称作一致性。最后，当资金转账成功结束后，即使发生了系统故障，账户A和账户B的余额也应该保持转账成功结束后的新值，这种保持的要求称作持久性。

1.7 数据库体系结构

 现在我们可以给出一个数据库系统各个部分以及它们之间联系的图了。

 数据库系统的体系结构很大程度上取决于数据库系统所运行的计算机系统。数据库系统可以是集中式的、客户/服务器式的；也可以使针对并行计算机体系结构设计数据库系统；分布式数据库包含地理上分离的多台计算机。

 数据库应用通常分为两或三部分，如下图所示，在一个两层体系结构中，应用程序驻留在客户机上，通过查询语言表达式来调用服务器上的数据库系统功能，像ODBS和JDBC这样的应用程序接口标准被用于进行客户端和服务器的交互。

 而在一个三层体系结构中，客户机只作为一个前端并且不包含任何直接的数据库调用。客户端通常通过一个表单界面与应用服务器进行通信。而应用服务器与数据库系统通信以访问数据。应用程序的业务逻辑，也就是说在何种条件下做出何种反应，被嵌入到应用服务器中，而不是分布在多个客户机上。

                                   系统体系结构图

                                                          两层和三层体系结构图

1.8 数据挖掘与信息检索

 数据挖掘指的是半自动地分析大型数据库并从中找出有用的模式的过程。和人工智能中的知识发现（也称为机器学习）或者统计分析一样，数据挖掘试图从数据中寻找规则或模式。但是，数据挖掘和机器学习、统计分析不一样的地方在于它处理大量的主要存储在磁盘上的数据。也就是说，数据挖掘就是在数据库中发现知识。

 文本数据也爆炸式增长。文本数据是非结构化的，与关系数据库中严格的结构化数据不同。查询非结构化的文本数据被称为信息检索。信息检索系统和数据库系统很大程度上是相同的——特别是基于辅助存储器的数据存储和检索。但是信息系统领域与数据库系统所强调的重点是不同的，信息系统重点强调基于关键词的查询，文档与查询的相似度，以及文档的分析、分类和索引。

1.9 数据库用户和管理员

使用 数据库的人员可分为数据库用户和数据库管理员。

1.9.1 数据库用户和用户界面

 根据所期望的与系统交互方式的不同，数据库系统的用户可以分为四种不同类型。系统为不同类型的用户设计了不同的用户界面。

• 无经验的用户是默认经验的用户，他们通过激活事先已经写好的应用程序同系统进行交互。此类用户的典型用户界面是表格界面，用户只需要填写表格的相应项就可以了。无经验的用户也可以很简单地阅读数据库产生的报表。考虑一个学生，他在课程注册的过程中想通过Web界面来注册一门课程。应用程序首先验证该用户的身份，然后允许他去访问一个表格，他可以在表格中填入想填的信息。表格信息被送回给服务器上的Web应用程序，然后应用程序确定该课程是否还有空额，如果有，就把这位学生的信息添加到数据库中的该课程花名册中。
• 应用程序员是编写应用程序的计算机专业人员。此类用户甚至可以直接用数据库客户端登录数据库，随意地增删改查数据。
• 老练的用户不通过编写程序来同系统交互，而是用数据库查询语言或数据分析软件这样的工具来表达他们的要求。分析员通过提交查询来研究数据库中的数据，所以属于这一类用户。
• 专门的用户是编写专门的不适合于传统数据处理框架的数据库应用的富有经验的用户。这样的应用包括：计算你辅助设计系统、知识库和专家系统。

1.9.2 数据库管理员

使用DBMS的一个主要原因是可以对数据和访问这些数据的程序进行集中控制。对系统进行集中控制的人称作数据库管理员（DataBase Administrator, DBA）。DBA的作用包括：

• 模式定义
• 存储结构及存取方法定义
• 模式及物理组织的修改
• 数据访问授权
• 日常维护