理解范式及其原因和解决的问题

1.1范式出现的原因

范式的出现是为了解决关系型数据库数据冗余、数据增删改查异常等问题，范式通过规范表的设计规则，优化表的结构，提高数据的完整性与一致性问题，并减少数据储存空间。

在实际的数据库设计中，最常用的范式是第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。这三种范式能够解决大多数关系数据库设计中的问题，如数据冗余、更新异常、插入异常和删除异常。虽然更高范式（如BCNF、4NF、5NF）也存在，但在实际应用中较少使用，因为它们通常适用于更复杂的场景。

1.2范式种类及解决的问题

1.第一范式（1NF）

定义：每一列都是不可再分的原子数据项。

解决的问题：

• 数据冗余：确保每个字段都是单一值，避免存储复杂结构（如数组或对象）。
• 维护困难：原子性字段便于数据的插入、更新和删除操作。

示例： 假设一个学生信息表中包含“学校”字段，存储了学校名称和地址。这不符合1NF，因为“学校”字段可以进一步拆分。调整后，将“学校”拆分为“学校名称”和“学校地址”。

总结：拆到不可再分，数据单一，方便CRUD

2. 第二范式（2NF）

定义：在满足1NF的基础上，所有非主键字段必须完全依赖于主键。

示例： 假设订单表中包含OrderID、CustomerID、OrderDate和CustomerName。CustomerName仅依赖于CustomerID，存在部分依赖，违反2NF。调整后，将CustomerName移到单独的Customers表中。

解决的问题：

• 部分依赖：避免非主键字段仅依赖于主键的一部分，导致数据冗余和更新异常。
• 数据一致性：通过分解表结构，确保数据的完整性。

总结：拆分表结构，确保每个表依赖一个主键（每个表都有自己的身份证），方便统一管理，提高整个数据库CRUD效率

3. 第三范式（3NF）

定义：在满足2NF的基础上，所有非主键字段直接依赖于主键，不存在传递依赖。

示例： 假设员工表中包含EmployeeID、DepartmentID、DepartmentName和ManagerID。DepartmentName依赖于DepartmentID，存在传递依赖，违反3NF。调整后，将DepartmentName和ManagerID移到单独的Departments表中。

存在的问题：

1. 数据冗余：因为多个员工可能处于同一部门，DepartmentName在表中重复存储，浪费存储空间。
2. 更新异常：如果系别名称发生变化（如“终端研发中心”改为“商业终端研发中心”），需要更新所有相关的员工记录。
3. 插入异常：如果需要添加一个新的部门，但还没有员工分配到该系别，无法插入系别信息。
4. 删除异常：如果删除某个员工记录，可能会丢失系别信息。

解决的问题：

• 传递依赖：避免非主键字段之间存在依赖关系，导致数据冗余和更新异常。
• 数据完整性：通过分解表结构，确保数据的独立性和一致性。

总结：

分解表结构，保证每个表非主键直接依赖主键，实现每个表单元最简，减少耦合，去除冗余数据。