ฉันทำแบบจำลองแนวคิดสำหรับฐานข้อมูลการสำรวจ

เป้าหมายคือเก็บคำตอบที่ได้รับจากผู้ใช้ (มันจะเป็นแอพ Android)

ฉันมีสามเอนทิตี: ผู้ใช้คำถามและตัวเลือก

คำถามจะมีหนึ่งหรือมากกว่าหนึ่งตัวเลือก (ตัวอย่างเช่น: คุณมีพนักงานกี่คนมี? 1-40, 40-1000, 1000)

ตัวเลือกจะมีข้อความ (1-40) และค่า (ค่าที่เลือกโดยผู้ใช้)

ผู้ใช้จะเลือกหนึ่งตัวเลือก (หรือมากกว่า) ของตัวเลือกเหล่านี้

แนวคิดการออกแบบของฉันคือ:

ฉันไม่ทราบวิธีเชื่อมโยงคำตอบกับผู้ใช้

ฉันจะแสดงความสัมพันธ์นั้นได้อย่างไร
ฉันมีเอนทิตีอื่นเพื่อแทนค่าตัวเลือกหรือไม่

รุ่นนี้จะเก็บคำถามและคำตอบล่วงหน้า (คำตอบที่เสนอ) และอนุญาตให้ใช้ซ้ำในแบบสำรวจต่างๆ

ฉันต้องแสดงคำถามเช่นนี้:

คำถามนี้เกี่ยวข้องกับคำถามนี้: การออกแบบฐานข้อมูลแบบสำรวจ: เวอร์ชันแรก มีข้อผิดพลาดหรือไม่?

คุณต้องให้ความแตกต่างระหว่างที่เป็นไปได้คำตอบและเลือกคำตอบ

Optionความต้องการที่จะเป็นตารางสองตาราง Optionตารางควรจะเป็น 1: M เพื่อQuestionและควรมีคำตอบที่เป็นไปได้สำหรับคำถามที่

แล้วคุณจะต้องทำให้เป็นนิติบุคคลแยกใหม่เรียกว่าSelected_Optionซึ่งตั้งอยู่ระหว่างและUserOption

หากคำถามของคุณให้โอกาสผู้ใช้กรอกค่าเป็นคำตอบ (เช่น "OTHER: ... ") ค่านี้จะถูกเก็บไว้ในSelected_Optionตาราง Optionมิฉะนั้นค่าที่เลือกโดยผู้ใช้จะคุ้มค่าที่พบใน

แก้ไข:

จากความต้องการที่ชัดเจนของ OP: สิ่งที่คุณต้องการไม่เหมือนกับแบบจำลองแบบสอบถามทั่วไปด้วยวิธีการดังต่อไปนี้:

• คำถามของคุณทุกคนมีคำตอบชุดเดียวกัน (คอลัมน์)
• คำตอบ (คอลัมน์) บางคำของคุณถูกจัดกลุ่มเข้าด้วยกัน
• กลุ่มของคำถามถูกจัดกลุ่มเข้าด้วยกัน

การนำสแน็ปช็อตในแบบฟอร์มของคุณมาเป็นแนวทางฉันได้แบ่งองค์ประกอบของแบบฟอร์มของคุณเป็นเอนทิตีที่ฉันใส่รหัสสีไว้แล้ว:

สิ่งนี้สามารถรองรับได้โดยโลจิคัล ERD ต่อไปนี้:

โปรดทราบว่าฉันได้ใส่รหัสเอนทิตีใน ERD เพื่อให้สอดคล้องกับภาพรวมของแบบฟอร์มตัวอย่างของคุณเพื่อแสดงความสัมพันธ์

สมมติฐานหนึ่งในโมเดลนี้คือแต่ละบล็อกมีชุด quesitons เพียงชุดเดียว (เช่นหนึ่งQUESTION_GROUP) ซึ่งสอดคล้องกับคอลัมน์ด้านซ้ายในบล็อก นี่เป็นข้อสันนิษฐานเล็กน้อย

สคีมาฐานข้อมูลการสำรวจ

นี่เป็นเกมคลาสสิคที่แท้จริงทำโดยคนเป็นพัน พวกเขามักจะดูเหมือน 'ค่อนข้างง่าย' ที่จะเริ่มต้น แต่จะดีจริง ๆ แล้วมันค่อนข้างซับซ้อน ในการทำสิ่งนี้ใน Rails ฉันจะใช้โมเดลที่แสดงในแผนภาพที่แนบมา ฉันแน่ใจว่ามันดูซับซ้อนเกินไปสำหรับบางคน แต่เมื่อคุณสร้างบางสิ่งเหล่านี้ในช่วงหลายปีที่ผ่านมาคุณรู้ว่าการตัดสินใจออกแบบส่วนใหญ่เป็นรูปแบบคลาสสิกมากที่สุดได้รับการแก้ไขโดยโครงสร้างข้อมูลแบบไดนามิกที่ยืดหยุ่น การเริ่ม
รายละเอียดเพิ่มเติมด้านล่าง:

รายละเอียดตารางสำหรับตารางคีย์

คำตอบ

ตอบตารางเป็นสิ่งสำคัญในขณะที่มันจับการตอบสนองที่เกิดขึ้นจริงโดยผู้ใช้ คุณจะสังเกตเห็นว่าการเชื่อมโยงคำตอบquestion_optionsไม่คำถาม นี่คือเจตนา

input_types

input_typesเป็นประเภทของคำถาม คำถามแต่ละข้อสามารถมีได้เพียง 1 ประเภทเท่านั้นเช่นการหมุนด้วยวิทยุทุกช่องข้อความ ฯลฯ ใช้คำถามเพิ่มเติมสำหรับเมื่อมี (พูด) 5 การโทรออกด้วยวิทยุและ 1 ช่องทำเครื่องหมายสำหรับ "รวม?" ตัวเลือกหรือการรวมกันบางอย่าง ติดป้ายกำกับคำถามสองข้อในมุมมองของผู้ใช้ว่าเป็นคำถามเดียว แต่มีคำถามสองข้อภายในคำถามหนึ่งข้อสำหรับการโทรออกด้วยวิทยุ - หนึ่งสำหรับช่องทำเครื่องหมาย ช่องทำเครื่องหมายจะมีกลุ่ม 1 ในกรณีนี้

option_groups

option_groupsและoption_choicesช่วยให้คุณสร้างกลุ่ม 'ทั่วไป' ตัวอย่างหนึ่งในแอปพลิเคชันอสังหาริมทรัพย์อาจมีคำถามว่า 'อสังหาริมทรัพย์มีอายุเท่าไหร่' คำตอบอาจต้องการในช่วง: 1-5 6-10 10-25 25-100 100+

จากนั้นตัวอย่างเช่นหากมีคำถามเกี่ยวกับอายุคุณสมบัติที่อยู่ติดกันการสำรวจจะต้องการ 'นำมาใช้ใหม่' ช่วงข้างต้นเพื่อให้ Option_group และตัวเลือกเดียวกันใช้งาน

หน่วยวัด

units_of_measureเป็นตามที่ฟัง ไม่ว่าจะเป็นนิ้วถ้วยพิกเซลอิฐหรืออะไรก็ตามคุณสามารถกำหนดได้เพียงครั้งเดียวที่นี่

FYI: แม้ว่าโดยทั่วไปในลักษณะหนึ่งสามารถสร้างแอปพลิเคชันด้านบนของนี้และสคีนี้เหมาะอย่างยิ่งกับกรอบRuby On Railsด้วยการประชุมเช่น "id" สำหรับคีย์หลักสำหรับแต่ละตาราง นอกจากนี้ความสัมพันธ์ยังเป็นเรื่องง่าย one_to_many โดยไม่จำเป็นต้องมีหลายอย่างถึง _to_many หรือมีจำนวนมาก ฉันอาจจะเพิ่ม has_many: throughs และ / หรือ: ผู้รับมอบสิทธิ์แม้ว่าจะได้รับสิ่งต่าง ๆ เช่น survey_name จากคำตอบของแต่ละบุคคลได้อย่างง่ายดายโดยไม่ต้อง

ลองดูแนวคิดทั่วไปนี้:

(เฉพาะฟิลด์ที่สำคัญที่สุดเท่านั้นที่รวมอยู่ในโมเดลด้านบนเพื่อความกะทัดรัด)

รุ่นนี้มีคุณสมบัติดังต่อไปนี้:

• คำถามเดียวสามารถใช้ร่วมกันระหว่างการสำรวจหลายครั้ง (และแน่นอนว่าการสำรวจเดียวสามารถมีคำถามได้หลายข้อ) SURVEY_QUESTION เป็นตาราง "ลิงก์" ที่ใช้ความสัมพันธ์ M: N
• ลำดับของคำถามในแบบสำรวจถูกกำหนดโดย SURVEY_QUESTION.QUESTION_NO เนื่องจาก {SURVEY_NO, QUESTION_NO} เป็นคีย์ (ทางเลือก) ซึ่งแสดงโดยU1ในแผนภาพด้านบนไม่มีคำถามสองข้อที่สามารถครอบครอง "slot" เดียวกันในแบบสำรวจเดียวกัน แบบสำรวจที่ต่างกันสามารถมีคำถามแบบเดียวกันตามลำดับที่แตกต่างกัน
• คำถามแต่ละข้อมีชุดของคำตอบที่เป็นไปได้หรือ "ตัวเลือก" ลำดับตัวเลือกแบบภาพจะถูกกำหนดโดย OPTION.OPTION_NO และเนื่องจากอยู่ใน PK จึงไม่มีตัวเลือกสองตัวที่สามารถครอบครอง "ช่อง" เดียวกันภายใต้คำถามเดียวกัน
• ผู้ใช้ที่ต่างกันสามารถให้คำตอบที่แตกต่างกันสำหรับคำถามเดียวกัน (และแน่นอนว่าผู้ใช้หนึ่งคนสามารถตอบคำถามได้หลายข้อ) ความสัมพันธ์ M: N นี้ถูกนำไปใช้ผ่านตาราง "ลิงก์" คำตอบ
• ผู้ใช้ตอบคำถามโดยเลือกอย่างน้อยหนึ่งตัวเลือก มั่นใจได้โดยไม่รวม OPTION_NO จาก PK ของ ANSWER หากคุณต้องการอนุญาตให้ผู้ใช้เลือกหลายตัวเลือกให้รวม OPTION_NO ใน PK

ไม่มีข้อมูลใดในโมเดลนี้ที่บังคับให้ผู้ใช้ตอบคำถามทุกข้อ - นี่เป็นสิ่งที่คุณต้องทำในระดับแอปพลิเคชัน อย่างไรก็ตามรุ่นนี้ควรเป็นการเริ่มต้นที่ดีสำหรับสิ่งที่คุณต้องทำ ...

คุณจะต้องมีตารางอื่นเพื่อเก็บคำตอบของผู้ใช้

user_answers
------------
  user_answer_id - คีย์หลักที่ไม่ซ้ำกัน
  user_id - FK ถึงตารางผู้ใช้
  selected_option_id - ตาราง FK ถึงตัวเลือก
  question_id - FK ถึงตารางคำถาม

หากคุณตัดสินใจว่าคุณต้องการให้ผู้ใช้สามารถเลือก "อื่น ๆ " เป็นตัวเลือกและกรอกค่าของพวกเขาเองฉันขอแนะนำตารางแยกต่างหากสำหรับ:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - ข้อความที่ผู้ใช้ป้อนสำหรับตัวเลือก "อื่น ๆ "
  user_answeR_id - ตาราง FK ถึง user_answers

[ฉันยังไม่สามารถแสดงความคิดเห็นดังนั้นนี่เป็นคำตอบ]

สำหรับโซลูชัน VansFannel ที่นำเสนอฉันทำแบบจำลองที่สมบูรณ์มากขึ้นที่นั่น

กรุณาตรวจสอบได้ที่นี่