前言知识
进入主题之前，先补充几个要点知识：
主键（Primary Key）：（在数据库设计中，只能有一个主键，但可以由多个列组成（复合主键）。）
- 唯一标识数据库表中每个记录的一列或一组列。
- 在表中必须是唯一的，每个记录都应该有一个不同的主键值。
- 列不允许包罗空值（NULL），因为它们用于唯一标识记录。
- 用于建立表之间的关系，例如，用于创建外键关联。
候选键（Candidate Key）：
- 表中具有唯一性要求的列或列组合。
- 值也必须是唯一的，就像主键一样。
- 不同于主键，候选键可以包罗空值，但其中至少有一个候选键值不能为 NULL。
- 在一个表中，可以有多个候选键，从多个候选键中选择一个作为主键。
候选键通常用于数据库设计的早期阶段，用来识别表中唯一性要求的列。然后，从中选择一个候选键作为主键，通常是选择最得当唯一标识表中记录的那一列或列组合。其他候选键可以用作唯一性约束或索引，以加速查询和确保数据的完整性。
总之，主键是表中用于唯一标识记录的重要标识符，而候选键是具有唯一性要求的列或列组合，可以作为主键的备选项。主键的选择通常依赖于表的设计和业务需求。
- 部分依赖（Partial Dependency）：
部分依赖指的是在关系数据库表中的非主键属性部分地依赖于候选键（或主键）的环境。
简而言之，如果一个表的某个非主键属性取决于候选键中的一部分，而不是全部候选键，就称为部分依赖。
这意味着某些属性依赖于表中的一部分键，但不是所有键。
举例来说，考虑一个订单表，其中主键是订单号和产物号。如果订单表中有一个非主键属性是“产物形貌”，但这个属性只依赖于“产物号”，而不依赖于“订单号”，那么它就是部分依赖。
这种环境下，数据库设计可能必要举行调整，以消除部分依赖，通常是将属性移到与其完全依赖的关系中。
完全依赖是指在关系数据库表中的非主键属性完全依赖于候选键（或主键）。
这意味着非主键属性的值取决于表中所有的候选键的值，而不是仅仅一部分。
举例来说，考虑同样的订单表，如果某个非主键属性（如“订单日期”）依赖于主键中的所有属性，即“订单号”和“产物号”，那么它就是完全依赖。
在这种环境下，数据库表的设计是符合第二范式（2NF）的。
总之，部分依赖和完全依赖是与数据库设计中的范式化有关的概念。
数据库设计师通常努力消除部分依赖，以确保数据库表的结构更清晰，减少数据冗余，提高数据一致性和完整性。
这通常涉及到将部分依赖的属性移动到另一个表中，以确保表的非主键属性完全依赖于候选键或主键。
1. 概念
1.1 严格定义
1NF、2NF 和 3NF 是关系数据库设计中的三个重要范式，用于规范化数据库表，以减少冗余数据，提高数据的一致性和完整性。以下是它们的概念：
一、第一范式（1NF - First Normal Form）：
第一范式要求数据库表中的每个列都包罗不可再分的原子数据，也就是每个单元格中只包罗一个值。不应该有多值属性或重复组。
1NF 的要点：
- 每个表中的每一列都必须包罗不可再分的原子数据。
- 表中的每一行必须具有唯一的标识符，通常是主键。
- 1NF 确保了表的结构简朴和数据的一致性，是数据库设计的第一步。
二、第二范式（2NF - Second Normal Form）：
第二范式要求在满意 1NF 的基础上，每列数据都必须完全依赖于表的候选键（Candidate Key）。
这意味着，如果表的候选键包罗多列，那么每一列数据都必须与这些列的组合相关，而不是仅与某一列相关。
2NF 的要点：
- 数据表必须满意 1NF。
- 所有非主键列数据必须完全依赖于整个候选键，而不是部分依赖。
- 2NF 的目标是消除部分依赖，以避免数据冗余和维护异常。
三、第三范式（3NF - Third Normal Form）：
第三范式要求在满意 2NF 的基础上，消除非主键列之间的传递依赖。这意味着非主键列不能依赖于其他非主键列。
3NF 的要点：
- 数据表必须满意 2NF。
- 每一非主键列都不能传递依赖于其他非主键列。
- 3NF 有助于进一步减少数据冗余，确保数据的完整性，提高数据表的清晰性。
范式的使用有助于设计出更清晰、更容易维护和查询的数据库结构。然而，范式并不是实用于所有环境的绝对规则，偶然会导致性能题目。在数据库设计中，必要根据具体需求和性能要求衡量范式和反范式（冗余数据）的使用。
1.2 平凡明确
类似大型的 Excel 表格，每一行代表一个记录，每一列代表一个属性。
第一范式要求每个单元格（交织点）中只包罗一个值。就像在 Excel 中，每个单元格只能包罗一个数字或文本，不能混合多个值。这确保了数据的原子性，使它更容易管理。
类似数据库表，其中有两列：一个是订单号，另一个是产物名称。
如果一份订单中包罗多种产物，那么订单号和产物名称之间存在冗余数据。第二范式要求把这种关联性拆分开，将订单号和产物名称分别存储在不同的表中。这就像将订单和产物的信息分开，以避免重复的信息。
数据库表，其中包罗员工信息，包罗员工姓名、部门和部门经理。
如果部门经理的信息可以通过部门名直接获取，那么存在传递依赖，因为部门经理信息依赖于部门名，而不是员工。第三范式要求消除这种传递依赖，将部门经理信息从员工表中移除，将它放到一个单独的表中，使数据更清晰，不会有冗余的信息。
总之，三大范式是一种数据库设计的指导原则，资助我们组织和规范化数据，以减少冗余、提高数据完整性和可维护性。
它们有助于确保数据库表结构清晰，数据不杂乱，减少错误和提高数据库的性能。但在实际设计中，偶然会根据具体需求和性能考虑，做一些衡量。
2. 例题讲授
以下是一个示例数据库表，以资助解释这些概念：
假设有一个订单管理体系，其中有两个表：
- 一个是“订单”表（Orders）
- 一个是“产物”表（Products）
这两个表之间有关系，订单中包罗了不同产物的信息。
1. 第一范式 (1NF) 示例：
订单表 (Orders)：
OrderIDCustomerNameProducts1JohnProduct1, Product22JaneProduct33BobProduct1, Product3 在上面的表中，每个单元格包罗原子值，没有多值属性，因此符合第一范式（1NF）。
2. 第二范式 (2NF) 示例：
如果我们将产物表（Products）引入，它包罗了产物信息，包罗产物号（ProductID）、产物名称（ProductName）和产物形貌（ProductDescription）。
订单表 (Orders)：
OrderIDCustomerName1John2Jane3Bob 产物表 (Products)：
ProductIDProductNameProductDescription1Product1Description12Product2Description23Product3Description3 产物表（Products）和订单表（Orders）之间存在关系，通过“产物号”（ProductID）来连接
这符合第二范式（2NF），因为非主键属性（如“产物形貌”）依赖于整个候选键（“产物号”）。
3. 第三范式 (3NF) 示例：
如果我们在订单表（Orders）中添加一个新的属性，比如“客户地址”（CustomerAddress）：
订单表 (Orders)：
OrderIDCustomerNameCustomerAddress1JohnAddress12JaneAddress23BobAddress1 在这种环境下，客户地址（CustomerAddress）依赖于“客户名称”（CustomerName），而不是订单号（OrderID）。
这违反了第三范式（3NF）。为了符合3NF，我们应该将“客户地址”移动到一个独立的客户表，其中“客户名称”是主键，然后在订单表中使用客户名称作为外键来建立关联。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
