https://www.ap-siken.com/s/kakomon/25_haru/pm06.html

  本文中に「活用事例が検索されやすくするために，活用事例ごとにキーワードを登録するだけでなく，活用シーンにもキーワードを関連付けることによって，より的確に活用シーンを検索できるようにする。」とありますが、現状のままでも活用シーンテーブル、活用事例テーブル、活用事例キーワードテーブル、キーワードテーブルを全て結合して、キーワードで候補を絞り、活用シーンのみを抽出すれば、キーワードから活用シーンを検索できると思うのですが、活用シーンテーブルとキーワードテーブルの間に、連関エンティティを作成する意味って何なのでしょうか？

  この辺からは余り自信がないのですが、外部キーにnulを設定できるデータベースもあるらしいので、それがありなら活用事例テーブルの活用シーンIDにnullが設定されると上記の方法ではキーワードから活用シーンを検索できなくなりますが、それなら活用シーンテーブルと活用事例キーワードテーブルの間に連関エンティティを作成しても本文中で言う「より的確に活用シーンを検索できるようにする。」が達成できてしまい、解答を「活用シーンテーブルとキーワードテーブルの間に、連関エンティティを作成する」に限定できないと思うのですが、その辺はどう解釈するのが正しいのでしょうか。

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

>活用シーンテーブルとキーワードテーブルの間に、連関エンティティを作成する意味って何なのでしょうか？

外部キーを設定する場合1対多にならなければならない（多対対はダメ）わけで、活用シーンに対して活用シーンキーワードみたいなのが1対で結び付けばいいですが、そうもいかない（活用シーンごとに1つしかキーワードが使えない？そんなわけがない）というわけで、間に挟むのが要ります。
それが連関エンティティです。

>この辺からは余り自信がないのですが、外部キーにnullを設定できるデータベースもあるらしいので、
一応MySQLもPostgresも出来はしますけど（普段意識しないところ）、連関エンティティとは関係ないです。
Oracleはムリだったと思う。

>活用シーンテーブルと活用事例キーワードテーブルの間に連関エンティティを作成しても
活用事例エンティティでどの活用シーンを使うかが固定される作りになっているわけですけど、そんな間に連関エンティティかませたら、活用事例と矛盾したデータの構成が作れちゃうわけですよね。連関エンティティの主キーは結ぶテーブルの主キーの合わせ技なので、活用事例ID、キーワードID、活用シーンIDとなる。

パフォーマンスとしてはよい場合もあるらしいけど、それをしたら運用がダルいのでごめんですね。
zenn.dev/yuitosato/articles/d7259cfe521b8a
PostgreSQLのNull許容外部キーの使い所について

なぜ多対多が実装的にダメなのか

多対多のリレーションシップ
fmhelp.filemaker.com/help/18/fmp/ja/index.html#page/FMP_Help/many-to-many-relationships.html


というわけです。

詳しい解説ありがとうございます。キーワードから活用シーンや活用事例の検索が現状だとできないので、どんな手段を使ってもいいから連関エンティティを作って検索できるようにしろと言う問題だと解釈してましたが、どうやらそうではなく、新たな検索ルートを作るためキーワードテーブル、活用シーンテーブル、活用事例テーブルを結合して検索できるようにしろと言うニュアンスの問題だったのですね。

表2があるのでキーワードテーブルと活用事例キワードテーブルの間に連関エンティティを作るのは許されないってことですかね？(表2に活用事例IDが入ってしまうため)

あと自分で言ってて何に使うのかよく分かってなかった外部キーNULLの使い道の解説もリンク貼っていただきありがとうございました。

>表2があるのでキーワードテーブルと活用事例キワードテーブルの間に連関エンティティを作るのは許されないってことですかね？(表2に活用事例IDが入ってしまうため)

表2を参考に考えろってなっているわけですから、そうなりますね。活用事例キーワードエンティティ自体が連関エンティティなわけで、そんな仮想エンティティに仮想エンティティを重ねてどうすんの？って実際の現場では言われるかもしれません。