软考进行时，再次对数据库部分进行学习，对数据库概念部分总结上图： 其中，宏观来说，我们所面对的数据库都是从ＥＲ图开始的，从概念模型到逻辑模型再到最后的内部模型，大概的数据库雏形就出来了，然后就是根据关系中的键，范式，函数依赖等来优化数据库结
软考进行时，再次对数据库部分进行学习，对数据库概念部分总结上图：
其中，宏观来说，我们所面对的数据库都是从ＥＲ图开始的，从概念模型到逻辑模型再到最后的内部模型，大概的数据库雏形就出来了，然后就是根据关系中的键，范式，函数依赖等来优化数据库结构，避免数据冗余等．数据库建好以后，我们在使用过程中就是对数据库的增删改查，最底层的操作便是运算中的关系运算和元组运算，通过不同的运算从数据库中执行我们响应的操作．
三者的关系如图中，类似于面向对象中的继承关系，主键作为父类，超键和候选键都是主键的子类．超键是唯一标识元组的属性集合，候选键是超键去除多余属性后的属性集或属性，主键是用户从候选键中选取的作为元组标识的键．
学生（学号，姓名，性别，专业号，年龄）
其中（学号，姓名）是超键（唯一标识元组的属性集合），学号是候选键（去除姓名这个多余的属性），同时也是主键．
学生（学号，姓名，联系方式）
其中的联系方式可以分为多种，ＱＱ，手机号等，所以不满足第一范式，应该将联系方式分解，或者定性为某一种联系方式．
修改为：学生（学号，姓名，ＱＱ，手机号）
选课关系（学号，课程号，成绩，学分）
其中可知关键字为（学号，课程号），而学分仅仅函数依赖于课程号，所以存在部分依赖．不满足第二范式，应该将关键字分解．
学生关系（学号，课程号，成绩） 课程关系（课程号，学分）
学生（学号，姓名，系别，系地址）
其中存在学号―＞系别－＞系地址，而系别－＞学号却不存在，即学号－＞系地址这层关系是通过系别－＞系地址来间接实现的而不是直接决定的．第三范式即不存在传递依赖．应将其分解．
学生（学号，姓名，系别） 系别（系名称，系地址）
三者的关系也类似于继承关系，第一范式为父类，第二第三范式为其子类．
数据库和数据结构从不同的角度解决了数据存储的问题，数据库更像是站在数据结构的肩膀上拥有友好，方便操作方式的一种存储方式。但是我们了解了数据库的基本知识还要再来看看较为底层的东西--数据结构（见下篇博客）
下载本文