数据库设计三范式

简介: 数据库三范式是设计表结构的指导原则:第一范式要求字段不可再分;第二范式要求消除部分依赖,即一张表只描述一件事;第三范式要求消除传递依赖。但实际应用中应根据需求权衡规范与实用性。

第一范式 - 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。
相关文章
|
8月前
|
uml C语言
系统时序图
时序图(Sequence Diagram)是UML中描述对象间消息传递时间顺序的交互图。横轴为对象,纵轴为时间,通过消息展现动态协作。强调时间顺序,可用于建模系统交互、展示并发进程。主要元素包括角色、对象、生命线、控制焦点和各类消息,如同步、异步与返回消息,支持自关联调用,直观呈现系统行为流程。
系统时序图
|
6月前
|
存储 监控 NoSQL
阿里云服务器ESSD云盘怎么样?ESSD云盘规格、计费与应用场景解析参考
阿里云ESSD云盘融合25GE网络与RDMA技术,为单个云盘提供高达100万随机读写性能,实现低时延,是阿里云在存储技术领域的重要成果。ESSD云盘规格多样,性能级别分PL0至PL3四档,满足不同业务需求,且性能随容量增加而提升。计费方式灵活,包括按量付费、包年包月及存储容量单位包。不同容量范围和性能级别,以及实例规格的存储I/O性能的差异可适应不同的应用场景,为用户提供稳定高效的存储支持。
|
8月前
|
负载均衡 应用服务中间件 Nacos
Nacos配置中心
本文详细介绍Nacos作为配置中心的实现原理与实践,涵盖配置管理、热更新、共享配置及优先级规则,并演示集群搭建与高可用部署,助力微服务架构下配置的集中化、动态化管理。
 Nacos配置中心
|
5月前
|
消息中间件 关系型数据库 Java
击穿分布式事务痛点:BASE 理论全解,从最终一致性到柔性事务落地全指南
本文深入解析分布式事务核心理论BASE(基本可用、软状态、最终一致性),对比ACID差异,详解五大最终一致性模型,并结合本地消息表、TCC、SAGA等四种柔性事务方案,提供可落地的代码实例与避坑指南,助你平衡一致性与可用性。
893 1
|
6月前
|
弹性计算 人工智能 并行计算
阿里云服务器多少钱一年?2026年新版阿里云服务器配置与价格表解析
在云计算应用日益普及的当下,阿里云服务器凭借稳定的性能、灵活的配置选择和覆盖广泛的地域支持,成为个人开发者、中小企业及大型企业数字化转型的重要基础设施。2026年,阿里云对服务器产品线进行了全面优化,推出了涵盖轻量应用服务器、ECS云服务器、GPU服务器等多个系列的产品,各系列在配置规格、价格定位和适用场景上形成了清晰的区分,满足不同用户的多样化需求。本文基于官方公布的配置参数与价格信息,对2026年阿里云服务器的产品体系、核心配置、价格标准及适用场景进行详细解析,为用户选择合适的服务器提供参考。
681 0
|
SQL 关系型数据库 MySQL
云服务器常用端口作用
了解云服务器常用端口的作用有助于高效管理资源、快速定位问题及更好地使用云服务。常见端口包括:21(FTP,文件传输)、22(SSH,远程连接Linux)、25(SMTP,发送邮件)、80(HTTP,网页服务)、110/143(POP3/IMAP,接收邮件)、443(HTTPS,加密网页)、1433(SQL Server)、3306(MySQL)、3389(RDP,远程访问Windows桌面)和8080(代理服务)。
905 2
|
人工智能 Serverless API
AI助理精准匹配,为您推荐方案——如何快速在网站上增加一个AI助手
通过向AI助理提问的方式,生成一个技术方案:在网站上增加一个AI助手,提供7*24的全天候服务,即时回答用户的问题和解决他们可能遇到的问题,无需等待人工客服上班,显著提升用户体验。
3051 13
|
人工智能 监控 搜索推荐
数字孪生与娱乐业:沉浸式体验的提升
数字孪生技术通过创建物理实体的虚拟副本,为娱乐业带来创作自由与沉浸体验的双重提升。本文探讨了该技术在虚拟演唱会、电影游戏制作、主题公园及音乐教育中的应用,以及提升沉浸体验的关键要素,展望了其面临的挑战与未来前景。
|
存储 机器学习/深度学习 搜索推荐
去中心化的模型训练
去中心化的模型训练(Decentralized Model Training)是一种不依赖单一中心服务器或数据存储中心,而是在多个节点(如设备或数据拥有者)上进行联合训练的方法。这种训练模式可以更好地保护数据隐私、降低数据传输成本,并提升模型的鲁棒性和可扩展性。随着数据安全和隐私保护需求的提升,去中心化训练在深度学习和人工智能应用中的重要性逐渐增加。
803 4
|
Java 测试技术 数据安全/隐私保护
🚀Java零基础-continue语句详解
【10月更文挑战第3天】本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
795 4

热门文章

最新文章