数据库设计结构和复杂性

时间:2012-02-08 14:02:55

标签: database-design

我的数据库设计需要你的帮助。我正在尝试开发一个结果应用程序,教师将能够计算5个不同级别(1-5年级)的各种学生的成绩。此外,所有学生在升读过程中都需要参加一些课程,没有学生将被注册两次,没有学生能够在将来的现有水平注册两门课程。

我的表格中有以下表格:

Database: RESULTS
-----------------

Table: STUDENTS
        This takes care of the student registration validation 
        and avoiding duplication)
 - studentID
 - first_name
 - last_name
 - other_name

Table: COURSES
        This is preloaded to the database, but it can be edited 
        to suit the needs of the user
 - courseID
 - course_code
 - course_title
 - course_unit

Table: SCORES
        This takes entries from the STUDENTS and COURSES table, 
        so there wouldn't be any occurrence of a student taking 
        the same course more than once
 - scoresID
 - courseID
 - studentID
 - semesterID
 - score
 - grade
 - remarks

我认为YEAR表是我所关注的 分别适用于1至5年级的所有课程, 所以任何学生注册的课程都会去 进入相应的一年。

Tables: YEAR1, YEAR2, YEAR3, YEAR4, YEAR5
 - courseID
 - studentID
 - score
 - grade
 - remarks

Table: SEMESTER
        This takes care of the semester courses identity.
 - semesterID 
   (year1_semester1, year1_semester2, 
    year2_semester1, year2_semester2, 
    year3_semester1, year3_semester2, 
    year4_semester1, year4_semester2, 
    year5_semester1, year5_semester2)

在每个table中,tableID都是唯一的。

请告诉我还应该在数据库设计中添加或删除哪些内容。

1 个答案:

答案 0 :(得分:1)

STUDENTSCOURSES都可以。

如果SCORES,可能不需要列scodeID,因为您可以使用courseIDstudentID列作为复合主键。
有关的问题这张表:学生能够参加两次考试/考试(例如第一次失败)吗?如果是,是应该记录两个分数还是仅记录最终分数?目前的设计不允许超过一个分数。

我不确定SEMESTERS表是否真的有必要。由于您不打算存储有关一年/一学期对的其他信息(即只存储一年和一学期,没有描述或其他详细信息),您只需使用SCORES中的两个数字列(而不是{{ 1}}):semesterIDyear。这两个都会对它们有一个检查约束; semester上的那个只允许值1到5; year上的另一个只允许1和2.只有当您想要向学期添加更多细节时,单独的表才有用。

semester ... YEAR1表格:我认为应该只有一个包含YEAR5列的表格,以便您分隔年份。拥有多个表来存储相同的记录结构将导致大量额外的编码 而且我不确定这些/这些表是否必要。此/这些表将存储的信息已存储在year表中。如果您将SCORES表格重命名为SCORES,并且COURSES_TAKENscore列最初为空(表明学生参加了该课程但尚未参加考试/ test)您可以将grade表的功能合二为一。

最后,你写道:" 没有学生将被注册两次,没有学生可以在现有水平或将来注册两门课程"。在我的职业生涯中我肯定学到的一件事就是像#"从来没有"和"永远"从长远来看是无效的。如果您开发出一个好的解决方案并且最终用户喜欢它,他们会想要很多新东西并对其进行更改;即使是他们之前声称他们永远不需要的新事物和变化。因此,请始终尽量保持您的设计灵活,以便能够轻松处理任何疯狂的新请求。