数据库范式

原文: http://blog.gqylpy.com/gqy/473 置顶：来自一名75后老程序员的武林秘籍——必读 （博主推荐） 来，先呈上武林秘籍链接： http://blog.gqylpy.com/gqy/401/ 你好，我是一名极客！一个 75 后的老工程师！ 我将花两分钟，表述清楚我让你读这段文字的目的！ 如果你看过武侠小说，你可以把这个经历理解为，你失足落入一个山洞遇到了一位垂暮的老者！而这位老者打算传你一套武功秘籍！ 没错，我就是这个老者！ 干研发 20 多年了！我也年轻过，奋斗过！我会画原理图，会画 PCB，会模拟，会数字！玩过 PLC，玩过单片机，会用汇编，会用 C！玩过 ARM，比如 PLC，STM32，和时下正在起飞的 NXP RT1052！搞过 DSP，比如 TMS320F28335！搞过 FPGA，不管 Xilinx 还是 Altera，也不管是 Verilog 还是 VHDL，或者直接画数字电路图！我懂嵌入式系统，比如 uCOS 和 Linux！我懂开源的硬件，比如 Arduino 和树莓派!我也搞软件，学了一堆上位机的语言C#，JAVA，Python，Kotlin，Swift！会写爬虫工具，又自学写APP，不管Android 还是 IOS！ 可是这一切有什么用呢？土鸡瓦狗！不值一提！干技术的永远就是最苦逼的那个人！ 我相信看到这里的你，应该是个 IT

范式一： 一范式就是属性不可分割。属性是什么？就是表中的字段。 不可分割的意思就按字面理解就是最小单位，不能再分成更小单位了。 这个字段只能是一个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合一范式。 不过能不能分割并没有绝对的答案，看需求，也就是看你的设计目标而定。 举例： 学生信息组成学生信息表，有姓名、年龄、性别、学号等信息组成。 姓名不可拆分吧？所以可以作为该表的一个字段。 但我要说这个表要在国外使用呢？人家姓和名要分开，都有特别的意义，所以姓名字段是可拆分的，分为姓字段和名字段。 简单来说，一范式是关系数据库的基础，但字段是否真的不可拆分，根据你的设计目标而定。 范式二： 二范式就是要有主键，要求其他字段都依赖于主键。 为什么要有主键？没有主键就没有唯一性，没有唯一性在集合中就定位不到这行记录，所以要主键。 其他字段为什么要依赖于主键？因为不依赖于主键，就找不到他们。更重要的是，其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的。 如果有同学不理解依赖这个词，可以勉强用“相关”这个词代替，也就是说其他字段必须和它们的主键相关。因为不相关的东西不应该放在一行记录里。 举例： 学生信息组成学生表，姓名可以做主键么？ 不能！因为同名的话，就不唯一了，所以需要学号这样的唯一编码才行。 那么其他字段依赖于主键是什么意思

关系型数据库的三大范式： 第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项 假如有一列是存放地址：xx省xx市，但是在存取数据时需要按照xx省xx市两个因素来操作，那么该数据库的表就不满足1NF 第二范式（2NF）： 在第一范式的基础上，确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关 第三范式（3NF）：在2NF的基础上，需要确保数据表中的每一列数据都和主键直接相关而不能间接相关 来源： https://www.cnblogs.com/lijiangjun/p/11399439.html

DQL:查询语句 排序查询 聚合函数 分组查询 分页查询 约束 多表之间的关系 范式 数据库的备份和还原 DQL:查询语句 排序查询 语法：order by 子句 order by 排序字段1 排序方式1 ， 排序字段2 排序方式2… 排序方式： ASC：升序，默认的。 DESC：降序。 注意： 如果有多个排序条件，则当前边的条件值一样时，才会判断第二条件。 聚合函数：将一列数据作为一个整体，进行纵向的计算。 count：计算个数 一般选择非空的列：主键 count(*) max：计算最大值 min：计算最小值 sum：计算和 avg：计算平均值 注意：聚合函数的计算，排除null值。 解决方案： 1. 选择不包含非空的列进行计算 2. IFNULL函数 分组查询: 语法：group by 分组字段； 注意： 分组之后查询的字段：分组字段、聚合函数 where 和 having 的区别？ where 在分组之前进行限定，如果不满足条件，则不参与分组。having在分组之后进行限定，如果不满足结果，则不会被查询出来 where 后不可以跟聚合函数，having可以进行聚合函数的判断。 – 按照性别分组。分别查询男、女同学的平均分 SELECT sex , AVG(math) FROM student GROUP BY sex; – 按照性别分组。分别查询男、女同学的平均分,人数

数据库范式 第一范式 第二范式 第三范式 反范式化 第一范式 原子性：要求属性具有原子性，不可再分解 举例： 比如根据需求可以将时间拆成年月日 CREATE TABLE kpi2_tempgrade ( kpi2_tempGrade_userId varchar(30) NOT NULL, kpi2_tempGrade_name varchar(30) DEFAULT NULL, kpi2_tempGrade_year int(4) NOT NULL, kpi2_tempGrade_month int(2) NOT NULL, kpi2_tempGrade_grade varchar(1) DEFAULT NULL, kpi2_tempGrade_score float(5,3) DEFAULT NULL, PRIMARY KEY ( kpi2_tempGrade_userId , kpi2_tempGrade_year , kpi2_tempGrade_month ) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci; 第二范式 唯一性：要求记录有惟一标识，即实体的惟一性，即不存在部分依赖 举例： 比如多对多关系的表 考核人表 CREATE TABLE kpi2_checkperson (

　　在数据库设计中有五大范式,称为第一范式(1NF),第二范式(2NF),第三范式(3NF),第四范式(4NF),第五范式(5NF).但在一般的设计过程中,能够达到第三范式就满足了规范化的要求. 　　1第一范式(1NF) 　　　　确保每一列的原子性.如果每一列都是不可再分的最小单位,即满足第一范式.(将数据放在第一范式中审核,每个列都不可再分，保证了列的原子性。). 　　2第二范式(2NF) 　　　　数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指定的是存在组合关键字中的某些字段决定非关键字段的情况)，及所有非关键字段都完全依赖于任意一组候选关键字.(将数据放在第二范式中审核，每张表都只有一个主键，所有字段都依赖于主键。满足了第二范式的要求) 　　3.第三范式（3NF） 　　　　在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖，则符合第三范式。 　　 　　鲍依斯 – 科得范式（BCNF）:在第三范式基础上，数据库表中如任一候选关键字段的传递函数依赖，则符合鲍依斯 -科得范式。 来源： https://www.cnblogs.com/blacka/p/11378766.html

什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些 规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。 什么是三大范式： 第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要 求，否则，将有很多基本操作在这样的关系模式中实现不了。 第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。 第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF. 注： 关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性 第一范式 1、每一列属性都是不可再分的属性值，确保每一列的原子性 2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据。 如果需求知道那个省那个市并按其分类，那么显然第一个表格是不容易满足需求的，也不符合第一范式。 显然第一个表结构不但不能满足足够多物品的要求，还会在物品少时产生冗余。也是不符合第一范式的。 第二范式 每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复

在数据库设计中范式的应用是一个永恒的话题，从一开始学关系型数据库设计开始，老师就会对我们说在进行数据库的表结构设计时，运用范式会有多么重要的意义，确实，在实际工作当中你也会发现范式确实非常重要，但是随着工作的深入，你会慢慢发现有时候遵守范式反而会让你掉入一个又一个陷阱，于是我们又会谈到一个反范式的概念，什么时候需要遵守范式，什么时候又需要反范式，笔者试图利用几年开发的经验，结合大众点评网的实际例子，来跟大家分享一下这个过程。 总体来说，对于一个公共型网站的数据库的设计往往会经历三个阶段，第一阶段：遵守范式；第二阶段：反范式；第三阶段：结合范式与反范式，灵活应用。 今天想先讲讲第一阶段，举几个点评网数据库设计的例子来讲一下如何来遵守范式进行数据库设计的。 第一范式（1NF） 所谓第一范式（1NF），是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。 一般讲，只要是关系型数据库，一般都会遵守第一范式，但是事情往往没有那么简单，在进行数据库设计的时候，你真的都考虑清楚每个字段都是不可分割的了吗？就拿点评网的商户信息表来说，有一个字段叫“商户名”

第一范式(1NF) 强调的是列的原子性，即列不能够再分成其他几列。 第二范式 (2NF) 首先是 2NF，另外包含两部分内容一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 第三范式 (3NF) 首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。 第三范式通常已经可以满足业务需求了，表之间的关系也比较清楚了，容易维护。但是为什么要反范式呢？ 首先我们需要了解到定义数据库范式的历史背景，在20世纪70年代到80年代范式基本完善定型。在那个时候的系统下：一个硬盘的大小有限，一般也就几百兆（价格也比较高），上网的人也少，所以范式的理论强调减少依赖，降低冗余节省空间的使用。而现在最普通的硬盘都是500G，大一点的就上T了而且价格便宜，同时上网人数也增多了，数据库面临则高并发，业务逻辑复杂，低延迟的要求。很难在遵循这范式的基础上进行数据库设计开发，那么适当的降低范式，增加冗余，用空间来换时间是值得的。最低可以把范式降低到1NF。 通常在设计数据库时遵循以下原则： 1.核心业务使用范式。在类似交易有关的这种敏感核心业务中，强调数据安全和一致性，需要遵循范式保证数据唯一和一致。具体什么是核心业务视情况而定。 2.弱一致性需求——反ACID

1. 第一范式 确保数据表中每列（字段）的原子性。 如果数据表中每个字段都是不可再分的最小数据单元，则满足第一范式。 例如：user用户表，包含字段id,username,password 2. 第二范式 在第一范式的基础上更进一步，目标是确保表中的每列都和主键相关。 如果一个关系满足第一范式，并且除了主键之外的其他列，都依赖于该主键，则满足第二范式。 例如：一个用户只有一种角色，而一个角色对应多个用户。则可以按如下方式建立数据表关系，使其满足第二范式。 user用户表，字段id,username,password,role_id role角色表，字段id,name 用户表通过角色id（role_id）来关联角色表 3. 第三范式 在第二范式的基础上更进一步，目标是确保表中的列都和主键直接相关，而不是间接相关。 例如：一个用户可以对应多个角色，一个角色也可以对应多个用户。则可以按如下方式建立数据表关系，使其满足第三范式。 user用户表，字段id,username,password role角色表，字段id,name user_role用户-角色中间表，id,user_id,role_id 像这样，通过第三张表（中间表）来建立用户表和角色表之间的关系，同时又符合范式化的原则，就可以称为第三范式。 4. 反范式化 反范式化指的是通过增加冗余或重复的数据来提高数据库的读性能。 例如