設問3の方が面白いので、そちらも解説。
内容としては、関係スキーマの設計変更（属性の追加・削除／関係の追加）です。
設問3
設問3（1）
設問3（1）は、多段階抽選方式に対応するための関係スキーマの変更について、下記①〜③に答える問題である。
①関係に1つの属性を追加する。その関係名と属性名を答える。
②関係に1つの属性を削除する。その関係名と属性名を答える。
③関係を1つ追加する。その関係名と属性名を答える。
＜仕様変更整理＞
①多段階抽選の対象のエントリ枠には、後続のエントリ枠を1つ設定する。
②後続のエントリ枠が設定されたエントリ枠で落選した会員は、後続するエントリ枠の抽選対象に加える。
③エントリ枠の抽選結果毎に抽選結果を登録する。
下記は図2の一部抜粋。
仕様変更に対する対応は次のようになる。
①；関係”抽選エントリ枠”に属性”後続エントリ枠番号”を外部キー（関係”エントリ枠”の主キー属性の一部の”エントリ枠番号”から名称変更）の自己参照として加える。
これにより、（親）エントリ枠と後続エントリ枠の関係を表せる。
②；単独では、特に無し。
③；関係”参加申込み”ごとの属性”抽選結果”を削除して、エントリ枠ごとの抽選結果にする。後続エントリ枠が増えたので、エントリ結果ごとに抽選結果を持たせなければ、どのエントリ枠の抽選によるものか分からないからである。つまり、関係”抽選結果”を追加し、属性｛大会番号、エントリ枠番号、会員番号、抽選結果｝となる。
・大会番号；主キー。どの大会を表すのか？
・エントリ枠番号：主キー。どのエントリ枠に対するものなのか？
・会員番号：主キー。どの会員に対するものなのか？
・抽選結果；抽選結果の内容を表す
よって、回答は、
追加する属性；関係”抽選エントリ枠”の属性”後続エントリ枠番号”
削除する属性；関係”参加申込み”の属性”抽選結果”
追加する関係；”抽選結果”大会番号、エントリ枠番号、会員番号、抽選結果｝
ポイント解説
なぜ「抽選結果」を独立させる必要があるのか？
- もともと 関係「参加申込み」 では、主キーが
｛大会番号， 会員番号｝
でした。 - しかし、外部キーとして エントリ枠番号 を持つと、
1人の会員が複数のエントリ枠に紐づくケースが出てきます。 - この場合、同じ会員番号で複数の抽選結果を保持したいのに、
主キー制約（｛大会番号，会員番号｝）の重複違反が発生してしまいます。
解決策
- 新しく 関係「抽選結果」 を設けて、主キーを
｛大会番号， エントリ枠番号， 会員番号｝
に変更する。 - これにより、同じ会員番号でも異なるエントリ枠ごとに抽選結果を保持できるようになる。
まとめ
- 「参加申込み」では1大会×1会員しか管理できない。
- 「抽選結果」を独立させ、主キーにエントリ枠番号を含めることで、
1会員が複数エントリ枠に参加しても正しく管理可能 になる。
