【数据库】学生档案管理系统（续）

参见前一篇：【数据库】学生档案管理系统

数据库表的设计及分析

在此我们仅对关键表进行分析

学生关系拥有14个属性，其中学号为主键，是学生唯一的标识。外键班级号引用了班级表中的中的主键——班级号
该关系不存在多值属性以及复合属性
该关系存在函数依赖：
(1)学号->姓名,性别,电话,出生年月,籍贯,家庭地址,入校日期,班级号,职务,档案号,学籍状况,免冠照,学生密码
(2)档案编号->姓名,性别,电话,出生年月,籍贯,家庭地址,入校日期,班级号,职务,档案号,免冠照
因此，从属性的单值性和函数依赖关系可知：该关系符合3 NF.

奖惩记录关系拥有5个属性，其中记录编号作为主键，是奖惩记录的唯一标识。
该关系不存在多值属性以及复合属性。
该关系存在函数依赖：
(1)记录编号->奖惩日期，奖惩事件，性质，奖惩地点
因此，从属性的单值性和函数依赖关系可知：该关系符合3 NF.

奖惩情况关系不存在主键，外键“奖惩记录编号”引用奖惩记录表中主键——奖惩记录编号；外键“学号”引用学生表中主键——“学生编号”

档案管理员一共有3个属性，其中管理员编号为主键。是档案管理员的唯一标识。
该实体不存在多值属性以及复合属性
(1)管理员编号->管理员密码,管理员姓名，管理员密码
因此，从函数依赖可以看出，该表符合3NF

教育经历一共有6个属性，其中教育经历编号为主键。是教育经历的唯一标识。
该实体不存在多值属性及复合属性。
(1)编号->开始日期，终止日期，证明人，学校名称，在校职务
因此，从函数依赖可以看出， 该表符合3NF

教育情况关系不存在主键，外键“编号”引用教育经历记录表中主键——编号；外键，“学号”引用学生表中主键——“学生编号”

以上的四个表中具有如下的函数依赖：
班级号->教师号，学院号，专业号，班长，年级名称，班级名称
学院号->学院名
专业号->学院号，专业名称
教师号->学院号，教师姓名，教师密码
在这些函数依赖中没有非主元素对主元素的传递函数依赖，所以一句 这些函数依赖拆分的表示满足3NF的

开发和运行环境

开发环境

运行环境

效果展示

开始界面

登陆

学生管理

演示视频

（*点击图片跳转到Youku视频）

总结（*长文慎读）

因为这次的课程设计题目的需求很明确，所以我们并没有花太多时间在需求讨论上，直接就按题目的模块划分开始做详细设计。根据题目的要求进行了项目功能的划分。分析用例，画出用例图对每个功能快的功能进行分析。因为时间较为紧迫于是我们选择RAD的开发方式，进行任务分配，分开进行编码，最后进行整合与部署。
在设计数据库的时候我们开始以为只要按照题目要求，每个模块做一个表就可以，但当仔细考虑之后才发现设计一个优秀的数据库并没有那么简单。
这其中我们遇到很多问题。比如班级表的设计，较为简单的一种方法是班级做一张表，学院，专业，年级作为班级的属性。仔细分析我们就可以看到这样的函数依赖:班级号->专业，学院；专业->学院；存在非主属性对主键的传递函数依赖，同时这样的表中会有大部分的班级学院的属性是相同的（即在同一学院的班级学院列属性相同）会存在大量的数据冗余。所以我们将班级、专业、学院分别单独做表，因为专业和班级之间是一对多的关系，学院与专业也是一对多的关系，所以班级表中有引用专业的主键——专业号做外键，专业的表中引用学院的主键——学院号做外键。这样虽然满足了三范式，但在实际操作的时候我们才发现这种建表方法并不是绝对的好。因为每次查找学生班级情况或者添加学生的时候都需要将班级、专业、学院三张表连接起来，效率很低，相比还是建在同一张表中更为合理。
另外的问题就是学生与教育经验以及奖惩记录之间是“一对多”的关系还是“多对多”的关系。拿“奖惩记录”来说，似乎一对多更为合理——一个学生可以有多个奖惩记录或者没有奖惩记录；但如果我们这样考虑——不同的学生可以有相同的奖惩记录，比如以团队形式参赛的“全国大学生数学建模大赛”，这似乎也是合理的……这就像大一课程设计时将实际物体抽象成类，用程序语言描述习以为常的事物有时却不是习以为常的“容易”。最后我们选择了“多对多”的模式。但是实际操作中我们遇到了这样的问题，即在删除奖惩记录时，若有多个学生由此条记录，则会出现错误，即其他学生的奖惩记录会变为空值，而若不删除奖惩记录中的元组，则会造成大量数据的冗余，产生大量垃圾占用了存储空间，但是由于时间紧迫而且问题发现的较迟，我们就未进行改正，这也是我们的遗憾之一。
我们的程序还有一个致命性的问题，即效率与安全性的问题。在效率方面，我们大量的操作是通过C#语言来实现，虽然我们也用了触发器、存储过程、视图等，但是从程序整体上来说封装性较差，大量的代码使可读性下降了。
从安全性的角度来说，我们系统的授权是通过应用程序的代码授权实现的。主要是因为在SQL中很难实现元组的授权。于是整个SQL的授权机制便受到忽略。好处是会有细密的授权，问题有二，一是，授权代码会与应用程序的代码混合在一起；二是，通过应用程序的授权而非SQL的授权很难保证没有漏洞。由于一个疏忽，一个应用程序可能不检查程序而使没有权限的用户访问机密数据，要确保所有应用程序都具备所需的权限检查，其工作包括通读所有应用程序服务器的代码，这在一个大系统中是一个较为艰巨的任务。
但是我们的程序从功能上来说还是比较强大的，虽然是牺牲了效率，但是带给用户较大的方便性及可用性，同时我们设计了较为友好的人机交互界面，极大地提高了程序的易用性。

（转载请注明作者和出处：http://blog.csdn.net/xiaowei_cqu未经允许请勿用于商业用途）