View Single Post
Join Date: Dec 2007
Posts: 31
Reputation: AaronASterling is an unknown quantity at this point 
Solved Threads: 5
AaronASterling's Avatar
AaronASterling AaronASterling is offline Offline
Light Poster

Re: Student Database Design

 
0
  #2
Feb 28th, 2008
First off, the only two tables that are in any sort of normal form are Students and Subjects.
The others do not have a primary key. Secondly, you are repeating information from the StudentSubjects to ExamResults table. It seems to me that the StudentSubjects table is entirely redundent, further denormalizing the design. While there may be practical reasons for denormalization, (mostly reducing the need for large and expensive joins to increase query speed) i have the feeling that in an academic setting, this would be frowned upon. unless they actually wanted to *use* the database of course ;-)




So...

1) Eleminate Student subjects
2) Stick a primary key on everytable, even if you don't think you need one. For the tables that don't already have one an identity column should do.
3) I would make sure that every row in the OverallMarks table is for a year in which the student actually took a class. In sql, you could do this via a trigger or by denying insert/update access to the users and forcing them to use a stored procedure instead. you can't use checks because you're referencing another table, so it will be expensive one way or the other. perhaps it would be better done in the interface if you are not worried about bandwidth. The data is small so bandwidth shouldn't be to big a deal. If you take this route i would most surely slap an index on the StudentID column of of the StudentClasses table to speed it up.
Aaron Sterling
Reply With Quote