sql >> データベース >  >> RDS >> Database

オンライン調査のためのデータベースモデル。パート3

    パート2の結論 この一連の記事の中で、次のようなより高度な機能を追加すると述べました。

    • 質問の条件付き順序 調査、つまり、調査を通る条件付きパスの可能性
    • 管理 調査の
    • レポート および分析

    オンライン調査に関連するこの3番目の記事 、質問の条件付き順序付けをサポートするように機能を拡張します。

    将来的には、評価された回答が必要な質問を追加する可能性があります。例:「データベース設計はどれくらい好きですか。1から100の間で評価してください(1はほとんど好きではないことを示し、100は非常に好きであることを示します)」

    条件付きパス

    ユーザーの回答に基づいて、ユーザーに提示される質問に特定の条件を設定したいと思います。たとえば、質問4の答えが「はい」の場合、質問5を尋ね、質問6をスキップします。一方、質問4の答えが「いいえ」の場合は、質問5をスキップして、質問6を尋ねます。

    したがって、条件付きの質問と、質問への回答に基づいて質問を「スキップ」する方法を定義する必要があります。

    最初に、条件付きパスを単純に保つために、多肢選択式の質問に基づく条件を許可しませんが、極(はいまたはいいえ)の質問に対してのみ許可します。多肢選択問題に基づく条件付きパスをサポートするように設計を拡張できますが、それはより複雑であり、単純なものから始めたいと思います。

    前の質問への回答が現在の質問のフローを決定する可能性があるため(前の回答に基づいて質問をスキップするため)、アプリケーションが質問ごとにこのフローをチェックすることが重要です。

    管理とレポート

    今のところ、オンライン調査の管理者は追加しませんが、次の拡張のためにそれを保持します。

    いくつかのレポートと分析が必要になります。ただし、後で分析を実行するために最初にいくつかの情報を保存したいので、これは次のバージョンのために保持します。

    エンティティと関係

    調査の条件付きパスについては、question_orderを拡張します これは調査ごとに定義され、調査を質問にリンクします。前述のように、今のところ、条件付きジャンプ 極地の質問のみに基づいているため、肯定的な回答の場合に表示する次の質問と、否定的な回答の場合に表示する次の質問を定義できます。

    フォーマルデザイン

    パート1で作成したERDを拡張してみましょう このシリーズの記事の。

    conditional_orderを追加します question_orderにリンクされています;先に述べたように、私は極地の質問に基づく調査を通じてのみ条件付き順序をサポートします。現在、これを実装する方法はいくつかあります。私のニーズは単純なので、単純な実装を選択します。ニーズがより複雑な場合は、より複雑なソリューションが必要になります。

    現在の質問の回答に基づいて尋ねる「次の」質問を定義するだけでよいのですが、それでは調査の後半で質問をスキップできないため、柔軟性を高める必要があります。

    1つの方法は、肯定的な応答の場合に前進する質問の数と、否定的な応答の場合に前進する質問の数を指定することです。ただし、ジャンプが適用される質問と、使用する質問の応答を指定する必要があります。したがって、私の例をサポートするために、質問4の答えが「はい」の場合は質問5を尋ねて質問6をスキップし、質問4の答えが「いいえ」の場合は質問5をスキップして質問6を尋ねます-これには、質問4への回答を確認する2つのエントリが必要です。一方は、1つの質問を先に進め(通常どおり)、もう一方は2つの質問をスキップし(質問をスキップするため)、もう一方の条件は、質問5に回答した後に確認する必要があります。 6.

      +-------------------+----------------------+------------------------+------------------------+ 
      | question_order_id | response_to_question | positive_response_jump | negative_response_jump |
      +-------------------+----------------------+------------------------+------------------------+
      | 4                 | 4                    | 1                      | 2                      |
      +-------------------+----------------------+------------------------+------------------------+
      | 5                 | 4                    | 1                      | null                   |
      +-------------------+----------------------+------------------------+------------------------+
    

    別の方法は、特定の回答の場合に調査がジャンプする次の質問のIDを指定することです。肯定的な回答の場合は次の質問、否定的な回答の場合は次の質問です。応答。このアプローチには長所と短所があります。これにより、管理者が気付かない可能性のあるループが発生する可能性があります。ただし、ループは望ましい効果である可能性があるため、最後の質問で回答者に調査が終了したかどうかを尋ね、回答が「いいえ」の場合は最初の質問に戻ることができます。さらに、肯定的または否定的な回答の場合にジャンプする質問は、調査で指定された質問の順序に対する外部キーとして設定できるため、指定された質問が調査で定義されていることが確実にわかります。これは、参照整合性によって実装されたロジックの優れたチェックです。これがおそらくより良い解決策だと思うので、それがERDに見られるものです。

    したがって、私の例をサポートするために、質問4の答えが「はい」の場合は質問5を尋ねて質問6をスキップし、質問4の答えが「いいえ」の場合は質問5をスキップして質問6を尋ねます。

    前述のように、2つの行があります:

    Survey #1, question #4, response to question #4, positive response: next question order id = 5, negative response: next question order id = 6.

    Survey #1, question #5, response to question #4, positive response: next question order id = 7. We will never get to question #5 if the response to question #4 was negative, so we always skip question #6 after asking question #5.

      +--------+----------+----------------------+-------------------------------+-------------------------------+
      | survey | question | response_to_question | positive_response_question_id | negative_response_question_id |
      +--------+----------+----------------------+-------------------------------+-------------------------------+
      | 1      | 4        | 4                    | 5                             | 6                             |
      +--------+----------+----------------------+-------------------------------+-------------------------------+
      |        | 5        | 4                    | 7                             | null                          |
      +--------+----------+----------------------+-------------------------------+-------------------------------+
    

    条件を設定するとき、次の質問が存在することを確認するために外部キー(必須ではありません)を使用します。不可能なパス、または次の質問が指定されていない場合は条件付きで調査を終了するために、null値が使用されます。




    パート1で作成したテーブルに色を付けました 黄色の一連の記事のうち、パート2で追加された表 オレンジ色で、新しく追加されたテーブルは緑色で表示されているため、追加内容がわかりやすくなっています。

    結論

    調査を通じて条件付きステップを管理するために説明されているソリューションはどちらも、究極のルールベースのシステムではありませんが、私の目標の1つは、物事を単純かつ単純に保つことです。複雑さを圧倒することなく柔軟性を実現します。そして、繰り返しますが、他の要件があるかもしれません。要件を特定します。必要なものを実装または適応させます。私は、車輪の再発明ではなく、再利用を強く信じています。

    これで、このシリーズの記事のパート1とパート2で説明した改善の実装を開始しました。

    次の記事では、これらの機能のサポートを追加します:

    • 調査の管理
    • レポートと分析

    1. このクエリは、コンマ区切りリストSQL Serverを作成するために何をしますか?

    2. SQL Serverで日時フィルタリングのパフォーマンスを向上させる方法は?

    3. JDeveloper / SQL Developerがクレデンシャルを永続化するために使用している暗号化技術を知っている人はいますか?

    4. NOW()の例– MySQL