在实际的开发工作中，确实也必须仔细考虑范式和反范式的平衡，但我看了大神的文摘后试着分享了一下。
三范式与反范式
范式是符合某一水平的关系模式的集合。 建立数据库必须遵循一定的规则。 在关系数据库中，该规则是一种范式。
关系数据库中的关系必须满足一定的要求，即不同的范式。 在大数据生态中，各种强大的查询引擎层出不穷，相对便宜的磁盘和分布式技术允许数据冗余，更加方便。
在建立数据库的过程中，优质蛋饼是将其转化为若干表格的过程，该方法能使数据库得到的结果更加明确。 这可能会在数据库中生成重复数据，从而创建额外的表。 好的煎蛋卷是识别这些初始工作(包括数据库中的数据元素、关系和定义所需的表以及每个表中的项目)之后的精细过程。
1、第一范式
1NF要求属性具有原子性，即列不能再分解
表：字段1、字段2 (字段2.1、字段2.2 )、字段3 …
例如，学生(学号、姓名、性别、出生年月日) )。
有些钢筋可能会问西红柿，姓名可以分为姓、名两列，“出生年月日”也可以分为成人、月、日三个字段。 所以不再满足第一范式了！ 在此进一步强调原子性，原子性是根据易用性定制的最小单位。 中国人一般一起使用名字，但在美国习惯将名字分别保存在两个字段中。
2、第二范式
2NF要求记录有唯一标识，即不存在部分依赖；
简而言之，通过分解表，以人为的粒度制作明细表，以上课号码为粒度制作维度表，将两表关联起来使用，消除了数据的冗长性
表：学校编号、课程编号、姓名、单位
该表明显显示了两个事务：学生信息、课程信息； 因为非主键字段必须依赖主键，这里单位依赖于上课号码，名字依赖于学校号码，所以不符合二归一化。
可能有问题：
数据冗馀：所有记录都包含相同的信息
异常删除：删除所有学生成绩后，删除了所有课程信息；
插入异常：学生没有选课，无法记录在数据库中
更新异常：调整课程学分，调整所有行。
正确的做法：
学生： Student (学号，姓名)；
课程： Course (课程编号、单位)；
选择关系： StudentCourse (学校号码、课程号码、成绩)。
3、第三范式
3NF是对于字段的冗馀度，要求任何字段不能从其他字段派生，要求字段没有冗馀度，即不存在传输依赖
表：学号、姓名、年龄、学院名称、学院电话
因为： (学号()学生) ) (所在学院) )学院电话)。
可能有问题：
数据冗馀：具有重复值
更新异常：存在重复的冗馀信息，修改时需要同时修改多条记录。 否则，会发生数据不一致。
正确的做法：
学生：(学号、姓名、年龄、所属学院)；
学院：(学院，电话)。
4、反范式化
一般来说，数据库只需要满足第三模式(3NF )。
不能进行冗长的数据库设计。 但是，没有冗余的数据库并不一定是最好的数据库，为了提高运用效率，有时必须降低规范化标准，妥善保存冗余数据。 具体来说，在概念数据模型设计中，遵守第三范式，降低范式标准的工作在物理数据模型设计中进行考虑。 降低范式是增加字段，允许冗余，达到在空间上改变时间的目的。
) )表1中有收纳商品的基本表。 “金额”字段的存在表明此表的设计不满足第三模式。 “金额”是“单价”乘以“数量”得到的，因此“金额”表示是冗馀字段。 但是，通过增加“金额”这一冗馀字段，可以加快调查统计数据的速度。 这就是用空间改变时间的方法。
Rose 2002规定了两种类型的数据列和计算列。 类似“金额”的列称为“计算列”，类似“单价”或“数量”的列称为“数据列”。
5、范式化设计和反范式化设计的优缺点
5.1归一化(时间的空间转换) )。
优点：
规范化表减少了数据冗余，数据表更新操作快，存储容量小。
坏处：
查询时必须关联多个表，这将降低查询性能。
索引优化更难
5.2范式转换(空间互换) ) ) ) )。
非规范化过程是通过冗余数据提高查询性能，但冗余数据会牺牲数据的一致性
优点：
可以减少表的关联
能够更好地进行索引优化
坏处：
存在大量冗馀数据
数据维护成本变高(删除异常、插入异常、更新异常) )。
6、OLAP和OLTP中的范式设计
OLAP一般冗余度较高，以查询分析为中心，为了提高查询效率，一般采用非规范化设计。 更新通常是定时大量数据插入。
OLTP是尽量消除冗馀，提高变更的效率。 因为这样的APP总是频繁地变化着。
————————————————
这是CSDN博客“不吃西红柿丶”的原创报道。 符合CC 4.0 BY-SA版权协议。 请附上原文出处的链接和本声明。
原文链接： 3359 blog.csdn.net/weixin _ 39032019/article/details/120239321