mysql三范式和数据之间的关系

最新推荐文章于 2022-11-09 13:04:43 发布
最新推荐文章于 2022-11-09 13:04:43 发布
阅读量159 收藏
点赞数
分类专栏： mysql 文章标签： mysql 数据库 sql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/ypqdcsdn/article/details/127619766
版权

三范式

第一范式:列原子性

要求
最基本的范式
数据库表每一列都是不可分割基本数据项，同一列中不能有多个值
简单说就是要确保每列保持原子性
第一范式的合理遵循需要根据系统的实际需求来定
在这里插入图片描述

示例
用户表（用户名，家庭地址）
用户表（用户名，省，城市，详细地址）
系（系名称，系主任，系高级职称人数）
系（系名称，系主任，系教授人数，系副教授人数）

第二范式:数据和联合主键完全相关性

要求
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（言）。即在一个数据库表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
在这里插入图片描述

示例
学号和课程编号作为联合主键
课程名称只依赖于课程编号，而和学号没有关系

解决
提取出学生表
提取成课程表
提取选课表，存放选课记录

学生表 --------------------------------- 选课表 ---------------------------------------------- 课程表
在这里插入图片描述

第三范式:数据和主键直接相关性

要求
确保数据表中的每一列数据都和主键直接相关，而不能间接相关
属性不依赖于其他非主属性。
示例1：学生班级表
在这里插入图片描述
完善之后的方案：
在这里插入图片描述
示例2:订单明细表 :
在这里插入图片描述
完善之后的方案：分割成图书表和订单表两种表
在这里插入图片描述
范式的总结
优点

  • 结构合理
  • 冗余较小
  • 尽量避免插入删除修改异常

缺点

  • 性能降低
  • 多表查询比单表查询速度慢

数据库的设计应该根据当前情况和需求做出灵活的处理。
在实际设计中，要整体遵循范式理论。
如果在某些特定的情况下还死死遵循范式也是不可取的，因为可能降低数据库的效率，此时可以适当增加冗余而提高性能。

示例：

  • 比如经常购物车条目的中除了条目编号，商品编号，商品数量外，可以增加经常使用的商品名称，商品价格等

图书表
订单表中增加冗余列图书名称、价格，以空间换时间。
在这里插入图片描述

范式是指导数据设计的规范化理论，可以保证数据库设计质量
第一范式：字段不能再分
第二范式：不存在局部依赖
第三范式：不含传递依赖（间接依赖）
使用范式可以减少冗余，但是会降低性能
特定表的的设计可以违反第三范式，增加冗余提高性能

数据之间的关系

一对一

A表中的一条数据对应B表中的一条数据
在这里插入图片描述

一对多

A表中的一条数据对应B表中的多条数据
在这里插入图片描述

多对多

A表中对应B表中多条数据,同样B表中对应A表中多条数据
多对多需要通过中间表体现关系
中间表讲多对多的关系转变成两个一对多
在这里插入图片描述

MySQL三大范式详解
Zjs15630471263的博客
05-21 1343
一些约束、规范、规则 来优化数据库表的设计和存储，这些规则就称为范式。前面提到了三大范式的要求是啥，比较官话。下面简而言之并举例。大家可以直观的看出来，通过三范式改造，我们去除了很多数据的冗余，数据的逻辑关系变得更加的清晰，可视化了。
【MySQL进阶之路 | 高级篇】第二范式和第三范式
2301_80912559的博客
07-22 312
第二范式要求，在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。比赛表player_game，里面包含球员编号，姓名，年龄，比赛编号，比赛时间和比赛场地等属性，这里候选键和主键都为（球员编号，比赛编号），我们可以通过候选键来决定如下关系。成绩表（学号，课程号，成绩）关系中，（学号，课程号）可以决定成绩，但学号不能决定成绩，课程号也不能决定成绩，所以“（学号，课程号）--> 成绩”就是完全依赖关系。（球员编号，比赛编号）--> （姓名，年龄，比赛时间，比赛场地，得分）
数据库三范式
weixin_59868842的博客
08-19 363
必须保证数据库设计的合理性,对数据库设计总结的一些经验性的规范,称之为范式1.范式是符合某一种设计要求的总结。2.要想设计一个结构合理的关系型数据库，必须满足一定的范式。3.数据库设计关系整个系统的架构，关系到后续开发效率和运行效率4.数据库的设计主要包含了设计表结构和表之间的联系。
MYSQL三大范式
热门推荐
iVan
02-23 1万+
<br /><br />第一范式:确保每列的原子性.<br />    如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.<br />    例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。<br /> <br /> <br />第二范式:在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关.<br />    如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式.<br />    例如:订
MySQL - MySQL 三范式理解
Chon.Wang
08-02 2498
MySQL 三范式理解
MYSQL--三大范式
diyingshou8608的博客
06-06 158
　　　　　　　　　　MYSQL--三大范式 　　范式简介： 　　　　　　设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美...
Mysql数据库中数据表的优化、外键与三范式用法实例分析
09-08
在MySQL数据库管理中，数据表的优化、外键的使用以及三范式是确保数据完整性、提高系统性能和设计规范性的重要概念。以下是对这些知识点的详细解释： **数据表优化** 数据表优化是为了提升数据库的读写速度和存储...
MySQL三大范式详解.docx
05-17
MySQL 三大范式详解 MySQL 三大范式是关系型数据库...MySQL 三大范式是关系型数据库设计的基础，它们之间存在着紧密的联系和依赖关系。正确地理解和应用 MySQL 三大范式，可以帮助我们设计出高效、可靠的数据库系统。
mysql三范式.doc
10-03
MySQL三范式是数据库设计中遵循的重要原则，用于构建高效、规范化的数据库模式，避免数据冗余和操作异常。这三范式分别是第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。让我们逐一详细解释。 1. 第一范式（1...
MySQL三范式
weixin_42352733的博客
04-02 2297
三范式其实就是一种建议的规范，跟resful规范一样，只是建议可以这样遵守； 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。 第一范式（1NF）： 保证了每列的原子性；也就是数据库的每一列的字段都是不可分割的原子性 例如： 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库满足了第一范式。 第一范式需要根据系统的实际需求来定，比如有一张用户信息表： 一般来说"住址"设计成一个字段...
Mysql数据库三范式（详细解释）
qq_42166308的博客
02-27 434
数据库设计三范式 设计数据库表的时候所依据的规范，共三个规范： 第一范式：要求有主键，并且要求每一个字段原子性不可再分 第二范式：要求所有非主键字段完全依赖主键，不能产生部分依赖 第三范式：所有非主键字段和主键字段之间不能产生传递依赖 第一范式 数据库表中不能出现重复记录，每个字段是原子性的不能再分 不符合第一范式的实例： 存在问题: 最后一条记录和第一条重复（不唯一，没有主键） 联系方式字段...
mysql设计之三范式_MySQL设计之三范式的理解
weixin_39759155的博客
01-28 67
转自：https://blog.youkuaiyun.com/wangqyoho/article/details/52900585设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。但是有些时候一昧的追求范式减少冗余，反而会降低数据读写的效率，这个时候就要反范式，利用空间来换时间。目前关系数据库有六种范式：第一范式(...
MySQL设计之三范式的理解
一诺
05-07 309
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。但是有些时候一昧的追求范式减少冗余，反而会降低数据读写的效率，这个时候就要反范式，利用空间来换时间。 目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范
MySQL三大范式
weixin_33843947的博客
04-06 119
2019独角兽企业重金招聘Python工程师标准>>> ...
MySql之数据库设计三范式
oLengNuanZiZhi12的博客
01-03 332
这里写目录标题1>什么是数据库设计范式？2>数据库设计范式第一范式第二范式第三范式3>总结表的设计4>最后总结 1>什么是数据库设计范式？ 数据库表的设计依据。教你怎么进行数据库表的设计。 2>数据库设计范式 第一范式：要求任何一张表必须有主键，每一个字段原子性不可再分。 第二范式：建立在第一范式的基础之上，要求所有非主键字段完全依赖主键， 不要产生部分依赖。 第三范式：建立在第二范式的基础之上，要求所有非主键字段直接依赖主键， 不要产生传递依赖。 声明：三范式是
MySQL数据库设计三范式
Weber's blog
11-09 506
数据库设计三范式五约束
MySQL三范式的通俗理解
Chandler的博客
02-02 1533
第一范式就是属性不可分割，每个字段都应该是不可再拆分的。比如一个字段是姓名（NAME），在国内的话通常理解都是姓名是一个不可再拆分的单位，这时候就符合第一范式；但是在国外的话还要分为FIRST NAME和LAST NAME，这时候姓名这个字段就是还可以拆分为更小的单位的字段，就不符合第一范式了。 第二范式就是要求表中要有主键，表中其他其他字段都依赖于主键，因此第二范式只要记住主键约束就好了。比如...
mysql三范式
最新发布
03-11
<think>好的，我现在需要回答用户关于MySQL三大范式的概念和应用的问题。首先，我得回忆一下数据库范式的基本知识，然后结合用户提供的引用内容来组织回答。用户提到了三个引用，其中引用[1]详细介绍了三大范式，引用[2]提到实际应用中的变通，引用[3]和[4]讨论了反范式化。我需要确保回答涵盖三范式的定义、示例以及实际应用中的注意事项。 首先，第一范式（1NF）要求数据不可再分，每个字段都是原子的。比如，用户的地址如果存储为“北京朝阳区”，这可能没问题，但如果存储为“北京,朝阳区”，就违反了1NF，因为包含多个值。需要拆分为单独的字段或者另一张表。 接下来是第二范式（2NF），必须满足1NF，并且非主属性完全依赖于主键。例如，订单明细表中，主键是订单ID和产品ID，如果产品名称只依赖于产品ID，而不依赖于订单ID，那么就需要拆分成订单明细表和产品表，避免部分依赖。 第三范式（3NF）需要满足2NF，并且消除传递依赖。例如，学生表中包含学生ID、姓名、学院ID和学院地址。学院地址依赖于学院ID，而学院ID又依赖于学生ID，这就形成了传递依赖。解决方法是拆分成学生表和学院表。 然后要考虑实际应用中的反范式化，比如允许冗余字段来提高查询效率。例如，在订单表中冗余存储客户姓名，避免每次查询都要连接客户表。这时候需要权衡数据冗余和查询性能。 在组织回答时，需要结构清晰，分点解释每个范式，给出具体示例。同时，在最后部分提到反范式化的概念，说明实际应用中可能需要灵活处理。还要注意引用标记的正确使用，比如在提到反范式化时引用[3]和[4]。 最后，生成相关问题，可能涉及范式与反范式的比较、实际应用案例，或者如何设计符合范式的表结构。确保问题相关且有启发性，帮助用户深入理解。 检查是否所有数学表达式使用了正确的格式，比如主键的表示可能涉及字段组合，但这里可能不需要数学公式。如果有涉及，比如函数依赖，可能需要用$符号包裹，但根据用户指令，变量或术语如主键、外键不需要，但需要确保行内公式的正确格式。例如，如果有数学表达式，比如函数依赖关系，可能需要用$...$，但在这个问题中可能较少用到，但需注意。 现在，将这些思考整合成符合用户要求的回答，确保结构清晰，示例明确，并正确引用资料。</think>### MySQL 数据库三范式详解与示例 #### 一、第一范式（1NF） **定义**：确保每列具有**原子性**，即数据不可再分。 **示例**： 假设有一张`用户表`，其中包含字段`用户地址`，存储值为“北京市朝阳区XX街道”。若需要单独查询“区”或“街道”信息，这种设计就违反了1NF。符合1NF的设计应拆分为多个字段： $$ \begin{aligned} &\text{用户表} \\ &\text{用户ID | 省份 | 城市 | 区 | 街道} \end{aligned} $$ **应用意义**：避免数据冗余和操作复杂性[^1]。 --- #### 二、第二范式（2NF） **定义**：在满足1NF的基础上，**非主属性必须完全依赖主键**（消除部分依赖）。 **示例**： 订单明细表设计如下： $$ \begin{aligned} &\text{订单明细表} \\ &\text{订单ID（主键） | 产品ID（主键） | 产品名称 | 数量} \end{aligned} $$ 此处`产品名称`仅依赖于`产品ID`，而非完全依赖组合主键`(订单ID, 产品ID)`，违反了2NF。改进方法是将产品信息拆分到独立表： $$ \begin{aligned} &\text{订单明细表：订单ID | 产品ID | 数量} \\ &\text{产品表：产品ID | 产品名称} \end{aligned} $$ **应用意义**：减少数据冗余，避免更新异常。 --- #### 三、第三范式（3NF） **定义**：在满足2NF的基础上，**消除传递依赖**（非主属性不依赖于其他非主属性）。 **示例**： 学生表设计如下： $$ \begin{aligned} &\text{学生表} \\ &\text{学生ID | 姓名 | 学院ID | 学院地址} \end{aligned} $$ 此处`学院地址`依赖于`学院ID`，而`学院ID`又依赖于`学生ID`，形成传递依赖。改进后： $$ \begin{aligned} &\text{学生表：学生ID | 姓名 | 学院ID} \\ &\text{学院表：学院ID | 学院地址} \end{aligned} $$ **应用意义**：进一步减少冗余，提高数据一致性。 --- #### 四、实际应用中的反范式化 虽然范式化能减少冗余，但在**高频查询场景**中可能降低性能。例如： - 在订单表中冗余存储`客户姓名`，避免每次查询都关联客户表[^3][^4]。 - 在电商系统中，商品详情页可能直接存储分类名称，而非通过外键关联分类表。 **权衡原则**：根据业务需求，在数据一致性和查询效率之间取舍[^2]。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值