暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

数据库设计文档:详解第一、第二、第三范式

解压泡泡糖 2024-12-05
118
美国发射导弹去俄罗斯,作为回应,俄罗斯也发射了导弹去美国,两个导弹在中途相遇。俄罗斯导弹很热情:“都是同行,相聚不易,一起喝一杯吧。” 于是,一杯为了相识,一杯为了世界和平。美国导弹说:“擦,我喝醉了,今天肯定来不及飞到目的地了。” 俄罗斯的拥抱了他说:“没关系,我没醉,我送你回家。”

1. 引言

数据库设计是构建高效、稳定、可扩展的数据库系统的基础。为了确保数据库设计既满足业务需求,又能在数据一致性、查询效率和扩展性方面表现优异,数据库设计需要遵循一定的规范化原则。范式是数据库设计中非常重要的一部分,范式(Normal Form)是对关系型数据库中数据结构的一种规范,旨在减少数据冗余,保证数据的完整性和一致性。

本篇文档将详细介绍第一范式(1NF)第二范式(2NF)第三范式(3NF),以及它们在数据库设计中的应用。我们将通过具体的例子来解释每个范式的要求和如何通过逐步规范化提高数据库的设计质量。


2. 第一范式(1NF)

2.1 定义

第一范式(1NF)要求数据库表中的每个字段必须是原子性的(Atomic),即每个字段只能包含一个单一的值,而不能包含集合、数组、列表等复合数据类型。简单来说,1NF 强调的是“字段不可分”原则。

2.2 要求

  • 每个表的列值必须是不可再分的原子值。
  • 表中的每个字段必须具有唯一名称。
  • 表中的每一行数据应该是唯一的(即,具有唯一的主键)。

2.3 举例说明

假设我们有一个学生信息表Student
,它的字段包含了学生的姓名、学号、以及所选的课程(一个学生可能选多门课程)。

不符合第一范式的设计(包含复合数据类型):

学号
姓名
课程
S001
张三
数学, 物理
S002
李四
化学, 英语, 计算机
S003
王五
数学, 化学

这个表中的课程
字段不符合1NF,因为它包含了多个课程(复合数据类型)。为了使其符合1NF,我们需要将每门课程拆分成独立的记录:

符合第一范式(1NF)设计:

学号
姓名
课程
S001
张三
数学
S001
张三
物理
S002
李四
化学
S002
李四
英语
S002
李四
计算机
S003
王五
数学
S003
王五
化学

通过拆分字段,我们将课程
字段变成了原子性数据,符合了1NF。

2.4 影响

  • 数据冗余增加
    :当一个学生选了多门课程时,数据会重复。
  • 查询复杂度提高
    :需要多次存储同一个学生的姓名、学号等字段。

3. 第二范式(2NF)

3.1 定义

第二范式(2NF)要求数据库表已经符合第一范式(1NF),并且消除了部分依赖。即,表中的每个非主属性(字段)必须完全依赖于主键,而不是仅仅依赖于主键的一部分。

第二范式的主要目标是消除“部分依赖”,即某些字段只依赖于复合主键中的一部分,而不是整个主键。

3.2 要求

  • 表必须符合第一范式(1NF)
  • 所有非主属性必须完全依赖于主键。

3.3 举例说明

假设我们有一个学生课程表
,其中包含学生的学号、课程编号、课程名称、教师姓名等信息。该表的主键是学号 + 课程编号
,即每个学生-课程组合是唯一的。

不符合第二范式的设计:

学号
课程编号
课程名称
教师姓名
S001
C001
数学
王老师
S001
C002
物理
李老师
S002
C001
数学
王老师
S003
C002
物理
李老师

在这个表中,课程名称
只依赖于课程编号
,而不依赖于学号
,这就是部分依赖。为了消除部分依赖,我们可以将课程名称
教师姓名
提取到一个新的课程表
中,单独存储课程信息。

符合第二范式(2NF)设计:

学生课程表:

学号
课程编号
S001
C001
S001
C002
S002
C001
S003
C002

课程表:

课程编号
课程名称
教师姓名
C001
数学
王老师
C002
物理
李老师

通过这种设计,所有非主属性(课程名称
教师姓名
)完全依赖于主键课程编号
,而不是依赖于复合主键学号 + 课程编号
,符合了第二范式。

3.4 影响

  • 减少冗余
    :将课程信息从学生课程表
    中提取到独立的课程表
    中,避免了每次插入学生-课程组合时重复存储课程名称和教师姓名。
  • 提高数据一致性
    :在更新课程名称或教师姓名时,只需要修改课程表
    ,不需要修改每一条学生课程记录。

4. 第三范式(3NF)

4.1 定义

第三范式(3NF)要求数据库表已经符合第二范式(2NF),并且消除了传递依赖。传递依赖是指某一非主属性依赖于主键,但通过其他非主属性间接依赖于主键。

第三范式的目标是进一步消除依赖关系,将不相关的字段分离到不同的表中。

4.2 要求

  • 表必须符合第二范式(2NF)
  • 表中不存在传递依赖。即,非主属性不能依赖于其他非主属性。

4.3 举例说明

假设我们有一个员工表
,包含了员工的姓名、地址、所在部门以及部门经理等信息。表的主键是员工ID

不符合第三范式的设计:

员工ID
姓名
地址
部门
部门经理
E001
张三
北京
IT
李经理
E002
李四
上海
HR
王经理
E003
王五
深圳
IT
李经理

在这个表中,部门经理
依赖于部门
,而部门
又依赖于主键员工ID
,所以部门经理
实际上是通过部门
间接依赖于员工ID
。这种依赖关系属于传递依赖

为了解决这个问题,我们可以将部门经理
迁移到部门表
中,使得部门经理
直接依赖于部门
,而不是间接依赖于员工ID

符合第三范式(3NF)设计:

员工表:

员工ID
姓名
地址
部门
E001
张三
北京
IT
E002
李四
上海
HR
E003
王五
深圳
IT

部门表:

部门
部门经理
IT
李经理
HR
王经理

通过这种设计,部门经理
不再依赖于员工ID
,而是直接依赖于部门
,消除了传递依赖。

4.4 影响

  • 进一步减少冗余
    :通过消除传递依赖,减少了存储冗余信息的可能性。
  • 提高数据一致性
    :部门经理的修改只需要在部门表
    中进行,而不需要在员工表
    中重复修改。

5. 总结

  • 第一范式(1NF)
    :保证字段的原子性,消除复合数据类型。
  • 第二范式(2NF)
    :消除部分依赖,使所有非主属性完全依赖于主键。
  • 第三范式(3NF)
    :消除传递依赖,确保每个非主属性只直接依赖于主键。

通过遵循这些范式,数据库设计能够有效避免数据冗余、保证数据一致性,并提高系统的可维护性。合理应用这些范式能够帮助开发人员在设计阶段减少潜在的设计缺陷,为构建高效、可扩展的数据库系统奠定基础。


文章转载自解压泡泡糖,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论