H31 午後2 問1 設問1(2)
匿名希望さん
(No.1)
外部キーの列に索引を定義する理由は何でしょうか?
問題文を読むと効率的な結合のためのようですが、よくわかりません。
例えば、処理5では、ログ基本テーブルと窓口端末テーブルを店番と機番をキーとして結合し①、
結合したテーブルと端末種別テーブルを端末種別コードをキーとして結合します②。
ここの②の結合で疑問なのですが、端末種別テーブルの端末種別コードに索引があれば良く、
窓口端末の端末種別コードには索引は不要だと思うのですが回答では必要となっています。
失念しているところがあればご指摘いただけないでしょうか。
問題文を読むと効率的な結合のためのようですが、よくわかりません。
例えば、処理5では、ログ基本テーブルと窓口端末テーブルを店番と機番をキーとして結合し①、
結合したテーブルと端末種別テーブルを端末種別コードをキーとして結合します②。
ここの②の結合で疑問なのですが、端末種別テーブルの端末種別コードに索引があれば良く、
窓口端末の端末種別コードには索引は不要だと思うのですが回答では必要となっています。
失念しているところがあればご指摘いただけないでしょうか。
2021.09.26 01:55
Yライセンスさん
(No.2)
まず、設問に解答する上で、私ならこうするというスタンスを述べてみますね。
設問に関連する箇所には、「図1中のマスタ情報を格納するテーブルについて、処理1~6で結合に用いられる主キー以外の列に索引を定義することにし、その対象テーブル名・列名を表5にまとめた。」とあり、設問1(2)にも「表5中の空欄を埋め、表を完成させよ。」とあるだけで、”不要な索引であれば定義する必要はない”等の注意書きも特にないので、結合処理に用いられる外部キーを見つけてそのまま表5に書けば良い、というのが解答に当たってのスタンスになります。仮に、処理1~6で結合に用いる外部キーを3つ以上発見したら、表5の空行が2行しかないので、どれかが不要なのか?という考察は必要かもしれませんが、幸いにも結合に用いる外部キーは2つのみです。
解答のスタンスについては以上で、以下からは問題背景に対する考察になります。
外部キーの列に索引を定義する理由としては、仰る通り、結合処理を高速化するためだと思われます。
そして、例えば処理5については、端末種別テーブルの主キーに索引があるので、既に結合処理を高速化できているから、他の索引は不要じゃないか?(なぜ外部キーに別の索引を定義するのか?)という疑問も確かにあるかと思います。
しかし、処理3~6については具体的なSQLが出てきていないので、どのテーブルが内部表になり、どのテーブルが外部表になるかわかりません(つまり、処理5が、質問者さんの仰るような①と②の処理として実装されるかわからないということです)。端末種別テーブルが内部表となる場合は、端末種別テーブルの主キーに索引があるので、結合処理を高速化できますが、そうなるとは限りません。そして、端末種別テーブルが内部表にならない場合には、設問のように、窓口端末の端末種別コードに索引を定義しておくと高速化できる場合があるということになります。
内部表や外部表についてご存知でなければ適宜他のページを参照してみてください。
設問に関連する箇所には、「図1中のマスタ情報を格納するテーブルについて、処理1~6で結合に用いられる主キー以外の列に索引を定義することにし、その対象テーブル名・列名を表5にまとめた。」とあり、設問1(2)にも「表5中の空欄を埋め、表を完成させよ。」とあるだけで、”不要な索引であれば定義する必要はない”等の注意書きも特にないので、結合処理に用いられる外部キーを見つけてそのまま表5に書けば良い、というのが解答に当たってのスタンスになります。仮に、処理1~6で結合に用いる外部キーを3つ以上発見したら、表5の空行が2行しかないので、どれかが不要なのか?という考察は必要かもしれませんが、幸いにも結合に用いる外部キーは2つのみです。
解答のスタンスについては以上で、以下からは問題背景に対する考察になります。
外部キーの列に索引を定義する理由としては、仰る通り、結合処理を高速化するためだと思われます。
そして、例えば処理5については、端末種別テーブルの主キーに索引があるので、既に結合処理を高速化できているから、他の索引は不要じゃないか?(なぜ外部キーに別の索引を定義するのか?)という疑問も確かにあるかと思います。
しかし、処理3~6については具体的なSQLが出てきていないので、どのテーブルが内部表になり、どのテーブルが外部表になるかわかりません(つまり、処理5が、質問者さんの仰るような①と②の処理として実装されるかわからないということです)。端末種別テーブルが内部表となる場合は、端末種別テーブルの主キーに索引があるので、結合処理を高速化できますが、そうなるとは限りません。そして、端末種別テーブルが内部表にならない場合には、設問のように、窓口端末の端末種別コードに索引を定義しておくと高速化できる場合があるということになります。
内部表や外部表についてご存知でなければ適宜他のページを参照してみてください。
2021.09.26 03:43
匿名希望さん
(No.3)
ご丁寧に説明いただき、まことにありがとうございます。
これは確かに私の仮定でした。
この高速化の具体的な方法を、宜しければご教示いただけますでしょうか。
考えてみたのですが思いつきませんでした。
>①と②の処理として実装されるかわからないということです
これは確かに私の仮定でした。
>窓口端末の端末種別コードに索引を定義しておくと高速化できる場合があるということになります。
この高速化の具体的な方法を、宜しければご教示いただけますでしょうか。
考えてみたのですが思いつきませんでした。
2021.09.26 13:05
DCLさん
(No.4)
外部キーに索引を定義する理由は参照制約における参照整合性を保つためです。
例えば端末種別テーブのデータを削除する場合、窓口端末に削除されるコードが存在しないことを確認します(存在してると削除できない為)
その確認の際に、窓口端末の端末種別に索引がないと、全行参照してしまうためです。
※H30年度の午後1、問2にも同様の解答がありますので、確認してみて下さい。
RDBMSによっては外部キーを設定すると
自動的に索引が作成されるものもあります。
例えば端末種別テーブのデータを削除する場合、窓口端末に削除されるコードが存在しないことを確認します(存在してると削除できない為)
その確認の際に、窓口端末の端末種別に索引がないと、全行参照してしまうためです。
※H30年度の午後1、問2にも同様の解答がありますので、確認してみて下さい。
RDBMSによっては外部キーを設定すると
自動的に索引が作成されるものもあります。
2021.09.26 14:53
Yライセンスさん
(No.5)
>この高速化の具体的な方法を、宜しければご教示いただけますでしょうか。
考えてみたのですが思いつきませんでした。
端末種別テーブルが外部表になり、窓口端末が内部表になる場合(端末種別テーブルを左に指定し、窓口端末を右側に指定したSQLを書いた場合)です。
なお、追記になりますが、問題文に”結合処理を高速化するため”とは書いていないため、上記の考察自体が見当違いかもしれません。DCLさんの仰るような参照制約のためかもしれません。
2021.09.26 19:31
匿名希望さん
(No.6)
DCLさん、Yライセンスさん
ご丁寧に説明いただき、まことにありがとうございます。
DCLさんへ
参照整合性を保つためと考えると納得がいきました。
Yライセンスへ
ご説明いただいた方法ですと確かに外部キーの索引が使用されて効率的に結合できますが、
結合したテーブルには索引はないと思いますので、
ログ基本テーブルと結合したテーブルを結合する際は結合したテーブルを全行参照してしまうため
あまり効率的な結合とは言えないような気がします。
「参照整合性を保つため」で納得しようと思います。
ご丁寧に説明いただき、まことにありがとうございます。
DCLさんへ
参照整合性を保つためと考えると納得がいきました。
Yライセンスへ
>端末種別テーブルが外部表になり、窓口端末が内部表になる場合(端末種別テーブルを左に指定し、窓口端末を右側に指定したSQLを書いた場合)です。
ご説明いただいた方法ですと確かに外部キーの索引が使用されて効率的に結合できますが、
結合したテーブルには索引はないと思いますので、
ログ基本テーブルと結合したテーブルを結合する際は結合したテーブルを全行参照してしまうため
あまり効率的な結合とは言えないような気がします。
「参照整合性を保つため」で納得しようと思います。
2021.09.26 21:23
匿名希望さん
(No.7)
>Yライセンスへ
「>Yライセンスさんへ」です。大変失礼いたしました。
2021.09.26 21:34
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。