## 词汇
以下是一些在数据库领域中常用的中文术语及其简单解释,涵盖从基础概念到常见操作、优化等方面,供你在工作中参考使用。实际使用时可根据项目需要进行扩展或深入。
1. **数据库(Database)**
1. 存放数据的「容器」,是数据集中存储、管理以及组织的基础。常见数据库类型包括关系型数据库和非关系型数据库。
3. **表(Table)**
1. 数据的逻辑结构化存储单位,由行(记录)和列(字段)组成。
5. **字段 / 列(Field/Column)**
1. 表中的垂直结构,定义了每条记录所包含的数据属性。
7. **行 / 记录(Row / Record)**
1. 表中的横向结构,是数据库中实际存储的一条数据。
9. **主键(Primary Key)**
1. 唯一标志表中每条记录的字段或字段组合,不可重复且不能为空。
11. **外键(Foreign Key)**
1. 用于建立表与表之间的关系,引用另一个表的主键以维护数据一致性和完整性。
13. **视图(View)**
1. 基于表或其他视图的逻辑查询结果,存储的是查询语句而非实际数据,常用于简化查询或控制访问权限。
15. **索引(Index)**
1. 用于加速查询的数据结构,常见类型包括 B-Tree 索引、Hash 索引等。使用不当可能导致插入或更新操作变慢。
17. **事务(Transaction)**
1. 数据库操作的最小逻辑单元,必须满足 ACID 特性(原子性、一致性、隔离性、持久性)。常见的事务控制语句包括 BEGIN、COMMIT、ROLLBACK 等。
19. **触发器(Trigger)**
1. 当表中发生特定事件(如插入、更新、删除)时自动执行的数据库程序,可用于审计、数据一致性维护等场景。
21. **存储过程(Stored Procedure)**
1. 预先编写并存储在数据库中的一段可重复执行的 SQL 代码,用于简化业务逻辑或减少网络交互。
23. **函数(Function)**
1. 与存储过程相似,但通常必须有返回值,常用于处理计算或格式转换等操作。
25. **游标(Cursor)**
1. 用于在结果集中逐行处理数据的数据库对象,适合需要对结果集进行细粒度处理或循环处理的场景。
27. **连接(Join)**
1. 将多张表根据某些条件组合成一个结果集的操作,常见类型包括 INNER JOIN、LEFT JOIN、RIGHT JOIN 和 FULL JOIN 等。
29. **范式 / 正规化(Normalization)**
1. 组织数据库结构的原则,减少数据冗余并提高数据一致性。常见范式包括第一范式 (1NF)、第二范式 (2NF) 和第三范式 (3NF) 等。
31. **反范式 / 去范式(Denormalization)**
1. 为了提高查询性能等原因,在数据库设计中有意进行的数据冗余或表结构变形操作。
33. **执行计划(Execution Plan)**
1. 数据库对 SQL 语句进行解析、优化后最终执行的步骤与策略,常用于分析和调优查询性能。
35. **分区(Partition)**
1. 将大表或索引按一定规则拆分为更小的逻辑单元或物理文件,以提高查询性能或管理灵活性。
37. **分布式数据库(Distributed Database)**
1. 将数据分布在多个物理节点或服务器中进行存储和管理,以获得更好的扩展性和高可用性。
39. **集群 / 高可用(Cluster / High Availability)**
1. 多个数据库节点共同对外提供服务的架构,具备自动故障转移(Failover)等特性,保证系统在某些节点出现故障时仍能提供服务。
41. **复制 / 同步(Replication / Synchronization)**
1. 在多个数据库节点或服务器之间复制数据,保证数据一致性和高可用性。常见模式如主从复制、主主复制等。
43. **读写分离(Read/Write Splitting)**
1. 将数据库写操作定向到主库,读操作定向到从库,以减轻主库压力,提高并发量与查询效率。
45. **备份与恢复(Backup and Restore)**
1. 备份是将数据库数据或结构的副本保存到安全存储,用于应对故障或灾难;恢复是根据备份文件将数据库恢复到备份时刻或指定时间点。
47. **锁(Lock)**
1. 在数据库事务并发访问时为保护数据一致性而设置的机制,常见类型有行锁、表锁、悲观锁(Pessimistic Lock)、乐观锁(Optimistic Lock)等。
49. **调优(Optimization)**
1. 为提升数据库性能所做的各种操作,包括 SQL 语句优化、索引优化、硬件资源配置、分库分表、缓存机制等。
50. **笛卡儿连接 (Cartesian Join)**
1. 会将两个表中的每一行分别与对方所有行进行组合,形成所有可能的行配对
## 范式
在关系型数据库设计中,范式是为了**减少数据冗余**、**提高数据一致性**而制定的一系列规范。常用的有第一范式、第二范式和第三范式等。下面详细解释:
---
### 1. 第一范式
**核心要求:** 所有字段(列)都具有**原子性**,即字段不可再分。
- **原子性**:字段中不允许同时存储多个信息。例如,不能把「姓名 + 电话号码」合在同一个字段里。
- **行唯一**:表中每行代表一条唯一的记录,不允许重复行。
- **列无序**:列的顺序不会影响数据的含义。
- **行无序**:行的先后与数据本身的属性无关。
**举例说明:**
- 不符合第一范式的情况:
| 学生ID | 联系信息 |
| ---- | -------------- |
| 1 | 张三, 135xxxxxxx |
这里一个字段 「联系信息」 里包含了姓名和电话号码,明显可以再拆分。
- 规范做法:
| 学生ID | 姓名 | 电话号码 |
| ---- | --- | ---------- |
| 1 | 张三 | 135xxxxxxx |
在第一范式中,每一个字段必须是最小单元(可以理解为「单一值」)。
---
### 2. 第二范式
**核心要求:** 在满足第一范式的基础上,表中的所有非主键字段都需要**完全依赖**于主键(没有部分依赖)。
- **完全依赖**:指若主键是复合主键(由多列组成),则非主键字段必须依赖于**所有**主键列,而非只依赖其中一部分。
- **部分依赖**:若一个非主键字段仅依赖于主键的一部分列,就会违反第二范式,需要将此字段拆分到新的表中。
**举例说明:**
假设有一张选课表,主键是 (学生ID,课程ID),同时表中还有「学生姓名」字段:
| 学生ID | 课程ID | 学生姓名 | 成绩 |
|--------|--------|----------|------|
| 1 | A01 | 张三 | 95 |
| 2 | A01 | 李四 | 90 |
- 主键: (学生ID,课程ID)
- 「学生姓名」只依赖于 **学生ID**,与「课程ID」无关,这就是**部分依赖**。在 2NF 要求下,需将「学生姓名」拆分到「学生表」中。
- 调整后的做法:
- 学生表: 以「学生ID」为主键,存储学生相关信息(姓名、班级等)。
- 选课表: 以(学生ID, 课程ID)作为主键,记录选课的「成绩」等信息。
---
### 3. 第三范式
**核心要求:** 在满足第二范式的基础上,所有非主键字段都**直接**依赖于主键,而不允许存在**传递依赖**。
- **传递依赖**:如果字段A依赖主键,字段B又依赖字段A,那么字段B就**间接**依赖于主键,形成传递依赖。
- 满足第三范式:表中每个非主键字段都只依赖于主键,而不依赖于其他非主键字段。
**举例说明:**
一张学生表(以 学生ID 为主键)中包含:学生ID、姓名、系ID、系名称:
| 学生ID | 姓名 | 系ID | 系名称 |
|--------|------|------|------------|
| 1 | 张三 | 10 | 计算机系 |
| 2 | 李四 | 20 | 外语系 |
- 这里「系名称」依赖于「系ID」,而「系ID」又依赖于学生ID(主键)。因此「系名称」对「学生ID」是**传递依赖**。
- 按第三范式,我们需要将「系ID」和「系名称」等系信息单独拆到「系表」中,让「学生表」只存「系ID」作为外键。这样「系名称」就不再跟学生表形成传递依赖。
拆分后:
1. **学生表**: (学生ID【主键】, 姓名, 系ID【外键】)
2. **系表**: (系ID【主键】, 系名称, 其他系相关信息…)
---
### 总结
- **第一范式**:字段原子性,不可再拆分
- **第二范式**:在第一范式基础上,非主键字段完全依赖主键,无部分依赖
- **第三范式**:在第二范式基础上,非主键字段不通过其他非主键字段而依赖于主键,无传递依赖
通过遵循这些范式,可以**减少数据冗余**、**提高更新和维护的效率**以及**保证数据一致性**。当然,在实际生产环境中,出于性能或查询效率考虑,也会进行**反范式(去范式)处理,但总体上理解并掌握范式依然是数据库设计的基础。**