Desain basis data survei: kaitkan jawaban ke pengguna

12

Saya sedang melakukan model konseptual untuk database survei.

Tujuannya adalah menyimpan jawaban yang diberikan oleh pengguna (itu akan menjadi aplikasi Android).

Saya memiliki tiga entitas: pengguna, pertanyaan dan opsi.

Sebuah pertanyaan akan memiliki satu atau lebih opsi (misalnya: Berapa banyak karyawan yang Anda miliki? 1-40, 40-1000, +1000).

Opsi akan memiliki teks (1-40) dan nilai (nilai yang dipilih oleh pengguna).

Pengguna akan memilih satu (atau lebih) dari opsi ini.

Desain konseptual saya adalah:

masukkan deskripsi gambar di sini

Saya tidak tahu cara mengaitkan jawaban dengan pengguna.

Bagaimana saya bisa mewakili hubungan itu?
Apakah saya memiliki entitas lain untuk mewakili nilai opsi?

Model ini akan menyimpan pertanyaan dan jawaban yang sudah dibuat sebelumnya (jawaban yang ditawarkan) dan memungkinkan mereka untuk digunakan kembali dalam survei yang berbeda.

Saya harus mewakili pertanyaan seperti ini:

masukkan deskripsi gambar di sini

Pertanyaan ini terkait dengan yang satu ini: Desain database survei: versi pertama. Apakah ada kesalahan?

VansFannel
sumber
1
Sepertinya Anda perlu tabel lain untuk menangani hubungan banyak-ke-banyak antara Pengguna dan Opsi.
OliverAsmus

Jawaban:

7

Anda harus membuat perbedaan antara jawaban yang mungkin dan jawaban yang dipilih .

The Optionmeja perlu dua tabel. The Optiontabel harus 1: M untuk Questiondan harus mencakup kemungkinan jawaban untuk pertanyaan itu.

Maka Anda perlu membuat entitas persimpangan baru, sebut saja Selected_Optionyang berada di antara Userdan Option.

Jika pertanyaan Anda memberi pengguna kesempatan untuk mengisi nilai sebagai jawaban (yaitu "OTHER: ...") maka nilai ini akan disimpan dalam Selected_Optiontabel. Kalau tidak, nilai yang dipilih oleh pengguna akan menjadi nilai yang ditemukan di Option.


EDIT:

Berdasarkan klarifikasi persyaratan OP: Apa yang Anda butuhkan tidak seperti model kuesioner khas dengan cara berikut:

  • Semua pertanyaan Anda memiliki rangkaian jawaban yang sama (kolom)
  • Beberapa jawaban Anda (kolom) dikelompokkan bersama.
  • Blok pertanyaan dikelompokkan bersama.

Mengambil snapshot formulir Anda sebagai panduan, saya telah membagi elemen formulir Anda menjadi entitas yang telah saya beri kode warna:

Contoh Bentuk Kode Warna

Ini dapat diakomodasi oleh ERD logis berikut:

ERD logis

Perhatikan bahwa saya telah memberi kode warna pada entitas di ERD agar sesuai dengan snapshot formulir sampel Anda untuk menunjukkan korelasinya.

Salah satu asumsi dalam model ini adalah bahwa setiap blok hanya memiliki satu set quesiton (yaitu satu QUESTION_GROUP) yang sesuai dengan kolom sebelah kiri pada blok. Ini sedikit asumsi yang menyederhanakan.

Joel Brown
sumber
Saya telah memperbarui pertanyaan saya dengan gambar pertanyaan survei tipical.
VansFannel
1
@VansFannel - Saya telah memperbarui jawaban saya untuk mencerminkan pertanyaan Anda yang diedit.
Joel Brown
Terima kasih banyak! Anda telah banyak membantu saya. Saya telah menambahkan desain akhir saya sebagai pertanyaan di sini: dba.stackexchange.com/questions/16066/… Anda dapat memeriksanya jika Anda mau.
VansFannel
Satu pertanyaan: Apa artinya "urutan" dan "nilai"? Saya belum banyak bekerja dengan ERD (maaf).
VansFannel
@VansFannel - Catatan atribut di ERD hanya kolom yang tidak sepele (atau tidak jelas) dalam tabel. Saya berharap Anda akan menebak di mana harus meletakkan ID, FK, deskripsi, dll. Karena sequencesaya menyarankan Anda perlu / ingin mengontrol urutan item yang ditampilkan. Karena valuesaya menunjukkan bahwa nilai yang dimasukkan pengguna (bukan hanya pilihan pilihan) mungkin sesuai.
Joel Brown
13

Skema Basis Data Survei.

Ini klasik nyata, dilakukan oleh ribuan orang. Mereka selalu tampak 'cukup sederhana' untuk memulai tetapi untuk menjadi baik itu sebenarnya cukup kompleks. Untuk melakukan ini di Rails saya akan menggunakan model yang ditunjukkan pada diagram terlampir. Saya yakin ini kelihatannya terlalu rumit untuk beberapa orang, tetapi begitu Anda telah membangun beberapa dari ini, selama bertahun-tahun, Anda menyadari bahwa sebagian besar keputusan desain adalah pola yang sangat klasik, paling baik ditangani oleh struktur data fleksibel yang dinamis di awal.
Lebih detail di bawah ini:

masukkan deskripsi gambar di sini

Detail tabel untuk tabel utama

jawaban

The jawaban table sangat penting karena menangkap tanggapan yang sebenarnya oleh pengguna. Anda akan melihat bahwa jawaban tautan ke pertanyaan_pilihan , bukan pertanyaan . Ini disengaja.

input_types

input_types adalah jenis pertanyaan. Setiap pertanyaan hanya dapat terdiri dari 1 jenis, misalnya semua panggilan radio, semua bidang teks, dll. Gunakan pertanyaan tambahan ketika ada (katakanlah) 5 panggilan radio dan 1 kotak centang untuk "sertakan?" opsi atau kombinasi tersebut. Beri label dua pertanyaan dalam tampilan pengguna sebagai satu tetapi secara internal ada dua pertanyaan, satu untuk panggilan radio, satu untuk kotak centang. Kotak centang akan memiliki grup 1 dalam hal ini.

option_groups

option_groups dan option_choices memungkinkan Anda membangun grup 'umum'. Salah satu contoh, dalam aplikasi real estat mungkin ada pertanyaan 'Berapa umur properti?'. Jawabannya mungkin diinginkan dalam kisaran: 1-5 6-10 10-25 25-100 100+

Kemudian, misalnya, jika ada pertanyaan tentang usia properti yang berdampingan, maka survei akan ingin 'menggunakan kembali rentang di atas, sehingga option_group dan opsi yang sama digunakan.

units_of_measure

units_of_measure seperti kedengarannya. Baik itu inci, cangkir, piksel, batu bata atau apa pun, Anda dapat menentukannya sekali di sini.

FYI: Meskipun sifatnya generik, seseorang dapat membuat aplikasi di atas ini, dan skema ini sangat cocok untuk kerangka kerja Ruby On Rails dengan konvensi seperti "id" untuk kunci utama untuk setiap tabel. Juga hubungan semua one_to_many sederhana tanpa banyak many_to_many atau has_many throughs diperlukan. Saya mungkin akan menambahkan has_many: throughs dan / atau: delegasi untuk mendapatkan hal-hal seperti survey_name dari jawaban individu dengan mudah tanpa.multiple.chaining.

Michael Durrant
sumber
Bagus! Terima kasih atas jawaban anda. Saya akan belajar banyak dengan itu. Terima kasih.
VansFannel
Jawaban yang bagus Sangat berguna karena saya sedang menghadapi masalah desain yang sama sekarang. :)
Dr. Mike
Ini seharusnya jawaban yang dipilih. Sangat membantu, terima kasih!
dsignr
@Michael "Anda akan melihat bahwa jawaban tautan ke pertanyaan_pilihan, bukan pertanyaan. Ini disengaja." Bisakah Anda memberikan penjelasan lebih lanjut tentang mengapa? :)
Pak
@Michael Hai, jawaban yang bagus! Jika Anda harus dapat menyesuaikan CSS dari beberapa pertanyaan di halaman HTML, bagaimana Anda melakukannya? Saya telah membuat properti CssFile di tabel perusahaan saya tetapi saya harus lebih spesifik di tingkat pertanyaan. Terima kasih.
Patrick
2

Lihatlah ide umum ini:

masukkan deskripsi gambar di sini

(Hanya bidang yang paling penting yang dimasukkan dalam model di atas, untuk singkatnya.)

Model ini memiliki karakteristik sebagai berikut:

  • Satu pertanyaan dapat dibagikan di antara banyak survei (dan survei tunggal, tentu saja, dapat berisi beberapa pertanyaan). SURVEY_QUESTION adalah tabel "tautan" yang mengimplementasikan hubungan M: N ini.
  • Urutan pertanyaan dalam survei ditentukan oleh SURVEY_QUESTION.QUESTION_NO. Karena {SURVEY_NO, QUESTION_NO} adalah kunci (alternatif), dilambangkan U1dalam diagram di atas, tidak ada dua pertanyaan yang dapat menempati "slot" yang sama dalam survei yang sama. Survei yang berbeda dapat memiliki pertanyaan yang sama dalam urutan yang berbeda.
  • Setiap pertanyaan memiliki serangkaian kemungkinan jawaban atau "opsi". Urutan visual opsi ditentukan oleh OPTION.OPTION_NO, dan karena berada di PK, tidak ada dua opsi yang dapat menempati "slot" yang sama di bawah pertanyaan yang sama.
  • Pengguna yang berbeda dapat memberikan jawaban berbeda untuk pertanyaan yang sama (dan, tentu saja, satu pengguna dapat menjawab beberapa pertanyaan). Hubungan M: N ini diimplementasikan melalui tabel "tautan" JAWABAN.
  • Seorang pengguna menjawab pertanyaan dengan memilih paling banyak salah satu opsi. Ini dipastikan dengan mengecualikan OPTION_NO dari PK ANSWER. Jika Anda ingin mengizinkan pengguna memilih beberapa opsi, sertakan OPTION_NO di PK.

Tidak ada dalam model data ini yang memaksa pengguna untuk menjawab semua pertanyaan - ini adalah sesuatu yang harus Anda lakukan di tingkat aplikasi. Meskipun demikian, model ini harus menjadi awal yang baik untuk apa yang perlu Anda lakukan ...

Branko Dimitrijevic
sumber
Saya telah memperbarui pertanyaan saya dengan gambar pertanyaan survei tipical.
VansFannel
1

Anda akan membutuhkan tabel lain untuk menampung jawaban pengguna.

user_answers
------------
  user_answer_id - kunci primer unik
  user_id - FK ke tabel Pengguna
  selected_option_id - FK ke tabel Opsi
  question_id - FK ke tabel Pertanyaan

Jika Anda memutuskan ingin pengguna dapat memilih "Lainnya" sebagai opsi dan mengisi nilainya sendiri, saya akan merekomendasikan tabel terpisah untuk itu:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - teks yang dimasukkan pengguna untuk opsi "lain".
  user_answeR_id - FK ke tabel user_answers
FrustratedWithFormsDesigner
sumber
Saya telah memperbarui pertanyaan saya dengan gambar pertanyaan survei tipical.
VansFannel
0

[Saya belum bisa berkomentar, maka ini sebagai jawaban]

Untuk solusi yang disajikan VansFannel, saya membuat model yang lebih lengkap di sana.

Tolong, periksa di sini .

Marcus Vinicius Pompeu
sumber