Tôi đang làm mô hình khái niệm cho một cơ sở dữ liệu khảo sát.

Mục tiêu là lưu trữ các câu trả lời do người dùng đưa ra (đây sẽ là một ứng dụng Android).

Tôi có ba thực thể: người dùng, câu hỏi và tùy chọn.

Một câu hỏi sẽ có một hoặc nhiều tùy chọn (ví dụ: Bạn có bao nhiêu nhân viên? 1-40, 40-1000, +1000).

Tùy chọn sẽ có một văn bản (1-40) và một giá trị (giá trị được lựa chọn bởi người dùng).

Người dùng sẽ chọn một (hoặc nhiều) trong số các tùy chọn này.

Thiết kế khái niệm của tôi là:

Tôi không biết cách liên kết câu trả lời với người dùng.

Làm thế nào tôi có thể đại diện cho mối quan hệ đó?
Tôi có một thực thể khác để đại diện cho giá trị tùy chọn không?

Mô hình này sẽ lưu trữ các câu hỏi và câu trả lời được tạo sẵn (câu trả lời được cung cấp) và cho phép chúng được sử dụng lại trong các khảo sát khác nhau.

Tôi phải đại diện cho câu hỏi như thế này:

Câu hỏi này liên quan đến câu hỏi này: Thiết kế cơ sở dữ liệu khảo sát: phiên bản đầu tiên. Có lỗi không?

Bạn cần phân biệt giữa câu trả lời có thể và câu trả lời được chọn .

Các Optionbảng cần phải được hai bảng. Các Optionbảng nên là 1: M để Questionvà nên bao gồm các câu trả lời có thể cho câu hỏi đó.

Sau đó, bạn cần tạo một thực thể giao lộ mới, gọi nó là Selected_Optiongiữa Uservà Option.

Nếu câu hỏi của bạn cung cấp cho người dùng cơ hội điền vào một giá trị dưới dạng câu trả lời (nghĩa là "KHÁC: ...") thì giá trị này sẽ được lưu trong Selected_Optionbảng. Nếu không, giá trị được người dùng chọn sẽ là giá trị được tìm thấy trong Option.

BIÊN TẬP:

Dựa trên các yêu cầu làm rõ của OP: Những gì bạn cần không giống như một mô hình câu hỏi thông thường theo các cách sau:

• Tất cả các câu hỏi của bạn đều có cùng một bộ câu trả lời (cột)
• Một số câu trả lời của bạn (cột) được nhóm lại với nhau.
• Các khối câu hỏi được nhóm lại với nhau.

Lấy ảnh chụp nhanh biểu mẫu của bạn làm hướng dẫn, tôi đã chia các yếu tố của biểu mẫu của bạn thành các thực thể mà tôi đã mã hóa màu:

Điều này có thể được bổ sung bởi ERD logic sau:

Lưu ý rằng tôi đã mã hóa màu các thực thể trong ERD để tương ứng với ảnh chụp nhanh của mẫu mẫu của bạn để hiển thị mối tương quan.

Một trong những giả định trong mô hình này là mỗi khối chỉ có một bộ quesitons (tức là một QUESTION_GROUP) tương ứng với cột bên trái trong khối. Đây là một chút của một giả định đơn giản hóa.

Lược đồ cơ sở dữ liệu khảo sát.

Đây là một cổ điển thực sự, được thực hiện bởi hàng ngàn. Chúng luôn có vẻ "khá đơn giản" để bắt đầu nhưng để tốt thì nó thực sự khá phức tạp. Để làm điều này trong Rails tôi sẽ sử dụng mô hình được hiển thị trong sơ đồ đính kèm. Tôi chắc chắn rằng nó có vẻ phức tạp đối với một số người, nhưng một khi bạn đã xây dựng một vài trong số đó, qua nhiều năm, bạn nhận ra rằng hầu hết các quyết định thiết kế là các mẫu rất cổ điển, được giải quyết tốt nhất bằng cấu trúc dữ liệu linh hoạt động tại ban đầu
Thêm chi tiết dưới đây:

Bảng chi tiết cho các bảng chính

câu trả lời

Bảng câu trả lời là rất quan trọng vì nó nắm bắt các phản hồi thực tế của người dùng. Bạn sẽ nhận thấy rằng các câu trả lời liên kết đến question_options chứ không phải câu hỏi . Đây là cố ý.

input_types

input_types là các loại câu hỏi. Mỗi câu hỏi chỉ có thể có 1 loại, ví dụ: tất cả các quay số radio, tất cả các trường văn bản, v.v. Sử dụng các câu hỏi bổ sung khi có (nói) 5 quay số radio và 1 hộp kiểm cho "bao gồm?" tùy chọn hoặc một số kết hợp như vậy. Dán nhãn cho hai câu hỏi trong chế độ xem của người dùng là một nhưng bên trong có hai câu hỏi, một cho quay số radio, một cho hộp kiểm. Hộp kiểm sẽ có một nhóm 1 trong trường hợp này.

nhóm tùy chọn

option_groups và option_choices cho phép bạn xây dựng các nhóm 'chung'. Một ví dụ, trong một ứng dụng bất động sản có thể có câu hỏi 'Tài sản này bao nhiêu tuổi?'. Các câu trả lời có thể được mong muốn trong các phạm vi: 1-5 6-10 10-25 25-100 100+

Sau đó, ví dụ, nếu có câu hỏi về tuổi thuộc tính liền kề, thì khảo sát sẽ muốn 'sử dụng lại' các phạm vi trên, để cùng tùy chọn và nhóm tùy chọn được sử dụng.

đơn vị đo lường

đơn vị_of_measure là như nó âm thanh. Cho dù đó là inch, cốc, pixel, gạch hay bất cứ thứ gì, bạn có thể xác định nó một lần ở đây.

FYI: Mặc dù về bản chất chung chung, người ta có thể tạo một ứng dụng trên đầu trang này và lược đồ này rất phù hợp với khung công tác Ruby On Rails với các quy ước như "id" cho khóa chính cho mỗi bảng. Ngoài ra, các mối quan hệ đều đơn giản là one_to_many không có nhiều thông số cần thiết hoặc has_many. Tôi có thể sẽ thêm has_many: thông qua và / hoặc: đại biểu mặc dù để có được những thứ như Survey_name từ một câu trả lời cá nhân một cách dễ dàng mà không có.multipl.chained.

Hãy xem ý tưởng chung này:

(Chỉ các trường thiết yếu nhất mới được đưa vào mô hình ở trên, cho ngắn gọn.)

Mô hình này có các đặc điểm sau:

• Một câu hỏi có thể được chia sẻ giữa nhiều khảo sát (và tất nhiên, một khảo sát có thể chứa nhiều câu hỏi). SURVEY_QUESTION là bảng "liên kết" thực hiện mối quan hệ M: N này.
• Thứ tự của các câu hỏi trong khảo sát được xác định bởi SURVEY_QUESTION.QUESTION_NO. Vì {SURVEY_NO, QUESTION_NO} là một khóa (thay thế), được biểu thị U1trong sơ đồ trên, không có hai câu hỏi nào có thể chiếm cùng một "vị trí" trong cùng một khảo sát. Các khảo sát khác nhau có thể có cùng một câu hỏi theo một thứ tự khác nhau.
• Mỗi câu hỏi có một loạt các câu trả lời có thể hoặc "tùy chọn". Thứ tự trực quan của các tùy chọn được xác định bởi OPTION.OPTION_NO và vì nó nằm trong PK, nên không có hai tùy chọn nào có thể chiếm cùng một "vị trí" trong cùng một câu hỏi.
• Những người dùng khác nhau có thể cung cấp các câu trả lời khác nhau cho cùng một câu hỏi (và tất nhiên, một người dùng có thể trả lời nhiều câu hỏi). Mối quan hệ M: N này được thực hiện thông qua bảng "liên kết" TRẢ LỜI.
• Một người dùng trả lời câu hỏi bằng cách chọn tối đa một trong các tùy chọn của nó. Điều này được đảm bảo bằng cách loại trừ OPTION_NO khỏi PK của ANSWER. Nếu bạn muốn cho phép người dùng chọn nhiều tùy chọn, hãy bao gồm OPTION_NO trong PK.

Không có gì trong mô hình dữ liệu này buộc người dùng phải trả lời tất cả các câu hỏi - đây là điều bạn sẽ cần làm ở cấp ứng dụng. Tuy nhiên, mô hình này sẽ là một khởi đầu tốt cho những gì bạn cần làm ...

Bạn sẽ cần một bảng khác để giữ câu trả lời của người dùng.

user_answers
------------
  user_answer_id - khóa chính duy nhất
  user_id - FK đến bảng người dùng
  chọn_option_id - FK vào bảng Tùy chọn
  question_id - Bảng câu hỏi FK

Nếu bạn quyết định bạn muốn người dùng có thể chọn "Khác" làm tùy chọn và điền vào giá trị của riêng họ, tôi khuyên bạn nên sử dụng một bảng riêng cho điều đó:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer lòng - văn bản mà người dùng đã nhập cho tùy chọn "khác".
  user_answeR_id - FK đến bảng user_answers

[Tôi chưa thể bình luận, vì vậy đây là một câu trả lời]

Đối với giải pháp mà VansFannel trình bày, tôi đã tạo ra một mô hình hoàn chỉnh hơn ở đó.

Xin vui lòng, kiểm tra nó ở đây .