概要
・社内資料としてまとめたものをリタッチ
・公式ドキュメントでは解答のみがあり、この記事ではなぜその選択になるのかを解説
・自分が取り組んだ時に、欲しかった解説をイメージして作成

答え：A

解説：多対多のリレーションを行うには、中間テーブル（3つ目のエンティティ）に関係を持ちたいエンティティのIdを持たせるのが効果的です。

B：Orderエンティティの主キーを利用した場合、Orderエンティティに複数のレコードが登録できない。

C、D：関係を持たせることは出来るが多対多を実現できない。

答え：C

解説：エンティティ識別子＝サロゲートキーの考えで良い
サロゲートキーの解説

A、B、D：可能なため、不正解
→データ型を変更できること、手動で指定できること、自動作成されるアトリビュートだが削除可能なことを、それぞれ覚えておきたい。

答え：A

解説：集約関数を使用した場合、集約関数がレコードのアトリビュートになる。

考え方はSQLと同じで、集約した項目と元のアトリビュートの項目は同時に出力できない。

答え：D

解説：
　Priorityがあり → [Order] Only With [Priority]
　Employeeが０人以上の → [Order] With or Without [Employee]

　With or Withoutは、SQLのLEFT JOIN、
　Only WithはINNER JOINの考え。

A：
　[Order] With or Without [Employee]は、LEFT JOINとなるため、
　OrderにEmployeeが紐づいていないOrderも取得する。
　「Employeeがある」とはならないため違う。

B：
　[Order] Only With [OrderStatus]は、INNER JOINとなるため、
　OrderにOrderStatusが紐づくレコードしか取得できない。
　「Statusもない」とはならないため違う。

C：Aと同様

ややこしいが、結合条件とN件以上の条件に切り分けて考えると解きやすい。

答え：B

解説：
　PriorityごとにOrderの数を取得したい。

　→Priority.IdでGroup化し、Order.Descriptionの数を数える（Orderのアトリビュートはどのアトリビュートでも良い）

A：OnlyWithでは、Priorityに対してOrderが0件のPriorityが取得できない

　　Priority.Idではなく、Orderの数を数えたいため違う。

C：Priority.Idではなく、Orderの数を数えたいため違う。

D：Priority.Idではなく、Orderの数を数えたいため違う。