软考之---数据库

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

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

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

易混淆知识分析：

１：超键，候选键，主键

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

学生（学号，姓名，性别，专业号，年龄）

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

２：范式

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

学生（学号，姓名，联系方式）

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

修改为：学生（学号，姓名，ＱＱ，手机号）

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

选课关系（学号，课程号，成绩，学分）

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

学生关系（学号，课程号，成绩）　课程关系（课程号，学分）

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

学生（学号，姓名，系别，系地址）

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

学生（学号，姓名，系别）　系别（系名称，系地址）

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

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