MarkUs Blog

MarkUs Developers Blog About Their Project

Grade Entry Form: Database Schema

with 4 comments

Yesterday’s meeting got me thinking more about the database schema for the grade entry feature. Here’s what I originally had in mind: Original Grade Entry Database Schema

I had originally considered a separate Grades table, as shown in the diagram. However, it would probably be better if we could combine the Grades table and the Marks table. There are two fields in the Marks table from Scenario 4 for the new marking scheme that do not really apply to simple grade entry: criterion_id and result_id. In addition, a table which stores grades for simple grade entry would require two fields which the existing Marks table does not need: grade_entry_item_id and grade_entry_student_id. The fields both tables have in common are: grade/mark, created_at, and updated_at. Any thoughts on how we could go about combining these tables?

Written by Farah Juma

October 24th, 2009 at 5:21 pm

4 Responses to 'Grade Entry Form: Database Schema'

Subscribe to comments with RSS or TrackBack to 'Grade Entry Form: Database Schema'.

  1. Hi Farah,

    I’m not sure if it makes sense to combine the Grades and the Marks table. I don’t see any similarities other than grade (or mark), given that created_at and updated_at are in any table (this is a Rails thing, which makes sense BTW.).

    My question is, why have as many tables as you are proposing? What’s the rationale? Could we do GradeEntryForm, GradeEntryItem and GradeEntryStudent only, enriching GradeEntryStudent with a marks attribute and grade_entry_item_id foreign key?

    I’m not too much concerned about some duplicate entries in the field marks…

    Severin

    25 Oct 09 at 8:25 am

  2. I think you’re right about leaving the Grades and Marks tables separate. I think I got caught up thinking that grades and marks were similar things but I now see that the two tables are different. Thanks, Severin!

    Here’s a description of the tables I have proposed:

    GradeEntryForm is meant to represent something like an exam, for example.

    GradeEntryItem is meant to represent a column name in a grade entry table. For example, an exam has multiple questions and each question is out of a certain number of marks. For each question on the exam, there would be a GradeEntryItem to represent it. Thus, many GradeEntryItems would be associated with one GradeEntryForm.

    Grade is meant to represent a table cell in a grade entry table. A Grade is associated with a particular student and a particular question on the exam. Thus, many Grades would be associated with one GradeEntryItem.

    GradeEntryStudent is meant to represent a row in a grade entry table. For example, a grade entry table has one row for each student. Each row consists of the grades a student got on each question of the exam. Thus, many Grades would be associated with one GradeEntryStudent. When we release marks to a student, we’ll want to release the marks for all the questions on the exam, not on a per question basis. GradeEntryStudent has a released_to_student field which indicates whether or not the marks for the questions have been released.

    If we were to get rid of the Grades table and add a grade field and a grade_entry_item_id foreign key to GradeEntryStudent, then we would lose track of the rows in the grade entry table. We would also then be storing whether or not marks for individual questions have been released to students so I’m not sure if this makes sense.

    Thoughts?

    Farah Juma

    25 Oct 09 at 11:23 am

  3. Farah,

    Forget about what I said. That doesn’t make sense, given your explanation of what represents what. Apart from that, I probably didn’t understand it right anyway. Thanks for your clarifying comments.

    Provided that we want to grow and shrink rows and columns as needed, I don’t see any other way to represent that in the DB. Excellent work. You totally have my vote on this.

    Severin

    25 Oct 09 at 2:33 pm

  4. […] Worked on the database schema for simple grade entry (see http://blog.markusproject.org/?p=629 and the comments) […]

Leave a Reply