R4 午後2 問2のフェリーの問題についてです。

船型別宿泊区画テーブルの業務上の利用のされ方について考えてみたのですが以下の理解は合っていますでしょうか。

🔹前提
・宿泊区画は船型ごとに管理される。船型が同じならどんなフェリーも同じ宿泊区画を持つ。よって、必ずフェリーごとの宿泊区画よりも、船型ごとの宿泊区画の方が先に決まっているべきである。

🔹役割: フェリーごとの宿泊区画番号を決めるために間接的に参照される役割
🔹具体例
・やりたいこと: フェリーAの宿泊区画番号を求める

・処理の流れ
1. フェリーAのフェリー番号を利用して、フェリーテーブルからフェリーAに対応する船型番号を特定する。
2. 船型宿泊区画テーブルにて、1.で求めた船型番号に対応するレコードから宿泊区画番号だけ抽出する。
3. 船型が同じならどんなフェリーでも宿泊区画が同じなので、2.で求めた宿泊区画番号とフェリーAのフェリー番号の組み合わせを、宿泊区画テーブルに追加する。

同じ属性名があるのに船型別宿泊区画と宿泊区画のリレーションが存在しないのに最初違和感があり、宿泊区画と船型別宿泊区画にリレーションがない理由について以下のように考えてみましたが、いかがでしょうか。

「前提として、宿泊企画テーブルはフェリーごとに管理を行いたい目的で作成されているものである。宿泊区画から、船型別宿泊区画を参照したいなら主キーである船型番号と宿泊区画番号をどちらも外部キーとして持たないといけないが、それを宿泊区画に持たせてしまうと、結局船型番号ごとの管理になり、フェリーごとに管理したいという目的と反する。
また、フェリーごとの宿泊区画は、船型ごとの宿泊区画よりも必ず後に決まるので、船型別宿泊区画テーブルから、宿泊区画テーブルを参照しに行くことはありえない。」

「前提」と「役割」と「具体例」の前のマークが「&#128313」にエンコードされました。ただの四角のマークつけてただけなので、「&#128313」は四角のマークだと思っていただければと思います。
見づらくて申し訳ないのですがよろしくお願いいたします。

  本当はリレーションシップがあるんだけれど出題意図に選ばれなかった、という事ではないかしら。好意的に見ると、出題者が頑張り過ぎてそうなっちゃった、批判的に見ると、アンチパターン、適性・・・。

> それを宿泊区画に持たせてしまうと、結局船型番号ごとの管理になり、フェリーごとに管理したいという目的と反する。
  外部キーが最優先です。制約が効かない状況下では、少しずつおかしくなって遅かれ早かれデスマーチですね。

  

間違っているかもしれませんが。

R4の図2は、関係スキーマではなくテーブル構造です。
関係スキーマだったら融通が効いて、宿泊区画テーブルに船型番号属性を継承して
船型別宿泊区画からリレーションシップを引っ張ったかもしれませんが、
今回はテーブル構造なので、現実に参照制約を定義できないものは
消し飛んだのかもしれませんね。

似たような論点が、R3 空欄k, l でも見られます。

  もしかして、「テーブル構造は、継承リレーションシップを、諸事情で消去した。」との記述がないから、概念データモデルの継承リレーションシップは引かないという事なのかしら。

船形別宿泊企画と、宿泊企画の関係は「多対多」ですね。

多対多の関係は望ましくないので、そういう関係がでないように間にテーブル挟んで
1対多、多対１になるように設計する、と思います。

多対多のリレーションを引くことはないと思います。

みなさま、ご回答いただきありがとうございます!

>No3. 5.さん
確かに私が記述したような運用ルールを絶対に守り通せば、二つのテーブルで不整合が起きないかもしれないですが、ルールを破れば二つのテーブルの間で不整合が起きますものね..

>No.4さん
お恥ずかしながらこれまで関係スキーマとテーブル構造の違いをほとんど意識してきませんでした..
これが意識できるようになったのはとても大きいです..! ありがとうございます!

そして私も、確かに関係スキーマなら関係が表現されているかもしれないと思いました。

>No.6さん
私が、複合主キーをお互いに持つ同士のエンティティの多対多の関係を見たことがないので、イメージが持てていないのですが、この二つの関係は多対多なのでしょうか..?

私も最初は多対多だと思っていたのですが、

・船型番号はフェリー番号で一意に決まる
・宿泊区画.宿泊区画番号と船型別宿泊区画.宿泊区画は必ず同じにならなければならない
という制約がある中で、

(船型番号と宿泊区画番号)と(フェリー番号と宿泊区画番号)の組み合わせを色々と試してみたところ、これは多対多なのか..?となり分からなくなったのも、質問のきっかけの一つです。

船型番号, 宿泊区画番号  フェリー番号 宿泊区画番号
○ 1, 1 , 1, 1
×  1, 1 , 2, 1(船型別宿泊区画の主キー制約に反する)
○ 2, 2,  2, 2
×  3, 3,  2, 3(フェリー番号と宿泊区画番号の対応が一つ上の行と矛盾する)
×  2, 2,  2, 3(3行目が正しいなら、船型番号2に属しているフェリーは必ず宿泊区画も2になるはずなので矛盾する)

難しい...

↑のコメントについて補足
・宿泊区画.宿泊区画番号と船型別宿泊区画.宿泊区画は必ず同じにならなければならない
これちょっと間違っているというか誤解を生みかねないと思うので、無視でお願いします

私の認識では、
主キーの一部が一致しているが他の主キーは一致していない場合はリレーション不要だと思います。

片方の主キーがもう片方の主キーを包含する場合や、外部キーに持つ場合などにリレーションをつなぐと思います。

私も補足です。
私も、関係スキーマとテーブル構造の違いについて、
あまりよく分かっていません。分かっているのは、

- スーパタイプ-サブタイプの取扱いが違う事例の出題が多い
- テーブル構造のほうがより実装に近い
  （実装のために解決すべき曖昧さの解決を進めないといけないらしい）

ということです。
今回はスーパタイプ-サブタイプではないのですが、
テーブル構造上参照制約を定義しがたいので、
「ああ参照制約の実装は諦めたんだな」と思ったという次第ですね。

RAJAMさんも、ぜひご自身で勉強を進めてみて下さい。

みなさまありがとうございました!