H31午後Ⅰ設問3(1)③多段階[抽選結果]主キー
logres_Fanさん
★DB ブロンズマイスター
(No.1)
多段階抽選方式に対応できるように、新たに1つの関係を追加すると
一方、関係名[参加申込み]は、属性名(抽選結果)を削除して
関数従属性に注目してみて下さい。[抽選結果]は、大会番号と会員番号とエントリ枠番号の組み合わせを認めていますが、[参加申込み]はこれを認めていません。つまり、[抽選結果]と[参加申込み]は矛盾しています。
故に、公式解答として不正解とならないのでしょうか?
[抽選結果]{大会番号,会員番号,エントリ枠番号},抽選結果
になる、と公式解答されています。一方、関係名[参加申込み]は、属性名(抽選結果)を削除して
[参加申込み]{大会番号,会員番号},エントリ枠番号※下線付き,参加申込年月日,入金年月日,使用ポイント
となっています。関数従属性に注目してみて下さい。[抽選結果]は、大会番号と会員番号とエントリ枠番号の組み合わせを認めていますが、[参加申込み]はこれを認めていません。つまり、[抽選結果]と[参加申込み]は矛盾しています。
故に、公式解答として不正解とならないのでしょうか?
2022.09.22 02:13
VETIVERさん
(No.2)
勉強を始めて日が浅いので頓珍漢なことを申し上げていたらご指摘下さい。
私は、[エントリ枠]が[参加申し込み]に対して抽選結果を複数持つことになるので、[エントリ枠]と[参加申し込み]が多対多の関係になるので、[抽選結果]を外部のテーブルとして持つことでそれを回避しようとしたのでは、と思いました。
[エントリ枠]の複合主キー{大会番号、エントリ枠番号}と[参加申し込み]の複合主キー{大会番号、会員番号}を用いて多対多の関係を回避できそうだなと考えたのですが…
このようなやり方ってOKなのでしょうか?
私は、[エントリ枠]が[参加申し込み]に対して抽選結果を複数持つことになるので、[エントリ枠]と[参加申し込み]が多対多の関係になるので、[抽選結果]を外部のテーブルとして持つことでそれを回避しようとしたのでは、と思いました。
[エントリ枠]の複合主キー{大会番号、エントリ枠番号}と[参加申し込み]の複合主キー{大会番号、会員番号}を用いて多対多の関係を回避できそうだなと考えたのですが…
このようなやり方ってOKなのでしょうか?
2022.09.22 03:00
logres_Fanさん
★DB ブロンズマイスター
(No.3)
VETIVERさん、回答ありがとうございます。
正しいやり方に従っているから結果も正しい、という事を確認したい。これはなかなか難しいと思います。流行り廃れや将来ひっくり返るリスクがあるからです。あるやり方である結果を得た場合、どうすればいいのか。 現時点では、ある結果を導いたら関数従属性を確認する、これが1番無難です。正しいやり方に従ったとしても、矛盾があれば結果を修正する。時には、正しいやり方を見直す事もあるでしょう。
多対多回避するために外部テーブルを持つように設計した。関数従属性を確認すると矛盾がある。そこで、質問に戻ります。
> やり方ってOKなのでしょうか?
正しいやり方に従っているから結果も正しい、という事を確認したい。これはなかなか難しいと思います。流行り廃れや将来ひっくり返るリスクがあるからです。あるやり方である結果を得た場合、どうすればいいのか。 現時点では、ある結果を導いたら関数従属性を確認する、これが1番無難です。正しいやり方に従ったとしても、矛盾があれば結果を修正する。時には、正しいやり方を見直す事もあるでしょう。
多対多回避するために外部テーブルを持つように設計した。関数従属性を確認すると矛盾がある。そこで、質問に戻ります。
2022.09.22 15:32
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。