数据库设计三范式

本文涉及的产品
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
简介: 数据库三范式简介:第一范式要求字段原子性,不可再分;第二范式在1NF基础上消除部分依赖,确保主键唯一确定非主键;第三范式消除传递依赖,避免非主键间推导。范式旨在减少冗余、提升效率,但实际设计需结合业务需求灵活应用,不必机械遵循。

第一范式 - 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 张表,保证一张表只描述一件事情。
  4. 学生表 - 学号做主键
    学号
    姓名
    年龄
    001
    小张
    28
    002
    小黄
    25
    003
    小高
    22
  5. 课程表 - 课程名称做主键
    课程名称
    学分
    语文
    3
    数学
    2
  6. 成绩表 - 学号和课程名称做联合主键
    学号
    课程名称
    成绩
    001
    语文
    90
    001
    数学
    90
    002
    语文
    90
    002
    语文
    90
    003
    数学
    90
    这时候我们可能会想,为什么我们就要遵循第二范式呢?不遵循第二范式会造成什么样的后果呢?
  7. 造成整表的数据冗余。
    如学生表,可能我就只有2个学生,每个学生都有许多的信息,比如,年龄、性别、身高、住址......如果与课程信息放到同一张表中,可能每个学生有3门课程,那数据总条数就会变成6条了。但是通过拆分,学生表我们只需要存储 2 条学生信息,课程表只需要存储 3 条课程信息,成绩表就只需保留学号、课程名称和成绩字段。
  8. 更新数据不方便。
    假设,课程的学分发生了变更,那我们就需要把整表关于该课程的学分都要更新一次,但如果我们拆分出课程表,那我们就只需要把课程表中的课程信息更新就行。
  9. 插入数据不方便或产生异常。
    ① 假设主键是学号或课程名称,我们新增了某个课程,需要把数据插入到表中,这时,可能只有部分人有选修这门课程,那我们插入数据的时候还要规定给哪些人插入对应的课程信息,同时可能由于成绩还没有,我们需要对成绩置空,后续有成绩后还得重新更新一遍。
    ② 假设主键是学号和课程名称的联合主键。同样也是新增了某课程,但是暂时没有人选修这门课,缺少了学号主键字段数据,会导致课程信息无法插入。
    第三范式 - 3NF
    在满足第二范式的情况下,消除传递依赖。即,在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B。
    仍然用一个经典例子来解析
    学号
    姓名
    班级
    班主任
    001
    小黄
    一年级(1)班
    高老师
    这个表中,学号是主键,它可以唯一确定姓名、班级、班主任,符合了第二范式,但是在非主键字段中,我们也可以通过班级推导出该班级的班主任,所以它是不符合第三范式的。
    那怎么设计表结构,才是符合第三范式的呢?
  10. 学生表
    学号
    姓名
    班级
    001
    小黄
    一年级(1)班
  11. 班级表
    班级
    班主任
    一年级(1)班
    高老师
    通过把班级与班主任的映射关系另外做成一张映射表,我们就成功地消除了表中的传递依赖了。
    总结
    不知道读者们有没有发现,以上所介绍的范式的最终目的都是为了减少我们的工作量呢?所以说,尽管范式是一种很好的指导规范,但在实际应用中,我们也不需要太局限在范式中,更多的是应该从项目中出发,设计出合理的表结构。
    以下是本篇三范式的简单总结:
    第一范式(1 NF):字段不可再拆分。
    第二范式(2 NF):表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值。
    第三范式(3 NF):在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B。
相关文章
|
SQL 消息中间件 分布式计算
Flink 面试指南 | 终于要跟大家见面了,我有点紧张。(附思维导图)
面试,一个令人大多数同学头疼的问题,要么成功进入心仪公司,要么沮丧与其失之交臂。但是,如果能在面试前就能知道面试官将会问的问题,然后可以好好提前准备,这种感觉是不是特别棒?
Flink 面试指南 | 终于要跟大家见面了,我有点紧张。(附思维导图)
|
存储 数据采集 分布式计算
一篇文章搞懂数据仓库:四种常见数据模型(维度模型、范式模型等)
一篇文章搞懂数据仓库:四种常见数据模型(维度模型、范式模型等)
一篇文章搞懂数据仓库:四种常见数据模型(维度模型、范式模型等)
|
SQL 存储 关系型数据库
技术心得记录:数仓建模方法之范式建模、ER实体建模、维度建模
技术心得记录:数仓建模方法之范式建模、ER实体建模、维度建模
1479 1
|
分布式计算 关系型数据库 OLAP
阿里云AnalyticDB基于Flink CDC+Hudi实现多表全增量入湖实践
阿里云AnalyticDB基于Flink CDC+Hudi实现多表全增量入湖实践
731 0
|
5天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
6天前
|
人工智能 自然语言处理 文字识别
阿里云百炼Qwen3.7-Max简介:能力、优势、支持订阅计划参考
Qwen3.7-Max是阿里云百炼面向智能体时代推出的新一代旗舰模型,对标GPT-5.5、Claude Opus 4.7等闭源旗舰。该模型支持百万级token上下文窗口,具备顶级推理能力、多模态搜索与视觉理解增强、流式输出低延迟响应等核心优势,覆盖编程、办公、长周期自主执行等复杂场景。同时支持OpenAI接口兼容,便于系统快速迁移。用户可通过Token Plan团队或节省计划等订阅方式灵活调用,适合企业级高要求场景使用。
8672 37
阿里云百炼Qwen3.7-Max简介:能力、优势、支持订阅计划参考
|
6天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
673 5
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
|
6天前
|
人工智能 运维 JavaScript
阿里云Qoder CN(原通义灵码)全解析 产品形态、版本划分与技术适配说明
在AI辅助开发与智能办公工具持续普及的当下,阿里云旗下原通义灵码正式更名为Qoder CN,同时延伸出QoderWork CN、Qoder CN CLI、Qoder CN Mobile等多款配套产品,形成覆盖代码开发、日常办公、终端交互、移动端使用的完整工具矩阵。Qoder CN核心定位为AI智能编码助手,深度适配主流代码编辑器、集成开发环境以及终端场景;QoderWork CN则偏向桌面端综合办公辅助,二者面向不同使用场景,划分了多个版本档位,搭配差异化资源配额、功能权限与计费规则,同时兼容多款主流大模型。
671 5
|
6天前
|
数据采集 人工智能 前端开发
让 Coding Agent 从黑盒到透明:阿里云 Agent 观测审计数据采集实践
AI Agent 规模化落地带来执行黑盒、行为难追溯、成本难度量三大难题。阿里云基于 OTel 标准,面向 Coding Agent、个人通用助理和框架型 Agent,推出 LoongSuite Pilot、插件及探针等无侵入采集方案,让 Agent 实现可看见、可分析、可审计、可治理。
734 148

热门文章

最新文章