【前言】
小编今天来讲讲SQL中的三大范式。
通常我们在创建数据库需要一定的规则去遵守,在RDBMS中,这种规则就是范式。而规范化目的就是使结构更合理,消除存储异常,使数据冗余尽量小。便于插入、删除和更新。使得它符合第一范式的规则,然后是第二范式,最后是第三范式。一般来说,数据库只需满足第三范式就行了。
【正文】
一、第一范式
每个表具有一个主键(主键可以由一个列或多个列组成,是记录的唯一标识符);
每个字段只能存放单一的值并确保有数据没有重复的组
字段不可在分
<**举例**>
现有一个学生家庭信息表
学生家庭信息表
学号 | 姓名 | 性别 | 家庭住址 |
1 | 春花 | 女 | 四川省成都市锦江区 |
2 | 夏雪 | 女 | 新疆乌鲁木齐市天山区 |
3 | 秋月 | 女 | 浙江省杭州市滨江区 |
从图中我们可以发现:学号、姓名、性别都是具有唯一性的,是不可在分割的部分。而家庭住址中由省、市、区三部分组成,所以我们在细分则为下图:
学生家庭信息表
学号 |
姓名 | 性别 | 省 | 市 | 区 |
1 | 春花 | 女 | 四川省 | 成都市 | 锦江区 |
2 | 夏雪 | 女 | 新疆 | 乌鲁木齐市 | 天山区 |
3 | 秋月 | 女 | 浙江省 | 杭州市 | 滨江区 |
现在这就是一个规则的第一范式的表了
二、第二范式
第二范式是在第一范式的基础上建立起来的,即满足第二范式必须先满足第一范式;
要求数据表里的所有数据都要和该数据表的主键有完全依赖关系
<**举例**>
现有一个学生信息表
学生信息表
学号 | 姓名 | 性别 | 年龄 | 家庭住址 | 学院编号 | 课程 | 任课教师 | 上课地点 | 上课时间 |
1 | 春花 | 女 | 19 | 河北省廊坊 | 177 | 计算机 | 李平 | 北教1号楼 | 14:00 |
2 | 夏雪 | 女 | 20 | 河北省邯郸 | 143 | 临床医学 | 王平 | 北教2号楼 | 15:00 |
3 | 秋月 | 女 | 18 | 河北省石家庄 | 245 | 教育学 | 汪平 | 南区1号楼 | 16:00 |
现在我们就可以从这个表中可以看出:学号和学院编号作为了这个表的联合主键。而任课教师、上课地点等信息都与主键没有直接关联,违反了第二范式的原则,则需要我们对这个表进行一些改动,使之符合第二范式的要求。
将两个主键的主要信息分别分割为学生信息表和专业信息两个表,将上课专业的具体信息也分为课程信息表。学生所在专业作为了一个唯一性的列(一个学校只具有这一个专业),而专业所往下又可划分为不同信息,不同的课程所上课时间、地点、老师又都各不相同。
则修改之后如图:
学生信息表
学号 | 姓名 | 性别 | 年龄 | 家庭住址 |
1 | 春花 | 女 | 19 | 河北省廊坊 |
2 | 夏雪 | 女 | 20 | 河北省邯郸 |
3 | 秋月 | 女 | 18 | 河北省石家庄 |
专业信息表
学院编号 | 课程 | 学号 |
177 | 计算机 | 1 |
143 | 临床医学 | 2 |
245 | 教育学 | 3 |
课程信息表
课程 | 任课教师 | 上课地点 | 上课时间 |
计算机 | 李平 | 北教1号楼 | 14:00 |
临床医学 | 王平 | 北教2号楼 | 15:00 |
教育学 | 汪平 | 南区1号楼 | 16:00 |
三、第三范式
符合第二范式;
消除了传递依赖关系,任何两个非主键字段之间不存在依赖关系。
<**举例**>
学生选课信息表
学号 | 姓名 | 性别 | 课程 |
1 | 春花 | 女 | 计算机 |
2 | 夏雪 | 女 | 临床医学 |
3 | 秋月 | 女 | 教育学 |
课程信息表
课程 | 任课教师 | 上课地点 | 上课时间 |
计算机 | 李平 | 北教1号楼 | 14:00 |
临床医学 | 王平 | 北教2号楼 | 15:00 |
教育学 | 汪平 | 南区1号楼 | 16:00 |
从这两张表中我们都可以明显的发现:不管哪一字段都与表当前的主键是紧密相连的,都依赖它。比如:一个学生的学号是唯一的,当你从数据库中要查找一个学生所选的课程时,你只需使用WHERE子句指定查找学号即可查出。课程信息表也是如此。
所以对于建好一个数据库来说,这三个范式是多么的重要啊。不仅使我们避免了大量的数据冗余,节省了存储空间,而且保持了数据的一致性。要查询不同表中的数据只需进行SELECT联合查询就可。
小编的SQL三大范式就介绍到这里,有什么不足之处欢迎补充!