平成31年 春 午前II

Tweet

問3

答えはエ。

アについて

新しい組織レベルを設ける場合、どのモデルも変更する必要がないとのことだが、モデルAに新しく係りの下に「チーム」を追加しようとした場合、テーブルを追加する必要がある。

モデルBは、以下のようにレコードを一つ増やすだけで対応できるため、モデルの変更は必要ない。

モデルCも、組織テーブルにチームを追加し、組織構造に係りの下にチームがつながるようにすればできるため、モデルの変更は必要ない。

よって、アは間違い。

イについて

どのモデルも、一つの子組織が複数の親組織から管轄される状況を記述できないとのことだが、
ちょっとわかりにくい。具体的に言うと、係が部からも課からも管轄されるという状況を記述できないよ、と言っている。
モデルAはできない。係のテーブルは課のコードしかわからない。課、部両方の管轄になるには、係テーブルは部のコードも外部キーに持つ必要がある。
具体的にはこんな感じ。

モデルBもできない。

グレーの係は今、課を親に持っているが、部も親にするにはこんな感じになる。

ここで組織コードは主キーではなく、重複してよいのならばOKだが、まぁ、普通組織コードは主キーだよね。だからＮＧ。

モデルＣはできる。

結局、モデルC以外はできないので、イは間違い。

ウについて

モデルBを関係データベース上に実装する場合、親は子の組織コードを外部キーとするとのことなので、モデルBだけ考える。

親が子の組織コードを持つということは、部が課のコードを覚えて、課が係のコードを覚えるということ。

できないことはないが、普通は親が子は持たない。子が親を持つのが多い。
何故なら、親を削除したときに、レコードの改定がメンドクサイから。一つの部に課が3個くらいいたとする。
親が子を持つと考えた場合、こんなテーブルになる。

すでに、主キーが被って実現不可能なのだが、これでもOK、とした場合、部を消そうぜ、または改名する（部から部1とか）場合に3か所書き換えることになる。
あとは、根本的にUMLは以下であり、普通に読めば、子が親を持たない(0)か、親を一つだけ持つ(1)と書いてあるため、絶対に違う。

エについて

モデルCでは、組織の親子関係が循環しないように制約を課す必要がある。
これはその通り。こんな風に書いたら循環してしまう。

グレーの部分が係は親に課を持つ、課は親に係を持つという循環が生じてしまう。

イも循環しそうなものだが、イはUMLに{階層}と書かれており、これは循環しないよという制約があることを表している。つまり、循環するなよ、と制約が課されている。課されているだけで、無視すればできるが、ここでは問われていないのでイは関係ない。

よって、答えはエ。