https://www.ap-siken.com/kakomon/18_haru/q70.html

管理人様

掲題の解説の図につきまして、
誤りと思われる箇所がありましたので報告致します。
ご確認をお願い致します。

(1)参照関係の矢印の向きが逆
(2)表aの事業本部コードの参照先が異なる

(1)について
参照元と参照先の関係「1:多」を矢印で表現する場合、
矢印の向きは[参照先]→[参照元]が一般的のようです。

表cの主キー{事業本部コード, 部門コード}のうち、事業本部コードは、
表bの主キー「事業本部コード」を外部参照しています。
表bと表cの関係「1:多」を表す矢印の向きは以下が妥当ではないでしょうか。
表bの事業本部コード → 表cの事業本部コード

表aの非キー{事業本部コード, 部門コード}は
表cの主キー{事業本部コード, 部門コード}を外部参照しています。
表cと表aの関係「1:多」を表す矢印の向きは以下が妥当ではないでしょうか。
表cの{事業本部コード, 部門コード} → 表aの{事業本部コード, 部門コード}

(2)について
表aの事業本部コードの参照先が表bの事業本部コード、
表aの部門コードの参照先が表cの部門コードになっていますが、
表cに存在しない{事業本部コード, 部門コード}の組合せのデータは
表aに追加できませんので、
表aの{事業本部コード, 部門コード}の参照先は、
表cの主キー{事業本部コード, 部門コード}が妥当ではないでしょうか。

以上、長文失礼致しました。

管理人様
先程の投稿内容に不備がありましたので訂正致します。
申し訳ありません。

【誤記】
(1)について
参照元と参照先の関係「1:多」を矢印で表現する場合、
矢印の向きは[参照先]→[参照元]が一般的のようです。

【訂正】
(1)について
参照先と参照元の関係「1:多」を矢印で表現する場合、
矢印の向きは[参照先]→[参照元]が一般的のようです。

(1)について
おわ！さんの投稿内容通り、E-R図でエンティティ間の多重度を表すときには、"1対多"を"→"と記載します。主キー属性と外部キー属性には1対多の関係があり、主キーは参照される側、外部キーは参照する側です。
しかし解説図の矢印は属性間の参照関係を表したものなので、エンティティ間の多重度を表すE-R図の表記をそのまま当てはめて良いのか疑問です。矢印を逆にした場合、混乱してしまう利用者もいるのではないかという懸念があります。

そこで、解説の図に□→□（参照する）などの凡例を付けて改善する方法を考えたのですがいかがでしょうか？

(2)について
>表cの{事業本部コード, 部門コード} → 表aの{事業本部コード, 部門コード}
問題文では"ほかの表で【キー】になっている列の値が…"と記載されているので、事業本部コードと部門コードを個別に矢印で結ぶよりも、ご指摘の通りキー同士で結ぶのが適切ですね。

意見の合意がとれましたら両方の改善を盛り込んだ画像に更新させていただこうと思います。
よろしくお願い致します。

横から失礼します。

表aの{事業本部コード, 部門コード}が外部キーとなって表cの{事業本部コード, 部門コード}を参照するだけでなく、表aの事業本部コードが外部キーとなって表bの事業本部コードを参照するのでしょうか？

その場合、表aのCREATE TABLE文のFOREIGN KEYとREFERENCESで、その両方を記述するのでしょうか？

あまり詳しくないので、後学のために教えてください。

管理人様、ご回答ありがとうございます。
後程、確認して、ご返信させて頂きます。申し訳ありませんがお時間ください。
順序が逆になりますが、助け人さんのご質問に先に回答致します。

私の認識では、この問題では、外部キーは二つだけです。

(1)表aの{事業本部コード, 部門コード}が外部キーとなって表cの主キーを参照する。
 ※表cの主キーは{事業本部コード, 部門コード}の複合キー

(2)表cの事業本部コードが外部キーとなって表bの主キーを参照する。
 ※表bの主キーは事業本部コード

文法は自信ありませんが、表aのCREATE TABLE文の
FOREIGN KEYには列名リストを(事業本部コード, 部門コード)、
REFERENCESには参照先を表c(事業本部コード, 部門コード)または表c
だけを記述する認識です。

表aに追加できるデータの{事業本部コード, 部門コード}の組合せは
表cに存在する{事業本部コード, 部門コード}の組合せのみとなり、
表aの事業本部コードから表bの事業本部コードは参照しない認識です。

この投稿は投稿者により削除されました。(2020.08.16 22:57)

おわ！さん

ありがとうございます。やはり、表aの事業本部コードは、表bの事業本部コードを参照する外部キーにはならないのですね。そうすると、表aの事業本部コードから表bの事業本部コードへの矢印は、省くことになりますね。

この投稿は投稿者により削除されました。(2020.08.17 00:14)

助け人さん

整理頂き、ありがとうございます。仰る通りです。
一番肝心な結論を、頼ってしまい申し訳ありません。
次回からは問題点、結論を簡潔、明瞭にお伝えするよう気を付けます。

管理人様

ご回答ありがとうございました。返信が遅くなりまして申し訳ありません。

解説図の矢印は属性間の参照関係を表したものとのこと、承知致しました。
誤解からお騒がせしてしまい、申し訳ありませんでした。
矢印を逆にする件は撤回させて頂きたいと思います。

改善のご検討ありがとうございます。全て合意致します。

なお、No.3の管理人様のご回答と、No.7の助け人さんのご指摘を踏まえて
解説を読み返しましたところ、
表aの事業本部コードから表bの事業本部コードへの矢印を省いて頂ければ、
その他は現状のままでも、利用者の理解に支障ないと存じます。
改めまして、下記いずれかで要望させて頂きます。

ミニマム改善
  表aの事業本部コードから表bの事業本部コードへの矢印を除去

マックス改善
  ミニマム改善＋ご検討いただいた改善

お手数をおかけして申し訳ありませんが、宜しくお願い致します。

本問の表をRDBで実装するときのFOREIGN KEY指定は、

・表aの{事業本部コード, 部門コード} → 表cの{事業本部コード, 部門コード}
・表cの{事業本部コード} → 表bの{事業本部コード}

の2つであることには納得できるのですが、表aと表bの{事業本部コード}に参照関係がないと言い切ってしまえるかどうかについてイマイチ腑に落ちていません。

・表aの{事業本部コード} → 表bの{事業本部コード}

のFOREIGN KEY指定は、

・表aの{事業本部コード, 部門コード} → 表cの{事業本部コード, 部門コード}

により事実上達成でき、冗長になるから記述しなくても良いのであって、実際には両者の間には参照関係があるのではないかと考えています。表aと表bを結合する際には、外部キー＆主キーとして{事業本部コード}を使うということも引っ掛かるところです。

また仮に表cに{事業本部コード}が存在しなければ、表aの{事業本部コード}には表bへの外部キー制約が指定されるわけですから、参照関係がないとも言えないと思うのです。

おわ！さん

CREATE TABLE文で、
・表aの{事業本部コード, 部門コード} → 表cの{事業本部コード, 部門コード}
と
・表aの{事業本部コード} → 表bの{事業本部コード}
を同時に記述できるかは、とうとう分かりませんでした。
前者は、表制約でFOREIGN KEYを記述し、後者は列制約でFOREIGN KEYを書かずにREFERENCESだけを記述するような内容が出ていましたが、よく分かりませんでした。
(SQLを実行できる環境があれば試せたかもしれません)

ここは、管理人様にお任せするのはいかがでしょうか？

管理人様
助け人さん

返信が遅くなりまして申し訳ありません。

本件の一連の投稿は、私の浅学から来た誤解によるのもです。
論理の通らない感覚的な思い込みを、正解のように言い張り、
恥ずかしいです。

お二方から頂きましたご指摘、ご教示につきましても
私には理解が難しく、手に余ります。

私からの修正のご要望はすべて、取り下げさせて頂きます。

本問のご解説の内容につきましては、
すべて管理人様にお任せいたします。

また、私事ながら、本件に関わらず、最近心身のバランスを崩し、
粗暴な気持ち、姿勢で投稿をしつつありますので、
やはりこの掲示板の利用を控えます。

今までありがとうございました。

おわ！さん

おわ！さんとの掛け合いは、結構、楽しくて刺激的だったのですが、事情がおありのようですので、無理に引き留めることができませんね。

本日、応用情報で1件、安全確保支援士で1件回答しましたが、返信はなく放置されたままです。ここのところ、本当に、気軽く質問しっぱなしで、最低限の礼儀が保たれていないことが多すぎます。

もし、今後、私が回答した内容が面白かったら、遠慮なく絡んできてくださいね。

おわ！さん、助け人さんの意見を踏まえ、{事業本部コード、部門コード}をキーとしてまとめ、凡例を付けることにいたしました。

管理人様

スレ主はおわ！さんですが、もう投稿されないと思います。乗りかかった船ですから、おわ！さんに成り代わり、ありがとうございます。