応用情報技術者平成28年春期 午前問27
広告
ドーナツさん
(No.1)
関数従属を次のように表記するとき,属性a~eで構成される関係を第3正規形にしたものはどれか。の回答について質問です。
〔正規化する関係〕で[a]→[c]に矢印が付いていますが、
解説には、「一意に決まる項目を別表に移します。」と記載があり、
[b][d]の組み合わせが分かれば[e]が一意に決まるのは理解できます。
ただ[c]については、少しわかりづらいです。
[c]には[a]と[b]から矢印が向いていますが、なぜ[b]→[c]だけの表だけなのでしょうか。
[a]から[b]に矢印が向いており、[b]から[c]に矢印が向いているのであれば[a]から[c]の矢印は必要ないと思うのですが、、、。
ご返答いただけますとうれしいです。よろしくお願いいたします。
〔正規化する関係〕で[a]→[c]に矢印が付いていますが、
解説には、「一意に決まる項目を別表に移します。」と記載があり、
[b][d]の組み合わせが分かれば[e]が一意に決まるのは理解できます。
ただ[c]については、少しわかりづらいです。
[c]には[a]と[b]から矢印が向いていますが、なぜ[b]→[c]だけの表だけなのでしょうか。
[a]から[b]に矢印が向いており、[b]から[c]に矢印が向いているのであれば[a]から[c]の矢印は必要ないと思うのですが、、、。
ご返答いただけますとうれしいです。よろしくお願いいたします。
2023.12.19 14:33
非情報大学さん
(No.2)
えぇっと、この単元は実は集合を使う単元だけどそれだと難しいから解説がそれをあえて、使わないで強引で言葉で表現している単元であることを留意してね。
基本はy=ax+cでxが分かればyが分かるようにした方が管理がしやすいって事を目標にしてるんだ。
aが定まるとb,c,dが決まるって書いてあるね。
でもcに限って言えば
a→c
b→c
になるとも書かれているんだ。
だから
{a,b} {c,d}にしたいけど、主キーの一部で一意に定まるものを許さないって第二正規化にルールがあったはず。
aとbでc,dが定まるとか言っておきながら、一部のbだけでcが定まるからこれを分離しようねって話になって
{a} {b,d}
{b} {c}
になるんだ。
{b,d} {e}に関しては、bとdが揃って初めて定まるし、片方で実はカンニングみたいなことは出来ないから、これでよいんだよ。
基本はy=ax+cでxが分かればyが分かるようにした方が管理がしやすいって事を目標にしてるんだ。
aが定まるとb,c,dが決まるって書いてあるね。
でもcに限って言えば
a→c
b→c
になるとも書かれているんだ。
だから
{a,b} {c,d}にしたいけど、主キーの一部で一意に定まるものを許さないって第二正規化にルールがあったはず。
aとbでc,dが定まるとか言っておきながら、一部のbだけでcが定まるからこれを分離しようねって話になって
{a} {b,d}
{b} {c}
になるんだ。
{b,d} {e}に関しては、bとdが揃って初めて定まるし、片方で実はカンニングみたいなことは出来ないから、これでよいんだよ。
2023.12.20 11:16
非情報大学さん
(No.3)
{a} {b,c,d}の説明省いたけど
aが決まればb,c,dが決まるとか言っておきながら、cはbが決まれば定まるから主キー以外で決まるのは良くないよねってのが第三正規だったと思うよ。
aが決まればb,c,dが決まるとか言っておきながら、cはbが決まれば定まるから主キー以外で決まるのは良くないよねってのが第三正規だったと思うよ。
2023.12.20 11:27
ドーナツさん
(No.4)
非情報大学さん
丁寧にご回答いただきましてありがとうございます!
第三正規の主キー以外の列に関数従属している列を切り出すことで
{a} {b,d}
{b} {c}
と分離するということですね。
イメージとしては「受注No.」を主キーとし、
受注No.が分かれば顧客コード,顧客名称,受注日付が①
顧客名称が分かれば顧客コードが決まるけど、第三正規のルール上主キー以外で決まるのはよくない(bからcが決まるのはダメ)
ということで、②と③に分けようが
{a} {b,d}
{b} {c} になる。
{ a b c d }
①{受注No,顧客コード,顧客名称,受注日付} これだと{a,b,c,d}
↓
②{受注No,顧客コード,受注日付} {a} {b,d}
③{顧客コード,顧客名称} {b} {c}
といったかんじでしょうか。
間違った認識になってしまっていたらごめんなさい。
丁寧にご回答いただきましてありがとうございます!
第三正規の主キー以外の列に関数従属している列を切り出すことで
{a} {b,d}
{b} {c}
と分離するということですね。
イメージとしては「受注No.」を主キーとし、
受注No.が分かれば顧客コード,顧客名称,受注日付が①
顧客名称が分かれば顧客コードが決まるけど、第三正規のルール上主キー以外で決まるのはよくない(bからcが決まるのはダメ)
ということで、②と③に分けようが
{a} {b,d}
{b} {c} になる。
{ a b c d }
①{受注No,顧客コード,顧客名称,受注日付} これだと{a,b,c,d}
↓
②{受注No,顧客コード,受注日付} {a} {b,d}
③{顧客コード,顧客名称} {b} {c}
といったかんじでしょうか。
間違った認識になってしまっていたらごめんなさい。
2023.12.20 14:05
非情報大学さん
(No.5)
それでよいと思うよ。
薄々、思ったと思うんだけど、結局これって関数従属してるだけじゃ扱いずらいから、新しいルールを追加するよって話なんですよね。
第四正規化とかが実は裏にあって、実用性はそこまでないからあまり扱われてないマイナー扱いらしいけど、関数従属していれば、データとして最低限、体を成しているから、お作法だと思いながら、候補キーとかデータの正規化をすると良いと思うよ。
薄々、思ったと思うんだけど、結局これって関数従属してるだけじゃ扱いずらいから、新しいルールを追加するよって話なんですよね。
第四正規化とかが実は裏にあって、実用性はそこまでないからあまり扱われてないマイナー扱いらしいけど、関数従属していれば、データとして最低限、体を成しているから、お作法だと思いながら、候補キーとかデータの正規化をすると良いと思うよ。
2023.12.20 14:16
広告
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。
広告