Database Systems Engineer Examination

丁寧にありがとうございます。

ただまだ完全に分かっていないのでもう少し
付き合ってもらえるとありがたいです。

>｛乗員，日付｝→｛便名，日付｝→機種 は，見つけてはいけない関数従属性です。

｛乗員，日付｝→｛便名，日付｝は図2から見つけているのでしょうか？
本文中からわかる関数従属性は｛乗員，日付｝→機種と{便名,日付}→機種の2つですよね。
そして"フライト"の主キーは，｛便名，日付，乗員｝であるため、｛便名，日付，乗員｝→機種という関係も保存しないといけないということですか？

{乗員、日付、機種}と{便名，日付，乗員}という分割もできるということでしょうか？

>>2 ：おみおみ さん
こんばんわ。

＞｛乗員，日付｝→｛便名，日付｝は図2から見つけているのでしょうか？

インスタンスから
　｛乗員，日付｝→便名 が，
問題文から
　｛便名，日付｝→機種 が成立しています。

　｛乗員，日付｝→便名 であれば，増加律により
　｛乗員，日付，日付｝→｛便名，日付｝＝｛乗員，日付｝→｛便名，日付｝
です。

で，推移律により
｛乗員，日付｝→｛便名，日付｝→機種
ですね。
※｛乗員，日付｝→機種　は，推移律がなくとも成立しています

【推測論に関する参考情報】
　nwdb: 関数従属性に関する推測論
　宇陀助教授: データベース: 第6回資料

＞そして"フライト"の主キーは，｛便名，日付，乗員｝であるため、｛便名，日付，乗員｝→機種という関係も保存しないといけないということですか？

と，いうことです。
※｛便名，日付，乗員｝→機種のを導出した元となる
｛便名，日付｝→機種 の関係も保存しないといけません。
　
＞{乗員，日付，機種}と{便名，日付，乗員}という分割もできるということでしょうか？

この場合だと，｛便名，日付｝→機種が保存されませんので分割できません。

　上の記事は説明が不足していました。。。補足しておきます。

返信ありがとうございます。

｛乗員，日付｝→便名は問題文に明記されておらず、図2からの推測であり、使ってはいけないと私は考えますが、「見つけてはいけない」と書いてるので、同意見ということでよろしいでしょうか？

>>{乗員，日付，機種}と{便名，日付，乗員}という分割もできるということでしょうか？

>この場合だと，｛便名，日付｝→機種が保存されませんので分割できません。

関数従属性を見ると乗員と便名は対称性があり、入れ替え可能なように思えるのですが。
解答例で｛乗員，日付｝→機種が成り立っていて、
私の例で｛便名，日付｝→機種が成り立たないというのが理解できません。

どうでしょうか？

>>4 ：おみおみ さん

＞｛乗員，日付｝→便名は問題文に明記されておらず、図2からの推測であり、使ってはいけないと私は考えますが、「見つけてはいけない」と書いてるので、同意見ということでよろしいでしょうか？

同意見です。

ご指摘のとおり，

便（便名，機種，日付）　乗務（便名，日付，乗員）　で
｛乗員，日付｝→機種　が成り立てば

｛乗員，日付，機種｝　｛便名，日付，乗員｝　で
｛便名，日付｝→機種　は成り立ちますね。失礼しました　m(_ _)m

関数従属性が保存されますので，おみおみさんの例も「正解」ということになりますね。
午後I 問題なのに奥が深いなぁ。。。

　余談ですが，ちょっと困りませんか？関係名の付け方に。。。
　何か名前をつけて，関係名（　）　と，しようとしたんですが，適当な名前が思いつかず，とりあえず　｛　｝　のままにしています。

どうもすっきりはしませんが、そういうものかと思って先へ進もうかと思います。付き合ってくれてありがとうございました。

私も関数名をつけるのは苦手で、列名を合体させて作る場合が多いですね。この場合はやはり便や乗務が適切ではないでしょうか？区別したければ便1,便2とかでどうですか？

>>6 ：おみおみさん

＞列名を合体させて作る
　定番っすよね(^^

＞やはり便や乗務が適切
　前設問が不適切な分解の指摘のなので，前設問で分解し損ねた便と乗務に分解する（命名する）のが適切だと思います。

まだちょっと私が気になっている点
　便（乗員，日付，機種）
　乗務（便名，日付，乗員）
と，した時に

関数従属はないものの互いに関連のある
便名と機種を分けてしまうのが良いのかどうかという点です。

便名と機種は航空機に関する属性ですし，一般的に便名が決まればほぼ機種が決まるんですよね。。。

こんばんは。
その後参考書を見て気づきましたが、
ITECの参考書では設問2(2)の解答を「特定の乗員と日付が決まると便名は一意に決まるという情報」としてるものが多いです。
これはつまり{乗員、日付、便名}で一意ということで、｛乗員，日付｝→機種については言及していません。

そしてITEC合格への総まとめ2003では、｛乗員，日付｝→機種が失われるとはっきり書いています。乗員，日付｝→機種を保存するためには(乗員、日付、機種)、(便名、日付、機種)、(便名、日付、乗員)と三つのスキーマが必要とあります。

g@kkoさんの作った図でも、やはり｛乗員，日付｝→機種は成り立っていないのじゃないでしょうか？（ここはうまく説明できませんが)

>>8 ：おみおみ さん
＞｛乗員，日付｝→機種については言及していません。
これは，
　単に候補キー→非キー属性の関数従属指摘するのが手っ取り早いからではないでしょうか。
　インスタンスを見ても分かるとおり，｛乗員，日付｝→機種の関係が失われるのは明白です。

＞そしてITEC合格への総まとめ2003では
　ITEC予想問題集2005には書いてないです。。。

＞g@kkoさんの作った図
　アイテックの解答例にたどり着いた時点で思考が停止していたんでしょうね（苦笑
　｛乗員，日付｝→便名がなければ，｛乗員，日付｝→｛便名，日付｝→機種とたどり着きませんね。
　アイテック解答例が「第２正規化すればよい」としているのが，ちょっと引っかかりますね。なんで第３正規化までしないのか。と。

すみません。誤解を招く説明をしてしまいました。

>ITECの参考書では設問2(2)の解答を「特定の乗員と日付が決まると便名は一意に決まるという情報」としてるものが多いです。
これはつまり{乗員、日付、便名}で一意ということで、｛乗員，日付｝→機種については言及していません。

図9&図１０では{乗員、日付、便名}および｛乗員，日付｝→機種の関係が失われています。

>そしてITEC合格への総まとめ2003では、｛乗員，日付｝→機種が失われるとはっきり書いています。

これは（便名，機種，日付）と（便名，日付，乗員）に分割した場合に、｛乗員，日付｝→機種が失われると書いてあるということです。

設問2(2)と(3)は関連していますので、(2)の答としては{乗員、日付、便名}を答としないといけないでしょう。

>アイテック解答例が「第２正規化すればよい」としているのが，ちょっと引っかかりますね。なんで第３正規化までしないのか。と。

これはこの問題の場合、第2正規化した段階で第3正規形も満たしているからじゃないでしょうか。

>>10 ：おみおみ さん
　こちらこそ，すいません。

　ちょっと今日は疲労が。。。いい判断が出来ていないです。
　レスは明晩まで保留させてください。。。

　設問２（２）において，失われる関係を「｛便名，日付，乗員｝→機種」とせずに，この部分関数従属である，「｛便名，日付｝→機種」を指摘，もしくは両方を指摘すると設問２（３）で行き詰るということですか。。。
　現行のアイテックの解答例が「｛便名，日付，乗員｝→機種」と解答し，設問２（３）でこの関係（だけ）保存している点を考えると。。。
問題が悪い??ということなんでしょうか。。。
もやっと感が残りますねぇ。。。

＞第２正規化の表現
　元の関係｛便名，日付，乗員｝→機種から， 部分関数従属である｛便名，日付｝→機種 を排除したということで，第２正規化という表現になっていると推察します。
　分割後の関係には推移関数従属もないので，第３正規形ですが。。。すべての関数従属性は保存されていないということになります。

　アイテック・アイタック以外の解答例を見てみたいですねぇ。。。