当前位置:首页 » 《随便一记》 » 正文

〖Python 数据库开发实战 - MySQL篇⑫〗- 数据表的字段约束

27 人参与  2022年07月22日 13:29  分类 : 《随便一记》  评论

点击全文阅读


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


前言
✌ 作者简介:渴望力量的哈士奇 ✌,大家可以叫我 ?哈士奇? ,一位致力于 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 分。 如果仅仅是按照学号、成绩、日期来保存数据的话,会是下面这个样子。

学号成绩日期
101602012-12-12
101602012-12-12

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

流水号学号成绩日期
201212121201101602012-12-12
201212121202101602012-12-12

? 第三范式:关联性

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

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

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

fathersundaughterdaughter_toysdaughter_clothes
张三张小三张小丹芭比娃娃校服

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

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

fathersundaughter
张三张小三张小丹

daughterdaughter_toysdaughter_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_" 则代表说这个数据表是一个虚拟的表,是 "视图"


? 外键约束

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

“部门数据表” 如下:

deptnodnametel
10财务部1001
20技术部1002
30销售部1003

“员工数据表” 如下:

empnonamesexdeptnohiredate
1张三102012-12-12
2李四302018-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 字段"

示意图如下:




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

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

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

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


在这里插入图片描述



点击全文阅读


本文链接:http://zhangshiyu.com/post/43703.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1