多くのユーザーが多くのイベントを作成できます。また、ユーザーは所有者にそのイベントに参加するためのリクエストを送信できます（候補者、投票者、またはその両方として）。候補リクエストの場合、追加の詳細が候補詳細テーブルに保存されます。
User(u_id pk, username, password)
Event(e_id pk,u_id,e_name,e_date)
UserRequestPool(urp_id pk,u_id,e_id,request_type)＃リクエストタイプが両方の場合は2つのエントリを追加
CandidateDetails(id pk,u_id,e_id,candidate_image,candidate_promises)
Ballot(u_id,e_id,flag)＃重複投票を確実にするため
イベントIDとユーザーIDではなく、候補の詳細にユーザー要求プールIDを保存する必要があります。
CandidateDetails (id pk, urp_id, candidate_image, candidate_promises)
投票用紙についても同じです。
Ballot (urp_id, flag)
リクエストタイプをテーブルに保存することをお勧めします。
UserRequestPool (urp_id pk, u_id, e_id, r_id)
RequestType (r_id, request_type)
候補者はユーザーになることができますか？あなたはそれを除外したくないでしょう、そしてあなたは彼らが彼ら自身のイベントに投票するのを防ぐことができます。ユーザー関与コンテキストはサブジェクト名から独立している必要があり（candidate_detailsは不適切な選択であり、データベースの将来の拡張を制限する可能性があります）、セマンティクスをクリーンに保ちます-これは単なるスタイル上の推奨事項ですが、全体的に役立ちます。ユーザーのイベントへの参加は次のようになります。リンクテーブルに記録user_vote（u_id、e_id、vote）user_participant（u_id、e_id、status（accepted、denied））
userrequestpool内の重複したエントリの代わりに、両方に対応するもう1つのrequest_typeまたはr_idを定義できます。