データベーススペシャリスト 試験情報＆徹底解説

お世話になっております。
R2DMPM2問2の輸送指示、調達手配、専用部品発注の関係について質問します。
輸送指示の関係スキーマの空欄サは支給指示調達番号、専用部品発注調達番号などとして
調達手配のサブタイプである支給指示、専用部品発注からの外部キーとして解答せずに
スーパタイプの調達手順を参照しているという形でサ調達手順にまとまったものが解答として記載されています。
これは同問題の図6が関係スキーマとなっているために概念データモデルでは2つのエンティティからリレーションを受けているように見えても関係スキーマ上はスーパタイプにまとまるように解答しなければならないということだと理解しました。
これは支給指示と専用部品発注が同時に輸送指示に関与しないという前提があるから出来るわけで、
例えばH26PM1問1(スーパタイプサブタイプの問題ではありませんが)のバグと工程の関係ように、バグを発見した工程の工程IDや発見した工程IDといった風にバグエンティティが複数の異なる工程エンティティを参照するような際にはやはり外部キーを複数設ける必要があると思います。
(本問が例えば支給指示で出された物品と専用部品発注指示で出された物品をまとめたものを輸送指示を出して運び出すといったようなケースであった場合)
また、図6がもしR4PM2問2の問題のように関係スキーマでなくテーブル構造を答えさせる設問だった場合は実際のテーブル構造を答えなければならないわけですので、本問の関係スキーマと同様にサブタイプをそのままテーブルとして設計した際には輸送指示テーブルの調達番号は２つの異なるテーブルを参照することになってしまい、実装は出来なくなると思います。
よってそのときは空欄サは支給指示調達番号、専用部品発注調達番号のような解答になるのでしょうか?
そうだとすると、PM2の問題を解答するにあたって「関係スキーマ」なのか「テーブル構造」なのかはこういう点が大きな違いになるのかなと思いました。
大変お手数ですが、以上のような理解で良いのか御意見いただきたくお願い申し上げます。

>サブタイプをそのままテーブルとして設計した際には… 実装は出来なくなると思います。
  同意します。その場合、不都合の理由が出題されると思います。H26午後Ⅰ設問1(3)空欄イを参考に。

> よってそのときは空欄サは支給指示調達番号、専用部品発注調達番号のような解答になるのでしょうか?
  別の不都合が生じます。
例えば、XXX調達番号とYYY調達番号があって、輸送元と輸送先が同じ。そこで、まとめて輸送指示を出すと、そのような解答になると思います。

logres_fan様、お返事いただきましてありがとうございます。

>>">サブタイプをそのままテーブルとして設計した際には… 実装は出来なくなると思います。"
>  同意します。その場合、不都合の理由が出題されると思います。H26午後Ⅰ設問1(3)空欄イを参考に。
H26午後Ⅰ"問3"設問1(3)空欄イの在庫テーブルの外部キーに案2で起こる不都合の話ですね。
確かにこのパターンで来ることはありえますね。

>>"> よってそのときは空欄サは支給指示調達番号、専用部品発注調達番号のような解答になるのでしょうか?"
?  別の不都合が生じます。
>輸送番号,支給指示調達番号,専用部品発注調達番号,…,ルート番号,積地巡回順,卸地巡回順
>001,AAA,BBB,…,ルート番号001,積地巡回順？,卸地巡回順？
>例えば、XXX調達番号とYYY調達番号があって、輸送元と輸送先が同じ。そこで、まとめて輸送指示を出すと、そのような解答になると思います。 

輸送番号(001),支給指示調達番号(AAA),専用部品発注調達番号(NULL),…,ルート番号(001),積地巡回順(1),卸地巡回順(1)
輸送番号(002),支給指示調達番号(NULL),専用部品発注調達番号(BBB),…,ルート番号(001),積地巡回順(1),卸地巡回順(1)
という風に支給指示と専用部品発注で分けた場合になるところを
スーパタイプにまとめたときに
輸送番号(001),調達番号(AAA),…,ルート番号(001),積地巡回順(1),卸地巡回順(1)
輸送番号(002),調達番号(BBB),…,ルート番号(001),積地巡回順(1),卸地巡回順(1)
のようになる。
ここで何が問題になるのかというと、調達番号を使うようなプログラムを組む場合(輸送指示の調達番号でソートするようなニーズが出たとき)、
スーパタイプにまとめていないとそういった操作が出来ないという不都合が生じる
ということで理解しました。

>? 別の不都合が生じます。
  すみません、説明に失敗しました。打ち間違えもあったので再投稿します。
  No1を読んで次のように考えましたが、ボタンの掛け違えがあるかもしれません。混乱させてしまうといけないので、その際は聞き流して下さい。

  関係“調達手配”のテーブルの設計に当たり、次の案を考えました。サブタイプ別に“支給指示”テーブル及び“専用部品発注”テーブルとする。”輸送指示“テーブルも含めて、テーブル構造を下記に示す。※巡回ルートをA社倉庫→BP社→A社倉庫と仮定しています。
もし支給部品と外注専用部品を梱包して輸送指示を発行する場合
支給部品の積地巡回順は1(A社倉庫)、一方、外注専用部品の積地巡回順は2(BP社)。互いに衝突して決められない。卸地巡回順も同様に、不都合が生じる。

logres_fan様、たびたび御解回答頂き恐縮でございます。
ああ、なるほど
支給部品と専用部品を梱包して輸送指示を発行する場合に
支給指示調達番号と専用部品調達番号以外の列が同じでないとコンフリクトが起こるというわけですね。
そしてA社からBP社への支給はA社倉庫からBP社へ
専用部品はBP社からA社倉庫へ輸送が行われるわけなので輸送指示は
そもそも一つのテーブルに実装が出来ないと理解しました。
解答にあるように外部キーがスーパタイプを示す調達番号一つであった場合は
こういった矛盾が生じないために実装が可能であるということでした。
納得致しました。

  ER図が完成したら、それはさておきと横に置いて臨まなければいけない設問だったのかもしれません。まずは、関係スキーマだけで解答を導き出す練習が必要になるのかしら。倉庫入庫実績が類似例といえば、まあそうなんですけど、なかなか説明が難しいです。
  H26PM1問1のように、属性項目“ステータス”があれば、外部キーを複数設けるべきかで悩む事になるでしょう。