数据库基础知识体系：概念、约束、范式与国产产品

数据库基础知识体系：概念、约束、范式与国产产品

数据库（Database）是按照数据结构来组织、存储和管理数据的仓库，其核心目标是高效、安全地处理大量数据的增删改查操作，广泛应用于网站后台、企业管理系统、金融交易系统等各类场景。

一、数据库的核心概念

1.数据（Data）

数据库中存储的基本单元，包括数字、文本、图片、音频等多种格式。例如：用户的姓名、年龄、手机号。

2.数据表（Table）

数据库中数据的主要存储形式，采用行（Row）和列（Column） 的二维结构组织数据，类似 Excel 表格。

列（字段 / Field）：代表数据的属性，每一列有固定的数据类型（如整数、字符串、日期）。

行（记录 / Record）：代表一条完整的数据，是多个字段的组合。

例：用户表（user）

id	name	age	phone
1	张三	25	13800138000
2	李四	30	13900139000

3.数据库管理系统（DBMS）

用于管理数据库的软件，用户通过 DBMS 与数据库交互，执行数据的创建、查询、更新和删除操作。常见的 DBMS 有 MySQL、Oracle、PostgreSQL、SQL Server 等。

4.结构化查询语言（SQL）

操作关系型数据库的标准语言，分为三类核心指令：

数据定义语言（DDL）：创建 / 修改 / 删除数据库、表结构，如 CREATE、ALTER、DROP。

数据操作语言（DML）：增删改数据，如 INSERT、DELETE、UPDATE。

数据查询语言（DQL）：查询数据，核心指令为 SELECT。

二、数据库的分类

根据数据的存储结构和组织方式，数据库主要分为两大类型：

1. 关系型数据库（RDBMS）

核心特点：以二维表结构存储数据，表与表之间通过主键（Primary Key）和外键（Foreign Key） 建立关联关系，支持事务（ACID 特性）和复杂的多表查询。

主键（PK）：唯一标识表中一条记录的字段，不可重复、不可为空，例如用户表的 id。

外键（FK）：用于关联两个表的字段，指向另一个表的主键，例如订单表的 user_id 关联用户表的 id。

ACID 特性：保证事务的可靠性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

原子性（Atomicity）：事务是一个不可分割的最小工作单元，事务中的所有操作要么全部执行成功，要么全部执行失败并回滚到事务执行前的状态。

一致性（Consistency）：事务执行前后，数据库的数据完整性约束保持不变，数据始终处于合法、一致的状态。

隔离性（Isolation）：当多个事务并发执行时，不同事务之间相互隔离，一个事务的执行不能被其他事务干扰，每个事务都感觉不到其他事务的存在。

持久性（Durability）：一个事务一旦提交（Commit），其对数据库中数据的修改就是永久性的，接下来的其他操作或系统故障都不会影响已提交的事务数据。

代表产品：MySQL（开源常用）、Oracle（企业级商用）、PostgreSQL（开源高级特性丰富）、SQL Server（微软生态）。

2. 非关系型数据库（NoSQL）

核心特点：不依赖二维表结构，存储格式灵活（键值对、文档、列族、图形等），主要用于处理海量、高并发、非结构化或半结构化数据，牺牲部分事务一致性换取高性能。

常见类型及代表

类型	存储格式	代表产品	适用场景
键值型	Key-Value	Redis	缓存、会话存储、计数器
文档型	JSON/BSON 文档	MongoDB	日志存储、内容管理系统
列族型	列族式存储	HBase	大数据分析、时序数据存储
图形型	节点和边	Neo4j	社交网络、推荐系统

三、数据库的核心功能

1.数据存储

按照预设的结构（如关系型表、NoSQL 文档）持久化存储数据，支持海量数据的高效写入。

2.数据查询

提供灵活的查询能力，支持单表查询、多表关联查询、条件筛选、排序、分页等操作。

3.数据更新与删除

支持对已有数据的修改和删除，保证操作的原子性。

4.事务管理

关系型数据库的核心能力，确保一组操作要么全部成功，要么全部失败，避免数据不一致。

5.权限控制

对不同用户分配不同的操作权限（如只读、读写、管理员权限），保障数据安全。

6.索引优化

通过创建索引（类似书籍的目录），大幅提升数据查询的效率。

四、数据库的常用术语

1.索引（Index）

对表中一个或多个字段的值进行排序的结构，用于加速查询，常见类型有主键索引、唯一索引、普通索引、复合索引。

注意：索引会提升查询速度，但会降低插入、更新、删除的速度，需合理创建。

2.视图（View）

基于一个或多个表的查询结果创建的虚拟表，不存储实际数据，仅保存查询逻辑，可简化复杂查询、限制数据访问范围。

3.存储过程（Stored Procedure）

预编译的 SQL 语句集合，存储在数据库中，可通过名称调用，支持参数传递，能减少网络传输、提高执行效率。

4.触发器（Trigger）

与表关联的特殊存储过程，当表发生 INSERT/UPDATE/DELETE

操作时自动执行，常用于数据校验、日志记录等场景。

5.游标（Cursor）

数据库游标（Cursor）：逐行处理数据的 “指针”

游标是关系型数据库中用于逐行读取和处理查询结果集的数据库对象，它就像一个 “指针”—— 普通的 SELECT 查询会一次性返回所有符合条件的结果集，而游标可以让你精准定位到结果集中的某一行，逐个读取、修改甚至删除该行数据，特别适合处理需要逐行判断或操作的复杂业务逻辑。

(1) 特性

面向行操作：突破 SQL"面向集合" 的特性，将批量结果集拆解为单行处理；

可定位性：支持在结果集中前后移动指针（如移到第一行、最后一行、下一行）；

可操作性：部分游标支持修改 / 删除当前指向的行数据；

会话级生命周期：游标绑定到数据库会话，会话结束后游标自动销毁。

(2) 游标的适用场景

游标通常用于普通 SQL 语句难以实现的逐行处理场景，比如：

批量更新数据时，需要根据每行的具体值做不同逻辑判断（如按用户等级调整积分）；

逐行读取大结果集，避免一次性加载所有数据导致内存溢出；

数据迁移 / 清洗时，对每行数据做复杂的格式转换或校验。

注意：游标会降低数据库性能（逐行操作比批量操作慢），仅在无法用批量 SQL（如 UPDATE ... WHERE）实现时使用。

(3) 游标的使用步骤

游标使用遵循固定流程：声明 → 打开 → 读取 → 关闭 → 释放

5.数据库三大范式

范式（Normal Form，NF）是判断数据库表结构设计是否合理的标准，遵循的范式级别越高，数据冗余越低，但多表关联的复杂度会上升。

第一范式（1NF）：原子性

定义：表中的每一列都必须是不可再分的原子数据项，不能存在复合字段或多值字段。

反例：用户表中设计 contact 字段存储 电话-邮箱，违反原子性。

id	name	contact
1	张三	13800138000-zhangsan@xxx.com

正例：拆分为独立字段，满足原子性。

id	name	phone	email
1	张三	13800138000	zhangsan@xxx.com

第二范式（2NF）：唯一性

定义：在满足 1NF 的基础上，非主键字段必须完全依赖于主键，而不能依赖于主键的一部分（主要针对联合主键场景）。

前提：当表的主键是多个字段的组合（联合主键）时，才会涉及 2NF 的判断。

反例：订单明细表（联合主键：order_id + product_id）中包含 user_name 字段。

order_id	product_id	product_name	user_name	price
1001	2001	小米手机	张三	2999
1001	2002	华为耳机	张三	399
问题：user_name 只依赖 order_id（订单属于哪个用户），不依赖 product_id，违反 2NF。

正例：拆分表，消除部分依赖。

订单表（order_id 为主键）：存储订单与用户的关联

order_id	user_name	order_time
1001	张三	2025-01-01

订单明细表（联合主键：order_id + product_id）：存储订单与商品的关联

order_id	product_id	product_name	price
1001	2001	小米手机	2999
1001	2002	华为耳机	399

第三范式（3NF）：传递性

定义：在满足 2NF 的基础上，非主键字段不能传递依赖于主键，即非主键字段之间不能存在依赖关系。

传递依赖：A → B，B → C → 则 A → C（A 是主键）。

反例：用户表（user_id 为主键）中包含 city和 province字段。

user_id	user_name	city	province
1	张三	深圳市	广东省
问题：province 依赖 city，city 依赖 user_id → province 传递依赖于 user_id，存在冗余（多个深圳用户会重复存储 “广东省”）。

正例：拆分表，消除传递依赖。

用户表

user_id	user_name	city_id
1	张三	1

城市表（city_id 为主键）

city_id	city	province
1	深圳市	广东省

5.数据库的完整性约束

数据库的完整性约束是指为了保证数据库中数据的正确性、一致性和有效性，对数据表及数据操作施加的一系列规则限制。其目标是防止非法、无效的数据进入数据库，避免因数据错误导致业务逻辑异常。

分类：

(1) 实体完整性约束（Entity Integrity）

目标：保证表中每条记录都是唯一可识别的，即主键字段的唯一性和非空性。

约束类型：

主键约束（PRIMARY KEY）：

定义：表的主键字段必须唯一且非空，一个表只能有一个主键（可以是单一字段或联合字段）。

示例：

1. CREATE TABLE user (
2. id INT PRIMARY KEY AUTO_INCREMENT, -- 主键约束，自增保证唯一性
3. name VARCHAR(20) NOT NULL
4. );

复制代码

唯一约束（UNIQUE）：

定义：保证字段值唯一，但允许单个空值（NULL）（多个 NULL 不视为重复），一个表可以有多个唯一约束。

示例：用户手机号不能重复

1. CREATE TABLE user (
2. id INT PRIMARY KEY AUTO_INCREMENT,
3. phone VARCHAR(11) UNIQUE -- 唯一约束
4. );

复制代码

区别：主键约束 = 唯一约束 + 非空约束；唯一约束可用于非主键的唯一标识字段（如手机号、邮箱）。

(2) 域完整性约束（Domain Integrity）

目标：保证表中字段的值符合预设的类型和规则，限制字段的取值范围、数据类型、格式等。

常见约束类型：

约束类型	作用	示例
数据类型约束	限制字段的数据类型（如 INT、VARCHAR、DATE）	age INT（年龄必须是整数）
非空约束（NOT NULL）	字段值不能为 NULL	name VARCHAR(20) NOT NULL
默认值约束（DEFAULT）	字段未赋值时，自动填充默认值	status TINYINT DEFAULT 0（状态默认 0）
检查约束（CHECK）	限制字段值的范围或条件（MySQL 8.0 后正式支持）	age INT CHECK (age > 0 AND age < 150)

示例:定义用户表的域约束

1. CREATE TABLE user (
2. id INT PRIMARY KEY AUTO_INCREMENT,
3. name VARCHAR(20) NOT NULL, -- 非空约束
4. age INT CHECK (age > 0), -- 检查约束：年龄必须大于0
5. gender CHAR(1) DEFAULT '未知' -- 默认值约束
6. );

复制代码

(3) 参照完整性约束（Referential Integrity）

目标：保证表与表之间的关联关系有效，防止出现孤立的外键数据，维护数据的一致性。

约束类型：

外键约束（FOREIGN KEY）

定义：子表的外键字段必须引用父表的主键或唯一键字段，外键值必须是父表中已存在的值，或为 NULL（若允许）。

关联操作：当父表数据被修改 / 删除时，可配置外键的联动策略：

• ON DELETE CASCADE：父表删除数据，子表关联数据自动删除
• ON UPDATE CASCADE：父表更新主键，子表关联外键自动更新
• ON DELETE SET NULL：父表删除数据，子表外键设为 NULL

示例:订单表（子表）关联用户表（父表）

1. -- 父表：用户表
2. CREATE TABLE user (
3. id INT PRIMARY KEY AUTO_INCREMENT,
4. name VARCHAR(20) NOT NULL
5. );
7. -- 子表：订单表，外键关联用户表id
8. CREATE TABLE order_info (
9. order_id INT PRIMARY KEY AUTO_INCREMENT,
10. user_id INT,
11. order_time DATETIME,
12. -- 外键约束
13. FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE
14. );

复制代码

注意：高并发场景中，为提升写入性能，部分系统会取消数据库外键约束，改为在业务代码中维护参照完整性。

(4) 用户定义完整性约束

目标：满足特定业务场景的自定义规则，是对上述三类约束的补充。

常见场景：

密码长度必须大于 6 位

邮箱格式必须符合 xxx@xxx.xxx

订单金额必须大于 0

实现方式：

1. 简单规则可通过 CHECK 约束实现；
2. 复杂规则可通过触发器（TRIGGER） 或存储过程实现；
3. 也可在业务代码层进行校验（如后端接口参数校验）。

(5) 自定义完整性约束（业务层补充）

在实际开发中，部分复杂的完整性规则无法通过数据库原生约束实现，需要在业务代码中完成，例如：

同一个用户不能在 1 分钟内重复下单

转账时，转出账户余额不能小于转账金额

五、数据库的应用场景

互联网领域：用户信息、订单数据、商品信息的存储与查询（如电商、社交平台）。

企业管理：员工档案、财务数据、客户关系管理（CRM）系统。

大数据领域：海量日志数据、时序数据的存储与分析（如 HBase+Spark）。

物联网（IoT）：设备采集的传感器数据存储与实时监控。

六、学习数据库的路径

掌握SQL 语法：熟练使用 SELECT、INSERT、UPDATE、DELETE 及多表关联查询（JOIN）。

理解关系型数据库设计原则：遵循三大范式，合理设计表结构、主键、外键。

学习数据库优化：索引设计、查询语句优化、分库分表、读写分离等。

了解NoSQL 数据库：根据业务场景选择合适的非关系型数据库，掌握其核心操作。

七、国产数据库

1、金融级分布式事务数据库（OLTP 核心）

产品	厂商	核心特性	典型场景
OceanBase	蚂蚁集团	原生分布式、强一致性、TPC-C 世界纪录、兼容 MySQL/Oracle	银行核心交易、支付清算、证券核心系统
TDSQL	腾讯云	金融级高可用、分布式扩展、HTAP 融合、多副本容错	银行信用卡核心、保险保单系统、政务支付
GoldenDB	中兴通讯	分布式事务强一致、证券交易市占率领先	证券交易、银行理财、基金清算

---

2、传统全栈自研数据库（信创核心）

产品	厂商	核心特性	典型场景
达梦 DM	达梦数据	全栈自研、高安全（等保四级）、兼容 Oracle	政务云、军工、国家电网、南方航空
人大金仓 KingbaseES	电科金仓	兼容 PostgreSQL/Oracle、适配国产芯片	政务核心系统、能源调度、军工管理
南大通用 GBase	南大通用	列式存储、MPP 并行计算、PB 级分析	电信数据仓库、金融风控、政务大数据

---

3、云原生数据库（云场景主流）

产品	厂商	核心特性	典型场景
PolarDB	阿里云	存储计算分离、秒级扩容、AI 融合优化	电商高并发、SaaS 多租户、政企云平台
GaussDB/openGauss	华为	全栈自主、OLTP/OLAP 双场景、鲲鹏优化	省级政务云、电信核心网、金融数据分析
TiDB	平凯星辰	MySQL 兼容、HTAP、弹性扩展、分布式 SQL	互联网中台、金融风控、物流调度

---

4、其他特色数据库

分析型：GBase 8a（南大通用，列式存储，适配数据仓库）、TDengine（时序数据，物联网 / 工业监控）。

时序 / 物联网：TDengine（高效时序存储，电力 / 车联网）、InfluxDB（国产适配版，监控数据）。

多模：GBase 8c（南大通用，多模多态分布式，适配混合负载）。

---

5、选型

场景匹配：金融核心选 OceanBase/TDSQL；政务信创选达梦 / 人大金仓；云原生选 PolarDB/GaussDB；HTAP 选 TiDB/TDSQL。

生态适配：优先适配国产芯片（龙芯、飞腾）、操作系统（麒麟、统信）与中间件。

性能与成本：分布式适合海量高并发；云原生适合弹性扩缩；传统架构适合稳态核心系统。