自己建设网站需要审核吗原创软文

三范式

三范式简介

所谓三范式, 其实是表设计的三大原则, 目的都是为了节省空间, 但是三范式是必须要遵守的吗?
答案是否定的(但是第一范式必须遵守) 因为有时候严格遵守三范式会导致查询的效率下降
(DQL链接查询的笛卡尔积现象)所以表的最终设计, 在生产环境中还是要根据具体的要求进行操作

第一范式

第一范式简介:
任何一张表都应该有主键, 且每个字段是原子性的不可再分
每一张表必须有主键, 否则被视为一张无效的表, 这里提醒一下, 因为每张表对应Java中的一个类
但是一个类不可以作为一个字段存在(has a 关系), 必须进行外键链接
比如我们下面的表设计的就有问题

在联系方式的那行, 数据并不是完全不可以再分的, 所以我们的修改如下

现在这种设计就完全满足了第一范式, 有主键, 且每个字段都是原子性的

第二范式

第二范式简介:
第二范式建立在第一范式的基础上(必须有复合主键), 要求所有的非主键字段完全依赖主键, 不能产生部分依赖
比如下面的学生表

存在复合主键, 但是存在部分依赖主键的现象, 比如学生姓名依赖的是学生编号, 教师姓名依赖的是教师编号
这就产生了部分依赖, 我们更改的方法就是设置三张表(这是一种典型的多对多, 下面会说), 一张学生表(学生编号为主键), 一张教师表(教师编号为主键), 然后设置一张关系表来关联这两张表, 修改方法如下

第三范式

第三范式简介:
建立在第二范式的基础上, 非主键字段不可以传递依赖于主键字段
第三范式的重点就在传递两个字上, 下面我们举一个例子

首先学生编号是主键, 其余所有字段应该都依赖于主键字段, 但是班级名称依赖的是班级编号, 班级编号依赖学生编号(主键)
所以我们认为发生了传递, 这种现象我们就说违反了第三范式
我们对这个表设计的修改方式是创建两张表(实际上这是一种典型的一对多的情况, 多的一方添加外键)

表设计

上面我们介绍了三大范式, 而且也对一些案例如何修改表的设计进行了简单的说明, 下面我们进行系统的说明

一对一

一对一的设计常见的有两种, 外键唯一与主键关联
其实这里大多数人有一定的疑问, 本来就是关联的同一组数据, 为什么要插开设置为两张表呢,
一对一也不存在表空间的浪费啊, 事实上, 对于测试环境确实没必要, 但是对于线上的生产环境
有可能一条数据有多个列, 即使是一对一, 数据列数过大还是不合适
下面是我们的测试情况

这是情侣的对应信息(一定是一对一)
主键共享:
方式就是, 男女双方公用同一个主键(也就是女生表的id列既是主键也是外键)

此时就是主键共享的处理, 女方的主键一定与男方的一致
外键唯一:
外键唯一就是对女方表设置一个外键h_id, 同时要求这个外键具备唯一性, h_id(fk + unique)

这两种方式, 我们最常用的是外键唯一的方式

一对多

一对多就是一方对另一方是一对一, 另一方对一方是一对一, 比如我们之前介绍的班级学生表, 对于一个学生只对应一个班级, 对于班级来说, 学生就是多个, 所以就是一对多
我们的设计原则是 :
一对多, 两张表, 多的加外键

上面是我们的学校信息, 下面是学生信息, 学生是多的那方, 所以添加一个外键

多对多

多对多就是两个一对多结合起来, 总结起来就下面一句话
多对多三张表，关系表添加外键
我们用刚才的教师学生信息表为例

我们创建了三张表, 一张学生表, 一张教师表, 还有一个关联信息表…

最终的设计

最终的设计还是要落实到用户的要求上来, 到底是优化空间, 还是用时间换速度…

视图

1. 只能将select语句创建为视图。

2. 创建视图

create or replace view v_emp as select e.ename,d.dname from emp e join dept d on e.deptno = d.deptno;

3. 视图作用

如果开发中有一条非常复杂的SQL，而这个SQL在多处使用，会给开发和维护带来成本。使用视图可以降低开发和维护的成本。
视图可以隐藏表的字段名。

4. 修改视图

alter view v_emp as select e.ename,d.dname,d.deptno from emp e join dept d on e.deptno = d.deptno;

5. 删除视图

  drop view if exists v_emp;

6. 对视图增删改（DML：insert delete update）可以影响到原表数据。