MySQL——数据库设计三范式

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 第二范式:建立在第一范式的基础之上,要求所有非主键字段完全依赖主键, 不要产生部分依赖。

image.png


数据库设计范式共有3个


第一范式:要求任何一张表必须有主键,每一个字段原子性不可再分。


第二范式:建立在第一范式的基础之上,要求所有非主键字段完全依赖主键, 不要产生部分依赖。


第三范式:建立在第二范式的基础之上,要求所有非主键字段直接依赖主键, 不要产生传递依赖。


设计数据库表的时候,按照以上的范式进行,可以避免表中数据的冗余,空间的浪费。


第一范式


最核心,最重要的范式,所有表的设计都需要满足。必须有主键,并且每一个字段都是原子性不可再分。


学生编号 学生姓名 联系方式
------------------------------------------
1001    张三    zs@gmail.com,1359999999
1002    李四    ls@gmail.com,13699999999
1001    王五    ww@163.net,13488888888
以上是学生表,满足第一范式吗?
  不满足,第一:没有主键。第二:联系方式可以分为邮箱地址和电话
学生编号(pk) 学生姓名 邮箱地址      联系电话
----------------------------------------------------
1001    张三    zs@gmail.com  1359999999
1002    李四    ls@gmail.com  13699999999
1003    王五    ww@163.net    13488888888


第二范式


4.4、第二范式:建立在第一范式的基础之上, 要求所有非主键字段必须完全依赖主键,不要产生部分依赖。


学生编号 学生姓名 教师编号 教师姓名

1001 张三 001 王老师 1002 李四 002 赵老师 1003 王五 001 王老师 1001 张三 002 赵老师


这张表描述了学生和老师的关系:(1个学生可能有多个老师,1个老师有多个学生) 这是非常典型的:多对多关系!


分析以上的表是否满足第一范式? 不满足第一范式。


怎么满足第一范式呢?修改


学生编号+教师编号(pk) 学生姓名  教师姓名


1001 001 张三 王老师 1002 002 李四 赵老师 1003 001 王五 王老师 1001 002 张三 赵老师


学生编号 教师编号,两个字段联合做主键,复合主键(PK: 学生编号+教师编号) 经过修改之后,以上的表满足了第一范式。但是满足第二范式吗? 不满足,“张三”依赖1001,“王老师”依赖001,显然产生了部分依赖。 产生部分依赖有什么缺点? 数据冗余了。空间浪费了。“张三”重复了,“王老师”重复了。


为了让以上的表满足第二范式,你需要这样设计: 使用三张表来表示多对多的关系!!!! 学生表


学生编号(pk) 学生名字


1001 张三 1002 李四 1003 王五


教师表


教师编号(pk) 教师姓名


001 王老师

002 赵老师


学生教师关系表


id(pk) 学生编号(fk) 教师编号(fk)

1 1001 001 2 1002 002 3 1003 001 4 1001 002


背口诀: 多对多怎么设计?多对多,三张表,关系表两个外键!


第三范式


第三范式建立在第二范式的基础之上 要求所有非主键字典必须直接依赖主键,不要产生传递依赖。


学生编号(PK) 学生姓名 班级编号  班级名称


1001 张三 01 一年一班 1002 李四 02 一年二班 1003 王五 03 一年三班 1004 赵六 03 一年三班


以上表的设计是描述:班级和学生的关系。很显然是1对多关系! 一个教室中有多个学生。


分析以上表是否满足第一范式? 满足第一范式,有主键。


分析以上表是否满足第二范式? 满足第二范式,因为主键不是复合主键,没有产生部分依赖。主键是单一主键。


分析以上表是否满足第三范式? 第三范式要求:不要产生传递依赖! 一年一班依赖01,01依赖1001,产生了传递依赖。 不符合第三范式的要求。产生了数据的冗余。


那么应该怎么设计一对多呢?


班级表:一


班级编号(pk) 班级名称


01 一年一班 02 一年二班 03 一年三班


学生表:多


学生编号(PK) 学生姓名 班级编号(fk)


1001 张三 01 1002 李四 02 1003 王五 03 1004 赵六 03


背口诀:一对多,两张表,多的表加外键!!


表的设计总结


总结表的设计?


一对多: 一对多,两张表,多的表加外键


多对多: 多对多,三张表,关系表两个外键


一对一: 一对一放到一张表中不就行了吗?为啥还要拆分表? 在实际的开发中,可能存在一张表字段太多,太庞大。这个时候要拆分表。 一对一怎么设计? 没有拆分表之前:一张表 t_user id login_name login_pwd real_name email


1 zhangsan 123 张三 zhangsan@xxx 2 lisi 123 李四 lisi@xxx


这种庞大的表建议拆分为两张:t_login 登录信息表 id(pk) login_name login_pwd


1 zhangsan 123 2 lisi 123


t_user 用户详细信息表


id(pk) real_name email login_id(fk+unique)


100 张三 zhangsan@xxx 1 200 李四 lisi@xxx 2


口诀:一对一,外键唯一


数据库设计实际中要注意的


数据库设计三范式是理论上的。


实践和理论有的时候有偏差。


最终的目的都是为了满足客户的需求,有的时候会拿冗余换执行速度。


因为在sql当中,表和表之间连接次数越多,效率越低。(笛卡尔积)


有的时候可能会存在冗余,但是为了减少表的连接次数,这样做也是合理的, 并且对于开发人员来说,sql语句的编写难度也会降低。

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
16天前
|
弹性计算 关系型数据库 数据库
手把手带你从自建 MySQL 迁移到云数据库,一步就能脱胎换骨
阿里云瑶池数据库来开课啦!自建数据库迁移至云数据库 RDS原来只要一步操作就能搞定!点击阅读原文完成实验就可获得一本日历哦~
|
16天前
|
人工智能 小程序 关系型数据库
【MySQL】黑悟空都掌握的技能,数据库隔离级别全攻略
本文以热门游戏《黑神话:悟空》为契机,深入浅出地解析了数据库事务的四种隔离级别:读未提交、读已提交、可重复读和串行化。通过具体示例,展示了不同隔离级别下的事务行为差异及可能遇到的问题,如脏读、不可重复读和幻读等。此外,还介绍了在MySQL中设置隔离级别的方法,包括全局和会话级别的调整,并通过实操演示了各隔离级别下的具体效果。本文旨在帮助开发者更好地理解和运用事务隔离级别,以提升数据库应用的一致性和性能。
94 2
【MySQL】黑悟空都掌握的技能,数据库隔离级别全攻略
|
19天前
|
SQL 关系型数据库 MySQL
【MySQL 慢查询秘籍】慢SQL无处遁形!实战指南:一步步教你揪出数据库性能杀手!
【8月更文挑战第24天】本文以教程形式深入探讨了MySQL慢SQL查询的分析与优化方法。首先介绍了如何配置MySQL以记录执行时间过长的SQL语句。接着,利用内置工具`mysqlslowlog`及第三方工具`pt-query-digest`对慢查询日志进行了详细分析。通过一个具体示例展示了可能导致性能瓶颈的查询,并提出了相应的优化策略,包括添加索引、缩小查询范围、使用`EXPLAIN`分析执行计划等。掌握这些技巧对于提升MySQL数据库性能具有重要意义。
50 1
|
11天前
|
前端开发 C# 设计模式
“深度剖析WPF开发中的设计模式应用:以MVVM为核心,手把手教你重构代码结构,实现软件工程的最佳实践与高效协作”
【8月更文挑战第31天】设计模式是在软件工程中解决常见问题的成熟方案。在WPF开发中,合理应用如MVC、MVVM及工厂模式等能显著提升代码质量和可维护性。本文通过具体案例,详细解析了这些模式的实际应用,特别是MVVM模式如何通过分离UI逻辑与业务逻辑,实现视图与模型的松耦合,从而优化代码结构并提高开发效率。通过示例代码展示了从模型定义、视图模型管理到视图展示的全过程,帮助读者更好地理解并应用这些模式。
27 0
|
11天前
|
SQL 数据采集 关系型数据库
|
11天前
|
数据库 关系型数据库 MySQL
惊!Hibernate与MySQL的绝密优化技巧大揭秘,让你的数据库飞起来!
【8月更文挑战第31天】在企业应用开发中,结合使用持久层框架Hibernate与数据库管理系统MySQL可显著提升数据库交互效率。本文探讨了多项优化策略,包括配置二级缓存、采用单向关联减少JOIN操作、优化HQL查询语句以及合理使用MySQL索引。通过具体示例,文章详细讲解了如何实施这些优化措施,以期为企业应用提供更高效稳定的数据支持。
21 0
|
11天前
|
SQL 关系型数据库 MySQL
SQL Server、MySQL、PostgreSQL:主流数据库SQL语法异同比较——深入探讨数据类型、分页查询、表创建与数据插入、函数和索引等关键语法差异,为跨数据库开发提供实用指导
【8月更文挑战第31天】SQL Server、MySQL和PostgreSQL是当今最流行的关系型数据库管理系统,均使用SQL作为查询语言,但在语法和功能实现上存在差异。本文将比较它们在数据类型、分页查询、创建和插入数据以及函数和索引等方面的异同,帮助开发者更好地理解和使用这些数据库。尽管它们共用SQL语言,但每个系统都有独特的语法规则,了解这些差异有助于提升开发效率和项目成功率。
70 0
|
21天前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
90 2
|
19天前
|
关系型数据库 MySQL 数据库
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
|
21天前
|
数据可视化 关系型数据库 MySQL
Mysql8 如何在 Window11系统下完成跳过密钥校验、完成数据库密码的修改?
这篇文章介绍了如何在Windows 11系统下跳过MySQL 8的密钥校验,并通过命令行修改root用户的密码。
Mysql8 如何在 Window11系统下完成跳过密钥校验、完成数据库密码的修改?

热门文章

最新文章