求软件工程课程设计项目的数据设计
题目要求:一 毕业设计互选系统
1 需求
系统为教师、学生、管理人员分别提供操作界面，三部分分别由不同的同学完成。
能登记保存教师信息、学生信息，将信息存入文件。教师信息包括教师工号、姓名、年龄、职称、所在系、联系电话。学生信息包括学号、姓名、所在系、宿舍、联系电话。
能为教师登记毕设课题信息，将课题存入文件。课题信息包括课题编号、课题名、主持老师、面向系、课题内容、课题要求。
能为学生查看毕设课题资料。
能为学生填写毕设志愿，每个学生可以填写三个课题志愿。学生填写志愿必须跟课题面向系匹配。如果学生没有确定毕设题目，则可以任意修改志愿。课题没有确定选题同学则可以被够资格的同学申请。
填写完志愿后，能为教师筛选志愿，确定每个课题选题同学，每个课题只能由一个学生选题。
教师筛选志愿完成后，将没有选定毕设课题的同学和没有被选的课题进行随机分配，直到每个学生分配到课题为止。
提供每个同学选题统计的报表。
其它使系统更完善的功能。
我们没有学过数据厍原理,表的设计要怎样才更合理?至少要符合第三范式吧!
虽然我大概设计了表的结构,但我很想知道学过数据厍原理后,会设计成怎样,如果精通SQL的人又会怎样设计?
有兴趣,大家一起讨论. 先把你的想法说说吧。。。 我是这样想的:
三种不同用户,学生,教师,管理员,分别建立三个表,字段一样,为:
用户编号，用户名，密码
另外三个表是以上三种用用户的基本信息:
学生表:
学号，姓名，所在系，宿舍，联系电话
教师表:
教师工号、姓名、年龄、职称、所在系、联系电话
管理员表：
管理员编号，姓名，电话号码（注：这个表不重要）
课题信息表：
课题编号、课题名、主持教师编号、主持教师姓名、面向系、课题内容、课题要求，已选人数，已选确认。
学生选课后的临时表，叫它为已选课表：
学生编号，课题1编号，课题2编号，课题3编号
确定选课后的表，这里叫它为选课结果表：
学生编号，已选课题号
每个基本表我都选择编号为主键，其中用户编号就对应其它表的如学号，教师工号，管理员编号。
课题信息表中，通过主持教师编号就可以查到主持教师姓名，但为了不要在显示数据时执行查询，我选择让数据存在冗余。
对已选课表的设计，我是这样想的，以学生编号为主，三个课题编号，可尽量减少重复数据。
至于建立外键约束，我在SQL中不会操作。哎！
以上我的想法，我也确实这样去实现，可是遇到了难题。因为在表中设计的数据通常不能作为显示，每次显示更新都操作一个以上的表。这是因为我对SQL不懂，加上我也是初学JSP，用JSP+SQL设计，现在进退两难，不知是不是我的数据厍设计得不合理，还是我应该去学学SQL呢！
希望得到指正！ 今晚没时间了，要走了，
明天再详细看看。 原帖由 hjack 于 2006-3-26 23:09 发表
今晚没时间了，要走了，
明天再详细看看。
有空不要忘记了啊!期待中... 角色表:
ID 角色名
你这个题目的数据有三条,分别是,老师,学生,管理员
用户表:
ID 用户名 密码 角色ID
这里用户表和角色表是一对多关联
用户信息表: (你可以根据特定的业务逻辑分为教室信息表,学生信息表,管理员信息表等等...)
ID 名字 年龄 等等....
用户表和用户信息表是一对一关联
课题表:
ID 课题名 教师编号(外键) 面向系(如果有院系表的话这里用外键) 课题内容 课题要求
教室编号和用户表一对多关联
如果要按照3nf设计,,,已选人数和已选确认不方便放入数据表,但可以放到持久化对象中统计...
选课表:
用户ID 课题ID选课状态(什么确不确定之类,用标志表示,比如1代表确定...) 我按我理解这么设计...
大家讨论下... 实体:系,学生,教师,课题
关系:选题
系表
系号,系名
教师表
教师工号,系号,姓名,出生日期,职称,电话 (系号为外键)
学生表
学号,系号,姓名,宿舍,电话 (系号为外键)
课题表
课题号,课题名,主持老师工号,系号,内容,要求 (教工号为外键,系号为外键)
选题关系表
课题号,学号,选课状态(课题号,学号均为外键,
选课状态可以为已选,取消,系统安排.对于候选的课题学生可以选择,当选课时间结束后,根据一定的业务逻辑把已选的一个课题定给一个学生,比如先到先得或者选择后统一再分配,并把该生的另两条选课状态变为取消,对于没有选到题的学生,系统安排一个课题给他,并把选课状态设为系统安排)
可以用程序逻辑控制一个学生选三个课题.也可以用数据约束来控制.
没有考虑密码的情况,要的话可以加张表.
|--------| |--------|
| | 1 ------ n | |
| 系 表|-----(拥有) ----> | 教师表 |
| | ------ | |
|--------| |--------|
|1 |1
| |
------ ------
( 拥有 ) ( 拥有 )
------ ------
| |
|n |n
V V
|--------| |--------|
| | n ------ m | |
| 学生表 |-----(选课) ----> | 课题表 |
| | ------ | |
|--------| |--------|
[ 本帖最后由 hjack 于 2006-3-28 20:06 编辑 ] 好,顶一下先!
有空再重新设计我的数据表 今天重做,问题仍在困扰.
因为学生可以选多个课题,而每个课题可以有多个老师负责,其中一个是主要负责人,其它两三个是合作者,而且一个课题面向一个或多个专业.这样,课题表的关系变得很复杂了.
课题和学生是多对多关系 (选课)
课题和系是多对多关系 (面向系)
课题和教师是多对多关系 (负责人)
这样,要查看一条课题信息,要求显示基本的题目,内容,要求外,也显示负责教师,面向系.
这样的SQL语句我写不出来.
为了解决这个"复杂的问题",有人将课题表的教师用名字而不用ID号,这样显示就不用连表查询;
对面向系,却把系号用分号格开,然后逐个查询;
而选课表,是 Wool 和 Hjack 所描述的那样的连接表,里面加上标记状态.
因为我们学院没有两个教师是同名字的,所以这样没有出现任何问题.
哪位有什么好的方法啊?请指点一二.
不然,这样的数据设计会让我变坏,以后遇到难题就想着为方便程序的编写而改变数据库的设计.
help! 无甚概念的路过。。。。
PPT等一两年，我肯定给你个满意的答案。。。。 一两年后,没有IPv4了,只有IPv6啦!
呵呵~
善意灌水 原帖由 powerwind 于 2006-9-27 10:14 发表
今天重做,问题仍在困扰.
因为学生可以选多个课题,而每个课题可以有多个老师负责,其中一个是主要负责人,其它两三个是合作者,而且一个课题面向一个或多个专业.这样,课题表的关系变得很复杂了.
课题和学生是多 ...
多表的关联可以做成视图的，
例：CREATE VIEW 视图名 ASselect a.*,b.* from table_a a,table_b b where a.condition=b.condition --oracle语法
这样就可以把视图名当表来用，但更新就要分开更新。
多表关联也一样的，只要加上关联条件就行。
一般不要用中文名做表的主键，因为多数系统会遇到中文编码问题。并且主键一般用数字类型，不用字符型。 视图当表来用,还真没试过.
试试看,结果似乎也挺复杂的.
谢谢提点. 其实一句话，表分为基础数据和业务数据，你自己分类看看，分清就易办了。
根据WOOL和Hjack的设计，结合起来
由于此系统的角色权限并不复杂，所以不使用角色表。1,系表
ID系号,系名
2,用户基表:(考虑到管理员可能不属于任何一个系的)
ID 用户名 密码 角色ID 名字手机电话权限标志(可用0，1，2表示管理员，学生，教师)（等等，一系列所有用户共同的信息）
3,教师表(继承用户基表) 与系表是多对一关系（或者也可以是多对多）
教师工号,系号,职称 (系号为外键)
4，学生表 (继承用户基表)与系表是多对一关系
学号,系号,姓名,宿舍,选课上限,已选课数 (系号为外键)
5,课题表
ID 课题号,课题名,内容,要求 , 选课上限 , 说明
6,选题关系表 与用户记表是多对多关系
课题表ID,用户ID 选课状态
[ 本帖最后由 深圳情缘 于 2006-9-28 20:29 编辑 ] 首先感谢各位的热心帮助.
这个项目对我来说,主要的难点在:
课题和学生是多对多关系 (选课)
课题和系是多对多关系 (面向系)
课题和教师是多对多关系 (负责人)
这个复杂的关系里.
我现在对解决这个问题还觉得很头痛.
现在有这样的打算:
为解决课题和系是多对多关系 (面向系)的问题,我想在全局变量(application)中保存院系的信息,因为学院的系不会太多.
为解决课题和教师是多对多关系 (负责人)的问题,我想在课题表中加入主要负责教师和两个合作教师的ID,虽然这里限制了合作教师不能超过两个,但应该是合理的.
而选课关系表当然是以上几位所说的那样啦.
现在还没有动手更改,一直在想,因为对数据库了解不够,就是想不到什么好方法.
暂时让它这样.
PS:楼上很久没来了,忙什么? Spring?Hibernate?EJB?
唉 惨啊 好久没怎么学习了
进来公司后都没培训过就上马了 我的实力实在是太差了一直都在改些头疼医头 脚疼医脚的BUG
和写Junit测试用例
BUG太多 系统不熟整天做些效率低下的工作都没学到什么新东西啊
很多东西都忘记了
现在开始搞开发，经验严重不足，进度比蜗牛还慢，实在是太羡慕WOOL和Hjack他们有大量项目经验的人啊 我是一点经验都没有,这是以前自找的,现在只能自己做点小东西,免得以后面试没话说.
可是自由地做,没有一点压力,进展很差,但感觉进步不少.
页:
[1]