Re: [SLUG] RFC: Gradebook Project Database

From: Bill Triplett (btt@nethouse.com)
Date: Tue Oct 15 2002 - 07:27:19 EDT


On Monday, October 14, 2002, at 11:27 PM, Paul M Foster wrote:

> On Mon, Oct 14, 2002 at 11:08:08PM -0400, Russell Hires wrote:
>
>> Hello all...
>>
>> Well, I'm off to the races. I looked around the internet a little bit
>> and
>> found that there are indeed Opensource/Free Gradebooks out there to
>> be had.
>> The problems with them are that they are too big/comprehensive, too
>> difficult
>> to use (we're talking teachers here!), don't have web-based
>> interfaces, or
>> have to built from scratch by somebody. Teachers don't have time for
>> this.
>> [snip]
>> But here's the tables. The way I've got this is in a shorthand
>> format, with
>> underscores around the primary key of each table. The table names
>> will have
>> _tbl at the end of their names, and will be the item directly before
>> the
>> opening parenthesis.
>>
>> Student_Tbl(_STUDENT_ID_, FNAME,
>> LNAME,SSN,ADDRESS,CITY,ST,ZIP,GRADELEVEL,MOTHERNAME,FATHERNAME)
>
> I'd leave off SSNs in all tables. Privacy issues. Even if the school
> needs to have this number, I suspect teachers don't; student_id should
> suffice for teachers.

Yeah, I agree about the SSNs, but i know that somewhere a school is
probably using the SSN as the student ID, in which case it wouldn't
matter. The problem would be that if the type for student_id is INT or
something numeric, you'll have problems with SSNs because they can
(IIRC) have leading zeros that might be wiped out on INSERT.

Also, one useful column might be a COMMENTS column. It could be of the
TEXT type. It would be very easy to implement as it has no calculations
related to it and some teachers may find it useful. OTOH, I suppose
that most teachers will know their students pretty well after a while
and would keep such comments as part of their overall opinion of the
student.

>>
>> CLASSES_TBL(_CLASS_ID_,NAME,DESCRIPTION)
>>
>
> I'm not sure if you're aiming at just having teachers run this, or
> having the school administration have something to do with it. If the
> latter, then the school itself would be filling in this table. In that
> case, you would also want to add grade_level, and class_period to this
> table, since these things are inherent in a "class".

Since some teachers will teach the same class at different times of the
day, you could add a class_periods table with class_id FK'd to
classes_tbl(_class_id_) and include some basic class scheduling
information (but not too much :) since one of the design criteria is
that this should be simple to use).

Lastly, something that might be useful is an assignments table and a
grades table to keep track of assignments and grades. This would be a
little more difficult to implement, i imagine, because there are lots
of different types of assignments that weigh differently in relation to
a students running grade in the class (pop quiz, chapter test,
homework, extra credit, was it graded on a curve, yikes :), etc.) Off
the top of my head:

table assignments (
assignment_id,
class_id,
class_period,
date_assigned,
assignment_type (?),
weight_of_overall_class_average,
assignment_desc (leave lots of room here),
...
);

table grades (
student_id (FK to students_tbl(student_id)),
assignment_id (FK to assignments(assignment_id)),
score,
date_completed,
...
);

You could calculate the students running grade in the class from the
grades table rather than having an explicit column in the students_tbl.
The cost of implementing this part would be high, but the payoff in the
statistics it provides might be worth it. From the user's perspective,
i don't think it would be that complicated.

Ok. that's about all I'm good for at this hour (and w/lots of coffee!).
Hopefully this provides some brainstorming ideas. Also keep in mind
that i'm not a professional oracle developer or anything, just an
armchair enthusiast. So if this sounds far-out... then it probably is
;).

Good luck...



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:10:59 EDT