Robię model koncepcyjny dla bazy danych ankiet.

Celem jest przechowywanie odpowiedzi udzielonych przez użytkowników (będzie to aplikacja na Androida).

Mam trzy podmioty: użytkownika, pytanie i opcję.

Pytanie będzie mieć jedną lub więcej opcji (na przykład: Ilu pracowników masz? 1-40, 40-1000, +1000).

Opcje będą miały tekst (1-40) i wartość (wartość wybrana przez użytkownika).

Użytkownik wybierze jedną (lub więcej) z tych opcji.

Mój projekt koncepcyjny to:

Nie wiem, jak powiązać odpowiedź z użytkownikiem.

Jak mogę przedstawić tę relację?
Czy mam inną jednostkę do reprezentowania wartości opcji?

Ten model przechowuje pytania i gotowe odpowiedzi (oferowane odpowiedzi) i pozwala na ich ponowne użycie w różnych ankietach.

Muszę przedstawić takie pytanie:

To pytanie jest związane z tym: Projekt bazy danych ankiet: pierwsza wersja. Czy są jakieś błędy?

Musisz rozróżnić możliwe odpowiedzi od wybranych odpowiedzi.

OptionStół musi być dwa stoły. OptionTabela powinna wynosić 1: M do Questioni powinno zawierać możliwych odpowiedzi na to pytanie.

Następnie musisz utworzyć nowy byt skrzyżowania, nazwać go, Selected_Optionktóry znajduje się pomiędzy Usera Option.

Jeśli twoje pytanie daje użytkownikowi możliwość wpisania wartości jako odpowiedzi (tj. „INNE: ...”), wówczas wartość ta zostanie zapisana w Selected_Optiontabeli. W przeciwnym razie wartość wybrana przez użytkownika będzie wartością znalezioną w Option.

EDYTOWAĆ:

W oparciu o wyjaśnienie wymagań PO: To, czego potrzebujesz, nie jest typowym modelem kwestionariusza w następujący sposób:

• Wszystkie twoje pytania mają takie same zestawy odpowiedzi (kolumny)
• Niektóre z twoich odpowiedzi (kolumn) są zgrupowane razem.
• Bloki pytań są pogrupowane razem.

Biorąc migawkę formularza jako przewodnik, podzieliłem elementy formularza na elementy, które kodowałem kolorami:

Może to zostać uwzględnione przez następujący logiczny ERD:

Zauważ, że kodowałem kolorami elementy w ERD, aby odpowiadały migawce twojego przykładowego formularza, aby pokazać korelację.

Jednym z założeń tego modelu jest to, że każdy blok ma tylko jeden zestaw quesitonów (tj. Jeden QUESTION_GROUP), który odpowiada lewej kolumnie w bloku. Jest to trochę uproszczenie.

Schemat bazy danych ankiety.

To prawdziwy klasyk, robiony przez tysiące. Na początku zawsze wydają się „dość proste”, ale aby być dobrym, w rzeczywistości są dość złożone. Aby to zrobić w Railsach, użyłbym modelu pokazanego na załączonym schemacie. Jestem pewien, że dla niektórych wydaje się to zbyt skomplikowane, ale po zbudowaniu kilku z nich z biegiem lat zdajesz sobie sprawę, że większość decyzji projektowych to bardzo klasyczne wzorce, najlepiej rozwiązane za pomocą dynamicznej elastycznej struktury danych w początek.
Więcej szczegółów poniżej:

Szczegóły tabeli dla tabel kluczy

odpowiedzi

Odpowiedzi tabela jest krytyczna, gdyż oddaje rzeczywiste reakcje przez użytkowników. Zauważysz, że odpowiada na linki do pytań_opcji , a nie pytań . To celowe.

typy_wejściowe

typy_wejściowe to typy pytań. Każde pytanie może być tylko jednego typu, np. Wszystkie numery wybierania radiowego, wszystkie pola tekstowe itp. Użyj dodatkowych pytań, gdy jest (powiedzmy) 5 numerów wybierania radiowego i 1 pole wyboru dla „dołącz?” opcja lub jakaś taka kombinacja. Oznacz dwa pytania w widoku użytkowników jako jedno, ale wewnętrznie masz dwa pytania, jedno dla wybierania radiowego, jedno dla pola wyboru. W tym przypadku pole wyboru będzie miało grupę 1.

grupy_opcji

Option_groups i Option_choices pozwalają budować „wspólne” grupy. Jednym z przykładów może być pytanie dotyczące aplikacji nieruchomości „Ile lat ma nieruchomość?”. Odpowiedzi mogą być pożądane w zakresach: 1-5 6-10 10-25 25-100 100+

Następnie, na przykład, jeśli pojawi się pytanie o przylegający wiek nieruchomości, wówczas ankieta będzie chciała „ponownie wykorzystać” powyższe zakresy, aby wykorzystać tę samą grupę opcji i opcje.

jednostki miary

Jednostki pomiaru są takie, jak się wydaje. Niezależnie od tego, czy są to cale, kubki, piksele, cegły czy cokolwiek innego, możesz zdefiniować to tutaj.

FYI: Mimo że jest to rodzaj ogólny, można na nim utworzyć aplikację, a ten schemat jest dobrze dostosowany do frameworka Ruby On Rails z konwencjami takimi jak „id” dla klucza podstawowego dla każdej tabeli. Również wszystkie relacje są proste one_to_many, bez potrzeby wielu_to_many lub koniecznych przejść przez wiele. Prawdopodobnie dodałbym has_many: throughs i / lub: delegatów, aby łatwo uzyskać takie rzeczy jak nazwa_badania z indywidualnej odpowiedzi bez.multiple.chaining.

Spójrz na ten ogólny pomysł:

(Dla uproszczenia w powyższym modelu uwzględniono tylko najbardziej istotne pola).

Ten model ma następujące cechy:

• Jedno pytanie można podzielić na wiele ankiet (a jedna ankieta oczywiście może zawierać wiele pytań). SURVEY_QUESTION to tabela „link”, która implementuje tę relację M: N.
• Kolejność pytań w ankiecie określa SURVEY_QUESTION.QUESTION_NO. Ponieważ {SURVEY_NO, QUESTION_NO} jest (alternatywnym) kluczem oznaczonym U1na powyższym schemacie, żadne dwa pytania nie mogą zajmować tego samego „pola” w tej samej ankiecie. Różne ankiety mogą mieć te same pytania w innej kolejności.
• Każde pytanie ma szereg możliwych odpowiedzi lub „opcji”. Kolejność wizualna opcji jest określona przez OPTION.OPTION_NO, a ponieważ jest w PK, żadne dwie opcje nie mogą zajmować tego samego „slotu” pod tym samym pytaniem.
• Różni użytkownicy mogą udzielić różnych odpowiedzi na to samo pytanie (i oczywiście jeden użytkownik może odpowiedzieć na wiele pytań). Ta relacja M: N jest realizowana za pomocą tabeli „link” ODPOWIEDŹ.
• Użytkownik odpowiada na pytanie, wybierając najwyżej jedną z jego opcji. Jest to zapewnione przez wykluczenie OPTION_NO z PK ODPOWIEDZI. Jeśli chcesz zezwolić użytkownikowi na wybór wielu opcji, włącz opcję OPCJE_O w PK.

W tym modelu danych nie ma niczego, co zmusiłoby użytkownika do udzielenia odpowiedzi na wszystkie pytania - jest to coś, co musisz zrobić na poziomie aplikacji. Niemniej jednak ten model powinien być dobrym początkiem tego, co musisz zrobić ...

Będziesz potrzebować kolejnej tabeli do przechowywania odpowiedzi użytkowników.

user_answers
------------
  user_answer_id - unikalny klucz podstawowy
  identyfikator_użytkownika - FK do tabeli użytkowników
  selected_option_id - FK do tabeli opcji
  question_id - FK do tabeli pytań

Jeśli zdecydujesz, że użytkownicy będą mogli wybrać opcję „Inne” jako opcję i wpisać własną wartość, zaleciłbym osobną tabelę:

user_alt_answers
----------------
  user_alt_answer_id - PK
  alt_answer_text - tekst, który użytkownik wprowadził dla opcji „inne”.
  user_answeR_id - FK do tabeli user_answers

[Nie mogę jeszcze komentować, dlatego jest to odpowiedź]

Dla rozwiązania przedstawionego przez VansFannel stworzyłem tam bardziej kompletny model.

Proszę to sprawdzić tutaj .