平成30年 午後Ⅰ 問2 設問3(1)
ひろしさん
(No.1)
問題の意味が今ひとつ分かりません。
表3は、例えば従業員テーブルの部署コードは、部署テーブルの部署コードを参照(外部キー?)、部署テーブルのレコードをDELETEすると削除されたレコードの部署コードの従業員テーブルのレコードも削除されると言う意味で宜しいでしょうか?
そうすると、設問3の回答の「削除された部署に所属している従業員が従業員テーブルから削除される」の何が不具合なのでしょうか?そのように設計していているのだから何ら問題ないかと思ったのですが。
そもそも従業員が所属する部署を削除する設計自体大丈夫なのでしょうか?情報処理試験試験というより通常のシステムとして。
表3は、例えば従業員テーブルの部署コードは、部署テーブルの部署コードを参照(外部キー?)、部署テーブルのレコードをDELETEすると削除されたレコードの部署コードの従業員テーブルのレコードも削除されると言う意味で宜しいでしょうか?
そうすると、設問3の回答の「削除された部署に所属している従業員が従業員テーブルから削除される」の何が不具合なのでしょうか?そのように設計していているのだから何ら問題ないかと思ったのですが。
そもそも従業員が所属する部署を削除する設計自体大丈夫なのでしょうか?情報処理試験試験というより通常のシステムとして。
2019.04.18 22:18
bさん
(No.2)
表3 参照制約機能の利用案の1行目(以下の内容のところ)から、ご指摘の点がわかります。
テーブル名:従業員
列名:部署コード
参照先: 部署(部署コード
実行契機: DELETE
挙動モード: CASCADE
さらに、〔参照成約機能の利用の検討〕段落に、
「定期的な組織変更及び人事異動に対応する処理」
とあるので、組織変更にともなって既存の部署が不要になるケースが考えられます。
たとえば「管理部」 を「総務部」と「人事部」に再編する場合、
問題文の更新手順に沿って行うと、
(1) 管理部を削除(参照制約のCASCADEによって従業員テーブルから管理部に所属する従業員が削除されてしまう)
(2) コミット
(3) 総務部を追加
人事部を追加
(4) コミット
(5) 従業員テーブルの部署コードを更新(更新先が無い)
(6) コミット
となるので、(5)で更新先が無くなってしまう原因である(1)の連鎖的に従業員テーブルから削除されてしまうのが不具合で、それが発生する契機を回答すればよいのだと思います。
>部署テーブルのレコードをDELETEすると削除されたレコードの部署コードの従業員テーブルのレコードも削除される
テーブル名:従業員
列名:部署コード
参照先: 部署(部署コード
実行契機: DELETE
挙動モード: CASCADE
さらに、〔参照成約機能の利用の検討〕段落に、
「定期的な組織変更及び人事異動に対応する処理」
とあるので、組織変更にともなって既存の部署が不要になるケースが考えられます。
たとえば「管理部」 を「総務部」と「人事部」に再編する場合、
問題文の更新手順に沿って行うと、
(1) 管理部を削除(参照制約のCASCADEによって従業員テーブルから管理部に所属する従業員が削除されてしまう)
(2) コミット
(3) 総務部を追加
人事部を追加
(4) コミット
(5) 従業員テーブルの部署コードを更新(更新先が無い)
(6) コミット
となるので、(5)で更新先が無くなってしまう原因である(1)の連鎖的に従業員テーブルから削除されてしまうのが不具合で、それが発生する契機を回答すればよいのだと思います。
2019.04.18 23:29
ひろしさん
(No.3)
お返事ありがとうございます。
お返事に書かれてることは理解出来るのですが、
そもそも部署テーブルを削除した際に、従業員テーブルのレコードを連動して削除する設定が問題ある気がするのに、そうなるようにしておきながらそうなったら不具合というのが理解できません。
設計通りじゃないのでしょうか?
お返事に書かれてることは理解出来るのですが、
そもそも部署テーブルを削除した際に、従業員テーブルのレコードを連動して削除する設定が問題ある気がするのに、そうなるようにしておきながらそうなったら不具合というのが理解できません。
設計通りじゃないのでしょうか?
2019.04.19 02:43
okomeさん
(No.4)
No3に返信
設計通りとかではなく、今は、
必要な処理を行えるように設計をしている段階
なのです。
16ページ真ん中あたりに
[参照制約機能の利用と検討]
という見出しで書かれているので、まだどういう設計をするのか決めかねている状況だと考えられます。
消える設定を追加すれば書くSQLが少なくなるのではないかという仮説をもとに、設計を見直している段階です。処理結果を変えずに、設計を変しなければなりません。そのため、元々の処理結果から変わってしまうことがバグなのです。
設計の段階のものもバグ(不具合)と呼ぶらしいです。
いつ解いたのか覚えていませんが、プロジェクトでバグを修正した時にDBに登録していく問題がIPAの過去問で出題されています。そこでは、要件定義の段階のミスもバグと呼んでいます。
さすがに要件定義のミスすらバグと呼ぶのは腑に落ちないですが、設計だったらこっちのさじ加減でどうにでもなってしまうので、バグと呼んであげてもいいでしょう。。。
いや、やっぱり私も納得できません。
ゲームの仕様変更をバグと言い張る運営の逃げ道が見えた気がします。
スマホげーは闇...
設計通りとかではなく、今は、
必要な処理を行えるように設計をしている段階
なのです。
16ページ真ん中あたりに
[参照制約機能の利用と検討]
という見出しで書かれているので、まだどういう設計をするのか決めかねている状況だと考えられます。
消える設定を追加すれば書くSQLが少なくなるのではないかという仮説をもとに、設計を見直している段階です。処理結果を変えずに、設計を変しなければなりません。そのため、元々の処理結果から変わってしまうことがバグなのです。
設計の段階のものもバグ(不具合)と呼ぶらしいです。
いつ解いたのか覚えていませんが、プロジェクトでバグを修正した時にDBに登録していく問題がIPAの過去問で出題されています。そこでは、要件定義の段階のミスもバグと呼んでいます。
さすがに要件定義のミスすらバグと呼ぶのは腑に落ちないですが、設計だったらこっちのさじ加減でどうにでもなってしまうので、バグと呼んであげてもいいでしょう。。。
いや、やっぱり私も納得できません。
ゲームの仕様変更をバグと言い張る運営の逃げ道が見えた気がします。
スマホげーは闇...
2019.04.19 09:42
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。