## 词汇 以下是一些在数据库领域中常用的中文术语及其简单解释,涵盖从基础概念到常见操作、优化等方面,供你在工作中参考使用。实际使用时可根据项目需要进行扩展或深入。 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【主键】, 系名称, 其他系相关信息…) --- ### 总结 - **第一范式**:字段原子性,不可再拆分 - **第二范式**:在第一范式基础上,非主键字段完全依赖主键,无部分依赖 - **第三范式**:在第二范式基础上,非主键字段不通过其他非主键字段而依赖于主键,无传递依赖 通过遵循这些范式,可以**减少数据冗余**、**提高更新和维护的效率**以及**保证数据一致性**。当然,在实际生产环境中,出于性能或查询效率考虑,也会进行**反范式(去范式)处理,但总体上理解并掌握范式依然是数据库设计的基础。**