数据库设计三范式

简介: 数据库三范式简介:第一范式要求字段原子性,不可再分;第二范式在满足第一范式基础上,消除部分依赖,确保主键唯一确定非主键;第三范式消除传递依赖,避免非主键间相互决定。范式旨在减少数据冗余、提升一致性,但实际设计需结合业务需求灵活应用,不必生搬硬套。(238字)

第一范式 - 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

  1. 课程表 - 课程名称做主键
    课程名称 学分
    语文 3
    数学 2
  2. 成绩表 - 学号和课程名称做联合主键
    学号 课程名称 成绩
    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)班
  3. 班级表
    班级 班主任
    一年级(1)班 高老师
    通过把班级与班主任的映射关系另外做成一张映射表,我们就成功地消除了表中的传递依赖了。总结不知道读者们有没有发现,以上所介绍的范式的最终目的都是为了减少我们的工作量呢?所以说,尽管范式是一种很好的指导规范,但在实际应用中,我们也不需要太局限在范式中,更多的是应该从项目中出发,设计出合理的表结构。以下是本篇三范式的简单总结:第一范式(1 NF):字段不可再拆分。第二范式(2 NF):表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值。第三范式(3 NF):在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B。
相关文章
|
4月前
|
机器学习/深度学习 存储 自然语言处理
大模型基础概念术语解释
大语言模型(LLM)基于Transformer架构,通过海量文本训练,实现强大语言理解与生成。其核心包括注意力机制、位置编码、嵌入层等,支持万亿级参数与涌现能力,能完成翻译、问答等多任务,展现卓越泛化与推理能力。
|
4月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用的两大关键技术。前者是跨模型的标准协议,实现多工具动态集成;后者是模型调用外部功能的机制。MCP构建通用连接桥梁,支持多模型、跨平台协作,具备高扩展性与解耦能力;Function Call则依赖特定模型,直接解析意图并调用函数。两者在企业级系统中可协同工作:模型通过Function Call识别意图,转为MCP标准请求调用工具,兼顾智能解析与生态扩展。未来将趋向融合,形成“模型解析-协议传输-工具执行”的统一范式。
|
4月前
|
消息中间件 人工智能 决策智能
AgentScope x RocketMQ:构建多智能体应用组合
AgentScope是阿里巴巴推出的开发者友好型多智能体框架,支持模块化、可定制的智能体应用开发。通过集成RocketMQ,实现高效、可靠的A2A通信,助力构建如“智能旅行助手”等复杂协作场景,提升开发效率与系统可扩展性。(238字)
|
4月前
|
监控 Java 调度
XXLJob定时任务概述
定时任务是基于时间表达式调度执行的任务,适用于定时对账、超时取消等场景。单体架构可使用轮询、Timer、ScheduledExecutorService、Quartz或SpringTask;分布式环境下需解决重复执行、故障转移等问题,主流方案有XXL-JOB、Elastic-Job、Saturn和ScheduleX。
|
4月前
|
消息中间件 人工智能 Linux
基于 RocketMQ 构建 高可靠 A2A 通信通道
A2A协议由Google于2025年发起,旨在构建跨厂商AI智能体的标准化通信机制。通过支持gRPC、JSON-RPC及RocketMQ异步通信,实现多智能体高效协同。基于RocketMQ的实现方案提供开箱即用的高可靠通信,支持任务分发、流式交互与状态查询,助力构建开放、可扩展的多智能体系统生态。(238字)
|
4月前
|
XML 算法 安全
详解RAG五种分块策略,技术原理、优劣对比与场景选型之道
RAG通过检索与生成结合,提升大模型在企业场景的准确性与安全性。分块策略是其核心,直接影响检索效果与生成质量。本文系统解析五种主流分块方法:固定大小、语义、递归、基于结构和基于LLM的分块,对比其优缺点及适用场景,助力构建高效、可信的RAG系统,尤其适用于金融、医疗等高精度领域。(239字)
|
4月前
|
人工智能 自然语言处理 API
全面认识MCP:大模型连接真实世界的“USB-C接口”
MCP(模型上下文协议)是Anthropic推出的AI“万能接口”,旨在统一大模型与工具、数据源的连接标准。它简化集成、提升任务处理能力,被誉为AI时代的“USB-C”。通过标准化通信,MCP让智能体可自主调用工具、执行复杂任务,推动AI应用迈向高效、安全、可扩展的新阶段。
|
4月前
|
机器学习/深度学习 数据采集 人工智能
大模型训练方法与技术术语解释
预训练、微调、RLHF、思维链等技术共同构建大模型能力。预训练打基础,微调适配具体任务,RLHF融入人类偏好,思维链提升推理,少/零样本学习增强泛化,指令微调优化交互,自监督学习利用海量无标注数据,温度控制生成风格,蒸馏实现知识迁移,缩放定律指导模型扩展。这些核心技术推动大模型在多领域智能应用中持续突破,实现从理解到创造的跨越。(238字)
|
30天前
|
PHP
PHP 8 新特性:让代码更优雅的四个技巧
PHP 8 新特性:让代码更优雅的四个技巧
240 76
|
4月前
|
小程序 安全 NoSQL
陪玩小程序/代练APP/代打一键发布任务/打手抢单方便快捷
本文介绍游戏陪玩与代练平台搭建方案,涵盖业务定位、源码采购、部署环境及合规要求。建议明确“陪玩社交”或“技术代练”主方向,选择正规渠道获取商业源码,部署4核8G服务器,配置Nginx、MySQL、Redis环境,办理ICP证。运营需集成官方支付、押金托管、内容审核及打手实名认证机制,确保安全合规。
395 0