平成29年春期 午前 問27
広告
niveaさん
(No.1)
この問題、毎回間違えてしまいます。
なぜ間違えるのかというと、
受注番号+明細番号が主キーであることは問題文のとおりですが、
受注番号+商品コードも候補キーであろう と考えてしまうからです。
受注番号+商品コードが候補キーならば商品コードから商品名の従属が
部分従属になるので第2正規形を満たしておらず第1になるという思考です。
受注明細+商品コードを候補キーと解釈してしまうことに無理があるんですかね?
なぜ間違えるのかというと、
受注番号+明細番号が主キーであることは問題文のとおりですが、
受注番号+商品コードも候補キーであろう と考えてしまうからです。
受注番号+商品コードが候補キーならば商品コードから商品名の従属が
部分従属になるので第2正規形を満たしておらず第1になるという思考です。
受注明細+商品コードを候補キーと解釈してしまうことに無理があるんですかね?
2024.06.08 14:18
GinSanaさん
★AP プラチナマイスター
(No.2)
>受注番号+明細番号が主キーであることは問題文のとおりですが、
>受注番号+商品コードも候補キーであろう と考えてしまうからです。
受注番号+商品コードの場合、トランザクションの明細で同じ受注番号で同じ商品コードの行は複数起こり得るので、どの道受注番号+商品コードでは一意には持っていけない以上、候補キーにはなりません。
数量を合算するのかもしれないじゃないか、となるかもしれませんが、本文に書いてないのでそれもどうだかわからないし、主キーを出している時点でもう候補キーはどうでもよいので、考えることに意味がないのです。
2024.06.08 17:22
jjon-comさん
★AP プラチナマイスター
(No.3)
GinSanaさんの指摘が伝わっていない可能性を考えての蛇足です。
候補キーは,主キーとなり得る(複数の)候補です。
受注番号+商品コード を主キーとするDB設計もあるだろうし,
受注番号+明細番号 を主キーとするDB設計もあるだろう。
そのような候補のうち,
この問題では 受注番号+明細番号 を主キーにすると方針を決めたのですから,
この前提の下では
必要がない。
候補キーは,主キーとなり得る(複数の)候補です。
受注番号+商品コード を主キーとするDB設計もあるだろうし,
受注番号+明細番号 を主キーとするDB設計もあるだろう。
そのような候補のうち,
この問題では 受注番号+明細番号 を主キーにすると方針を決めたのですから,
この前提の下では
> 受注番号+商品コードも候補キーであろう と考えてしまう
必要がない。
> 主キーを出している時点でもう候補キーはどうでもよいので、考えることに意味がないのです。(No.2)
2024.06.10 19:28
niveaさん
(No.4)
GinSanaさん、jjon-comさん、ありがとうございます。
お手数掛けます。
DBスペシャリストの教科書に
第2正規形の定義は
・第1正規形であること
・すべての非キー属性は、いかなる候補キーにも部分関数従属していない(完全関数従属である)こと
と記載されています。
この2つ目の、「いかなる候補キー・・・」の部分は
主キー以外の他の候補キーからも部分関数従属してはダメ!と解釈したのですが、
その日本語解釈が間違っていますか?
お手数掛けます。
DBスペシャリストの教科書に
第2正規形の定義は
・第1正規形であること
・すべての非キー属性は、いかなる候補キーにも部分関数従属していない(完全関数従属である)こと
と記載されています。
この2つ目の、「いかなる候補キー・・・」の部分は
主キー以外の他の候補キーからも部分関数従属してはダメ!と解釈したのですが、
その日本語解釈が間違っていますか?
2024.06.10 20:51
niveaさん
(No.5)
No4の最後3行の補足です
「いかなる候補キー・・・」の解釈ですが、
主キーは候補キーの1つだと思っているので、
ここで言う「いかなる候補キー」は主キーが決まっているとしても、
主キー以外の候補キーも含んでいると解釈しているのですが、
その解釈が間違っていますか?
「いかなる候補キー・・・」の解釈ですが、
主キーは候補キーの1つだと思っているので、
ここで言う「いかなる候補キー」は主キーが決まっているとしても、
主キー以外の候補キーも含んでいると解釈しているのですが、
その解釈が間違っていますか?
2024.06.10 21:05
GinSanaさん
★AP プラチナマイスター
(No.6)
この投稿は投稿者により削除されました。(2024.06.10 22:56)
2024.06.10 22:56
GinSanaさん
★AP プラチナマイスター
(No.7)
もう少しその具体例を言うと、
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000gn5o-att/2016h28h_db_pm1_qs.pdf
DBSP平成28年午後1問1設問1(1)で
候補キー
{施設 ID,駐車場 ID},{施設経度,施設緯度,駐車場 ID}
部分関数従属性の有無 あり 推移的関数従属性の有無 あり
部分関数
従属性
・施設 ID→施設名
・施設 ID→カテゴリコード
・施設 ID→施設エリアコード
推移的関数
従属性
・施設 ID → カテゴリコード → カテゴリ名
こんな風に設計され、関係 周辺施設は第一正規形となると言われるので、たぶんこのあたりのでややこしくなった可能性はあります。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000gn5o-att/2016h28h_db_pm1_qs.pdf
DBSP平成28年午後1問1設問1(1)で
候補キー
{施設 ID,駐車場 ID},{施設経度,施設緯度,駐車場 ID}
部分関数従属性の有無 あり 推移的関数従属性の有無 あり
部分関数
従属性
・施設 ID→施設名
・施設 ID→カテゴリコード
・施設 ID→施設エリアコード
推移的関数
従属性
・施設 ID → カテゴリコード → カテゴリ名
こんな風に設計され、関係 周辺施設は第一正規形となると言われるので、たぶんこのあたりのでややこしくなった可能性はあります。
2024.06.10 22:42
GinSanaさん
★AP プラチナマイスター
(No.8)
この投稿は投稿者により削除されました。(2024.06.10 23:06)
2024.06.10 23:06
GinSanaさん
★AP プラチナマイスター
(No.9)
No.7でこの解答が導出できるのは、本文に制約があるからです。
デスペの場合、本文にどう従属するか?とかが書いてあるから導けますが、応用午前の場合、正直いって
https://www.ap-siken.com/kakomon/29_haru/q27.html
で「候補キー」を主キーで前提として置かれているもの以外で設定できる根拠がない。
だから、候補キーは「主キー」となったもの以外に存在しない、と考えないと変なことになります。己の常識でものを考えてはいけなくて、本文から読み取れることしか使ってはいけない。
そういう意味では、「仮に」商品コードが候補キーの一部になっていれば、第一正規形です。
しかし、問題では根拠がない以上、候補キーの一部ではない、ということです。
デスペの場合、本文にどう従属するか?とかが書いてあるから導けますが、応用午前の場合、正直いって
https://www.ap-siken.com/kakomon/29_haru/q27.html
で「候補キー」を主キーで前提として置かれているもの以外で設定できる根拠がない。
だから、候補キーは「主キー」となったもの以外に存在しない、と考えないと変なことになります。己の常識でものを考えてはいけなくて、本文から読み取れることしか使ってはいけない。
>主キー以外の他の候補キーからも部分関数従属してはダメ!と解釈したのですが、
>その日本語解釈が間違っていますか?
そういう意味では、「仮に」商品コードが候補キーの一部になっていれば、第一正規形です。
しかし、問題では根拠がない以上、候補キーの一部ではない、ということです。
2024.06.10 23:06
niveaさん
(No.10)
GinSanaさん ありがとうございます。
No7でDBスペシャリストの設問からの具体例まで挙げていただき感謝します。
当方DBスペシャリストの午後問題にだいぶ慣れてきて、そこから午前1対策をしている中で本問を説こうとした際に余計に勘ぐってしまったようです。
午前対策としてはシンプルに考えるようにします。
お手数お掛けしました。
No7でDBスペシャリストの設問からの具体例まで挙げていただき感謝します。
当方DBスペシャリストの午後問題にだいぶ慣れてきて、そこから午前1対策をしている中で本問を説こうとした際に余計に勘ぐってしまったようです。
午前対策としてはシンプルに考えるようにします。
お手数お掛けしました。
2024.06.12 21:23
広告
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。
広告