博客

今天是中秋佳节，老家称为小过年。愿大家团圆、幸福、安康。

今天来讲解本系列博客最后一节，用一个实例讲解下关系数据库设计。

数据库设计在传统的软件设计流程中属于详细设计之中。实际上，现在到处都讲究风口，如果按照传统的瀑布流程，也许等系统开发出来，风的中心就转移到别的位置了。现在大多数的软件公司在软件设计的时候都没有数据库设计这一步，直接划分模块，让程序员自己设计数据库。其实，前边省下的力气后边要加倍奉还。先看一下数据库设计的基本流程

需求介绍

设计一套学生公选课定课系统，其中内容包含课程编辑、讲师资料编辑、学生资料编辑、学生选课、考试成绩登记、成绩公示等模块。其他要求，要求进行权限最小化划分。

在此，以学生资料编辑这个子模块进行设计。

详细需求整理：学生资料包含学号、姓名、性别、身份证号、籍贯、所学专业、所属院系、辅导员、所属宿舍信息。

学生信息选取：只是选取与选课系统核心相关的信息，去掉籍贯、辅导员、所属宿舍信息。学生资料剩余：

学生信息（学号、姓名、性别、身份证号、所学专业、所属院系）。

确定下学生信息中属性分类，分类为本身自有属性与其他实体关联属性：

学号、姓名、性别、身份证号：自有属性。

所学专业、所属院系：关联性属性。

将自由属性不变，将关联性属性变为关联实体的id：

所学专业id、所属院系id：关联性实体id。

确定是否作为直接关联属性id。

确定是否属于直接关联属性的时候可以根据前面讲解的设计范式，也可以按照级别最接近的原则来选取：学生属于某个专业，专业属于某个学院。因此，学生信息只剩下所属专业id这个直接关联实体id。

最终确定学生的属性如下：

学生:学号、姓名、性别、身份证号、所学专业id。

同样对专业信息与学院信息操作如下：

专业信息：专业编号、专业名称、所属学院id。

学院信息：学院编号、学院名称。

汇总实体关系，画出ER图

学生、专业、学院三个实体之间的关系分析如下：

学生与专业之间，一个学生属于一个专业，主语关系1：1，一个专业包含多个学生,主语关系1：N。因此学生与专业之间的关系为N:1的关系。同样专业与学院之间的关系也是N:1的关系。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MGWxhy6o-1605337819702)(http://respam.qiniudn.com/blog/db/student.png)]

由于学生属于某个专业，专业属于某个学院都是一种相对固定的关系，因此通过在N（多）端设置对方id的方式进行表示这种关系。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QOigCGyT-1605337819704)(http://respam.qiniudn.com/blog/db/student-s.png)]

整理为详细的数据表结构

学生信息表

专业信息表

学院信息表