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:

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:

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

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:

Ini dapat diakomodasi oleh ERD logis berikut:

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.

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:

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.

Lihatlah ide umum ini:

(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 ...

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

[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 .