数据库设计结构和复杂性

Question

我需要你帮助我设计数据库。我正在尝试开发一个结果应用程序，教师可以通过该应用程序计算 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 表是我所担心的，它们应该是 分别适用于一年级至五年级的所有课程， 这样任何学生注册的课程都会去 进入相应的年份。

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都是唯一的。

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

Answer 1

表 STUDENTS 和 COURSES 正常。

对于 SCORES 列 scodeID 可能不是必需的，因为您可以使用 courseID 和 studentID 列作为复合主列关键。
关于此表的问题：学生可以参加两次考试/测试（例如第一次失败）吗？如果是，应该记录两个分数还是只记录最终分数？当前的设计不允许超过一个分数。

我不确定 SEMESTERS 表是否真的有必要。由于您不打算存储有关年份/学期对的附加信息（即仅存储年份和学期，没有描述或其他详细信息），因此您可以简单地在 SCORES 中使用两个数字列（而不是semesterID）：年和学期。这两者都会受到检查约束； year 只允许值 1 到 5； semester 上的另一个仅允许 1 和 2。仅当您想向学期添加更多详细信息时，单独的表才有用。

YEAR1 ... YEAR5 表：我认为应该只有一个带有 year 列的表，以便您分隔年份。使用多个表来存储相同的记录结构将导致大量额外的编码。
我不确定这个/这些表是否有必要。此/这些表将存储的信息已存储在 SCORES 表中。如果您将 SCORES 表重命名为 COURSES_TAKEN 并将 score 和 grade 列最初留空（以表明学生参加了课程但尚未参加考试/测试）您可以将 SCORES 和 YEARx 表的功能合二为一。

最后，您写道：“没有学生会注册两次，也没有学生能够在当前级别或将来注册两门课程”。我在职业生涯中确实学到的一件事是，“从不”和“总是”这样的词从长远来看是无效的。如果你开发了一个好的解决方案并且最终用户喜欢它，他们会想要很多新的东西并改变它；甚至是他们之前声称永远不需要的新事物和变化。因此，请始终尝试保持设计的灵活性，以便能够轻松处理任何疯狂的新请求。