https://www.ap-siken.com/s/kakomon/03_aki/pm06.html

設問2(1)の一括購入数量のニュアンスがわかりません。一括購入エンティティは書籍エンティティと企業エンティティの連関エンティティとなっており、本来の主キーは企業IDと書籍IDですが、一括購入IDがそれらの代用キーになっているという構成になっているように見えます。

そのため、一括購入数量という属性には、ある会社がある書籍を何冊一括購入したかという値が入ると思うので、例えば従業員分購入したとすると、500等の値が入り、手順1では500ぐらいの値が返ると予想されます。

対して、一括購入割当エンティティの方は、一括購入ID(企業ID+書籍ID)に加え、社員IDが主キーとして入っているので、手順2では基本的にはある社員に一括購入IDが割り当たっていれば1、いなければ0が返ると思います。

しかし、この考え方だと手順3では基本的に一括購入数量>手順2の値となるので、ほぼ毎回手順4に移行することになりますし、一度割り当てた一括購入IDを同じ社員に割り当てるケースも多発すると思うので、おそらく私の一括購入数量の捉え方が間違っているのだと思います。ただ、自分ではどう間違っているのかわからなかったのでご教授いただけると助かります。

>一括購入数量という属性には、ある会社がある書籍を何冊一括購入したかという値が入ると思うので、例えば従業員分購入したとすると、500等の値が入り、手順1では500ぐらいの値が返ると予想されます。
この考えは合っています。一括購入数量＝一括購入した冊数とそのまま捉えていいでしょう。

>一括購入割当エンティティの方は、一括購入ID(企業ID+書籍ID)に加え、社員IDが主キーとして入っているので、手順2では基本的にはある社員に一括購入IDが割り当たっていれば1、いなければ0が返ると思います。
ここがおかしいです。手順2ではCOUNTを使って、一括購入割当をした社員の数を取得します。例えば社員50人に割当をしていれば、一括購入割当テーブルには該当するレコードが50件存在するはずなので、手順2のSQLの実行結果は50となります。一括購入割当エンティティについての理解が誤っているように思われます。

chihiroさん、ありがとうございました。手順2の考え方は誤解していました。

>手順2ではCOUNTを使って、一括購入割当をした社員の数を取得します。例えば社員50人に割当をしていれば、一括購入割当テーブルには該当するレコードが50件存在するはずなので、手順2のSQLの実行結果は50となります。一括購入割当エンティティについての理解が誤っているように思われます。

確かにこうなりますね。しかし、そうなると手順3の判定というのは、全体の購入数量>実際に割り当てた社員数という判定になるので、この時点では、割り当てようとしている社員が未割当か割当済かの判定はできないと思われます。

仮に割当済の社員が誤ってもう一度割当してしまうケースがあったとして、全体の購入数量>実際に割り当てた社員数という状況であった場合、一旦手順4までは移行することになると思います。その場合、一括購入割当エンティティに重複してインサートしようとするも、主キー(一括購入ID+社員ID)が一意にならないのでエラーして結果重複せずに済むみたいな動きになるという解釈でよろしいのでしょうか。ご教授願います。

>しかし、そうなると手順3の判定というのは、全体の購入数量>実際に割り当てた社員数という判定になるので、この時点では、割り当てようとしている社員が未割当か割当済かの判定はできないと思われます。
手順3は特定の一括購入した書籍が全て割当済かどうかを判定するだけなので、この時点では社員が割当済か未割当かの判別はできません。

>仮に割当済の社員が誤ってもう一度割当してしまうケースがあったとして、全体の購入数量>実際に割り当てた社員数という状況であった場合、一旦手順4までは移行することになると思います。その場合、一括購入割当エンティティに重複してインサートしようとするも、主キー(一括購入ID+社員ID)が一意にならないのでエラーして結果重複せずに済むみたいな動きになるという解釈でよろしいのでしょうか。
割当済の社員が誤ってもう一度割当してしまうケースについては仰る通り、主キー制約によってレコードの挿入はできません。未割当の場合は普通に挿入されます。

詳しい解説ありがとうございました。助かりました。