开始界面

登陆

学生管理

演示视频

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

作者：xiaowei_cqu 发表于2013-3-23 0:39:39 原文链接

阅读：118 评论：0 查看评论