前言
? 随着互联网快速的发展,大量的数据不断产生,数据库的重要性与日俱增。SQL作为一种使用最广泛的数据库语言,互联网的从业者掌握SQL语言成为必备的技能。
正文
初识
? 数据库 将大量数据保存起来,通过计算机加工而成的可以进行高效访问的数据集合
? MySQL,是一个开源的关系型数据库管理系统(Relational Database Management System),属于Oracle公司。随着MySQL功能的不断完善,性能不断提高,又有开源免费的优势,越来越多的企业选择使用MySQL,而放弃商用收费的Oracle。所以对于互联网从业者掌握和熟悉MYSQL(SQL)是非常必要的,接下来几篇文章会会围绕这一主题。
安装
? 详情见菜鸟教程
关系型数据库的三大范式
-
第一范式:每一列都是不可分割的原子数据项 ? 看表1,看到系名/系主任 这一列数据,相信大多数人都会感到不适,它完全可以拆分为两个列的。这就是第一范式,处理后就是表2. ? 再来看看这张表2,还是存在许多问题:
- 存在非常严重的数据冗余,姓名、系名、系主任。
- 若删除一位学生,比如 Jack,连同管理系等等都删除了,事实上并不影响。
- 若添加一个系和系主任,没有对应的学生,学号等等,显然不合法。
-
第二范式:非属性码的属性必须完全依赖于主码 基本概念:函数依赖(完全、部分、传递)
-
完全函数依赖: A - > B,如果A是一个属性组,则B属性的确定需要依赖A属性组中的所有属性值。例如:分数的确定需要依赖于学号和课程,而学号和课程可以称为一个属性组。如果有学号没有课程,我们只知道是谁的分数,而不知道是那一学科的分数。如果有课程没有学号,那我们只知道是哪一个学科的分数,而不知道是谁的分数。所以该属性组的两个值是必不可少的。这就是完全函数依赖。 -
部分函数依赖: A - > B,如果A是一个属性组,则B属性的确定需要依赖A属性组中的部分属性值。例如:如果一个属性组中有两个属性值,它们分别是学号和课程名称。那姓名的确定只依赖这个属性组中的学号,于课程名称无关。简单来说,依赖于属性组的中部分成员即可成为部分函数依赖。 -
传递函数依赖: A - > B - > C,传递函数依赖就是一个依赖的传递关系。通过确定A来确定B,确定了B之后,也就可以确定C,三者的依赖关系就是C依赖于B,B依赖于A。例如:我们可以通过学号来确定这位学生所在的系部,再通过系部来确定系主任是谁。而这个三者的依赖关系就是一种传递函数依赖。 ? 使用分数完全函数依赖于学号和课程这个函数依赖关系。此关系中非属性码为:课程和分数,主码为学号。然后根据第二范式。继续修改表结构了。 正如你所看到的,我们把表2拆分成了表3和表4。这时候你再看表3,表3中的分数就完全函数依赖于表3中的学号和课程。表4中也挑选学号做主码。虽然解决了数据冗余问题,但是仅仅这样还是不够的,上述问题中其他的两个问题并没有得到解决!
存在的问题:
-
第三范式:非属性码的属性必须直接依赖于主码,消除传递依赖 ? 说到传递依赖,那我们的数据表中还有哪些传递依赖呢?这时候你会发现表4中含有传递依赖的。表4中的传递依赖关系为:姓名 - > 系名 - > 系主任。该传递依赖关系为系主任传递依赖于姓名。再根据此传递依赖关系分析我们添加和删除问题就漏洞百出了。消除传递依赖的办法还是将表4进行拆分。拆分后的表结构如下: 当我们把表4拆分成表5和表6时,你再来分析添加和删除问题就会有不一样的结果。假设在数据表中添加高主任管理的化学系时,该数据只会添加到表6中,不会发生传递依赖而影响其他数据。那假设Jack同学毕业了,要将Jack同学的相关数据从表中删除,这时我们需要删除表6中的学号3数据和表3中的学号3数据即可,它们也没有传递依赖关系,同样不会影响到其他数据。
该部分原文处
关于三大范式的思考
? 三大范式有优点也有缺点。在工业实践中,对数据的冗余是有一定容忍性的,但对于数据库增删改查的效率,往往会有很高的要求。若严格地遵循三大范式,造成中间表(关系表)过多,产生效率降低,得不偿失。
- 每个表地增删改地范围尽量在本表进行,一个表尽量对应一个业务模块
- 通过主键体现业务模块之间的对应关系,且应体现流程顺序
- 中间表不可以随意使用
? 在实际的开发设计中,我们往往要从更多角度思考数据库的设计,根据不同的需求场景,进行不同角度的侧重。比如开发是否便捷,表结构是否易维护,查询效率是否达到要求等等。
? 技术最终还是为了需求,计算机问题大多还是时间和空间的矛盾和妥协。
注意事项
? 以下限于windows+mysql8.0
总结
? 这篇挺水的,赶紧下一篇干货吧!!!
|