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…opt4
repeating 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
answers
table 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 leftid
columns in, note better off short, meaningful codes.student_id
valid because bothname
,email
large 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
answers
table 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.
answers
table, namedstudent_response,
has integrity.student
registered test instudent_test,
,student_responses
constrainedstudent_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
id
columns, read this answer.
- if more info on problems related
subject important. context in (a)
question
exists, , (b)test
exists. 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.
shortcodes
suchchar(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 student
those predicates not accurate.
student
can sittest
insubject.
given newsubject
table, think wantstudents
registeredsubjects,
, thereforestudent_test
constrainedsubjects
student
registered 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_test
constrainedsubjects
student
registered 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_subjects
now 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
id
fields in every file. eg:join
student_response
directlysubject
onsubject_code
, without having navigate 2 levels in-betweenjoin
student_response
directlystudent
onstudent_id
, without having navigate 2 levels in-between
Comments
Post a Comment