数据库设计三范式

简介: 数据库三范式是设计合理表结构的指导原则:第一范式要求字段原子性、不可再分;第二范式要求消除部分依赖,即主键确定所有非主键;第三范式要求消除传递依赖。但实际应用中应结合项目需求灵活调整,避免过度规范化带来复杂性。

第一范式 - 1NF

遵循原子性。即,表中字段的数据,不可以再拆分。先看一个不符合第一范式的表结构,如下:

员工编码

姓名

年龄

001

销售部小张

28

002

运营部小黄

25

003

技术部小高

22

在这一个表中的,姓名 字段下的数据是可以再进行拆分的,因此它不符合第一范式,那怎么样才符合第一范式呢?如下:

员工编码

部门

姓名

年龄

001

销售部

小张

28

002

运营部

小黄

25

003

技术部

小高

22

那是否遵循第一范式就一定是好的呢?如下:

员工编码

姓名

地址

001

小张

江西省南昌市东湖区

002

小黄

广东省佛山市禅城区

003

小高

湖北省武汉市新洲区

通过观察上述表结构,我们发现,地址是可以再进一步拆分的,比如:

员工编码

姓名

001

小张

江西省

南昌市

东湖区

002

小黄

广东省

佛山市

禅城区

003

小高

湖北省

武汉市

新洲区

虽然拆分后,看上去更符合第一范式了,但是如果项目就只需要我们输出一个完整地址呢?那明显是表在没拆分的时候会更好用。所以范式只是给了我们一个参考,我们更多的是要根据项目实际情况设计表结构。

第二范式 - 2NF

在满足第一范式的情况下,遵循唯一性,消除部分依赖。即,表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值。再通俗点讲就是,一个表只能描述一件事情。我们用一个经典案例进行解析。

学号

姓名

年龄

课程名称

成绩

学分

001

小张

28

语文

90

3

001

小张

28

数学

90

2

002

小黄

25

语文

90

3

002

小黄

25

语文

90

3

003

小高

22

数学

90

2

我们先分析一下表结构。

1. 假设学号是表中的唯一主键,那由学号就可以确定姓名和年龄了,但是却不能确定课程名称和成绩

2. 假设课程名称是表中的唯一主键,那由课程名称就可以确定学分了,但是却不能确定姓名、年龄和成绩。

3. 虽然通过学号和课程名称的联合主键,可以确定除联合主键外的所有的非主键值,但是基于上述两个假设,也不符合第二范式的要求。

那我们应该如何调整表结构,让它能复合第二范式的要求呢?

我们可以基于上述的三种主键的可能,拆分成 3 张表,保证一张表只描述一件事情

1. 学生表 - 学号做主键

学号

姓名

年龄

001

小张

28

002

小黄

25

003

小高

22

2. 课程表 - 课程名称做主键

课程名称

学分

语文

3

数学

2

3. 成绩表 - 学号和课程名称做联合主键

学号

课程名称

成绩

001

语文

90

001

数学

90

002

语文

90

002

语文

90

003

数学

90

这时候我们可能会想,为什么我们就要遵循第二范式呢?不遵循第二范式会造成什么样的后果呢

1. 造成整表的数据冗余。

如学生表,可能我就只有2个学生,每个学生都有许多的信息,比如,年龄、性别、身高、住址......如果与课程信息放到同一张表中,可能每个学生有3门课程,那数据总条数就会变成6条了。但是通过拆分,学生表我们只需要存储 2 条学生信息,课程表只需要存储 3 条课程信息,成绩表就只需保留学号、课程名称和成绩字段。

2. 更新数据不方便。

假设,课程的学分发生了变更,那我们就需要把整表关于该课程的学分都要更新一次,但如果我们拆分出课程表,那我们就只需要把课程表中的课程信息更新就行。

3. 插入数据不方便或产生异常。

① 假设主键是学号或课程名称,我们新增了某个课程,需要把数据插入到表中,这时,可能只有部分人有选修这门课程,那我们插入数据的时候还要规定给哪些人插入对应的课程信息,同时可能由于成绩还没有,我们需要对成绩置空,后续有成绩后还得重新更新一遍。

② 假设主键是学号和课程名称的联合主键。同样也是新增了某课程,但是暂时没有人选修这门课,缺少了学号主键字段数据,会导致课程信息无法插入。

第三范式 - 3NF

在满足第二范式的情况下,消除传递依赖。即,在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B

仍然用一个经典例子来解析

学号

姓名

班级

班主任

001

小黄

一年级(1)班

高老师

这个表中,学号是主键,它可以唯一确定姓名、班级、班主任,符合了第二范式,但是在非主键字段中,我们也可以通过班级推导出该班级的班主任,所以它是不符合第三范式的。

那怎么设计表结构,才是符合第三范式的呢?

1. 学生表

学号

姓名

班级

001

小黄

一年级(1)班

2. 班级表

班级

班主任

一年级(1)班

高老师

通过把班级与班主任的映射关系另外做成一张映射表,我们就成功地消除了表中的传递依赖了。

总结

不知道读者们有没有发现,以上所介绍的范式的最终目的都是为了减少我们的工作量呢?所以说,尽管范式是一种很好的指导规范,但在实际应用中,我们也不需要太局限在范式中,更多的是应该从项目中出发,设计出合理的表结构。

以下是本篇三范式的简单总结:

  • 第一范式(1 NF):字段不可再拆分。
  • 第二范式(2 NF):表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值。
  • 第三范式(3 NF):在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B。
相关文章
|
4月前
|
人工智能 监控 Java
请求限流
本文介绍如何使用Sentinel实现接口限流与降级,通过配置QPS阈值保护商品查询接口,并结合JMeter进行压测验证。同时讲解了线程隔离机制,包括信号量隔离的应用,确保系统在高并发下的稳定性。
请求限流
|
存储 运维 安全
课2-隐私计算开源如何助力数据要素流通
数据要素市场关键在于数据的内外循环,其中外循环面临数据权属、信任等问题。为解决这些问题,需建立基于区块链、可信计算的安全技术信任体系,并借助隐私计算保证数据流通时的隐私性。隐私计算遵循数据不可见、使用可控及不可识的原则,通过开源降低流通门槛。隐语作为开源隐私计算平台,具备统一架构、开放拓展、原生应用和高性能等优势,助力数据要素安全流通。
|
4月前
|
JSON 缓存 Java
Spring Boot集成 Swagger2 展现在线接口文档
Swagger是一款用于生成和管理API文档的工具,解决前后端分离架构中接口文档更新不及时的问题。通过集成Swagger2,可自动生成在线接口文档,支持实时查看与测试接口,提升开发效率。本文介绍其在Spring Boot中的配置与常用注解使用方法。
|
4月前
|
消息中间件 存储 缓存
RabbitMQ工作模型
工作队列模型通过多个消费者共同消费一个队列中的消息,实现任务的并行处理。默认情况下,消息平均分配给消费者,可能导致处理能力不同的消费者负载不均。通过设置`prefetch=1`,可实现“能者多劳”,即处理速度快的消费者自动接收更多消息,提升整体效率。发布订阅模型则通过交换机(Exchange)将一条消息转发给多个队列,支持Fanout、Direct、Topic等类型交换机,实现广播或多条件路由消息,满足不同业务场景需求。
|
4月前
|
存储 Java API
Spring Boot使用slf4j进行日志记录
本文介绍了在Spring Boot项目中使用SLF4J结合Logback进行日志管理的方法。通过配置`application.yml`和`logback.xml`,实现日志级别、输出格式、文件存储与滚动策略的灵活控制,并推荐使用SLF4J门面模式替代直接调用具体日志实现,提升系统可维护性与扩展性。
|
4月前
|
Java 测试技术 Linux
生产环境发布管理
本文介绍大型团队中基于自动化部署平台(Jenkins+K8S)的多环境发布流程,涵盖DEV、TEST、PRE、PROD各环境职责及CI/CD实践,结合Git分支管理、容器化部署与Skywalking日志追踪,实现高效发布与故障排查。
生产环境发布管理
|
4月前
|
安全 Java 测试技术
从Google线上故障,谈灰度发布的重要性
2025年6月12日,Google Cloud因未灰度发布的新配置引发空指针异常,导致Gmail、YouTube等服务中断超7小时。本文剖析故障根源,详解配置灰度发布的重要性及Nacos等工具的实践方案,强调通过IP、标签、流量等多路径实现安全发布,保障系统稳定性。
 从Google线上故障,谈灰度发布的重要性
|
4月前
|
缓存 Java 数据库
Spring Boot中使用监听器
本文系统介绍了Web监听器的概念及在Spring Boot中的应用,涵盖监听Servlet上下文、Session会话与Request请求的实战案例,并讲解自定义事件与监听器的实现方式,适用于数据缓存、在线人数统计、用户行为追踪等场景,具有较强的实用价值。
|
4月前
|
Java 关系型数据库 MySQL
Spring Boot事务配置管理
本文介绍了Spring Boot中事务的使用及常见陷阱。通过@Transactional注解可轻松实现事务管理,确保数据操作的原子性。重点剖析了三大易踩坑点:异常类型不匹配导致未回滚、try-catch吞掉异常、事务与锁范围不一致引发并发问题,助你在实际项目中有效规避风险。