I need your help with my database design. I’m trying to develop a Result Application whereby teachers will be able to compute the results of various students in 5 different levels (Year 1-5). Also all students are required to take some amount of courses as they progress, and no student will be registered twice and no student will be able to register for two courses either at there present level of in the future.
I have the following tables in my:
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
The YEAR tables are what I’ve got concerns about, they are supposed
to be for all the courses meant for Year 1 to 5 respectively,
so that courses registered by any student will go
into the respective 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)
In every table, the tableID is unique.
Please tell me what else should I add to or remove from the database design.
Tables
STUDENTSandCOURSESare OK.In case of
SCORESthe columnscodeIDis probably not necessary as you can usecourseIDandstudentIDcolumns as composite primary key.A question regarding this table: will the students be able to take an exam/test twice (e.g. first failed)? If yes, should both scores be recorded or only the final score? The current design does not allow more than one score.
I am not sure if
SEMESTERStable is really necessary. Since you do not plan to store additional information about a year/semester pairs (i.e. only year and semester would be stored, no description or other details), you could simply use two numeric columns inSCORES(instead ofsemesterID):yearandsemester. Both of these would have a check constraint on them; the one onyearwould allow only values 1 to 5; the other onsemesterwould allow only 1 and 2. The separate table would be useful only if you wanted to add more details to the semesters.The
YEAR1…YEAR5tables: I think there should be only one table with ayearcolumn to allow you to separate the years. Having multiple tables to store the same records structure will lead to a lot of extra coding.And I am not sure if this/these tables is/are necessary at all. The information that this/these tables would store is already stored in the
SCOREStable. If you rename theSCOREStable toCOURSES_TAKENand leave thescoreandgradecolumns initially empty (to show that the students took the course but do not yet take the exam/test) you can have the functionality ofSCORES and YEARxtables in one.Finally, you wrote: “no student will be registered twice and no student will be able to register for two courses either at there present level or in the future“. One thing I surely learned during my career is that words like “never” and “always” are not valid in the long term. If you develop a good solution and the end users like it, they will want a lot of new things and changes it; even new things and changes of which that they previously stated that they will never need. So, always try to keep your design flexible to be able to handle any crazy new requests easily.