Chap.1 绪论

1.1 数据库系统概述

1.1.1 数据库的四个基本概念

数据库中最基础的四个概念分别是:

• 数据(Data)
  • 是数据库中存储的基本对象
  • 定义为 描述事物的符号记录
  • 数据是 一个个数字 , 而数据的具体含义叫做 数据的语义
  • 分为三类:
    • 结构化数据: 关系数据(表)
    • 半结构化数据: 键值对, XML, JSON, 图, 向量等
    • 非结构化数据: 文本文档, 电子邮件, 图像…
• 数据库(DataBase, DB)
  • 数据库是 长期储存在计算机内的, 有组织, 可共享的大量数据集合
  • 基本特征已经体现在定义中:
    • 数据按照一定格式来组织, 储存
    • 可为各种用户共享
    • 冗余度较小
    • 易扩展
• 数据库管理系统(DBMS)
  • 是位于用于与操作系统之间的一层数据管理软件
  • 负责组织 / 存储数据, 同时在用户有需求时获取 / 维护数据
  • 主要功能包括两方面:
    • 对数据库本身的: 建立 / 维护 / 运行管理
    • 对数据库内部数据的: 定义 / 操纵 / 存储 / 组织 / 管理
• 数据库系统(DBS)
  • 是对数据库及其相关内容的总称, 包括:
    • 数据库
    • 数据库管理系统
    • 应用程序
    • 数据库管理员

1.1.2 数据管理系统的产生和发展

这一部分不是非常的重要, 一笔带过哈:

• 第一阶段是人工管理阶段: 没有存储设备, 只能在纸带 / 磁带上存储
  • 数据完全没有任何结构
  • 冗余程度极高
  • 通常 一个应用程序对应一个数据集
• 第二阶段是文件系统阶段: 建立在操作系统和文件系统产生之后.
  • 共享性差, 冗余度大
  • 文件系统变成了中间介质, 对应方式变成了 多个应用程序->1个文件系统->多个数据集
• 第三阶段就是数据库系统阶段: 大容量磁盘, 存储阵列开始出现.
  • 存储数据, 查询等操作更规范化, 模式化.
  • 极大幅度提高效率

1.1.3 数据库系统的特点

• 数据结构化
  • 数据的结构用统一的数据模型来描述
• 共享性高
  • 面向整个系统, 可以被多个用户, 多个应用使用
• 独立性高
  • 包括 物理独立性 和 逻辑独立性
  • 物理独立性指应用程序与物理存储结构相互独立(物理存储结构变更不需要导致应用程序变更)
  • 逻辑独立性指应用程序域逻辑结构相互独立(一样的, 逻辑结构变了, 应用程序不用变)
• 数据通过DBMS统一管理或控制
  • 就像我们说的, 应用程序与数据库本身之间隔着一层DBMS, 它负责了一切, 包括
    • 完整性
    • 安全性
    • 并发控制
    • 故障恢复

1.2 数据模型

1.2.1 数据建模

数据模型是 对现实世界数据特征的抽象 .
通常对于客观对象的抽象过程分两步:

• 将客观对象抽象为概念模型
  • 概念模型 还是用户的观点, 负责对现实进行抽象和建模
• 将概念模型抽象为数据库支持的数据模型
  • 逻辑模型 是一些DBMS实现了的模型, 比如网状模型 / 层次模型 / 关系模型等
  • 物理模型 是在物理磁盘上的存储模型

上图中信息世界的建模, 是我们应当着重关注的, 有一些基本的概念:

• 实体(Entity): 客观存在的一个事物
• 属性(Attribute): 实体具有的某一特性
• 码(Key): 用于唯一标识实体的属性集
• 实体类型(Entity Type): 用实体名和属性名集合来标识的一类实体
  • 学生(学号, 姓名)
• 实体集(Entity Set): 同一类型实体的集合
• 联系(Relationship):
  • 实体内部的联系: 各个属性之间的联系
  • 实体之间的联系: 不同实体集之间的联系
  • 一对一, 一对多, 多对多

在机器世界中, 有与其相对应的概念:

• 记录(元组): 信息世界中的一个实体
• 字段(数据项): 信息世界中的属性
• 码(键): 信息世界中的码
• 文件: 信息世界中的实体集

1.2.2 概念模型

我们关注的概念模型就是信息世界中建模的工具, 是现实世界和机器世界的一个中转站.

当前数据库主要是关系型数据库, 我们需要重点先关注实体集之间的关系:

• 一对一: 比如一个班只能有一个班长, 同时一个班长只能在一个班任职
• 一对多: 比如一个班里可以有很多学生, 但一个学生只能在一个班里
• 多对多: 比如一个课程里可以有很多选修它的学生, 而一个学生也可以选修多门课程

包括还有多个实体之间的联系(项目, 供应商, 零件), 单个实体型内部的联系(职工实体和领导关系).

这种描述不同实体之间联系的方式叫 ER(Entity Relationship)模型 , 其内部三要素即:

• 实体(矩形)
• 联系(菱形)
• 属性(椭圆)

它们之间用线段连接.

1.2.3 数据模型的组成要素

数据模型的组成要素有以下三点:

• 数据结构
  • 对系统静态特征的描述
  • 描述数据库的组成对象与联系
• 数据操作
  • 对数据库内各种对象允许进行的操作的集合
  • 增删改查等
• 完整性约束
  • 就是一组规则, 对给出的数据结构的限定
  • 需要保证数据正确 / 有效 / 相容

常用的数据模型包括:

• 层次模型
• 网状模型
• 关系模型

1.2.4 层次模型

层次模型用树形结构来表示各实体以及实体间的联系.

因为是树形结构, 因此比较适合 一对多 的关系叙述, 对于多对多, 只能分解成两个一对多.

其完整性约束如下:

• 无双亲则不能插入子女节点
• 删除双亲则必须一并删除子女节点

其存储结构很像数据结构中 树 的存储结构, 可以用邻接法, 也可以用链接法(链表).

• 查询效率高
• 对于插入和删除的限制多
• 必须通过双亲结点查询子女节点

1.2.5 网状模型

网状模型通常采用经典的网状结构来描述实体间的联系. 其特点如下:

• 允许一个以上的节点无双亲
• 一个节点可以有多于一个的双亲

可以看出来, 实际上 层次模型是网状模型的一个特例 .

网状模型通常直接使用链接法进行记录之间联系的构建. 并且, 可以构建多对多的联系(通过引入 联结记录 )

定义
联结记录, 实际上就是引入一种新的实体.
比如对于学生与课程之间的多对多关系, 那就引入一种联结记录叫 选课 .
学生与选课之间是一对多, 而课程与选课之间也是一对多.

• 网状模型的效率通常比较高, 性能还可以
• 结构随着数据库增大会变得非常复杂, 不利于管理

1.2.6 关系模型

关系模型是当前数据库主要采取的数据组织方式. 它通过二维表来表示实体集, 用外键表示实体之间的联系.

关系模型中有一些名词, 其实跟我们之前说的比较像:

• 关系(Relation): 通常指代一张表
• 元组(Tuple): 表中的一行即一个元组
• 属性(Attribute): 表中的一列就是一个属性
• 码(Key): 能够唯一标识元组的一个属性
• 域(Domain): 一组具有相同数据类型的值的集合(其实就是属性的取值范围)
• 分量: 元组中的一个属性值(表中的某一个具体格)
• 关系模式: 就是关系的表示方法: $ 学生(\underline{学号}, 姓名, 年龄, 性别, 系名, 年级) $ , 其中标下划线的是码(也叫主键)

关系模型的操作就是我们熟悉的:

• 增
• 删
• 改
• 查

其完整性约束也比较完善:

• 实体完整性: 实体的主键不能为NULL(针对主键本身)
• 参照完整性: 外键引用的主键必须在对应的主表中存在(针对实体的外键)
• 用户定义的完整性: 用户根据自己的需求对于属性进行的定义.(比如对于值域的定义, 对于枚举类的限制等)

特点如下:

• 数学概念严格
• 关系模式的存取对用户透明
• 查询效率通常低一些
• 为了性能问题需要优化查询, 提高了复杂度

除了上述三类之外, 近些年有一种叫做 面向数据关系类型 , 相当于把编程中的面向对象的思想搬了过来.
它有其问题, 主要是它的理论基础并不扎实. 在语言以及查询优化方面都没有明显的优势.

由于关系型数据库发展至今已经十分完善, 因此并未掀起很大的波动.

1.3 数据库系统的结构

从应用开发人员的角度来讲(说白了就是从应用开发者的角度), 数据库通常是由三级模式结构区分的:

• 外模式
• 模式
• 内模式

1.3.1 模式 / 实例

模式, 实际上就是数据库的结构定义. 以关系数据库为例, 像这样的ER图就可以作为我们数据库的模式:

当然, 我们也能通过这种图推导出如何构建这个表(通过SQL语言, 后文再讲), 这也叫模式.

而实例, 则是某组(某个)具体的数据集合(实体), 比如说一个学生表中的具体数据.

1.3.2 三级模式结构

我们刚刚说了, 三级模式结构:

• 外模式(External Schema)
• 模式(Schema)
• 内模式(Internel Schema)

现在一个个来说都是啥意思.

1.3.3 模式(Schema)

模式 , 也叫 逻辑模式 , 指的是数据库中所有数据的逻辑结构和特征的概述.
其实也就是我们具体怎么规划, 设计数据库的逻辑存储结构(就是上面的ER图).

显然, 它与数据的物理存储方式无关; 同时, 与具体的应用程序或者高级程序设计语言同样无关.

正如我们此前说的一样, 模式主要包含的就是:

• 数据的逻辑结构(由什么变量构成)
• 数据之间的联系(表的结构)
• 数据有关的安全性 / 完整性要求(参见1.2.6)

注意
一个数据库只能有一个模式.

1.3.4 外模式(External Schema)

外模式 , 亦称 用户模式 , 指的是数据库用户(应用设计者 / 最终用户)使用的局部数据的逻辑结构和特征的叙述.

举个例子而言, 我们数据库的模式就是具体存储的一个个表. 而我们的外模式可以在后端一并取出一个表的某一些属性 / 甚至几个表的属性我都拿出来呈现出来, 这种不同的呈现方式就是外模式的具体例子.

可以看出, 一个数据库虽然只能有一个模式, 但是它是可以有很多的外模式的对吧. 我怎么取出, 展示我的数据, 那可很自由了.
我们严谨一点给出外模式的特点:

• 外模式通常是模式的子集
• 一个数据库可以有多个外模式
• 模式中同一个数据, 在外模式中的结构, 表现形式, 保密级别都可能不同.

注意
这里提一嘴外模式根应用程序的关系.
外模式与应用程序是 一对多 的关系, 即一个外模式可以被很多个应用程序使用, 但是一个应用程序只对应一种外模式.

1.3.5 内模式(Internel Schema)

内模式 , 也叫 存储模式 , 是数据库数据物理结构和存储方式的叙述.
比如:

• 数据的物理存储策略(顺序, 链式, B树, …)
• 数据的组织方式
• 数据存储时是否压缩
• 数据存储时是否加密

可以看出, 内模式就是我们的模式具体是怎么在我们的存储结构中物理实现的.
相对应的, 一个数据库只能有一个内模式 .

1.3.6 数据库的二级映像功能与数据独立性

数据库的 二级映像 正是针对这三个模式而言的.

• 外模式 / 模式映像
• 模式 / 内模式映像

这两层影响保证了数据库的数据具有较高的 逻辑独立性 / 物理独立性 .

首先看 外模式 / 模式映像 , 它其实就是表达同一个模式是怎么被映射成不同样子的外模式的.
正因如此, 一个外模式通常就对应着一个外模式 / 模式映像, 而它也一般被写在外模式的描述中.

它的作用不言自明, 当模式发生变化, 只需要更改外模式与模式的对应关系即可, 而无需更改应用程序的代码(因为应用程序只与外模式相关) . 这就是 数据的逻辑独立性 .

再来看 模式 / 内模式映像 , 同理, 它表达了一个模式是怎么被存储在存储介质之中的.
因为对于同一个数据库, 只有一个模式 / 内模式, 因此 模式 / 内模式映像 是唯一的. 通常包含在模式的描述中.

它的作用是什么?
当内模式(就是存储结构)发生变化, 只需要更改模式与内模式的映射即可, 无需做出其它更改, 这就叫 数据的物理独立性 .

1.4 数据库系统的组成

一个数据库系统的组成通常包括:

• 硬件平台及数据库
  • 足够大的内存
  • 足够大的磁盘与磁盘阵列等设备
  • 较高的通道能力
• 软件
  • 操作系统
  • 数据库管理系统
  • 对接的高级语言编译系统
  • 对应的应用开发工具
  • 应用系统
• 人员
  • 数据库管理员DBA
  • 数据库设计人员
  • 应用程序员
  • 最终用户

1.4.1 数据库管理系统DBMS

我们之前在这个图里面提过数据库管理系统:

在了解了数据库的基本结构之后, 现在来详细的介绍一下它.

其功能主要有:

• 数据库的定义功能
  • 定义三级模式以及二级映像
  • 定义完整性 / 安全性等约束

注意
DBMS中是怎么存储 三级模式定义 的?
实际上, DBMS同样使用数据库来定义三级模式.
这被称之为 数据字典(DD, Database Dictionary)

• 数据库的操纵功能
  • 这不用说了, 增删改查, 之前提了很多回
• 数据库的保护功能
  • 完整性 / 安全性控制
  • 数据库的恢复
  • 数据库的并发控制
• 数据库的存储管理
  • 就是把高级的插入语言转化成底层操作系统能看懂的文件系统命令
• 数据库的维护功能
  • 数据装载
  • 数据库备份
  • 性能监控

读者把这五个方面都看一遍会发现, 我去, 数据库管理系统全包了, 把很复杂的工作简化成了对应的数据库语言.
这也就是为什么说 数据库管理系统是数据库系统的核心部分 .