数据库设计三范式
Posted jihite
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据库设计三范式相关的知识，希望对你有一定的参考价值。
概述
1NF 是对属性的原子性约束，要求属性具有原子性，不可再分解
反例：
name-age 非原子属性，违反1NF, 应该拆解
2NF 是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性
反例：
订单表两个相同ID，不能确保唯一性，违反2NF。可以分开，插入中间表
3NF 是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余
反例：
订单表中，产品ID 可以在产品表中找到产品名称，存在冗余，违反3NF,应该在订单表吧产品名称去掉
反3NF 允许存在少量得冗余
在实际的业务查询中会大量存在着表的关联查询，而大量的表关联很多的时候非常影响查询的性能。
所谓得反范式化就是为了性能和读取效率考虑适当得对数据库设计范式得要求进行违反。允许存在少量得冗余，换句话来说反范式化就是使用空间来换取时间
问题
json格式是否违反1NF?
是的，是第一范式的反例
参考
https://juejin.cn/post/7050690148689772575
MySQL（二十一）—— 数据库设计三范式
21. 数据库设计三范式
21.1 什么是数据库设计范式
数据库设计范式： 数据库表的设计依据，教我们怎么进行数据库表的设计。
21.2 三种数据库设计范式
- 第一范式： 要求任何一张表必须有主键，每一个字段原子性不可再分。
- 第二范式： 建立在第一范式的基础之上，要求所有非主键字段完全依赖主键，不要产生部分依赖。
- 第三范式： 建立在第二范式的基础之上，要求所有非主键字段直接依赖主键，不要产生传递依赖。
设计数据库表的时候，按照以上的范式进行，可以避免表中数据的冗余，空间的浪费。
21.3 第一范式
第一范式是最核心，最重要的范式，所有表的设计都需要满足。必须有主键，并且每一个字段都是原子性不可再分。
以上是学生表，满足第一范式吗？
不满足。原因：第一，没有主键；第二，联系方式可以分为邮箱地址和电话。以下表满足第一范式。
21.4 第二范式
第二范式建立在第一范式的基础之上，要求所有非主键字段必须完全依赖主键，不要产生部分依赖。
上面这张表描述了学生和老师的关系，1个学生可能有多个老师，1个老师有多个学生。这是非常典型的：多对多关系！
分析以上的表是否满足第一范式？
不满足第一范式。原因是没有主键。
怎么满足第一范式呢？ 需要进行修改，添加主键。
上表中，学生编号和教师编号两个字段联合做主键，复合主键（PK：学生编号+教师编号）。经过修改之后，以上的表满足了第一范式。但是满足第二范式吗？
不满足。原因是，“张三”依赖1001，“王老师”依赖001，显然产生了部分依赖。
产生部分依赖有什么缺点？
数据冗余、空间浪费。“张三”重复了，“王老师”重复了。
为了让以上的表满足第二范式，需要这样设计：使用三张表来表示多对多的关系！
多对多怎么设计？
总结：多对多，三张表，关系表两个外键！
21.5 第三范式
第三范式建立在第二范式的基础之上，要求所有非主键字典必须直接依赖主键，不要产生传递依赖。
以上表的设计是描述班级和学生的关系，很显然是1对多关系，一个教室中有多个学生。
分析以上表是否满足第一范式？
满足第一范式，有主键。
分析以上表是否满足第二范式？
满足第二范式，因为主键不是复合主键，没有产生部分依赖，主键是单一主键。
分析以上表是否满足第三范式？
第三范式要求：不要产生传递依赖！一年一班依赖01，01依赖1001，产生了传递依赖。不符合第三范式的要求，产生了数据的冗余。
那么应该怎么设计一对多呢？
总结：一对多，两张表，多的表加外键！
21.6 总结表的设计
一对多： 一对多，两张表，多的表加外键！
多对多： 多对多，三张表，关系表两个外键！
一对一： 一对一放到一张表中不就行了吗？为啥还要拆分表？
在实际的开发中，可能存在一张表字段太多，太庞大，这个时候要拆分表。
一对一怎么设计？
总结：一对一，外键唯一！
21.7 总结
数据库设计三范式是理论上的，实践和理论有的时候有偏差，最终的目的都是为了满足客户的需求，有的时候会拿冗余换执行速度。因为在sql当中，表和表之间连接次数越多，效率越低（笛卡尔积）。
有的时候可能会存在冗余，但是为了减少表的连接次数，这样做也是合理的，并且对于开发人员来说，sql语句的编写难度也会降低。
以上是关于数据库设计三范式的主要内容，如果未能解决你的问题，请参考以下文章