万叶集
? 隐约雷鸣，阴霾天空。 ?
? 但盼风雨来，能留你在此。 ?

---

前言：
✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 ?哈士奇? ，一位致力于 TFS - 全栈 赋能的博主 ✌
? CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主 ?
? 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步?
? 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。?
? 如果感觉博主的文章还不错的话，还请?关注、点赞、收藏三连支持?一下博主哦

---

专栏系列（点击解锁）	学习路线（点击解锁）	知识定位
?Python全栈白皮书?	零基础入门篇	以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。
语法进阶篇	主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。
自动化办公篇	实现日常办公软件的自动化操作，节省时间、提高办公效率。
自动化测试实战篇	从实战的角度出发，先人一步，快速转型测试开发工程师。
数据库开发实战篇	掌握关系型与非关系数据库知识，提升数据库实战开发能力。
爬虫入门与实战	更新中
数据分析篇	更新中
前端入门+flask 全栈篇	更新中
django+vue全栈篇	更新中
拓展-人工智能入门	更新中
网络安全之路	踩坑篇	记录学习及演练过程中遇到的坑，便于后来居上者
网安知识扫盲篇	三天打鱼，不深入了解原理，只会让你成为脚本小子。
vulhub靶场漏洞复现	让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。
shell编程篇	不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结]
WEB漏洞攻防篇	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
渗透工具使用集锦	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
点点点工程师	测试神器 - Charles	软件测试数据包抓包分析神器
测试神器 - Fiddler	一文学会 fiddle ，学不会倒立吃翔，稀得！
测试神器 - Jmeter	不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。
RobotFrameWork	Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。
Java实现UI自动化	文档写于2016年，Java实现的UI自动化，仍有借鉴意义。
MonkeyRunner	该工具目前的应用场景已不多，文档已删，为了排版好看才留着。

---

---

文章目录

? 数据库表的字段约束? 数据库的范式? 第一范式：原子性? 第二范式：唯一性? 第三范式：关联性 ? 字段的约束? 主键约束? 非空约束? 唯一约束? 主键约束、非空约束、唯一约束的案例使用? 外键约束? 为什么放弃 "外键约束"

该章节我们将来学习一下字段约束，毕竟定义数据表的时候是少不了字段约束的。

? 数据库表的字段约束

在讲解字段约束之前，先给大家介绍一下数据库的范式；然后才能更好的理解数据库的约束。

---

? 数据库的范式

在构造数据库的时候我们必须遵守着一定的规则，而这种规则就是范式。

在关系型数据库中，一共有六种范式；一般情况下，只满足第三范式即可。

---

? 第一范式：原子性

第一范式是数据库的基本要求，不满足这一点就不是关系型数据库。第一范式要求的是数据库的原子性，原子是不可再分的粒子，定义某个数据表的时候，某个字段中的数据也要满足原子性，不可再分。（即数据表中的每一列的基础数据不可拆分，同一列中不能有多个值，也不能存在重复的属性，示例如下：）

学号	姓名	班级
101	张三	七年级一班

这里的 “张三” 的班级内容就不符合 “原子性” ，因为 “七年级一班” 还可以拆分为 “七年级” 和 “一班”，所以它不符合第一范式。

---

学号	姓名	年级	班级
101	张三	七年级	一班

如此格式，才算得上是符合第一范式。这样拆分之后再去检索数据，就会更加的具有灵活性。

---

? 第二范式：唯一性

数据库为了避免保存重复的数据，浪费空间，于是有人提出了第二范式的概念。第二范式要求的是数据的唯一性，也就是数据表中必须有一个字段，每一条记录该字段的值是不能重复的，这个唯一属性列被称作为主键列。

举个例子：有一位同学，学号是 101 ，机考模拟考了 60 分 ，他觉得并不理想，于是又考了一次，结果还是 60 分。 如果仅仅是按照学号、成绩、日期来保存数据的话，会是下面这个样子。

学号	成绩	日期
101	60	2012-12-12
101	60	2012-12-12

这样的话就无法区分着两条数据的重复性，但是如果我们加入第四个字段 “流水号” 作为区分他们重复的主键列，就能够保证唯一性了，如下：

流水号	学号	成绩	日期
201212121201	101	60	2012-12-12
201212121202	101	60	2012-12-12

---

? 第三范式：关联性

第三范式也是我们必须要满足的一个范式，当满足了第三范式之后，同时也意味着满足了第一、第二范式。第三范式为 “关联性”，每个字段都必须与主键字段产生直接的关系，非主键字段之间是不能直接产生依赖的。

即数据可以拆分保存到不同的数据表，彼此保持关联。

来看一看下面这段表格的内容：

father	sun	daughter	daughter_toys	daughter_clothes
张三	张小三	张小丹	芭比娃娃	校服

如果将 “father” 字段作为主键的话，那么 “sun” 、“daughter” 字段则是依赖于 “father” 字段的；但是 “daughter_toys” 与 “daughter_clothes” 就违反了第三范式 ；“daughter_toys” 与 “daughter_clothes” 依赖的是 “daughter” 字段，并不是 “father” 这个字段。所以，这张表的设计就是违反了第三范式。

合理的设计 应该是下面这个样子的：

father	sun	daughter
张三	张小三	张小丹

---

daughter	daughter_toys	daughter_clothes
张小丹	芭比娃娃	校服

原来的一张表，拆分成两张表去设计："sun" 与 "daughter" 字段依赖于 "father" 字段生成一张表；"daughter_toys" 与 "daughter_clothes" 依赖于 "daughter" 生成另一张表；如此两张表的设计都是符合第三范式的。

关于为什么要设计符合第三范式的数据表关系？如果说数据表之间的关系非常的松散，那么数据表保存的这些数据就会存在问题，特别是在检索的时候速度就会非常的慢；按照第三范式创建的数据表、保存的数据在检索和提取数据的场景都非常的方便。如果违反了第三范式去保存数据，虽然说数据表也能创建出来，但是将来提取数据、查找数据的时候就会非常的慢。所以第三范式是一个非常重要的范式。

---

? 字段的约束

MySQL 中的字段约束共有4种：

约束名称	关键字	描述
主键约束	PRIMARY KEY	字段值唯一，且不能为 NULL
非空约束	NOT NULL	字段值不能为 NULL
唯一约束	UNIQUE	字段值唯一，且可以为NULL
外键约束	FOREIGN KEY	保持关联数据的逻辑性

PS：外键约束是唯一不推荐使用的约束。参照下文的 "外键约束" 目录，有单独讲解。

---

? 主键约束

主键约束要求字段的值在全表必须唯一，而且不能够为 NULL 值。MySQL操作数字的速度要远远大于字符串，所以建议主键一定要使用数字类型，因为数字的检索速度会非常的块。如果设定主键是数字类型，还可以设置自动增长：

CREATE TABLE test(    id INT PRIMARY KEY AUTO_INCREMENT,...);

PS：其实这个原理就是一个计数器而已，在创建数据表的时候在主键字段后面加上 "AUTO_INCREMENT" ，这样在插入数据的时候，就可以不用输入主键值了。主键值的生成就交给数据库完成了。

---

? 非空约束

非空约束要求字段的值不能够为 NULL 值。需要注意的是 NULL 值是没有数据的意思，而不是空字符串。

CREATE TABLE test(    id INT PRIMARY KEY AUTO_INCREMENT,    name VARCHAR(100) NOT NULL,    married BOOLEAN NOT NULL, DEFAULT FALSE);

PS：要求哪一个字段非空，直接在哪一个字段的后面加上 "NOT NULL" 即可；

PS："married BOOLEAN NOT NULL, DEFAULT FALSE" 这一段的意思是 非空 ，但是如果 "married" 这个字段为空的话，默认为 "FALSE" 。需要注意的是： "married" 这个字段为 "BOOLEAN" 类型， "FALSE" 作为数据存储到数据表中的时候，存入的是数字 "0" ;如果是 "TRUE" 的情况下，则是 "1" 。

---

? 唯一约束

唯一约束的要求：字段值如果不为 NULL ，那么在全表必须唯一。

CREATE TABLE test(    ......    tel CHAR(11) NOT NULL UNIQUE);

PS：添加唯一约束非常的简单，只需要在需要设置为 唯一约束的字段后面加上 "UNIQUE" 即可。

---

? 主键约束、非空约束、唯一约束的案例使用

这里就先将 “主键约束、非空约束、唯一约束” 写一个案例吧，至于 “外键约束” 下文会单独讲解。

CREATE TABLE tb_teacher(id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT COMMENT "主键：id，呈递增状态，不可重复；UNSIGNED：无符号的整数，也就是说没有负数。",name VARCHAR(50) NOT NULL COMMENT "姓名，不可为空",tel CHAR(11) NOT NULL UNIQUE COMMENT "手机号，不可为空，字段唯一",married BOOLEAN NOT NULL DEFAULT FALSE COMMENT "婚姻状态，不可为空，默认为 'FALSE' (即为假，未婚的意思) ")COMMENT "测试表";

这里有个需要注意的地方：在数据库中有些表是真实存在的，有些表并不存在（是虚拟表）。这些虚拟表在数据库中被叫做 "view" 也就是视图的意思。所以说如果在表的前缀加上 "t_" 或者 "tb_" ，就代表这是一个真实的数据表。

如果说数据表的前缀是 "v_" 或者 "vw_" 则代表说这个数据表是一个虚拟的表，是 "视图"

---

? 外键约束

外键约束是用来约束多张表之间关系数据的逻辑关系，见下面两张表的示例：

“部门数据表” 如下：

deptno	dname	tel
10	财务部	1001
20	技术部	1002
30	销售部	1003

---

“员工数据表” 如下：

empno	name	sex	deptno	hiredate
1	张三	男	10	2012-12-12
2	李四	女	30	2018-08-08

---

按照逻辑关系来看，应该是现有部门信息，然后才是员工的记录。这里按照先后，我们会将 “部门数据表” 称之为 “父表” ，“员工信息表” 称之为 “子表” 。

根据上述的情况来看，如果我们将 “财务部” 从 “部门数据表” 中删掉了，那么 “员工信息表” 中的 “张三” 就不符合逻辑了。

有鉴于此，为了约束数据表之间的关联数据的逻辑关系，就必须要引入外界的约束了。

接下来我们就看一下外键约束的 “父表” 与 “子表” 之间的创建语句。（需要注意的是 外键约束 的定义是写在子表上的！）

“部门数据表” 建表SQL语句如下：

CREATE TABLE tb_dept(deptno INT UNSIGNED PRIMARY KEY AUTO_INCREMENT COMMENT "部门主键：deptno",dname VARCHAR(20) NOT NULL UNIQUE COMMENT "部门名称，不可为空，字段唯一",tel CHAR(4) UNIQUE COMMENT "部门联系电话，字段唯一")COMMENT "部门数据表";

---

“员工数据表” 建表SQL语句如下：

CREATE TABLE tb_emp(empno INT UNSIGNED PRIMARY KEY COMMENT "员工编号，主键：empno",ename VARCHAR(20) NOT NULL COMMENT "员工姓名，不可为空",sex ENUM("男","女") NOT NULL COMMENT "性别；'ENUM' 是一个枚举的数据类型，可以设定好规范的值。",deptno INT UNSIGNED COMMENT "部门编号",hiredate DATE NOT NULL COMMENT "入职时间",FOREIGN KEY (deptno) REFERENCES tb_dept(deptno))COMMENT "员工数据表";

PS：需要注意的是 "FOREIGN KEY"：规定外键约束的字段 ；"REFERENCES"：关联父表 tb_dept 的 deptno 字段"

示意图如下：

---

---

---

? 为什么放弃 “外键约束”

为什么要放弃 “外键约束” 的语法呢？因为在多张表之中，如果我们建立了外键约束，一但形成闭环结构，那么任何一张表的数据都是无法删除的。会非常的麻烦…嗯…超级的麻烦。

形成闭环结构之后，任何一个数据表中的数据都是无法删除的，这样的情况下，数据库就丧失了增删改查的灵活操作，所以说在创建数据表的时候一定要放弃外键约束的。

在真实的项目中，上百张数据表是很正常的，所以说不好哪张表的外键就会形成闭环，从而影响到更多的数据表。

---

---