https://www.ap-siken.com/kakomon/03_haru/pm06.html
2点質問があります。

データモデルの→について、1対1や1対多のイメージはできるのですが、0対1のデータは含まれないのでしょうか？（例：会員にはなったが予約をしたことがない、予約はしたけど実績のデータがない）

>LEFT OUTER JOINと考えた方もいるかもしれませんが、図1を見ると貸出予約エンティティと貸出実績エンティティは1対1の関係です。貸出予約エンティティ対応する貸出実績エンティティは必ず存在するため、外部結合にする理由は何らありません。
とありますが、1対0の関係があり得るのであれば外部結合ならCOUNTが変わってくるのでダメな理由として分かりますが、1対1であればLEFT JOINでもいいのではないでしょうか？

表１において，会員表と貸出予約の多重度は次のとおり。
会員(1)――>(多)貸出予約
この(多)は「0以上」を表しています。
貸出予約の側の多重度が0というのは
「会員にはなったが予約をしたことがない」を表しています。

貸出予約と貸出実績の多重度は1対1だと表１に示されていますが，
貸出予約(1)――(0..1)貸出実績
が正しいと私は考えます。0または1ということです。
貸出実績の側の多重度が0というのは
「予約はしたけど貸出実績はない」を表しています。

ありがとうございます。
問題文がイマイチ腑に落ちませんが、そういうもんだと割り切ります。

「貸出予約」と「貸出実績」が１対１の関係なのは、
『予約＝空き車両を押さえる』ことなので、予約した時点で、
「車両ID」を持つ「貸出実績」データも作成される、と考えるべきかと思います。
（※実績時刻はNull）

> 『予約＝空き車両を押さえる』ことなので

というのは良くない設計だと考えます。

この予約時刻に，この駐車場IDの，この車種IDの
（これらはすべて「貸出予約」表の項目です）
車両が残っているなら
「どの車両IDでもいいから」貸出可能とするのが，良い予約の設計だと考えます。

予約の時点で車両IDと紐付けてしまうと，
・その車両は予定では返却されているはずだったが延長でその車両が駐車場にない
・しかし，車種IDは同じで車両IDが異なる別の車両は駐車場にある
という状態で貸出ができなくなります。

ただ。
試験問題の作成者は，こんなことは気づいていると思うんです。
私が気づいていないだけで，1対1とした理由があるんじゃないかな，とも思っています。

予約した時点で「車両ID」を持つ「貸出実績」データも作成される場合は
わざわざ別テーブルに分ける意味も分からないですしね...
貸出予約(1)――(0..1)貸出実績を1対1というのが普通なのかが疑問ですが。
また、AP公式の回答が「INNER JOIN」を回答としている以上は、やはり外部結合すると不都合があるデータが出てきてしまうことだと思うので、そういう意味でも(1)――(0..1)だとも思います。
この問題の解説もややこしくしている要因の一つですね。

>貸出予約(1)――(0..1)貸出実績を1対1というのが普通なのか
それはふつうです。0を含むとか含まないとかいうのが継ぎ足されますが（たまに、ゼロを含む含まないのカーディナリティの問題があるように）。仮にこれが入庫のヘッダと出庫のヘッダが1対1（だいたいそう）でも、入庫が発生するのは出庫より前or出庫と同時じゃなくて出庫より後なわけで、シーケンス的には出庫しかない時間ってのはふつうにあるわけです。貸出予約の段階では「駐車場」と「車種」しか決まらないわけで、そこから「車両ID」を決めるタイムラグがどうやっても発生するわけだから、アトミックに貸出予約と貸出実績は同時には作れないだろう、と考えられるわけです。でも、ゼロを含むからといって、1対1と言わないわけではない、というのは入庫のヘッダと出庫のヘッダの例でわかるはずです。
1対1で外部結合で不都合になるのは、たいてい片方しかない狭間のタイミングです。

※正確には、0を含む含まないはオプショナリティという概念なので、1対1とか1対多の概念であるカーディナリティとは別口の問題だから、ふつう、というのは端的には概念の違いによる。