As part of database design task for a high school, I am kind of stuck with classes table. The tables created so far are:
Students
--------------
Id
name
Grades (grade 1,2,....9,10)
------------------
id
description
term
Subjects (science,maths...)
-------------------
id
name
grade_subject (subjects tought in grades)
----------------
id
grade_id
subject_id
teacher
---------------------
id
name
teacher_subject (teachers who are assigned to teach subjects in particular grade)
---------------------
id
teacher_id
grade_subject_id
I am not confident about table design of teacher_subject table. This table makes use of id of grade_subject_id which might (not) be a good design. Should this table have two FKs , one grade_id and subject_id?
I also need further to store number of classes conducted on particular subject and grade by particular assigned teacher.
Would this table fit in this case:
Class (stores daily teaching schedule)
-----------------------------------
id
*teacher_id
grade_id
subject_id*
*or only teacher_subject_id from teacher_subject table*
date
start_time
end_time
status ( conducted/cancelled/postponed)+
And lastly, a table to store information about who attended the class
attandants
--------------------
student_id
class_id
Any suggestions would greatly be appreciated.
Data modelling is the art of representing the real world in a relationship diagram. Your mode is correct but is it true?
Consider, what is a CLASS? It’s a TEACHER, a SUBJECT and a GRADE. Those are your relationships. In addition you want to enforce the rules that the SUBJECT is appropriate for that GRADE and that the TEACHER can teach that SUBJECT in that GRADE.
I think your problem lies in the use of surrogate keys in the intersection tables. These are the tables which represent your many-to-many relationships:
teacher_subject,grade_subject. These are synthetic tables anyway, and they only consist of keys anyway. Hence a composite primary key will suffice.Surrogate primary keys have no meaning, so we need to define a unique constraint on
grade_subject(subject_id, grade_id)to ensure we don’t have two records for (‘PHYSICS’, ‘YEAR 2’). Given thatgrade_subjectis an intersection table with no other columns adding a surrogate key is pointless. The value of surrogate keys is to minimise the impact of a business key changing. Butgrade_subjectdoesn’t have a business key, just two surrogate keys,subject_idandgrade_id.This has an advantage when it comes to defining referential integrity.
So I would approach your problem this way:
This may look like a pile up of foreign keys, and I can envisage some arguments at the review stage. (I include the foreign key on
grade_subjectso I’ve got something to concede which I don’t care about that much and so could concede).But I don’t like having significant data relationships such as CLASS_SUBJECT obfuscated by being enforced through a subsidiary relationship such as TEACHER_SUBJECT. I don’t want to have to join to TEACHER_SUBJECT and SUBJECT_GRADE in order to join CLASS to SUBJECT.
Now, why do I choose to include referential integrity constraints to the single parent tables and the intersection table when the latter indirectly enforces the former? Because it makes the relationships clearer in the model. I stress in the model, because in the physical database I might choose to omit the single table foreign keys, or disable them, and trust in the relational integrity of the intersection table.
Something about a triple column composite bugs me, and I think it’s this: it’s not sufficiently normalised. You may have a special case but the more general model would be two rules, TEACHER_SUBJECT and TEACHER_GRADE. That would look like this
Of course, if you still wanted to enforce a rule that Mr Drury could only teach Maths to fourth formers and Physics to sixth formers you would need a TEACHER_SUBJECT_GRADE table.
One thing your data model doesn’t address is the problem of scheduling. School timetables have to mesh, so Classes need to fit into a pre-determined grid. You probably need to define the timetable’s slots as a separate table and link CLASS to that. Classes also need Classrooms. That’s another table.