mysql - Improve database design for online exam -
i working on multiple choice online test project here have designed database store result looking more optimized way.
requirements:
- every question have 4 options.
- only 1 option can selected , needs stored in database.
my design:
tables:
students
stud_id, name, email
tests
test_id, testname, duration
questions
que_id, question, opt1, opt2, opt3, opt4, answer, test_id
answers
stud_id, que_id, answer
by way answers can stored increase number of records every question solved student new record added in answers table.
e.g. 1 test consists 100 questions , 1000 students take test, every student there 100 records each question , 1000 students 100k records.
is there better way number of records less.
initial response
understanding data
you have done work. far data concerned, design correct, incomplete. there 2 errors:
opt1…opt4repeating group, breaks 2nf. must placed in separate table.further, there seems no option name or descriptor, strange (what paint on page, next each radio button?)
if ever add fifth option, catered for; if have questions less 4 options, catered for.
conversely, have fixed set of columns, , if there such changes in future, have change both database , existing code. , code horrendous (extra processing instead of direct selects)
your
answerstable has no integrity. stands, answers can recorded against question student not asked, or test student did not sit. prevention of type of error ordinary fare in relational database, , not possible in record filing system.in these dark days of it, common trend. people focus on data values; imagine values in spreadsheet form, , go directly implementing object contain values. instead of understanding data , means.
answers(stud_id, que_id, answer)has no meaning, no integrity, unless context of student_test asserted.
the third item not error, because did not give requirement. however, seems me question can used in more 1 test. way have set up, such questions duplicated (the whole point of database normalise it, such there no duplication).
- of course, consequence associative table,
test_question.
- of course, consequence associative table,
questions
by way answers can stored increase number of records every question solved student new record added in answers table.
yes. normal database.
is there better way number of records less.
for record filing system, yes. database, no. since have tagged question database-design, assume that want.
a database collection of facts, not of records related fields. facts real world, limited scope of database , app.
it important determine discrete facts need, because subordinate facts depend on higher-order facts. database design. , normalise data, progress, part of 1 , same exercise. normalisation has purpose of eliminating duplication, otherwise have update anomalies. , determine relational keys, progress, again part of 1 , same exercise. relational keys provide logical structure of relational database, ie. logical integrity.
e.g. 1 test consists 100 questions , 1000 students take test, every student there 100 records each question , 1000 students 100k records.
yes. expressed in isam record-processing terms. in database terms, cannot around fact database stores:
facts 100 questions
facts 1,000 students
facts 1,000 students times 100 choices made
you need head around 2 things: large number of discrete facts; , use of compound keys. both essential relational databases. if either of missing, or implement them reluctance, not have integrity, power, or speed of relational database, have pre-1970's isam record filing system.
further, sql platforms, , degree nonsql platforms such mynonsql, heavily optimised processing sets of data (not record-by-record); heavy i/o , caching; etc. if implement structures required high concurrency, obtain more performance.
implementation
as far implementation concerned, , particularly since concerned performance, there errors. restatement be, implementation should not attempted until data understood , modelled correctly.
the problem across board, have added surrogate (there no such thing "surrogate key", surrogate, physical record id). far in modelling exercise; hasn't progressed enough; model not stable, add surrogates.
surrogates additional column plus underlying index. consumes resources, , has cost on inserts , deletes.
surrogates do not provide row uniqueness, demanded in relational database.
the relational model demands keys made data. relational keys provide row uniqueness.
a surrogate isn't made data. therefore not relational key, , not provide of qualities of one.
if surrogate used, not replace key, in addition key. why evaluate need surrogates after, not before, modelling data. implementation concern, not modelling one.
solution
rather going , forth, let me provide proposal, , can discuss it.
student test data model (page 1 only, following progression).
if not used notation, please advised every little tick, notch, , mark, solid vs dashed lines, square vs round corners, means specific. refer idef1x notation.
for
test,question.have leftidcolumns in, note better off short, meaningful codes.student_idvalid because bothname,emaillarge migrate child tables.please check verb phrases carefully, comprise set of predicates. remainder of predicates can determined directly model. if not clear, please ask.
see if can determine collection of facts, , each fact discrete precisely because other facts depend on it; not collection of records fields related.
your
answerstable has no integrity. stands, answers can recorded against question student not asked, or test student did not sit. prevention of type of error ordinary fare in relational database, , not possible in record filing system.
- that prevented.
answerstable, namedstudent_response,has integrity.studentregistered test instudent_test,,student_responsesconstrainedstudent_test.
please comment/discuss.
response comments
i add additional table subject (subject_id, subject_name) , add subject_id in question table fk okay?
yes, means. has consequences. advice make sure properly, across board:
as explained, not use surrogates (record ids) unless absolutely have to. short codes better identifiers, both users , developers.
- if more info on problems related
idcolumns, read this answer.
- if more info on problems related
subject important. context in (a)
questionexists, , (b)testexists. did exist independent items (page 1 of dm), subordinatesubject.addition substantially improves data integrity.the fact of student registration , fact of student sitting test, discrete , separate facts.
gratefully, eliminated 2 surrogates
question_id,test_id.shortcodessuchchar(2)easier , more meaningful.note improvement in table names, improved clarity.
i have updated student test data model (page 2 only, following progression).
however, exposes (that why model data, paper cheap, many drafts normal). if evaluate predicates (readily visible in data model, detailed in idef1x notation document):
each subject_test taken 0-to-n student_tests each student_test [a taking of] 1 subject_test each student took 0-to-n student_tests each student_test taken 1 studentthose predicates not accurate.
studentcan sittestinsubject.given newsubjecttable, think wantstudentsregisteredsubjects,, thereforestudent_testconstrainedsubjectsstudentregistered for.- if information on important relational concept of predicates, , how used both understand , verify model, visit this answer, scroll down until find predicate section, , read carefully.
i have updated student test data model (page 3). have more integrity, such
student_testconstrainedsubjectsstudentregistered for. relevant predicates are:each student registered 0-to-n student_subjects each student_subject registration of 1 student each subject attracted 0-to-n student_subjects each student_subject attraction of 1 subject each subject_test taken 0-to-n student_tests each student_test [a taking of] 1 subject_test each student_subject took 0-to-n student_tests each student_test taken 1 student_subjectsnow data model appears complete.
context in database.
the data hierarchies plainly visible in compounding of keys.
notice relational keys, in child tables, provide relational integrity parent tables, every higher level (parent, grandparent) in hierarchy.
in case not obvious, notice power of relational joins. cannot record filing systems have
idfields in every file. eg:join
student_responsedirectlysubjectonsubject_code, without having navigate 2 levels in-betweenjoin
student_responsedirectlystudentonstudent_id, without having navigate 2 levels in-between
Comments
Post a Comment