首页 > 代码库 > 软考之---数据库

软考之---数据库

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

 

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

    易混淆知识分析:


     1:超键,候选键,主键

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

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

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

     2:范式

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

                  

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

 

                   

软考之---数据库