当前位置:Gxlcms > mysql > 软考之---数据库

软考之---数据库

时间:2021-07-01 10:21:17 帮助过:130人阅读

软考进行时,再次对数据库部分进行学习,对数据库概念部分总结上图: 其中,宏观来说,我们所面对的数据库都是从ER图开始的,从概念模型到逻辑模型再到最后的内部模型,大概的数据库雏形就出来了,然后就是根据关系中的键,范式,函数依赖等来优化数据库结

软考进行时,再次对数据库部分进行学习,对数据库概念部分总结上图:

\

其中,宏观来说,我们所面对的数据库都是从ER图开始的,从概念模型到逻辑模型再到最后的内部模型,大概的数据库雏形就出来了,然后就是根据关系中的键,范式,函数依赖等来优化数据库结构,避免数据冗余等.数据库建好以后,我们在使用过程中就是对数据库的增删改查,最底层的操作便是运算中的关系运算和元组运算,通过不同的运算从数据库中执行我们响应的操作.

易混淆知识分析:


1:超键,候选键,主键

三者的关系如图中,类似于面向对象中的继承关系,主键作为父类,超键和候选键都是主键的子类.超键是唯一标识元组的属性集合,候选键是超键去除多余属性后的属性集或属性,主键是用户从候选键中选取的作为元组标识的键.

学生(学号,姓名,性别,专业号,年龄)

其中(学号,姓名)是超键(唯一标识元组的属性集合),学号是候选键(去除姓名这个多余的属性),同时也是主键.

2:范式

第一范式即属性不可再分割的关系模型

学生(学号,姓名,联系方式)

其中的联系方式可以分为多种,QQ,手机号等,所以不满足第一范式,应该将联系方式分解,或者定性为某一种联系方式.

修改为:学生(学号,姓名,QQ,手机号)

第二范式即不含局部函数依赖,只有完全函数依赖的关系模式

选课关系(学号,课程号,成绩,学分)

其中可知关键字为(学号,课程号),而学分仅仅函数依赖于课程号,所以存在部分依赖.不满足第二范式,应该将关键字分解.

学生关系(学号,课程号,成绩) 课程关系(课程号,学分)

第三范式即无非主属性传递函数依赖的关系模式

学生(学号,姓名,系别,系地址)

其中存在学号―>系别->系地址,而系别->学号却不存在,即学号->系地址这层关系是通过系别->系地址来间接实现的而不是直接决定的.第三范式即不存在传递依赖.应将其分解.

学生(学号,姓名,系别) 系别(系名称,系地址)

三者的关系也类似于继承关系,第一范式为父类,第二第三范式为其子类.

数据库和数据结构从不同的角度解决了数据存储的问题,数据库更像是站在数据结构的肩膀上拥有友好,方便操作方式的一种存储方式。但是我们了解了数据库的基本知识还要再来看看较为底层的东西--数据结构(见下篇博客)

人气教程排行