系统架构设计笔记（7）—— 数据库模式与范式

淡淡的烟草味﹌ 2023-07-17 11:25 15阅读 0赞

数据管理技术的发展大致经历了人工管理阶段 、 文件系统阶段 、 数据库阶段和高级数据库技术阶段。数据库是长期储存在计算机内的 、 有组织的 、 可共享的数据的集合。

数据库管理系统 ( Database Management System ， DBMS ) 是一种负责数据库的定义 、 建立 、 操作 、 管理和维护的软件系统。其目的是保证数据安全可靠，提高数据库应用的简明性和方便性 。DBMS 的工作机理是把用户对数据的操作转化为对系统存储文件的操作，有效地实现数据库三级之间的转化。

数据库管理系统的主要职能有 : 数据库的定义和建立 、 数据库的操作 、 数据库的控制 、 数据库的维护 、 故障恢复和数据通信。

数据库系统 ( Database System ， DBS ) 是实现有组织地 、 动态地存储大量关联数据 、 方便多用户访问的计算机软件 、 硬件和数据资源组成的系统。一个典型的 DBS 包括数据库 、 硬件 、 软件 ( 应用程序 ) 和数据库管理员 ( DatabaseAdministrator，DBA ) 4个部分。根据计算机的系统结构， DBS 可分成集中式 、 客户 / 服务器式 、 并行式和分布式4种。

与文件系统阶段相比，数据库技术的数据管理方式具有以下特点 :  
( 1 ) 采用复杂的数据模型表示数据结构，数据冗馀小，易扩充，实现了数据共享。  
( 2 ) 具有较高的数据和程序独立性。包括数据库的独立性有物理独立性和逻辑独立性。  
( 3 ) 数据库系统为用户提供了方便的用户接口。  
( 4）数据库系统提供4个方面的数据控制功能，分别是并发控制 、 恢复 、 完整性和安全性。数据库中各个应用程序所使用的数据由数据库系统统一规定，按照一定的数据模型组织和建立，由系统统一管理和集中控制。  
( 5）增加了系统的灵活性。

高级数据库技术阶段的主要标志是分布式数据库系统和面向对象数据库系统的出现。

1.  分布式数据库系统的主要特点是数据在物理上分散存储，在逻辑上是统一的。分布式数据库系统的多数处理是就地完成，各地的计算机由数据通信网络相联系 ;
2.  面向对象数据库系统是面向对象的程序设计技术与数据库技术相结合的产物。面向对象数据库系统的主要特点是具有面向对象技术的封装性和继承性，提高了软件的可重用性。

数据库模式与范式是数据库系统中的两个重要概念，是进行数据库设计的基础。

## 1 数据库的结构与模式 ##

数据库技术中采用分级的方法将数据库的结构划分为多个层次。最著名的是美国 ANSI/SPARC 数据库系统研究组 1975 年提出的三级划分法，如图 1 所示。

![format_png][]

### 1.1 三级抽象 ###

数据库系统划分为三个抽象级：用户级、概念级、物理级。

（1）用户级数据库。用户级数据库对应于外模式，是最接近用户的一级数据库，是用户可以看到和使用的数据库，又称用户视图。用户级数据库主要由外部记录组成，不同的用户视图可以互相重叠，用户的所有操作都是针对用户视图进行的。

（2）概念级数据库。概念级数据库对应于概念模式，介于用户级和物理级之间，是所有用户视图的最小并集，是数据库管理员可看到和使用的数据库，又称 DBA（ DataBase Administrator，数据库管理员）视图。概念级数据库由概念记录组成，一个数据库可有多个不同的用户视图，每个用户视图由数据库某一部分的抽象表示所组成。一个数据库应用系统只存在一个 DBA 视图，它把数据库作为一个整体的抽象表示。概念级模式把用户视图有机地结合成一个整体，综合平衡考虑所有用户要求，实现数据的一致性、最大限度降低数据冗余、准确地反映数据间的联系。

（3）物理级数据库。物理级数据库对应于内模式，是数据库的低层表示，它描述数据的实际存储组织，是最接近于物理存储的级，又称内部视图。物理级数据库由内部记录组成，物理级数据库并不是真正的物理存储，而是最接近于物理存储的级。

### 1.2 三级模式 ###

数据库系统的三级模式为外模式、概念模式、内模式。

**（1）概念模式**  
概念模式（模式、逻辑模式）用以描述整个数据库中数据库的逻辑结构，描述现实世界中的实体及其性质与联系，定义记录、数据项、 数据的完整性约束条件及记录之间的联系，是数据项值的框架。

数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容，以及概念/物理之间的映射。

概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个概念模式。

**（2）外模式**  
外模式（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。

外模式是数据库用户（包括程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式。一个应用程序只能使用一个外模式。

**（3）内模式**  
内模式是整个数据库的最低层表示，不同于物理层，它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序，指引元、索引和存储路径等数据的存储组织。  
内模式是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。

--------------------

内模式、模式和外模式之间的关系如下：  
（1）模式是数据库的中心与关键；  
（2）内模式依赖于模式，独立于外模式和存储设备；  
（3）外模式面向具体的应用，独立于内模式和存储设备；  
（4）应用程序依赖于外模式，独立于模式和内模式。

### 1.3 两级独立性 ###

数据库系统两级独立性是指物理独立性和逻辑独立性。三个抽象级间通过两级映射（外模式—模式映射，模式—内模式映射）进行相互转换，使得数据库的三级形成一个统一的整体。

**（1）物理独立性**

物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的。当数据的物理存储改变时，应用程序不需要改变。  
物理独立性存在于概念模式和内模式之间的映射转换，说明物理组织发生变化时应用程序的独立程度。

**（2）逻辑独立性**

逻辑独立性是指用户的应用程序与数据库中的逻辑结构是相互独立的。当数据的逻辑结构改变时，应用程序不需要改变。  
逻辑独立性存在于外模式和概念模式之间的映射转换，说明概念模式发生变化时应用程序的独立程度。

> 逻辑独立性比物理独立性更难实现。

## 2 数据模型 ##

数据模型主要有两大类，分别是概念数据模型（实体—联系模型）和基本数据模型（结构数据模型）。

概念数据模型是按照用户的观点来对数据和信息建模，主要用于数据库设计。概念模型主要用实体—联系方法（Entity-Relationship Approach）表示，所以也称 E-R 模型。

基本数据模型是按照计算机系统的观点来对数据和信息建模，主要用于 DBMS 的实现。基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整性约束三部分组成。其中数据结构是对系统静态特性的描述，数据操作是对系统动态特性的描述，完整性约束是一组完整性规则的集合。

常用的基本数据模型有层次模型、网状模型、关系模型和面向对象模型。

**（1）层次模型**  
层次模型用树形结构表示实体类型及实体间的联系。层次模型的优点是记录之间的联系通过指针来实现，查询效率较高。层次模型的缺点是只能表示 1:n 联系，虽然有多种辅助手段实现 m:n 联系，但比较复杂，用户不易掌握。由于层次顺序的严格和复杂，导致数据的查询和更新操作很复杂，应用程序的编写也比较复杂。

**（2）网状模型**  
网状模型用有向图表示实体类型及实体间的联系。网状模型的优点是记录之间的联系通过指针实现， m:n 联系也容易实现，查询效率高。其缺点是编写应用程序的过程比较复杂，程序员必须熟悉数据库的逻辑结构。

**（3）关系模型**  
关系模型用表格结构表达实体集，用外键表示实体间的联系。其优点有：

1.  建立在严格的数学概念基础上；
2.  概念（关系）单一，结构简单、清晰，用户易懂易用；
3.  存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作。

**( 4 ) 面向对象模型**  
用面向对象观点来描述现实世界实体的逻辑组织 、 对象间限制 、 联系等的模型。一个面向对象数据库系统是一个持久的 、 可共享的对象库的存储和管理者，而一个对象库是由一个面向对象模型所定义的对象的集合体。  
面向对象数据库模式是类的集合，面向对象模型提供了一种类层次结构。在面向对象数据库模式中，一组类可以形成一个类层次，一个面向对象数据库可能有多个类层次。在一个类层次中，一个类继承其所有超类的全部属性 、 方法和消息。  
面向对象的数据库系统在逻辑上和物理上从面向记录上升为面向对象 、 面向可具有复杂结构的一个逻辑整体。允许用自然的方法，并结合数据抽象机制在结构和行为上对复杂对象建立模型，从而大幅度提高管理效率，降低用户使用复杂性。

## 3 关系代数（关系模型） ##

我们先了解几个相关的基本概念。

**（1）域**  
一组具有相同数据类型的值的集合 。

**（2） 笛卡儿积**

![format_png 1][]

**（3）关系**

![format_png 2][]

关系中的每个元素是关系中的元组，通常用 t 表示。关系是笛卡儿积的子集，所以关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。由于域可以相同，为了加以区分，必须为每列起一个名字，称为属性。

若关系中的某一属性组 ( 一个或多个属性 ) 的值能唯一地标识一个元组，则称该属性组为候选码 ( 候选键 ) 。 若一个关系有多个候选码，则选定其中ー个作为主码 ( 主键 ) 。 主码的所有属性称为主属性，不包含在任何候选码中的属性称为非码属性 ( 非主属性 ) 。在最简单的情况下，候选码只包含一个属性。在最极端的情况下，关系模式所有属性的组合构成关系模式的候选码，称为全码。

关系可以有三种类型 : 基本关系 ( 基本表 、 基表) 、 査询表和视图表。

1.  基本表是实际存在的表，它是实际存储数据的逻辑表示；
2.  査询表是査询结果对应的表；
3.  视图表是由基本表或其他视图表导出的表，是虚表，不对应实际存储的数据。

基本关系具有以下6条性质 :

1.  列是同质的，即每一列中的分量是同一类型的数据，来自同一个域 。
2.  不同的列可出自同一个域，称其中的每一列为一个属性，不同的属性要给予不同的属性名 。
3.  列的顺序无所谓，即列的次序可以任意交换 。
4.  任意两个元组不能完全相同。但在大多数实际关系数据库产品中，例如 Oracle 数据库，如果用户没有定义有关的约束条件，它们都允许关系表中存在两个完全相同的元组 。
5.  行的顺序无所谓，即行的次序可以任意交换 。
6.  分量必须取原子值，即每一个分量都必须是不可分的数据项。

![format_png 3][]

关系实际上就是关系模式在某一时刻的状态或内容。也就是说，关系模式是型，关系是它的值。关系模式是静态的 、 稳定的；而关系是动态的 、 随时间不断变化的，因为关系操作在不断地更新着数据库中的数据。但在实际当中，常常把关系模式和关系，统称为关系，我们可以从上下文中加以区别。

在关系模型中，实体以及实体间的联系都是用关系来表示。在一个给定的现实世界领域中，相应于所有实体及实体之间的联系的关系的集合构成一个关系数据库。

关系数据库也有型和值之分。关系数据库的型也称为关系数据库模式，是对关系数据库的描述，是关系模式的集合。关系数据库的值也称为关系数据库，是关系的集合。关系数据库模式与关系数据库通常统称为关系数据库 。

## 4 数据的规范化 ##

关系模型满足的确定约束条件称为范式，根据满足约束条件的级别不同，范式由低到高分为 1NF（第一范式）、 2NF（第二范式）、 3NF（第三范式）、 BCNF（BC 范式）、 4NF（第四范式）等。不同的级别范式性质不同。

把一个低一级的关系模型分解为高一级关系模型的过程，称为关系模型的规范化。关系模型分解必须遵守两个准则。  
（1）无损连接性：信息不失真（不增减信息）。  
（2）函数依赖保持性：不破坏属性间存在的依赖关系。

规范化的基本思想是逐步消除不合适的函数依赖，使数据库中的各个关系模型达到某种程度的分离。规范化解决的主要是单个实体的质量问题，是对于问题域中原始数据展现的正规化处理。

规范化理论给出了判断关系模型优劣的理论标准，帮助预测模式可能出现的问题，是数据库逻辑设计的指南和工具，具体有：  
（1）用数据依赖的概念分析和表示各数据项之间的关系。  
（2）消除 E-R 图中的冗余联系。

### 4.1 函数依赖 ###

通俗地说，就像自变量 x 确定之后，相应的函数值 f(x)也就唯一确定了一样，函数依赖是衡量和调整数据规范化的最基础的理论依据。

例如，记录职工信息的结构如下：

*  职工工号（EMP\_NO）
 *  职工姓名（EMP\_NAME）
 *  所在部门（DEPT）。

![format_png 4][]

则说 EMP\_NO 函数决定 EMP\_NAME 和 DEPT，或者说 EMP\_NAME， DEPT 函数依赖于 EMP\_NO，记为： EMP\_NO→EMP\_NAME， EMP\_NO→DEPT。

关系 R<U， F>中的一个属性或一组属性 K，如果给定一个 K 则唯一决定 U 中的一个元组，也就是 U 函数完全依赖于 K，就称 K 为 R 的码。一个关系可能有多个码，选中其中一个作为主码。

包含在任一码中的属性称为主属性，不包含在任何码中的属性称为非主属性。

关系 R 中的属性或属性组 X 不是 R 的码，但 X 是另一个关系模型的码，称 X 是 R 的外码。

主码和外码是一种表示关系间关联的重要手段。数据库设计中一个重要的任务就是要找到问题域中正确的关联关系，孤立的关系模型很难描述清楚业务逻辑。

数学表述如下：  
![format_png 5][]

![format_png 6][]

![format_png 7][]

![format_png 8][]

![format_png 9][]

![format_png 10][]

![format_png 11][]

### 4.2 分解关系模式 ###

如果某关系模式存在存储异常问题，则可通过分解该关系模式来解决问题。把一个关系模式分解成几个子关系模式，需要考虑的是该分解是否保持函数依赖，是否是无损联接。

![format_png 12][]

![format_png 13][]

![format_png 14][]

#### 4.2.1 第一范式 ####

1NF （Normal Form）是最低的规范化要求。如果关系 R 中所有属性的值域都是简单域，其元素（即属性）不可再分，是属性项而不是属性组，那么关系模型 R 是第一范式的。这一限制是关系的基本性质，所以任何关系都必须满足第一范式。第一范式是在实际数据库设计中必须先达到的，通常称为数据元素的结构化。

例如，表 1 所示的结构就不满足 1NF 的定义。因为住址是属性组，还可以再细分。

![format_png 15][]

表 1 为非第一范式，可以分解为表 2：

![format_png 16][]

就满足了第一范式。经过处理后，就可以以省、市为条件进行查询和统计了。

满足 1NF 的关系模型会有许多重复值，并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免出现忘记更新数据现象，我们需要更加规范的 2NF。

#### 4.2.2 第二范式 ####

如果一个关系 R 属于 1NF，且所有的非主属性都完全依赖于主属性，则称之为第二范式。

为了说明问题，现举一个例子来说明：  
有一个获得专业技术证书的人员情况登记表结构为：  
省份、姓名、证书名称、证书编号、核准项目、发证部门、发证日期、有效期。

![format_png 17][]

这个结构符合 1NF，其中“证书名称”和“证书编号”是主码，但是因为“发证部门”只完全依赖于“证书名称”，即只依赖于主关键字的一部分（即部分依赖），所以它不符合 2NF，这样首先存在数据冗余，因为证书种类可能不多。其次，在更改发证部门时，如果漏改了某一记录，存在数据不一致。再次，如果获得某种证书的职工全部跳槽了，那么这个发证部门的信息就可能丢失了，即这种关系不允许存在某种证书没有获得者的情况。

可以用分解的方法消除部分依赖的情况，而使关系达到 2NF 的标准。方法是，从现有关系中分解出新的关系表，使每个表中所有的非关键字都完全依赖于各自的主关键字。可以分解成两个表（省份、姓名、证书名称、证书编号、核准项目、发证日期、有效期）和（证书名称、发证部门），这样就完全符合 2NF 了。

![format_png 18][]

#### 4.2.3 第三范式 ####

如果一个关系 R 属于 2NF，且每个非主属性不传递依赖于主属性，这种关系是 3NF。

从 2NF 中消除传递依赖，就是 3NF。例如，有一个表（职工姓名，工资级别，工资额），其中职工姓名是关键字，此关系符合 2NF，但是因为工资级别决定工资额，也就是说非主属性“工资额”传递依赖于主属性“职工姓名”，它不符合 3NF，同样可以使用投影分解的办法分解成两个表：（职工姓名，工资级别），（工资级别，工资额）。

2NF 转换为 3NF：  
![format_png 19][]

![format_png 20][]

#### 4.2.4 BC 范式 ####

一般满足 3NF 的关系模型已能消除冗余和各种异常现象，获得比较满意的效果，但无论 2NF 还是 3NF 都没有涉及主属性间的函数依赖，所以有时仍会引起一些问题。由此引入 BC 范式（由 Boyeet 和 Codd 提出）。通常认为 BCNF 是第三范式的改进。

--------------------

![format_png 21][]

## 5 反规范化 ##

数据库中的数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O 次数减少，同时加快了增、删、改的速度，但是对完全规范的数据库查询，通常需要更多的连接操作，从而影响查询速度。因此，有时为了提高某些查询或应用的性能而破坏规范规则，即反规范化（非规范化处理）。

常见的反规范化技术包括：

**（1）增加冗余列**

增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。例如：以规范化设计的理念，学生成绩表中不需要字段“姓名”，因为“姓名”字段可以通过学号查询到，但在反规范化设计中，会将“姓名”字段加入表中。这样查询一个学生的成绩时，不需要与学生表进行连接操作，便可得到对应的“姓名”。

**（2）增加派生列**

增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。例如：订单表中，有商品号、商品单价、采购数量，我们需要订单总价时，可以通过计算得到总价，所以规范化设计的理念是无须在订单表中设计“订单总价”字段。但反规范化则不这样考虑，由于订单总价在每次查询都需要计算，这样会占用系统大量资源，所以在此表中增加派生列“订单总价”以提高查询效率。

**（3）重新组表**

重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。

**（4）分割表**

有时对表做分割可以提高性能。表分割有两种方式。

1.  水平分割：根据一列或多列数据的值把数据行放到两个独立的表中。水平分割通常在下面的情况下使用。

*  情况 1：表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询效率。
 *  情况 2：表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。
 *  情况 3：需要把数据存放到多个介质上。

1.  垂直分割：把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少 I/O 次数。其缺点是需要管理冗余列，查询所有数据需要连接操作。

[format_png]: /images/20230528/d85ee83649b64245a44e7e340c700849.png
[format_png 1]: /images/20230528/5c68375b1da146a1a833bb68a10bdef2.png
[format_png 2]: /images/20230528/e056ca1fcdbc489abca2d57ddd299d9b.png
[format_png 3]: /images/20230528/47db3e0510404e599dd83a83c72899bb.png
[format_png 4]: /images/20230528/0cdf4174040443d6a400c7c9a39d1325.png
[format_png 5]: /images/20230528/991d690617784b958d7ae0a86af9c991.png
[format_png 6]: /images/20230528/8547b27a82074803bf0465b192def16f.png
[format_png 7]: /images/20230528/3de8a7962d9a4723879992c636957b6b.png
[format_png 8]: /images/20230528/a181e97a2ea44333849f34de99b73384.png
[format_png 9]: /images/20230528/2e193290e88549d5a79079317f9b2d17.png
[format_png 10]: /images/20230528/caddc949f25544298b4ffb3717d80727.png
[format_png 11]: /images/20230528/81573205cedc43b490b3b4da23844b35.png
[format_png 12]: /images/20230528/10be546cdaba4bf3a10b5f882c152fe2.png
[format_png 13]: /images/20230528/5bafdcc1d7b445e0862d86995702ba60.png
[format_png 14]: /images/20230528/e39bcc8fdbff4e22823e54301dacb41e.png
[format_png 15]: /images/20230528/dcceec882ee246d0a6d3e426b4b9e55f.png
[format_png 16]: /images/20230528/60ce4168dc6c487690968a371f840db3.png
[format_png 17]: /images/20230528/9b1b6dfc19e2434c83bc187ea730b3dc.png
[format_png 18]: /images/20230528/e9de6b671b0545bcadb458359e9ebfc6.png
[format_png 19]: /images/20230528/69c08f41d89f4884982ce831a93769fb.png
[format_png 20]: /images/20230528/50c3fbad499b41c6b66e020943b7b9f2.png
[format_png 21]: /images/20230528/362f4f8b48f642e08cd71718cd5b2677.png