数据库系统概论

基础与模型类术语

数据

信息的符号表示，是数据库存储的基本对象。它本身没有特定的含义，是对客观事物属性的抽象表示。
eg：28是一个数据，但是如果知道它代表年龄，那它就被赋予了语境和含义，成为了信息。

数据库

数据库是长期存储在计算机内、有组织的、可共享的、统一管理的数据集合。它不仅仅是一堆数据的堆积，而是以某种数据模型组织起来，可以被多个用户和应用共享。

数据库的关键点如下：

长期存储：与内存中的临时数据不同，数据库数据是持久化的。
有组织：数据按照特定的结构（如表格）存放，而不是杂乱无章。
可共享：多个用户或应用程序可以同时访问和使用数据库。

数据库管理系统

数据库管理系统（Database Management System, DBMS）是一个位于用户（或应用程序）与操作系统之间的系统软件。它的核心任务是科学地组织和存储数据，并高效地获取和维护数据。

数据库管理系统的核心功能包括：包括数据定义、数据操作、数据存储与管理、数据库的建立与维护等。

eg: MySQL, Oracle是关系型 DBMS 的代表；MongoDB, Redis 是非关系型 DBMS 的代表。

数据库系统是由数据库，数据库管理系统，应用程序和数据库管理员组成的存储，管理，处理和维护数据的系统。

OLTP 和 OLAP

OLTP 和 OLAP 的共性：

OLTP 和 OLAP 都是用于存储和处理大量数据的数据库管理系统。

OLTP 和 OLAP 的区别：

“联机事务处理 (OLTP) ”系统的主要用途是处理数据库事务。

“联机分析处理 (OLAP) ”系统的主要用途是分析聚合数据。

OLTP 是业务的“手和脚”，负责干活，讲究快和准。MySql倾向于这一类数据库。
OLAP 是业务的“大脑”，负责思考，讲究深和广。

数据模型

数据模型是描述数据、数据之间的联系、数据语义以及数据一致性约束的概念工具的集合。它是数据库系统的核心和基础，决定了数据如何被组织。

数据模型可以分为两类：第一类是概念模型，第二类是逻辑模型和物理模型。

概念模型

概念模型也称为信息模型，它是按照用户的观点来对数据和信息建模，主要用于数据库设计。

概念模型主要涉及以下一些概念：

实体 - 客观存在并可相互区别的事务称为实体。
属性 - 实体具有的某一特性称为属性。
码 - 唯一标识实体的属性集称为码。
实体模型 - 用实体名及其属性名集合来抽象和刻画同类实体，称为实体模型。
实体集 - 同一类型实体的集合就是实体集。
联系
- 实体之间的联系通常指的是不同实体集之间的联系。
- 实体之间的联系有一对一，一对多和多对多等多种类型。

概念模型的一种表示方法是：实体-联系方法，该方法使用 ER 图来描述现实世界的概念模型，ER 方法也成为 ER 模型。

逻辑模型

数据库逻辑模型是将概念模型（如E-R图）转换为特定数据库管理系统（DBMS）所能理解和实现的逻辑结构的过程。它独立于具体的物理存储方式，但依赖于所选的数据模型（主要是关系模型）。

关系模型是目前主流数据库（即关系型数据库）所采用的数据模型

函数依赖

定义：设 R(U) 是属性集合 U={ A1, A2, … , An } 上的一个关系模式，X, Y 是 U 上的两个子集，若对 R(U) 的任意一个可能的关系 r ，r 中不可能有两个元组(行)满足在 X 中的属性值相等而在 Y 中的属性值不等，则称 “ X 函数决定 Y ” 或 “ Y 函数依赖于 X ” ，记作 X->Y 。

本质：函数依赖的本质就是反应了一个关系中属性之间的约束关系，或者依赖关系。函数依赖是一种数据依赖。

举例：

1 2	U = { 学号，姓名，年龄，专业 } {学号} → { 姓名，年龄，专业 }

范式

数据库规范化，又称“范式”，是数据库设计的指导理论,是数据库逻辑设计的黄金法则。它的目标是：设计出结构合理、冗余最少、数据一致性高的数据库表结构。

范式是层层递进的，高一级的范式必然满足低一级范式的要求。我们最常用的是前三个范式，下图展示了从非规范化表通过逐步拆解，达到更高范式的流程：

    flowchart TD
    A["非规范化表<br>包含重复组和冗余数据"] --> B["第一范式 (1NF)<br>消除重复组， 确保原子性"]
    B --> C["第二范式 (2NF)<br>消除部分函数依赖"]
    C --> D["第三范式 (3NF)<br>消除传递函数依赖"]
    D --> E["鲍依斯-科德范式 (BCNF)<br>强化3NF， 消除主属性间的依赖"]

    B --> B_Problem["问题: 存在部分依赖"]
    C --> C_Problem["问题: 存在传递依赖"]
    D --> D_Problem["问题: 主属性可能部分/传递依赖于候选键"]

    B_Problem --> C
    C_Problem --> D
    D_Problem --> E

第一范式 (1NF)

1NF 要求属性具有原子性，不可再分解。数据库表中的每一列都是不可再分的原子值：

每个字段只能有一个值
不能有数组、集合或者可以在分割的复合值

eg:

违反1NF：联系方式字段存储为 “手机：138xxx，电话：010-xxxx”。
符合1NF：拆分成手机号和固定电话两个独立的列。

1NF是所有关系型数据库的基本要求。

第二范式 (2NF)

2NF 要求记录有唯一标识，即实体的唯一性，即不存在部分依赖。说白话就是要求表里的所有非主属性，都必须完全函数依赖于整个主键

假设有一张 student 表，结构如下：

1 2	-- 学生表 student(学号、课程号、姓名、学分、成绩)

举例来说，现有一张 student 表，具有学号、课程号、姓名、学分等字段。从中可以看出，表中包含了学生信息和课程信息。由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖学号，所以不符合 2NF。

不符合 2NF 可能会存在的问题：

数据冗余 - 每条记录都含有相同信息。
删除异常 - 删除所有学生成绩，就把课程信息全删除了。
插入异常 - 学生未选课，无法记录进数据库。
更新异常 - 调整课程学分，所有行都调整。

根据 2NF 可以拆分如下：

-- 学生表
student(学号、姓名)
-- 课程表
course(课程号、学分)
-- 学生课程关系表
student_course(学号、课程号、成绩)

第三范式 (3NF)

如果一个关系属于第二范式，并且在两个(或多个)非主键属性之间不存在函数依赖（非主键属性之间的函数依赖也称为传递依赖），那么这个关系属于第三范式。

3NF 是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖。

传递依赖：指的是一个非主属性（B）依赖于另一个非主属性（C），而C又依赖于主键（A）。即 主键A -> 非主键C -> 非主键B。

假设有一张 student 表，结构如下：

1 2	-- 学生表 student(学号、姓名、年龄、班级号、班主任)

上表属于第二范式，因为主键由单个属性组成（学号）。

因为存在依赖传递：(学号) → (学生)→(所在班级) → (班主任) 。

可能会存在问题：

数据冗余 - 有重复值；
更新异常 - 有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。

可以基于 3NF 拆解：

1 2	student(学号、姓名、年龄、所在班级号) class(班级号、班主任)

口诀：

第一范式的列不可分；
第二范式的属性完全依赖于主键；
第三范式的属性不依赖于其它非主属性。

反范式

范式是设计的指导原则，不是铁律。有时为了提高查询效率，有必要适当的冗余数据，以达到空间换时间的目的——这就是“反范式”。

ER 图

E-R 图又称实体关系图，是一种提供了实体，属性和联系的方法，用来描述现实世界的概念模型。通俗点讲就是，当我们理解了实际问题的需求之后，需要用一种方法来表示这种需求，概念模型就是用来描述这种需求。

ER 图中的要素：

实体 - 用矩形表示。
属性 - 用椭圆形表示。
主键 - 在属性下方标记下划线。
联系 - 用菱形表示。实体之间的联系通常有 3 种类型：一对一联系，一对多联系，多对多联系。

绘制 ER 图常用软件：

Visio - Office 的绘图工具，特点是简单、清晰。
ProcessOn 官网 - 在线绘图工具，特点是简洁、清晰。

参考资料

https://dunwu.github.io/