基本情報技術者 試験情報＆徹底解説 -新制度に完全対応-

https://www.fe-siken.com/kakomon/24_haru/pm03.html
こちらの問題の設問３のaで精算表と料理表が必要なのは分かりますが、
明細表はどうして必要なのでしょうか？
どなたか解説よろしくお願いします。

精算表には清算コード・社員番号・日付・精算額のみが記載されています。また、料理表には料理コード・料理名・単価・カロリーのみが記載されています。

清算コードと実際に注文した料理（料理コード）を紐づけるのは明細表なので、明細表も必要になります。

理解できました。ありがとうございます。

これは最初からエンティティが
精算表、料理表、明細表に分けられているから  結合条件として必要なんだ  となるかもしれませんが、実際は
料理表に結合条件があったらそれでいいのか？ということをまず考えないとなりません。
そもそも、この明細表は精算表と料理表の主キーについでに注文数もつけましたよ、という構成ですが、なんでこうなるかを説明するのに  連関エンティティ  という概念が出てきます。

基本情報ではエンティティとかいう単語は出てこないから、応用になってから思い出してほしいのですが、
たとえばある案件レコードの担当者番号が、担当者のマスタテーブルに関連付けられていたら、1対多だよな、っていいますが、
これが
あるテーブルの複数のレコードが別のテーブルの複数のレコードと関連付けられている場合
だと、多対多
のつながりが発生します。
たとえば、多対多のリレーションシップは顧客と製品の間に存在します。
顧客はさまざまな製品を購入でき、製品は多数の顧客によって購入されます。

そんで、だからなんだ？という話になりますが、これが困るのは、
通常、世の中のOracleだとかMySQLだとかのいわゆる  リレーショナルデータベースシステム  では、2つのテーブル間に多対多の関係を持たせられない  のです。1対多はヨユーですけど。

たとえば、同じ請求書番号の請求書が多数あったとしましょう。
その請求書番号を照会されても、どのことかわかりません。

こうした問題を回避するために、いわゆる  連関エンティティ  とか  結合テーブル  とか呼ばれる第三のテーブルを使用して、多対多のつながりを2つの
1対多
のつながりに分割してやらねばならんのです。
ま、連関エンティティなんて単語が出てくるのはデータベーススペシャリストになってからなので、こんなこといってたな、くらいであとから思い出してください。

詳細な説明ありがとうございます。
多対多はだめだから間にテーブルを挟んで精算表1対多明細表  料理表1対多明細表のような感じにするということですね。