応用情報技術者 2013年 秋期 午後 問05

解答の論理構成

1. a はエンティティ “レンタルビデオマスタ” の主キー
   • 表1‐属性名の規則に「マスタ系エンティティの主キーとなる属性は、エンティティ名から “マスタ” を取り除き、末尾に “ID” を追加」とあります。
   • よって “レンタルビデオマスタ” → “レンタルビデオ”＋“ID” ＝ レンタルビデオID。
2. b はエンティティ “貸出明細” に存在する外部キー
   • 表1‐属性名の規則に「外部キーとなる属性は、対応する主キーの属性の名前と同じ」とあります。
   • 1対多の関連 “レンタルビデオマスタ ──> 貸出明細”（線上に d）に対応するので、外部キーも レンタルビデオID。
3. c は “貸出番号” を主キーにもつトランザクション系エンティティ
   • 表2「レンタルビデオ貸出管理」の説明に「c エンティティに貸出番号、会員ID、貸出日を登録」とあります。
   • 表1‐属性名の規則に「トランザクション系エンティティの主キーとなる属性は、エンティティ名の末尾に “番号” を追加」とあるため、主キー “貸出番号” からエンティティ名は “貸出”。
   • よって c は 貸出。

誤りやすいポイント

• 主キー作成時に “マスタ” を除かず “レンタルビデオマスタID” としてしまう。
• トランザクション系でも “ID” を付けて “貸出ID” と誤記する。
• 外部キーの破線下線を忘れ、主キーと同じ実線下線で書いてしまう。
• “c” を “貸出情報” や “貸出ヘッダ” と補足語を付けてしまう（命名規約は10文字以内）。

FAQ

解答の論理構成

1. 外部キー規約の確認
   表1には「外部キーとなる属性は、対応する主キーの属性の名前と同じとする。」とあります。
   したがって、あるエンティティに他エンティティの主キーと同名の列が存在すれば、そこには“参照される側（1）”と“参照する側（多）”の関係が成立します。
2. d（レンタルビデオマスタと貸出明細）の判定
   • 機能概要には「貸出時には、レンタルビデオマスタエンティティの貸出ステータスを“貸出中”に変更し、…貸出明細エンティティに貸出情報を登録する。」と記述されています。
   • 一つのレンタルビデオは貸出と返却を繰り返すため、貸出明細に複数行が蓄積される一方、貸出明細は必ず1本のレンタルビデオに紐付きます。
   • よって関係は「レンタルビデオマスタ（1）→貸出明細（多）」となり、d は “→” です。
3. e（貸出明細と c エンティティ）の判定
   • 機能概要の同一段落に「cエンティティに貸出番号、会員ID、貸出日を登録するとともに、貸出明細エンティティに貸出情報を登録する。」とあります。
   • “貸出番号”が c の主キー、同名列が貸出明細側にも存在することから、1回の貸出処理（＝1つの貸出番号）に対して複数の明細行が発生する仕組みです。
   • 従って関係は「c（1）→貸出明細（多）」ですが、図中では矢印が左向きに描かれるため e は “←” となります。

誤りやすいポイント

• 「外部キーがある側が“多”」を見落として逆方向に矢印を書いてしまう。
• d と e をどちらも同じ向きにしてしまい、レンタルビデオと貸出の粒度差を混同する。
• 図全体のスペース配置を見て方向を決めてしまい、論理（1対多）を後回しにする。

FAQ

解答の論理構成

• 【問題文】では、予約機能を実現するために「貸出予約エンティティ」を追加すると述べています。そのエンティティには「会員ID」が外部キーとして示されており、もう一つの外部キーが未決定でした。
• 予約は “会員が借りたいタイトル” を対象に行うため、予約レコードにはどのタイトルに対する予約かを示す列が必須です。
• タイトルを識別する主キーは、図1の「タイトルマスタ」エンティティ内の「タイトルID」であると示されています。
• 表1の命名規約には「外部キーとなる属性は、対応する主キーの属性の名前と同じとする。」と明記されています。
• したがって、貸出予約エンティティの外部キー名も主キーと同じ「タイトルID」となります。
• 外部キーであることを示すため、図1の凡例に倣い “破線下線” を付与します。

誤りやすいポイント

• 「レンタルビデオID」と解答してしまう
  → 予約は個別のディスク（物理媒体）ではなく “タイトル” 単位で受け付けるため誤りです。
• 命名規約を無視して「タイトルコード」など別名を付ける
  → 外部キーは主キーと同じ名前を使う規約に反します。
• 外部キーであることを示す破線下線を忘れる
  → 受験生が記法ミスで減点されやすい典型例です。

FAQ

解答の論理構成

1. 連結条件 g
   問題文では「タイトルマスタ」と「貸出予約」の両テーブルを INNER JOIN していると記載されています。INNER JOIN では“互いの主キー／外部キーが一致する列”を指定しなければ正しい結合になりません。予約情報には「タイトルID」が保存され、タイトル情報にも同じ列が存在するため

1. 集計列 h
   　目的は「予約日時が最も早い予約者」を求めることです。問題文中に

1. サブクエリの抽出条件 i
   　サブクエリ側では「検索対象タイトル」と「予約ステータス＝'予約中'」で絞り込み、その中で最小の予約日時を選定しています。タイトルの一致を示す列は「貸出予約.タイトルID」です。問題文で「“:予約タイトルID”はバーコードで読み取ったレンタルビデオのタイトルIDを格納した埋込み変数」と説明されているため、比較式は

誤りやすいポイント

• 結合条件を「タイトル名」で書いてしまう
  タイトルは重複する可能性があるため主キーである「タイトルID」を使う必要があります。
• 集約関数で MIN(*) や FIRST を選択してしまう
  SQL 標準で日時の最小値を取る関数は MIN です。FIRST は RDBMS 依存の擬似関数で誤りになります。
• サブクエリ側で 貸出予約.予約ステータス = '予約中' を書き忘れる
  ステータス条件を漏らすと「既に連絡が完了した予約」まで候補に含まれてしまい、仕様を満たせません。

FAQ

解答の論理構成

1. 【問題文】では、貸出可能連絡時に表示する予約者を
   「予約日時が最も早い予約者の連絡先が画面に表示される。」と定義しています。
2. その SQL は WHERE 句で
   貸出予約.予約ステータス = '予約中'
   を条件にしているため、抽出対象は “予約中” のレコードだけです。
3. 一方、連絡後も予約ステータスを変更する仕様はなく、【問題文】には
   「店員がこの予約者に連絡できた場合には、予約貸出待ち棚に格納」
   とあるだけで、状態遷移が示されていません。
4. その結果、同じタイトルを再度スキャンすると、連絡済であっても依然 “予約中” のままなので、 先ほどと同じレコードが再び最小予約日時として抽出されます。
5. 以上より「同じタイトルが返却される度に、連絡先として連絡済の会員が出力される」という問題が発生します。

誤りやすいポイント

• 予約ステータスが変わらないことに気付かず、「連絡後は自動で除外される」と思い込む。
• SQL の = '予約中' がフィルタ条件であることを見落とし、最小予約日時だけに注目してしまう。
• 取置き棚や予約貸出待ち棚の物理的運用に気を取られ、データ更新の欠落を意識しない。

FAQ

解答の論理構成

1. 問題の前提
   本文には「①予約者への貸出可能連絡時と予約貸出時に問題が発生することがある」とあります。この“問題”を特定するのが問われています。
2. 予約後の連絡手順
   予約ビデオが返却されたら、(3) 貸出可能連絡で「予約日時が最も早い予約者の連絡先が画面に表示される。店員がこの予約者に連絡できた場合には、予約貸出待ち棚に格納」します。ここでは連絡できたか否かだけを扱い、予約ステータスは依然として“予約中”のままです。
3. 予約貸出しの判定条件
   (4) 予約貸出しでは「この会員がこのレンタルビデオのタイトルを予約している（貸出予約エンティティの予約ステータスが“予約中”である）場合」に貸出処理を行います。つまり“連絡済みかどうか”は判定に使われていません。
4. 発生し得る事象
   そこで、連絡を受けた会員Ａが来店する前に、同じタイトルを予約していた会員Ｂが来店すると、Ｂも“予約中”なので貸出要件を満たしてしまいます。結果として、Ａは連絡を受けたのに借りられず、Ｂは連絡を受けていないのに借りられる――これが運用上の問題です。
5. 模範解答との一致
   よって模範解答「予約はしているが、連絡をもらっていない会員に対して貸出をしてしまう。」が導かれます。

誤りやすいポイント

• 「最も早い予約者」に限定するのは連絡時だけで、貸出時の条件と混同しやすい。
• 連絡可否に応じて棚を変更する動きに注目が集まり、予約ステータスが更新されていない事実を見落としやすい。
• 「貸出ステータスが“予約済”」と「予約ステータスが“予約中”」の二つのステータスを混同しがち。

FAQ