第二章 数据库基础概念：从数据到数据库系统的核心术语

在正式学习 openGauss 数据库之前，我们首先需要建立一套统一的“语言体系”。数据库领域中的术语看似简单，但往往容易混淆——例如“数据库”与“数据库管理系统”有什么区别？“行”与“记录”是否完全等同？主键与外键在物理存储上有什么不同？本章将围绕数据管理的核心概念展开，从数据出发，逐层剖析数据库、数据库管理系统、数据库系统之间的关系，并深入讲解关系模型中的表、行、列、主键、外键等关键术语。这些概念不仅是后续学习 SQL 语句的基础，更是理解 openGauss 内部存储引擎、事务机制和约束逻辑的基石。

2.1 数据与数据库：从零散记录到结构化存储

2.1.1 核心原理：数据的定义与层次

数据（Data）是描述事物的符号记录，可以是数字、文字、图形、图像、音频等。在数据库中，数据不仅仅是“值”，还包含其语义——例如数字“28”本身没有意义，但若与“学生年龄”关联，就构成了有效信息。数据在计算机中经历了从位（bit）→ 字节（Byte）→ 字段（Field）→ 记录（Record）→ 表（Table）→ 数据库（Database）的层次化组织过程。

数据库（Database，简称 DB）是长期存储在计算机内、有组织、可共享的数据集合。它具有三个显著特征：永久存储（非临时文件）、有组织（按特定数据模型组织）、可共享（多用户并发访问）。openGauss 作为企业级关系型数据库，其数据文件在磁盘上以特定格式存储，并通过缓冲区管理机制提供高效读写。

2.1.2 判断方法：区分“数据”与“数据库”

2.1.3 案例拆解：学生成绩管理场景

假设我们需要管理一个班级的学生成绩。初始状态下，我们可能有一堆纸质记录或 Excel 表格，这些是数据。当我们将这些数据按照“学号、姓名、科目、成绩”的固定格式录入 openGauss，并建立 student 表和 score 表时，就构成了一个数据库。此时，数据从无序变为有序，从孤立变为关联。

2.1.4 常见误区

• 误区一：认为“数据库”就是“数据库文件”。实际上，数据库是逻辑概念，文件只是其物理载体之一。
• 误区二：混淆“数据”与“信息”。数据是原始记录，信息是经过加工后对决策有意义的产物。

2.2 数据库管理系统与数据库系统：软件与整体的边界

2.2.1 核心原理：DBMS 与 DBS 的职责划分

数据库管理系统（Database Management System，简称 DBMS）是位于用户与操作系统之间的数据管理软件。它负责数据的定义（DDL）、操纵（DML）、控制（DCL）和维护。openGauss 就是一个典型的 DBMS，它提供了 SQL 解析、事务管理、并发控制、故障恢复等核心能力。

数据库系统（Database System，简称 DBS）是一个更宽泛的概念，它由四部分组成：数据库（DB）、数据库管理系统（DBMS）、应用程序、数据库管理员（DBA）和用户。可以这样理解：DBS = DB + DBMS + 应用 + 人员 + 硬件环境。

2.2.2 操作流程：从用户请求到数据返回

1. 用户通过应用程序（如 JDBC 客户端）发出 SQL 查询请求。
2. DBMS 的查询解析器对 SQL 进行词法、语法分析。
3. 优化器生成执行计划，选择最优索引路径。
4. 存储引擎访问磁盘中的数据文件，将结果返回。
5. DBMS 通过事务日志保证操作的原子性和持久性。

2.2.3 实战场景：openGauss 安装后的组件识别

当你完成 openGauss 安装后，通过 ps -ef | grep gauss 可以看到多个进程，如 gaussdb 主进程、gs_clean 辅助进程等。这些进程共同构成了 DBMS 的运行时实例。而当你使用 Data Studio 工具连接数据库并执行查询时，你正在使用一个完整的 DBS——包括客户端工具、网络连接、数据库服务端以及底层的操作系统文件系统。

2.2.4 常见误区与复盘

• 误区：认为“安装 openGauss 就是部署了数据库系统”。实际上，安装的只是 DBMS 软件，还需要创建数据库、配置用户、部署应用，才能形成完整的 DBS。
• 复盘：在故障排查时，要区分是 DBMS 层面的问题（如进程崩溃）还是应用层面的问题（如 SQL 写错），这决定了排查方向。

2.3 关系模型与表结构：二维世界的严谨之美

2.3.1 核心原理：关系模型的数学基础

关系模型（Relational Model）由 E.F. Codd 于 1970 年提出，它用二维表来表示实体及实体间的联系。关系模型中的术语与日常用语有严格对应：关系（Relation）即表（Table），元组（Tuple）即行（Row），属性（Attribute）即列（Column）。openGauss 完全遵循关系模型，支持 ACID 事务特性。

关系模型要求每一列必须是原子性的（不可再分），且同一列的数据类型必须一致。行在表中的顺序无关紧要，但列的顺序是固定的（由建表语句决定）。

2.3.2 判断方法：如何设计一张规范的表

2.3.3 案例拆解：openGauss 建表实操

-- 创建学生表
CREATE TABLE student (
    student_id INTEGER PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    age INTEGER CHECK (age > 0),
    department VARCHAR(100) DEFAULT '未分配'
);

-- 创建成绩表
CREATE TABLE score (
    student_id INTEGER,
    course_name VARCHAR(50),
    score NUMERIC(5,2),
    PRIMARY KEY (student_id, course_name),
    FOREIGN KEY (student_id) REFERENCES student(student_id)
);

在上述示例中，student 表的主键是 student_id，score 表使用复合主键 (student_id, course_name)，并通过外键关联到学生表。这种设计确保了数据的引用完整性——如果某个学生不存在，则无法为其添加成绩记录。

2.3.4 常见误区与总结

• 误区一：允许表中出现重复行。关系模型要求表中不能有完全相同的两行，必须通过主键区分。
• 误区二：将外键视为普通字段。外键不仅是字段，更是一种约束，它强制了表间的一致性。
• 总结：关系模型的核心是“规范化”，通过拆分表消除数据冗余，通过主外键建立关联。

2.4 主键与外键：数据完整性的守护者

2.4.1 核心原理：约束的本质

主键（Primary Key）是表中用于唯一标识每一行的字段或字段组合。其特性包括：唯一性（不能重复）、非空性（不能为 NULL）、稳定性（值不应频繁修改）。在 openGauss 中，主键会自动创建唯一索引，加速查询。

外键（Foreign Key）是表中引用另一表主键的字段。它用于建立和强制表之间的关联，保证引用完整性。外键可以引用自身表的主键（自引用），也可以引用其他表。

2.4.2 操作流程：主外键的设计与验证

1. 识别实体关系：确定一对多、多对多关系。
2. 在“多”方添加外键：例如成绩表（多）引用学生表（一）。
3. 定义约束行为：使用 ON DELETE CASCADE 或 ON DELETE RESTRICT 控制删除策略。
4. 验证完整性：尝试插入无效外键值，观察数据库报错。

2.4.3 案例拆解：订单系统的外键策略

假设有一个电商订单系统，包含 customer（客户）和 orders（订单）两张表。客户表主键为 customer_id，订单表通过 customer_id 外键关联。当删除一个客户时，有两种策略：

• CASCADE（级联删除）：自动删除该客户的所有订单。适用于订单无保留价值的场景。
• RESTRICT（限制删除）：若存在订单则拒绝删除客户。适用于需要保留历史订单的场景。

在 openGauss 中，可以通过以下语句实现：

CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES customer(customer_id) ON DELETE CASCADE
);

2.4.4 常见误区与复盘

• 误区一：认为主键只能是一个字段。实际上，复合主键（多个字段组合）在关联表中非常常见。
• 误区二：忽略外键索引。在 openGauss 中，外键列不会自动创建索引，这可能导致连接查询时全表扫描。建议手动为外键列创建索引。
• 复盘：在数据库设计评审时，应重点检查外键的删除策略是否符合业务预期，避免因误用 CASCADE 导致数据批量丢失。