软考知识点16：数据库相关知识

简介

软考中，关于数据库的考点还是比较多的，为了简化学习过程，只用一个文件介绍重要知识点。

在数据库考点中，重难点就是 关系模式。

其次还有数据库建模方式、数据关系分析等等知识点，关于数据库的知识点很多是需要有一定的经验积累才能更好的理解的，所以可能对于很多人来说比较难，但是如果你能记住这些知识点题型的计算过程，一般也足以应付考试了。

本文将以实际举例的形式讲解一些难以理解的知识点，希望能够帮助大家理解。

关注公众号“月上老狗”，发送“软件设计师”，获取历年软件设计师软考真题。

关系模式

关于数据库的关系模式，通常会考察以下几个主要内容：

关系模式的定义
关系模式的组成
关系模式的表示
关系模式的基本概念
关系模式的规范化
关系模式的操作

关系模式的表示

关系模式（Relation Schema） 主要是在关系型数据库中，描述表结构的框架的一种方式。它是关系数据库的核心概念之一，定义了一个关系（表）的属性（列）及其属性间的约束。

关系型数据库包括：Mysql、Oracle等。

在考题中通常以 R(U, F) 的形式出现，可能是纯字母表示，可能是现实例子。如下是一个现实例子：

培训关系模式R（后面讲解中，将以此为示例）

属性 U = (培训科目，培训师，学生，成绩，时间，教室)

依赖集 F = {培训科目 →→ 培训师，(学生，培训科目) → 成绩，(时间，教室) → 培训科目，(时间，培训师) → 教室，(时间，学生) → 教室}

其中 U 可以认为一张表的全部列；F 可以认为是这些列的查询关系。

如：(学生，培训科目) → 成绩 表示通过 学生，培训科目 这两列的值，可以查到 成绩 这一列对应的值。

→ 前面的是条件，后面的是结果。

候补关键字（主键）

候补关键字：在关系模式中，可以作为主键的列，被称为候补关键字，有时也会被称为候补键、候补主键、主要键等等，没有确定性的名称，根据题意理解即可。

注意：一个候补关键字可能是多列的组合，也可能是一列；在一个关系中，可能只有一个候补关键字，也可能有多个。视题意辨别。

那么给定一个关系，如何找到候补关键字呢？

我个人有一个简单的解题思路：

在关系依赖中，找到哪一列或多列不能作为结果被其他条件查到；
针对性分析每一列和多列的组合，看看能否查到这个关系中的所有列；
如果这一列或多列的组合可以查到全部列，则这一列或这一个组合就是候补键。

当然这个思路不是我最先想到的，早就有这个理论，只不过我更习惯用正常的语言说出来，而不习惯使用那些高大上的概念词。

如上面提到的题目，已知有如下依赖关系：

培训科目 →→ 培训师
(学生，培训科目) → 成绩
(时间，教室) → 培训科目
(时间，培训师) → 教室
(时间，学生) → 教室

我们采用上面提到的解题思路：

根据字面关系，可以看到 时间、学生 这两列的数据是没有作为结果被任何条件所查的；
分析 时间、学生、时间和学生，这三种情况下，谁作为条件可以查询出（推导出）全部列？
- 首先：只以 时间 为条件，查不到任何列数据；
- 然后：只以 学生 为条件，也查不到任何列数据；
- 最后：以 时间和学生 组合查询时，可以查到 教室 ，然后相当于我们知道了三列数据：时间、学生、教室，有了这三列数据，继续查询，根据依赖关系可以看到能查询出（推导出）全部列数据。
根据上面的枚举分析，我们确定了，这个关系模式中的候补键只有 时间和学生 这个组合键！

通过上面求取候补键的过程，希望大家能掌握解题思路，但我一直在想，这个思路在现实工作中到底用在哪里呢？思来想去，也没有发现特别需要的地方。可能在分析数据库设计是否合理的时候，可以用以下这个思路吧，用于确定表中列的定义是否合理？你说呢？

范式

关于数据库的范式，不仅是在考试中经常出现，在工作的面试问题中也是十分重要，如果你没有掌握范式，那么读本文内容就是赚到了！

首先什么是范式？范式可以认为是数据库设计时的规范化程度。规范化是将关系模式转换为一系列符合一定规范的更小、更简单的关系模式的过程，以减少数据冗余和提高数据一致性。

说人话：范式是一个等级制度：数据库设计规范化的不同程度，可以分为不同的范式等级。

那么有哪几个范式呢？一般我们认为有四个层级的范式，以此层级越高，则表示越规范：

第一范式（1NF）：所有属性的值都是不可分割的原子值。
第二范式（2NF）：在 1NF 的基础上，消除部分依赖。
第三范式（3NF）：在 2NF 的基础上，消除传递依赖。
BC范式（BCNF）：在 3NF 的基础上，每个非主属性完全依赖于候选键。

大家可以看到，范式一定是逐级上升的，所以如果第一范式都不符合，那么后面的范式就不用再看了！

接下来我们还是来举例子，帮助你理解上面的鬼话！：

上面的 (培训科目，培训师，学生，成绩，时间，教室) 这些列，一般而言是符合第一范式的，那什么情况下时不符合第一范式的呢？假如把 培训科目 和 培训师 这两列的数据合并为一列，如原来培训科目：语文和 培训师：张三 这两个数据合并成了一列：语文老师张三，那就是不符合第一范式的，懂了没？语文老师张三 可以继续拆分成 语文、张三这两列数据，也就是 可以分割的数据 ，所以不符合第一范式。这一点一定要懂！

部份依赖是什么？通过关于【候补关键字】的学习，我们已经知道了这个关系中的候补关键字是 时间和学生 ，假如在这个关系中，增加一个 学生 → 性别 的依赖关系，此时，性别 与 时间 就没关系了，但是因为我们的候补关键字是 时间和学生 这个组合键，所以此时 性别 列就是 部份依赖 于 学生 ，这就是 部份依赖 ！由此可见，本示例中如果增加 学生 → 性别，那么就不符合第二范式，原示例中没有这个关系，所以符合第二范式！

传递依赖又是什么？其实我们在【候补关键字】解题时，已经用到了传递依赖。【最后：以 时间和学生 组合查询时，可以查到 教室 ，然后相当于我们知道了三列数据：时间、学生、教室，有了这三列数据，继续查询，根据依赖关系可以看到能查询出（推导出）全部列数据。】在这推导查询的过程中，因为我们时先经过 时间和学生 组合查询时，查到 教室 后，再使用 教室 作为条件去进一步查询，这就可以称为 传递依赖 ！所以可以知道本示例不符合第三范式，因为他有传递依赖的现象！

完全依赖就不用多说了吧。

重要提示：有一些特殊情况：在一个关系模式中，如果没有非主属性，则认为符合第三范式，无需再细究部份依赖、传递依赖。 什么是非主属性？看下面的【扩展】

扩展

主属性：在任意候补关键字中出现的列，就是主属性，否则就是非主属性！

建模方式

数据流图（`DFD`）

定义：数据流图是一种结构化分析方法，用于描述系统的功能和数据流动。它以图形化的方式表示系统的各种功能和数据流，以及功能之间的关系。

组成：数据流图主要由四种图元组成：

外部实体（External Entity）：与系统交互的外部对象或系统。
过程（Process）：执行某些功能或操作的模块或子系统。
数据流（Data Flow）：在系统中流动的数据或信息。
数据存储（Data Store）：系统中存储数据的地方，如数据库或文件。

目的：数据流图用于可视化系统的功能和数据流动，帮助分析系统的结构和交互过程，以便更好地设计和理解系统。

实体关系图（ERD）

定义：实体关系图是一种用于数据建模的图形化表示方法，用于描述系统中的实体及它们之间的关系。

组成：实体关系图主要由三种组件组成：

实体类型（Entity Type）：系统中具有独立身份的对象或事物。
属性（Attribute）：描述实体类型的特征或属性。
关系（Relationship）：实体类型之间的关联或联系。

目的：实体关系图用于描述系统中的数据结构和关系，帮助分析系统中的实体之间的联系和约束，以便更好地设计和规划数据库结构。

目录

简介